Http parameter pollution

[AnGel]

HTTP Parameter Pollution — это новый вид атак на веб-приложения, основным преимуществом которого является возможность обхода WAF (Web Application Firewall). Концепт HPP был разработан итальянскими исследователями

Пожалуйста, Вход или Регистрация для просмотра содержимого URL-адресов!

и

Пожалуйста, Вход или Регистрация для просмотра содержимого URL-адресов!

и представлен на недавно прошедшей конференции OWASP AppSec EU09 Poland.

Несмотря на простоту, HPP является довольно эффективным способом. Его суть заключается в смешивании или дословно «загрязнении» границ HTTP-параметров.


Согласно

Пожалуйста, Вход или Регистрация для просмотра содержимого URL-адресов!

параметрами 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. В связи с особенностями обработки запросов с одноименными параметрами возникают различные непредвиденные разработчиками ошибки и, как следствие, нарушение логики работы веб-приложений, что приводит к уязвимостям (

Пожалуйста, Вход или Регистрация для просмотра содержимого URL-адресов!

,

Пожалуйста, Вход или Регистрация для просмотра содержимого URL-адресов!

,

Пожалуйста, Вход или Регистрация для просмотра содержимого URL-адресов!

,

Пожалуйста, Вход или Регистрация для просмотра содержимого URL-адресов!

и др). Вызванные HTTP Parameter Pollution уязвимости подразделяются на категории серверных и клиентских.

Атаки на серверную часть

Одной из самых интересных особенностей HTTP Parameter Pollution является возможность обхода такого известного WAF как ModSecurity на IIS6.0 вкупе с ASP.NET. Ошибкой ModSecurity является то, что он анализирует запрос после того, как он был обработан веб-сервром, т.е. проверке подвергается каждый параметр независимо друг от друга. На самом деле, назвать это ошибкой было бы несправедливо, если бы IIS не производил бы конкатенацию параметров с одинаковыми именами с помощью запятой. Кто здесь больше виноват ModSecurity или IIS сказать сложно, но в любом случае это приводит к обходу фильтрации (имеется в виду базовый набор правил ModSecurity). Эту уязвимость обнаружил

Пожалуйста, Вход или Регистрация для просмотра содержимого URL-адресов!

.

В качестве примера можно рассмотреть следующую SQL-инъекцию:

Пожалуйста, Вход или Регистрация для просмотра содержимого URL-адресов!

Такой запрос был бы отвергнут ModSecurity, однако с помощью HTTP Parameter Pollution возможен обход фильтрации:

Пожалуйста, Вход или Регистрация для просмотра содержимого URL-адресов!

В итоге Request.QueryString[ʺidʺ] будет содержать склеенные запятой части расщепленного параметра id. IIS объединяет не только те параметры, которые относятся к query string, но также и те, которые присутствуют в POST и COOKIE. Кроме того, учитывая, что MSSQL, который чаще всего работает с ASP, а также и другие RDBS поддерживают многострочные комментарии /* … */, то становится возможным проведение еще более изощренной атаки:

Пожалуйста, Вход или Регистрация для просмотра содержимого URL-адресов!

В результате 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&param={$param}>test</a>";
?>

От XSS подобное приложение будет защищено, но не от HPP:

Пожалуйста, Вход или Регистрация для просмотра содержимого URL-адресов!

<a href=http://www.example.com/index.php?action=view&param=hpp&amp;action=edit>test</a>

Реальным примером уязвимости является возможность непреднамеренного удаления жертвой всех своих писем на Yahoo! Mail, что было продемонстрировано Stefano di Paola. Эта уязвимость к настоящему времени уже исправлена разработчиками. Вектор атаки был следующим:

Пожалуйста, Вход или Регистрация для просмотра содержимого URL-адресов!

%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=&arg4=1

При этом уязвимый код выглядит следующим образом:

<?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().