Ядовитый ответ

Кислицин Никита

Хакер, номер #071, стр. 071-070-3

Смотри, какая забавная штука получается. За несколько лет обширного применения CSS-атак программисты научились, наконец, фильтровать html-теги и прочую дрянь в сценариях, которые добавляют вводимые пользователем данные на сайт: в гостевую книгу, на форум или еще куда. Но при всем при этом они совсем не следят за данными, которые посылаются пользователю в cookies. И теперь может получиться так, что, перейдя по определенной ссылке на доверенном сайте, юзер с потрохами выдаст содержимое всех своих cookies человеку, спровоцировавшему его открыть ядовитую страницу. Разумеется, кража cookies – лишь одна из многих возможностей, которые открываются взломщику вместе с модификацией заголовков и тела документа. А сейчас настало время закончить с затянувшейся прелюдией и перейти, собственно, к атаке response splitting.

Что и зачем мы делим

На самом деле все, чем я грузил тебя до сих пор, было лишь вводной частью, иллюстрацией, призванной помочь тебе лучше понять основы новой атаки. CSS - это, конечно, очень здорово, но вдруг у нас получится извлечь что-то более весомое из возможности модифицировать заголовки и тело документа? Ну разумеется! Если присмотреться повнимательнее к проблеме, становится понятно, что взломщик способен распространить свои действия далеко за пределы конкретной страницы. Так, он может подменить почти любую страницу в кэше пользовательского браузера, заставить любой прокси-сервер прокэшировать нашу подделку, украсть секретную информацию и, как было видно в предыдущем примере, реализовать CSS-атаку. Но все это не совсем очевидные вещи. Я не буду особенно грузить тебя сложной теорией – я просто дам тебе некоторые рекомендации и прокомментирую предложенные мною рецепты. Если ты захочешь поглубже разобраться в проблеме, на нашем диске ты найдешь отличный документ, в котором довольно подробно и со всеми техническими нюансами описываются приложения этой атаки. А сейчас мы с тобой проведем один небольшой опыт. Давай попробуем подсунуть нашему скрипту еще одну хитрую строку:

cook.php?set=lala%0d%0aContent-Length: 1%0d%0a%0d%0aHTTP/1.1 200 OK%0d%0aContent-Type: text/html%0d%0aContent-Length:5%0d%0a%0d%0aaaaaa%0d%0a%0d%0a

Теперь, если ты посмотришь в заголовки возвращенной страницы, то увидишь следующее:

HTTP/1.1 200OK

Date: Thu, 07 Oct 2004 18:40:11 GMT

Server: Apache/1.3.29 (Unix)

X-Powered-By: PHP/5.0.1

Set-Cookie: val=lala2

Content-Length: 0

Keep-Alive: timeout=15, max=99

Connection: Keep-Alive

Content-Type: text/html

HTTP/1.1 200OK

Content-Length: 5

Content-Type: text/html

aaaaa

Ну что, у тебя уже появились какие-то мысли? Если нет, то дела совсем плохи, приятель :(. Смотри: в ответ на один запрос сервер возвращает целых два ответа! Как по-твоему, какой из них правильный? Первый или второй? Подсказываю: первый, а второй должен восприниматься как часть документа. Учитывая, что клиент послал один запрос, вряд ли он ожидает увидеть два отклика. А что произойдет, если одновременно с первым запросом клиент отправил еще и второй? Ха, в этом вся соль атаки. Оказывается, при определенных условиях можно заставить клиентскую часть поверить в то, что наш поддельный ответ является результатом обработки второго пользовательского запроса! Вот так-то!