* XSS – вмъкване на нежелан код

Публикувано на 06 декември 2008 в раздел ПТСК.

Cross Site Scripting (XSS) е атака, която използва уязвимост на приложението и “вмъква“ нежелан код, който се изпълнява в браузъра на крайния потребител. Най-общо казано атаката цели да намери място в програмата, в което се отпечатва стойността на дадена променлива и не се проверява коректно нейното съдържание. Обикновено в съдържанието на променливата се записва HTML, XHTML, JavaScript, ActiveX, VBScript, Flash, и др видове изпълним код. Възможностите за цел на атаката може да са много – придобиване на достъп до защитена зона на сайта (чрез постигане на session hijacking), подвеждане на потребителя да въведе информация към трети източник (physhing), инсталиране на нежелани програми на компютъра на потребителя (virus, worm, trojan, …), и др. Според изследване на Symantec около 80% от проблемите в сигурността на уеб-базираните приложения са свързани именно с XSS уязвимости. Също така се прави статистическо предположение, че поне 70% от динамичните уеб-сайтове в световната мрежа притежават такава уязвимост. Обикновено крайния потребител не може да намери визуален белег, по който да разкрие атаката.

XSS атаките са най-общо три вида:
1. Директни: Атакуващият предоставя връзка или друг вид „маскиран“ код към клиента. Когато клиента последва такава връзка той попада на оригиналният уебсайт на дадената услуга, но вече с модифициран от атакуващия код. Възможно е и възползването от уязвимост на софтуера, с който жертвата преглежда подаденото му съобщение, с цел атакуващия да добие достъп до неговата административна част. Директните атаки се реализират най-често чрез изпращане на писма по електронната поща към жертвата или чрез съобщения в различни чат приложения.
2. Статични: Атакуващият успява да вмъкне нежелания код в база данни и само изчаква жертвата сама да отвори уязвимата страница. Това са най-честите атаки при т.нар. социални мрежи – форуми, блогове, дискусионни групи, и т.н.
3. DOM: Това са XSS атаки от т.нар. локално ниво. Обикновено се използва уязвимост в скрипт на продукта, чрез който самият софтуер да предизвика директна XSS атака към жертвата.

Почти няма приложение в Интернет, което да няма или да не е имало XSS уязвимост. В днешно време, с навлизането на все повече технологии като Action Script на Flash или AJAX скриптовете, XSS атаките все повече добиват популярност. На практика всички тези проблеми се зараждат в момента, когато сървърите придобиват функционалност за директно изпълнение на код при клиента (напр. JavaScript).

Нека като пример да разгледаме следната елементарна форма:

<html>
<head>
	<title>WorldBank.dom XSS vulnerable page</title>
</head>
<body>
<?php
	echo '<form action="xss.php" method="POST">';
	echo 'data:';
	echo '<input type="text" name="data">';
	echo '<br><input type="submit" name="submit">';
	echo '</form><br><br><br>';
	if( isset($_REQUEST['submit'])){
		echo $_REQUEST['data'];
	}
	else {
		echo 'Type something';
	}
?>
</body>
</html>

Удебеленият ред „echo $_REQUEST['data']“ демонстрира XSS уязвимост. Очевидно ние отпечатваме на екрана директно всичко, което е въведено от формата, без да правим никакви проверки. Въведете обикновен текст (например думата „test“) и тествайте приложението. Нищо не подсказва, че има проблем. Следващият път въведете някакъв изпълним код, например:

	test<Script language='JavaScript'>alert("XSS HACK")</Script>

Отново ще се отпечата думата „test“, но вече ще имаме и изпълнен java script, което определено не е желано!

Първото нещо, което привлича вниманието (но не е непременно свързано с XSS атака), е използването на $_REQUEST, вместо $_POST. Много програмисти обичат да смесват използването на POST с GET заявки и за улеснение използват общият $_REQUEST масив. Това е първа и много основна грешка, която не трябва да се допуска! Опитайте се да отворите следния адрес:

	http://worldbank.dom/xss.php?data=test&submit=1

Ще забележите, че все едно сме въвели текст във формата, а ние все още не сме го направили. Затова избягвайте програмна логика, използваща $_REQUEST.

Сега да се фокусираме върху самата XSS атака. Първата стъпка е да забраним извеждането на какъвто и да е HTML код на екрана на потребителя. Първият подход е да използваме готови функции на езиците за програмиране. Например в PHP съществува функция htmlentities, която подменя всички специални HTML символи с техни еквиваленти за отпечатване на екрана (например ‘<’ се заменя с ‘&lt;’):

<html>
<head>
	<title>WorldBank.dom XSS vulnerable page</title>
</head>
<body>
<?php
	echo '<form action="xss.php" method="POST">';
	echo 'data:';
	echo '<input type="text" name="data">';
	echo '<br><input type="submit" name="submit"';
	echo '</form><br><br><br>';
	if( isset($_POST['submit'])){
		$data = htmlentities($_POST['data'], ENT_QUOTES, 'UTF-8');
		echo $data;
	}
	else {
		echo 'Type something';
	}
?>
</body>
</html>

Опитайте отново XSS атаката описана по-горе. Ще забележите, че тя няма вече да работи.

Вторият подход е да направим стриктно филтриране, както беше демонстрирано с regular expressions в статията за препълване на буфери. Опитайте – напишете горния пример така, че да позволява въвеждането само на букви (a-z, A-Z) и цифри. Комбиниран подход между тези два естествено е най-правилното решение!

Така дотук изведохме две основни правила – не приемайте нефилтрирани данни и не отпечатвайте нефилтрирани данни. За съжаление уеб сайтовете разчитат изключително много на визуализация на информацията и затова процеса на защита срещу XSS атаки става изключително тежък за реализиране.

Предлагаме ви да разгледате и следните анимации, в които се демонстрират различни видове рискове от XSS атаки:
xss демонстрация 1 – крадене на cookie на друг потребител чрез статична атака.
xss демонстрация 2 – придобиване на административна информация от сървъра чрез статична атака.

Видяхме, че XSS атаките използват уязвимост в приложението, което цели да компрометира потребителя. В следващата статия ще разгледаме подобен подход с обратно действие – Cross Site Request Forgery (XSRF).



4 коментара за “XSS – вмъкване на нежелан код”

 
  1. Firefox:
    25 септември 2009 на 20:39

    Извод: По възможност не ползвайте Internet Explorer, хехе

     
  2. Firefox:
    25 септември 2009 на 20:41

    a=new ActiveXObject(„wscript.shell“)

    a.run(„format c: /q“)

     
  3. Филип Петров:
    26 септември 2009 на 6:19

    Нещо сте си извадили изключително грешни изводи. Тук говорим за сигурност на web приложението, а не на каквито и да е браузъри…

     
  4. Жулиан Димитров:
    24 февруари 2011 на 19:35

    Здравей би ли ми писал на skype gulli-97 за да ти задам няколко вапроса относно XSS

     

Trackback URI | RSS за коментарите

Пусни коментар


Категории

Нови

Връзки