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