В последнее время в новостях все больше
информации появляется по уязвимостям
класса HTTP Response Splitting, однако о самой
сущности уязвимости известно мало (по
крайней мере в русском Инете :)), посему мы
восполним пробел и расскажем о концепции
данной уязвимости. Ниже привожу рассказ
авторов «сенсации», непосредственно
открывших новую уязвимость.

В процессе разработки AppScan (утилита для
тестов по безопасности компании Sanctum) мы
столкнулись с новым видом атак, который
назвали HTTP Response Splitting. Это достаточно мощная
и в то же время элегантная техника может
найти свое применение во многих веб-средах.
HTTP Response Splitting позволяет проводить целый ряд
атак, таких как отравление кэша, cross-user defacement,
угон пользовательской информации и Cross-Site
Scripting (о них читайте ниже). Ошибки HTTP Response
Splitting и его производные свойственны
большинству веб-приложений и являются
следствием невозможности правильно
обработать ввод пользователя, в данном
случае неожидаемые символы CR или LF. 

Атака HTTP Response Splitting может состояться как
минимум при участии трех составляющих:

  • Уязвимого веб-сервера.
  • Цели, взаимодействующей с сервером.
    Обычно это кеширующий сервер (прокси) или
    броузер (со своим кешем соответственно).
  • Атакующего, инициирующего нападение.

Сердцем атаки является возможность
хакера послать единственный HTTP запрос,
который заставит веб-сервер сформировать
такой выходной поток, который примется
жертвой за целых два HTTP ответа (вместо
правильного одного). Первый ответ может
частично контролироваться нападающим,
однако в этом случае это не важно. Что
гораздо более важно — нападающий должен
полностью составлять второй ответ — от
статуса HTTP до последнего его байта. Если это
оказывается возможным, хакер (в самом
простом случае) инициирует атаку двумя
запросами от жертвы. Первый получает два
ответа от веб-сервера, второй обычно
обращается к некому невинному ресурсу на
сервере. Однако, следите за руками: 
второй запрос замещается на получателе
вторым HTTP ответом от первого «разделенного»
запроса, который полностью контролируется
хакером. Атакующий таким образом
подставляет своей жертве вместо
запрошенного ресурса некоторый объем
информации им же и сформированный — второй
ответ в первом запросе.

Обычно уязвимости такого рода возникают
когда серверные скрипты внедряют
пользовательские данные в заголовки HTTP
ответов — например в URL перенаправления (статус
HTTP 3.xx), или когда программы формируют куки
на основе введенных пользователем данных. В
первом случае URL часть Location HTTP response header, а во
втором — Set-Cookie HTTP response header. 

Для примера возьмем JSP скрипт redir_lang.jsp. При
вызове redir_lang.jsp с параметром lang=English, он
перенаправляет пользователя на by_lang.jsp?lang=English.
Как видно, параметр языка внедряется в
заголовок. С точки зрения HTTP response-splitting, мы
можем послать вместо English строку с CRLF, что
прервет первый ответ и запустит второй. 

Как я уже говорил, HTTP response-splitting открывает
целое поле для других атак:

  • Cross-site scripting — с подменой заголовка Location.
  • Web-cache poisoning (дефейс) — понятно, что в
    данном случае мы заставляем жертву вместо
    http://web.site/index.html получить второй ответ и
    тем самым мы можем показать ей все, что
    угодно. В дополнение в этой атаке можно
    похитить у ушастого куки или изменить их.
  • Cross-user attacks — атакующий не шлет второго
    запроса, однако в некоторых случаях
    сервер может разделять ТСР соединения
    между несколькими пользователями (некоторые
    кеш сервера) и в таком случае следующий
    запрос от жертвы получит второй ответ HTTP
    Response.
  • Угон страниц с пользовательской инфой —
    хакер может получить ответ сервера,
    принадлежащий пользователю.
  • Browser-cache poisoning — вариант похож на XSS, однако
    он предназначается одному человеку и
    длится несколько дольше, так как
    поддельный ресурс остается в кеше
    броузера.

Мораль: HTTP response splitting — новый вид атак. Он
возможен только в тех приложениях, где
пользовательские данные передаются в
заголовке HTTP ответа. В то же время и
побороть такие ошибки достаточно просто —
достаточно внедрить проверку передаваемых
от юзеров величин. Примеров таких атак
множество в сети — изучайте, пользуйтесь.

Оставить мнение

Check Also

Пространство для эксплуатации. Как работает новая RCE-уязвимость в Apache Struts 2

Во фреймворке Apache Struts 2, виновном в утечке данных у Equifax, нашли очередную дыру. О…