freeman987

С примера ли ми не си съгласен? Нито веднъж не се обоснова, а все си критичен.

Не ми обяснявай на мен какво е XSS, по-добре от теб знам разликите. Ясно е, че класовете ни са пример за генериране на ключове против CSRF, но от много коментари насам се опитвам да ти обясня, че ти даде грешен пример със кражбата на сесии. Както и да е, явно не вникваш в нещата, които ти казвам. Ще ти дам много прост пример с една форма тук: http://jsfiddle.net/yGCSK/240/ Натискайки "Изпращане" ти правиш две отделни атаки. Първо правиш CSRF, защото формата не се намира на сървъра на google.bg, а физически е на jsfiddle.net . От физическото място се изпраща заявка към сървъра на гугъл и вече следва обработката от страна на техният сървър. Втората атака е опит за инжектиране на скрипт и изпълняването му в браузъра. Уви не минава (филтрира се добре) и ни връща резултат. Класовете ни се опитват да защитят точно от такова изпращане на заявки от други места различни от собственият ни сайт и това е същината на CSRF уязвимостите.

Напротив, XSS не е CSRF!!! Двете атаки са съвсем отделни неща. Може да се комбинират, но определено не са едно и също и определено могат да съществуват самостоятелно! Не извъртай нещата. Обясних ти по-горе къде ти сгреши. Кражбите на сесии (бисквитки) са XSS, поради естеството на работа с браузъра и използването на уязвимости при филтрирането на входящите от формата данни. CSRF изобщо не го интересуват входящите данни дали се филтрират или не. Това е атака от място различно от страницата на която си създал формата. CSRF може да подава спам и каквото още е позволено към формата, но го прави от място различно от оригиналната страница. Тоест от отдалечено място прави post или get заявка към сървъра ти. С какво класовете, които сме създали по-горе ни защитават от XSS? Не заблуждавам никой, че двете неща не могат едно без друго, обяснявам лично на теб разликите между двете атаки. Кражбата на бисквитки и използването им за възстановяване сесията на потребител Х е уязвимост, която означава съвсем друг проблем за решаване. Това не е CSRF.

Аз също чета Вашите теми и постове с охота, както и виждам, че има стабилни колеги тук. Проблема е, че типично по Български сме противоположни на световната идея за open data. Тук върлуват клишета, които даже не се поставят под въпроситела... Как може да се създава някакъв проект без да си зададеш фундаменталните за него въпроси? Както и да е. Ако е възможно да поставите задачата тук, за да си размътим мозъчетата и ние? Чисто от любопитство питам, не с друга цел! Впрочем, надявам се, че не е проблем да пиша и на "Ти", просто защото приемам комуникацията за не формална. Идеята ми е, че тук дори да не се познаваме лично на Вие се коментира доста по-спестено спрямо обясненията на някоя тема. Получава се разделение на стиловото обръщане и е малко трудоемко за читателите да сменят постоянно формите на обръщение от Вие на Ти.

Паралелните процеси са наистина една много интересна тема за обсъждане, но не е за този форум. Тук не се търси идейна производителност, която впрочем може да се използва много приятно за обработване на големи масиви и изчакване на информация, а се търси нещо от сорта на Havij. Ръгай url-то с GET параметър накрая и се моли SQLi да проработи. След това следва едно хвалене, едни теми как се "хаква" сайта и други. Реално не се разбира защо се е достигнало до там. Използвам паралелни процеси с PHP. Нужни са ми за различни проекти и по тази причина се интересувах доста от материята, поне за езика, но тя динамиката и алгоритъма важи и за много други езици.

Не можеш да го обясниш, защото говориш за съвсем друг вид атака. Кражбата на сесия се прави посредством XSS и инжектиране на зловреден код. Има смисъл, защото хората масово бъркат нещата, както в случая и ти сбърка. CSRF (Cross Site Request Forgery) грубо се превежда "Кръстосана фалшива заявка за сайт". XSS (Cross-Site Scripting) е нещо съвсем различно, като атака. CSRF token се опитва да защити формата от изпълнение на място различно от страницата на твоят сайт. XSS филтрирането се опитва да те защити от инжектирането на не регламентиран код: "<script>alert('XSS атака')</script>". XSS може да доведе до кражба на сесията (по-скоро за бисквитки говорим но и това не е грешно по ред причини), което ще афектира директно върху потребителите. За разлика от него CSRF може да доведе до много различни ситуации. От проблеми за потребителите до проблеми за приложението. И двете атаки са опасни, често бъркани и много грешно разбрани. Надявам се, че с новополучената информация ще се замислиш дали моят и твоят код в тази си форма, реално защитават от CSRF. Аз мога да обясня до къде се простира предела им, но не смятам, че е редно да го правя, щом не се разбира работата и целта им.

Виждам, че не пожела да обясниш, как така се краде сесията на потребителя, но харесваш коментарите ми тук. Много интересно ми стана това твърдение, но не пожела да защитиш думите си. Все още не съм обяснил, защо защитата не работи, но наистина на хората тук не им се слуша за такива "модерни" проблеми. Дай им SQLi да си дъмпват старите сайтове или умрели теми за Kali Linux, а да не говорим и за социалните мрежи. Тази тема е актуална и в момента се обсъжда от много специалисти в областта с търсене на по-адекватно решение, без да се натоварват потребителите. Уви, в този форум не се обсъждат нови неща.

