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

[ by: -=Jul=- ] [ 17.11.05 ]
(с)DKCS security