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

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

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

Если захотим, мы вынудим пользователя отправить сколько угодно запросов и проконтролируем результат их обработки; подменим любую html-страницу в кэше браузера, что практически приравнивается к дефейсу сайта – правда, очень локальному, поскольку увидит его всего один пользователь. Впрочем, специальным запросом можно заставить любой прокси-сервер прокэшировать поддельную страницу, что заметно увеличит количество людей, любующихся дефейсом :). Но конек этой атаки – кража пользовательской информации. Тут есть простор для настоящих чудес! Хотя не буду забегать вперед :). Обо всем по порядку.

Я нарисовал тебе достаточно радужную картину. Однако на нашем пути есть несколько проблем, самая большая из которых заключается в том, чтобы обмануть клиентскую часть и заставить ее адекватно воспринять оба ответа. Для этого чрезвычайно важно, чтобы все запросы были отправлены в рамках одного tcp-соединения. Если это так, встает вполне резонный вопрос: где, по мнению клиента, должен начинаться второй ответ, чтобы он был корректным? Вот тут-то и возникает некоторая неопределенность. Дело в том, что разные программные продукты по-разному обрабатывают поток с ответом сервера. Так, например, кэширующий прокси Squid поведет себя совсем не так, как браузер IE. разные. Так уж исторически сложилось, что есть три основных концепции, которые используют современные программы:

1) Тривиальный подход: второй ответ должен начинаться там же, где заканчивается первый. Софт, который использует эту схему, уязвим для атаки в самом тривиальном ее проявлении, который мы обсуждали абзацем выше. В этом случае второй ответ следует сразу после первого документа - моментально, безо всякой «подушки». Надо сказать, это довольно популярная концепция, и она используется, например, в кэширующем прокси Apache с mod_proxy и mod_cache.

2) Граница определяется длиной буфера чтения. Такой подход свойственен клиентам, которые обрабатывают поток данных кусками по n байт, читая их в специальный буфер. Эта концепция применяется в браузере Internet Explorer: данные читаются в кэш длиной 1024 байт. При этом совершенно понятно, что заголовок корректного ответа должен находится не где-нибудь, а в самом начале буфера. Что касается первого отклика, то это требование выполняется автоматически. А вот положение второго ответа мы определяем самостоятельно. Обрати внимание: ты можешь сдвинуть начало составленного тобой второго ответа на сколько угодно байт вниз, вставив перед ним «подушку» из малоосмысленных символов. Если этого не сделать, IE просто отбросит твой заголовок, не заметив в нем HTTP-документа. Как я уже отмечал, чтобы все работало, длина строки, идущей непосредственно перед вторым откликом, должна быть кратна длине буфера. Очевидно, что наша прямолинейная атака, которая работает в случае тривиального подхода к разграничению ответов, не сработает в данном случае. Нам придется увеличить длину первого ответа таким образом, чтобы он целиком занимал конечное число буферов и следующий ответ помещался не куда-нибудь, а точно в начало кэша.