4. Запрос get с заголовком Content-Length (backward snuggling)

Есть еще одна ошибка, которая заключается в том, что некоторые HTTP устройства считают, что запрос GET никогда не имеет тела, даже если присутствует заголовок Content-Length. Кеш сервер в этом случае (DeleGate/8.9.2) считает, что GET запрос с заголовком Content-Length не имеет тела, и поэтому он направляет данный запрос (но уже без тела) веб-серверу. Некоторые веб-сервера начинают обрабатывать запросы на статичные страницы до того момента, как получат запрос полностью. В таких случаях возможна атака отравления кеша (а в случае, если веб-сервер ожидает получения всего запроса полностью, то происходит блокировка).

Вот веб-серверы, чье поведение соответствует вышеописанному:

• Microsoft IIS/6.0

• Jakarta Tomcat 5.0.19 (coyote/1.1), Tomcat 4.1.24 (Coyote/1.0)

• Sun Microsystems SunONE web server 6.1 SP1

А вот и пример атаки:

1 GET http://SITE/static_foobar.html HTTP/1.1 2 Connection: Keep-Alive 3 Host: SITE 4 Content-Type: application/x-www-form-urlencoded 5 Content-Length: 40 6 7 GET http://SITE/page_to_poison.html HTTP/1.1 8 Foo: GET /poison.html HTTP/1.0 9

DeleGate решит, что данный GET запрос не имеет тела. Поэтому он отправит веб-серверу строки 1-6 как полный запрос. Веб-сервер отправит обратно /static_footback.html, но будет продолжать ожидать окончания запроса (т.е. получения дополнительных 40 байт от DeleGate). Получив обратно ответ на первый запрос, DeleGate прочитает следующий запрос от клиента, находящийся в строках 7-9, и направит его веб-серверу.

Веб-сервер прочитает первые 40 байт запроса и просто проигнорирует их. Эти первые 40 байт как раз последовательность: “GET /page_to_poison.html HTTP/1.1 CRLF Foo:”, которую прокси отправит веб-серверу в начале второго запроса. Поэтому веб-сервер проигнорирует их и прочитает второй запрос как GET /poison.html. И именно эта страница будет возвращена DeleGate, следовательно, DeleGate получит контент страницы /poison.html при запросе страницы /page_to_poison.html.

Данная атака может быть проведена с DeleGate/8.9.2 и всеми веб-серверами, указанными выше (IIS/6.0, Tomcat и SunONE).

5. Трюк с CRLF SP CRLF

Эта техника работает с редко используемой особенностью HTTP - “строка продолжения заголовка”. В соответствие со стандартом HTTP, строка заголовка, начинающаяся с пробела, является продолжением предыдущей строки заголовка. Тем не менее, некоторые программы не совсем правильно это реализуют, что приводит к ошибкам.

Вот программы, которые рассматривают CRLF SP CRLF как продолжение предыдущего заголовка:

• Checkpoint FW-1 kernel R55W beta (Web Intelligence)

• Squid (при некоторых условиях)

И веб-сервера, которые рассматривают CRLF SP CRLF как флаг конца заголовков:

• Microsoft IIS/5.0

A. Прямая атака

1 POST /dynamic_foobar.asp HTTP/1.0 2 Connection: Keep-Alive 3 Content-Type: application/x-www-form-urlencoded 4 [SP] 5 GET /malicious_url HTTP/1.0 6

FW-1 отправляет строки 1-6 веб-серверу (IIS/5.0). Файрвол рассмотрит строку 4 как продолжение строки 3 и обработает строку 5 как заголовок HTTP запроса. Так как FW-1 не проверяет HTTP заголовки, он пропустит такие строки, как “cmd.exe” (т.е. проверки на червей, XSS и SQL-инъекции не будут осуществляться).

А IIS/5.0 обработает это как два запроса: строки 1-4 как первый запрос (POST запрос с нулевой длиной тела, оканчивающийся последовательностью CRLF SP CRLF), а строки 5-6 как второй запрос (GET запрос, со злонамеренным URL).