1. Do you speak English? Use the English version of the site! Link
    Скрыть объявление
Скрыть объявление
Здравствуй гость! После регистрации на ресурсе, ты сможешь скачивать материалы с форума и участвовать в его жизни! Для регистрации откройте соответствующую форму или нажмите на эту ссылку.

Http parameter pollution

Тема в разделе "Взлом", создана пользователем AnGel, 26.10.2015.

  1. AnGel

    AnGel Администратор
    Команда форума

    Фев 23 2017 в 22:49
    Регистрация:
    27.08.2015
    Сообщения:
    2.112
    Симпатии:
    1.527
    Telegram:
    HTTP Parameter Pollution — это новый вид атак на веб-приложения, основным преимуществом которого является возможность обхода WAF (Web Application Firewall). Концепт HPP был разработан итальянскими исследователями Ссылки могут видеть только зарегистрированные пользователи. Зарегистрируйтесь или авторизуйтесь для просмотра ссылок! и Ссылки могут видеть только зарегистрированные пользователи. Зарегистрируйтесь или авторизуйтесь для просмотра ссылок! и представлен на недавно прошедшей конференции OWASP AppSec EU09 Poland.

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


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

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

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

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

    Ссылки могут видеть только зарегистрированные пользователи. Зарегистрируйтесь или авторизуйтесь для просмотра ссылок!

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

    Ссылки могут видеть только зарегистрированные пользователи. Зарегистрируйтесь или авторизуйтесь для просмотра ссылок!

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

    Ссылки могут видеть только зарегистрированные пользователи. Зарегистрируйтесь или авторизуйтесь для просмотра ссылок!

    В результате SQL-инъекция будет успешно проведена, так как запрос будет корректным:
    Код:
    -1/*,*/UNION/*,*/SELECT/*,*/username,password/*,*/FROM/*,*/users--
    Атаки на клиентскую часть

    Основная суть атак на клиента заключается в добавлении дополнительных параметров к ссылкам, различным тэгам, имеющих атрибут src, и к формам (атрибут action). Стандартный уязвимый код выглядит следующим образом:

    PHP:
    <?php
    $param 
    htmlspecialchars($_GET['param']);
    echo 
    "<a href=http://www.example.com/index.php?action=view&param={$param}>test</a>";
    ?>
    От XSS подобное приложение будет защищено, но не от HPP:

    Ссылки могут видеть только зарегистрированные пользователи. Зарегистрируйтесь или авторизуйтесь для просмотра ссылок!

    Код:
    <a href=http://www.example.com/index.php?action=view&param=hpp&amp;action=edit>test</a>
    Реальным примером уязвимости является возможность непреднамеренного удаления жертвой всех своих писем на Yahoo! Mail, что было продемонстрировано Stefano di Paola. Эта уязвимость к настоящему времени уже исправлена разработчиками. Вектор атаки был следующим:

    Ссылки могут видеть только зарегистрированные пользователи. Зарегистрируйтесь или авторизуйтесь для просмотра ссылок!%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:
    <?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().