Jump to content
¯\_( ツ)_/¯
  • TAD GROUP are currently hiring penetration testers. Please read the topic in Career Central subforum.
  • Sponsored Ad

Recommended Posts

Създадох един прост 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 и потвърдете отново изпращането на заявката. Резултатите ще са различни. 

  • Like 1

Сподели публикацията


Адрес на коментара
Сподели в други сайтове
<?php

session_start();
$_SESSION['errors'] = [];

class CSRF
{
	public static function generateToken()
	{
		return $_SESSION['token'] = md5(time()) . uniqid();
	}

	public static function validateToken()
	{
		return $_POST['token'] === $_SESSION['token'];
	}
}

if (isset($_POST['submit'])) {
	if (!CSRF::validateToken()) {
		$_SESSION['errors'][] = "Invalid CSRF";
	}
}

?>

<form method="post">
	<?= end($_SESSION['errors']) ?? ''; ?>
	<input type="hidden" name="token" value="<?= CSRF::generateToken(); ?>"/>
	<input type="submit" name="submit" value="Test"/>
</form>

 

Моето предложение как това би трябвало да изглежда. :D

Редактирано от DvDty

Сподели публикацията


Адрес на коментара
Сподели в други сайтове

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

Сподели публикацията


Адрес на коментара
Сподели в други сайтове
Quote

Проблема на цялата тази работа е, че е ефективна ама не съвсем.

 

Защо не?

Сподели публикацията


Адрес на коментара
Сподели в други сайтове
преди 3 минути, DvDty написа:

 

Защо не?

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

Сподели публикацията


Адрес на коментара
Сподели в други сайтове

CSRF предпазва от открадване на сесия. Ако нямаш защитата и изпълниш въпросителен файл (което не трябва да се прави на първо място, но 50% от потребителите биха го направили така или иначе) може да стане голямо мазало. Защитата е измислена заради това, и работи.

Сподели публикацията


Адрес на коментара
Сподели в други сайтове
преди 6 минути, DvDty написа:

CSRF предпазва от открадване на сесия. Ако нямаш защитата и изпълниш въпросителен файл (което не трябва да се прави на първо място, но 50% от потребителите биха го направили така или иначе) може да стане голямо мазало. Защитата е измислена заради това, и работи.

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

Сподели публикацията


Адрес на коментара
Сподели в други сайтове

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

  • Like 1

Сподели публикацията


Адрес на коментара
Сподели в други сайтове
На 15.04.2018 г. at 13:05, DvDty написа:

CSRF предпазва от открадване на сесия. Ако нямаш защитата и изпълниш въпросителен файл (което не трябва да се прави на първо място, но 50% от потребителите биха го направили така или иначе) може да стане голямо мазало. Защитата е измислена заради това, и работи.

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

Сподели публикацията


Адрес на коментара
Сподели в други сайтове
  1. Не мисля, че мога да обясня добре, колко други са го правили. Има достатъчно казано по тази материя в интернет.
  2. В темата, никой друг не е проявил интерес, има ли смисъл?

Сподели публикацията


Адрес на коментара
Сподели в други сайтове
На 20.04.2018 г. at 1:01, DvDty написа:
  1. Не мисля, че мога да обясня добре, колко други са го правили. Има достатъчно казано по тази материя в интернет.
  2. В темата, никой друг не е проявил интерес, има ли смисъл?

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

Сподели публикацията


Адрес на коментара
Сподели в други сайтове

Има доста начини за извършване на CSRF. XSS е един от тях. Не мисля, че трябва да се говори едновременно да тях до такава степен. Ще заблудиш някой, че едното не същяествува без другото.

Сподели публикацията


Адрес на коментара
Сподели в други сайтове
преди 4 минути, DvDty написа:

Има доста начини за извършване на CSRF. XSS е един от тях. Не мисля, че трябва да се говори едновременно да тях до такава степен. Ще заблудиш някой, че едното не същяествува без другото.

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

Сподели публикацията


Адрес на коментара
Сподели в други сайтове
Quote

Напротив, XSS не е CSRF!!! Не извъртай нещата.

Не съм казвал такова нещо.

 

Quote

Кражбите на сесии (бисквитки) са XSS

Не. XSS може да бъде изполван за такава цел.

 

Quote

 С какво класовете, които сме създали по-горе ни защитават от XSS?

Не защитават. И никой не претендира, че го правят. Те са просто примери за CSRF токени към форма.

Сподели публикацията


Адрес на коментара
Сподели в други сайтове

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

Сподели публикацията


Адрес на коментара
Сподели в други сайтове
Quote

Не ми обяснявай на мен какво е XSS

Не съм сългасен с някой от нещата в последния коментар, но щом си казал, спирам да пиша :) 

Сподели публикацията


Адрес на коментара
Сподели в други сайтове
преди 11 минути, DvDty написа:

Не съм сългасен с някой от нещата в последния коментар, но щом си казал, спирам да пиша :) 

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

Сподели публикацията


Адрес на коментара
Сподели в други сайтове

И нека и още едно некомпетентно мнение от мен.

CSRF се използва за да се предпазят форми със критични функции - например(примрите са до някаква степен фиктивни, a критични са в частен случай за уеб апликацията):

- CSRF за логин забавя брутфорцинга и енумерацията на потребители на уеб сайта - но това не е добър пример;

- ако например имаш уеб сайт с административен панел и ТИ си админ, ако функцията и форма 'Добави Администратор' не е предпазена и рекуеста се изпраща към ctf.bg/admin/adduser.php?u=d3k4z&pass=12345 някой може да те social engineer-не да кликнеш на линк и автоматично да добавиш новия администратор. Как става това - ако все още имаш кукито от последния ти login при посещение на ctf.bg ще бъдеш автоматично логнат, и следва изпълнение на функцията.

 Потобни критични функции са  тези за:

- Транзакции на пари;

- Добавяне на потребители или изтриване на данни от базата;

Fun Fact: Преди няколко години тествах една вътрешна система за HR и функцията за добраволно напускане не беше предпазена с CSRF т.е. ако накараш някой да кликне на линка и може да напусне компанията 'доброволно'.
 

 

Сподели публикацията


Адрес на коментара
Сподели в други сайтове

Създайте нов акаунт или се впишете, за да коментирате

За да коментирате, трябва да имате регистрация

Създайте акаунт

Присъединете се към нашата общност. Регистрацията става бързо!

Регистрация на нов акаунт

Вход

Имате акаунт? Впишете се оттук.

Вписване

  • Потребители разглеждащи страницата   0 потребители

    No registered users viewing this page.

×

Important Information

За да посещавате този уебсайт е необходимо да се съгласите с Terms of Use. We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.