Явно темата е безинтересна тук, въпреки, че защитата е масова в момента.

Дай повече информация за проекта. Ако желаеш може и на лично да ми пишеш.

Много интересен въпрос ми зададе. Благодаря ти. PHP по принцип не изпълнява така наречените мулти нишки. Въпреки това, библиотеката CURL предлага изпращането и обработването на мулти заявки създавайки дърво съдържащо задачите чакащи отговор от отсрещната страна. Понеже визира, че въпроса ти не е за тези многонишкови процеси, ако съм те разбрал правилно, то ме питаш дали един клас може да се изпълнява паралелно (успоредно) на две места. Създаваш си класът parallel.php, създаваш и две страници index1.php и index2.php. Инклудваш в индекс 1 и индекс 2 класът parallel и му правиш по една инстанция. Викаш си изчислителните методи и принтираш визуализация. Отиваш в браузъра и отваряш заедно индекс 1 и индекс 2, като те стартират всяка със своята логика и се получава паралелен процес. Оставяйки настрана това трудоемко обяснение на паралелното изпълнение, PHP предлага и библиотеката Thread: http://php.net/manual/en/class.thread.php, която отговаря за изпълняването паралелни процеси. Има и доста уроци за решаване на горепоставеният казус, но все още PHP няма тази мощ, която C++ примерно има в това отношение. Все пак, тук има и съществена разлика. В WEB основно се работи с ограничено процесорно време на ползване и честно казано, не е удобно за такива процеси в по-голям мащаб. Може би някакви по-лесни неща за решаване, но всичко това при условието, че говорим за една инстанция на класът. Ако в една страница направим две инстанции на един класс всяка работи сама за себе си с подадените параметри за обработване, но ще трябва да се изчака първата да извърти и върне резултат, след което втората инстанция да го стори. Все пак логиката за последовапелно процедурно изпълнение на кода си е заложена в PHP. Асемблер също има последователна структура на изпълнение зависеща от това коя команта над, под или преди и след какво се намира. Вече функцииите се дефинират и се викат в последствие, но няма да навлизаме в излишни обяснения. Дано правилно да съм ти разбрал въпроса, ако ли не те моля за извинение, просто съм уморен в момента и може да не съм схванал, какво имаш в предвид точно.

Аз пък мога да им бъда в пъти по-полезен от това. Прочети тук: https://www.xakep.bg/forum/topic/268-лични-данни/

Разбрах те какво имаш предвид, но те моля да обясниш на читателите, какво имаш предвид под кражба на сесия. Ще обясня и аз защо смятам, че до голяма степен е неефективна защита при по-кадърен нападател.

А защо да? Защитава те до един момент от там нататък е безполезна. Естествено, е много важно кака е изпълнено структурирането на сайта, но и форума тук е уязвим, въпреки, че има подобна по вид и близка до изпълнение защита. От какво е създадена да те предпазва? Идеята е, формата да бъде поствана само от твоята страница, не от друго място или от локален хост на някоя машина. Давам ги за пример само, не защото непременно трябва да е от там.

Въпрос на гледна точка. И двата кода са повече от прости и идеални за обяснение на защитата. И двата кода са еднакво ефективни и еднакво уязвими. Типът на защитата е един и същ спрямо логиката. Този вид е и първообраза на CAPTCHA. Зависейки от логиката на приложението няма проблем да се използват статични методи, Сингълтон или обикновен обект. Никой не те задължава да работиш с една инстанция на обекта, просто ще променяш имената на сесията. Както и да е. Вариациии на защитата има всякакви. Дали ще са с бисквитки, сесии или запазване в базата с данни това са типове на защитата с различна степен на трудност. Проблема на цялата тази работа е, че е ефективна ама не съвсем. Много зависи от общото изпълнение на приложението.

Създадох един прост PHP код с масово използвана вид защита от CSRF атаки в интернет. За да го активирате ще Ви е нужен инсталиран Localhost с PHP. XAMPP е идеалният инструмент за целта. Самият код е опростен с цел по-лесна четимост и обсъждане на проблема. Ще поставя кода тук, но няма да го обсъждам още. Бих желал да видя вашето мнение отностно него и до къде според Вас се простира неговата сила и какви са слабостите му. Идеята ми е да се обсъди една от масовите защити против тази атака и да се постави пред читателя отговор на дилемата дали да я използва или не. Ще изчакам първите коментари и при достатъчен интерес ще обясня до къде се простира защитата. <?php session_start(); class CSRF { private $token; public function set() { $this->token = md5(uniqid(rand(), true)); $_SESSION["token"] = $this->token; return $this; } public function get() { return $this->token; } public function clean() { $_SESSION["token"] = false; $this->token = false; return $this; } } if (isset($_POST['submit']) and $_POST['token'] === $_SESSION['token']) { print "<font color='green'>Valid post token ".$_POST['token']." === session token ".$_SESSION['token']."</font>"; } else { print "<font color='red'>Invalid post token ".$_POST['token']." === session token ".$_SESSION['token']."</font>"; } ?> <form action="" method="post"> <input type="hidden" name="token" value="<?php print (new CSRF)->set()->get(); ?>" /> <input type="submit" name="submit" value="Тест" /> </form> При натискане на бутона се изпраща генерираният и поставен в скритото поле ключ за сравнение с този запазен в сесията. Натиснете бутона и за да Ви стане по-ясно рефрешнете с F5 и потвърдете отново изпращането на заявката. Резултатите ще са различни.