HTTP Request smuggling (Часть 2)


Различные техники HRS

В предыдущей статье мы рассмотрели (и использовали) следующие ошибки при обработке HTTP запросов:
  1. Два различных заголовка Content-Length (Пример №1, №4 и №5)
  2. Запрос GET с заголовком Content-Length (Пример №3)
  3. Ошибка с 48К в IIS/5.0 (Пример №2)

Существуют еще несколько обнаруженных нами ошибок обработки. В большинстве случаев пара прокси/кеш/файрвол -сервер и веб-сайт может быть атакована, используя один или несколько методов HRS, но обычно для какой-то конкретной пары программ подходит только часть методов.
Ниже мы приведем список ошибок (и техник их использования), используемых для HRS, вместе с парами устройств, которые им подвержены. Заметьте, что это неполные результаты (т.к. для многих техник мы не протестировали все возможные пары программ). Это означает, что вероятно существует гораздо больше пар программ, уязвимых HRS, чем мы приведем ниже.

1. Двойной заголовок Content-Length

В данном случае ошибка очевидна - атакующий отсылает запрос с двумя заголовками Content-Length. Если кеш сервер и веб-сервер используют разные заголовки, тогда возможна HRS.
Техника HRS (Content-Length) №1
Кеш сервер использует последний заголовок Content-Length, а веб-сервер использует первый заголовок (примеры №1, №4 и №5). Следующие из исследованных кеш серверов используют последний заголовок Content-Length:
  • Microsoft ISA/2000
  • Sun Microsystems SunONE 3.6 SP4
Следующие из исследованных веб-серверов используют первый заголовок Content-Length:
  • Jakarta Tomcat 5.0.19 (Coyote/1.1)
  • Tomcat 4.1.24 (Coyote/1.0)
  • Sun Microsystems SunONE web server 6.1 SP1
Все 6 комбинаций кеш серверов и веб-серверов были протестированы, и все показали уязвимость к HRS. Особый интерес вызывает комбинация прокси сервера Sun Microsystems SunONE 3.6 SP4 и веб-сервера того же поставщика - SunONE web server 6.1 SP1.
Техника HRS (Content-Length) №2
Как вариант техники №1, в случае, когда атака forward smuggling не проходит, возможна атака backward smuggling. Она возможна в случае использования популярного коммерческого кеш-приложения (чье название мы не будем раскрывать, а обозначим за PCCA) и Jakarta Tomcat 5.0.19 (Coyote/1.1). PCCA обрабатывает последний заголовок Content-Length и направляет запросы (с телом) веб-серверу, используя отдельные соединения, таким образом, делая технику №1 бесполезной. Единственным путем, которым можно обойти это препятствие, является отправка запроса без тела, то есть нужно отправить второй заголовок Content-Length со значением “0″. Веб-сервер (который использует значение второго заголовка Content-Length) решит, что этот запрос не закончен, и мы получим блокировку. Тем не менее, некоторые серверы, а именно IIS/6.0 и Tomcat пошлют ответ при запросе статичного ресурса (например: /index.html) до того, как получат полностью тело запроса. Это можно использовать для проведения backward smuggling, что мы и собираемся продемонстрировать на примере PCCA и Tomcat. Атакующему необходимо отправить первый запрос (на произвольную статичную страницу) с двумя заголовками “Content-Length”. Первый заголовок должен иметь значение длины второго запроса. Второй заголовок первого запроса должен иметь значение “0″. Второй запрос - это запрос, который определяет ресурс, чей URL будет использован для прикрытия. А третий запрос определяет ресурс, чей контент необходимо получить. В этом случае контент ресурса, определенного в третьем запросе, будет закеширован под URL ресурса, определенном во втором запросе.
Вот пример атаки (используются PCCA и Tomcat):
1 GET http://SITE/static_foobar.html HTTP/1.0
2 Content-Length: 71
3 Content-Length: 0
4 Connection: Keep-Alive
5
6 GET http://SITE/page_to_poison.html HTTP/1.0
7 Host: SITE
8 Connection: Keep-Alive
9 GET /poison.html HTTP/1.0
10
PCCA использует последний заголовок Content-Length (cтрока 3) и, следовательно, передает серверу строки 1-5. Tomcat же обрабатывает запрос, используя первый заголовок Content-Length (строка 2), и поэтому ожидает еще 71 байт. Однако, так как запрос отправлен на статичную страницу (/static_foobar.html), Tomcat также немедленно возвратит ее обратно PCCA. PCCA отправляет этот ответ атакующему и отсылает следующий запрос, полученный им из входящего потока - в данном случае, строки 6-10 (запрос на /page_to_poison.html). Получив его, Tomcat использует 71 байт (строки 6-8, но не забудьте, что PCCA отбросит http://SITE из 6 строки при отправлении запроса серверу) и поэтому видит второй запрос в виде строк 9-10. Следовательно, Tomcat отправит контент страницы /poison.html. PCCA рассмотрит это как ответ на страницу page_to_poison.html. И в результате атака успешно проведена.
Техника HRS (Content-Length) №3
Кеш сервер использует первый заголовок Content-Length, в то время как веб-сервер использует второй заголовок Content-Length. Следующие кеш серверы, которые мы исследовали, используют первый заголовок Content-Length:
  • Squid 2.5stable4 (Unix)
  • Squid 2.5stable5(порт NT)
  • Oracle WebCache 9.0.2
Следующие из исследованных нами веб-серверов используют последний заголовок Content-Length:
  • BEA Systems WebLogic 8.1 SP1
Все три комбинации были проверены и показали свою уязвимость атакам HRS.

2. Запрос с заголовками “Transfer-Encoding: chunked” и “Content-Length:…”

Разбираясь с Apache 2.0.45, мы обнаружили, что он довольно интересно реагирует на такое сочетание заголовков. Запрос, полученный с обоими заголовками, воспринимается как имеющий блочное (chunked) тело.
[HTTP/1.1 не позволяет запросу иметь одновременно два заголовка: “Content-Length” и “Content-Encoding:chunked”].
Apache полностью прочитывает тело такого запроса и переделывает его в нормальный (не разбитый на блоки) запрос. По непонятным причинам Apache не добавляет собственный заголовок Content-Length и не удаляет существующий. В результате запрос направляется с первоначальным заголовком Content-Length и без заголовка “Transfer-Encoded:chunked” и с телом, включающим все части первоначального запроса. Очевидно, что, используя этот феномен, можно скрыть запрос, отослав заголовок “Content-Length: 0″ и закодированное блоками тело со спрятанным запросом.
Данная атака проходит на Apache 2.0.45 и на следующих веб-серверах:
  • Microsoft IIS/6.0 и 5.0
  • Apache 2.0.45 (как веб-сервер) и Apache 1.3.29
  • Jakarta Tomcat 5.0.45 (Coyote/1.1), Tomcat 4.1.24 (Coyote /1.0)
  • IBM WebSphere 5.1 и WebSphere 5.0
  • BEA Systems WebLogic 8.1 SP1
  • Oracle9iAS 9.0.2
  • Sun Microsystems SunONE web server 6.1 SP1
Необходимо отметить, что поведение Apache в этом случае очень странное, так как запросы, которые он создает по умолчанию, не имеют заголовка Content-Length и поэтому они могут вызывать проблемы при обработке на многих веб-серверах (которые в этом случае принимают значение Content-Length за 0). А когда нормальный запрос с заголовком Transfer-Encoded: chunked посылается через Apache, он доставляется веб-серверу как запрос с нормальным телом, но без Content-Length, что приводит к полному игнорированию тела запроса на большинстве веб-серверов.

3. Техника “Двойной CR в HTTP заголовке” (и техника “Заголовок SP”)

[Прим. CR - возврат каретки. SP - пробел.]
Эта техника использует ошибку в обработке HTTP запроса. Строка заголовка с единственным символом CR, следующая за последовательностью CRLF, обрабатывается некоторыми программами как строка HTTP заголовка, а другими как маркер конца заголовков.
[Прим. HTTP/1.1 не позволяет использовать такие строки в HTTP запросах.]
Чтобы использовать данную технику атаки нам необходимо применить еще одну технику. Эта техника использует ошибку под названием “Заголовок SP”. Техника “Заголовок SP” применяется, когда разные программы по-разному обрабатывают HTTP заголовки, имеющие пробелы между именем заголовков и символом “:”.
Некоторые программы воспринимают “foo SP:” как заголовок с именем “foo”, тогда как другие - как заголовок с именем “foo “ (”foo” с добавленным пробелом). Атака, которую мы опишем ниже, использует обе эти техники.
Позвольте начать с техники использования запроса с двойным CR в строке заголовка:
PCCA рассматривает этот запрос как имеющий заголовок “CR” и поэтому не заканчивает блок заголовков. IIS/5.0 же завершает блок заголовков, но при определенных условиях, которые мы обсудим позже.
Техника “Заголовок SP” нужна для того, чтобы обойти желание PCCA отправлять запросы с телом через новое TCP соединение, а также, чтобы IIS не отклонял запросы с двумя заголовками Content-Length.
Основная идея атаки заключается в следующем:
1 GET http://SITE/foobar.html HTTP/1.0
2 Connection: keep-alive
3 [CR]
4 GET /poison.html?aaaa … aaa [2048 times] HTTP/1.0
5 Content-Length: N
6 Content-Length : 0
7
8 GET http://SITE/page_to_poison.html HTTP/1.0
9
Где N - это длина запроса на URL “http://SITE/page_to_poison.html” (строки 8-9), отправленного PCCA веб-серверу как проверенный запрос.
PCCA воспринимает строки 1-7 как первый запрос. Это GET запрос с Content-Length равным 0 (запомните, что PCCA обрабатывает два заголовка Content-Length: один в строке 5, а второй в строке 6. Заголовок строки 6, содержащий технику “Заголовок SP”, нестандартный, потому что содержит дополнительный пробел после имени заголовка. Тем не менее, PCCA все также обрабатывает эту строку как заголовок Content-Length. Так как PCCA использует последнее значение заголовка, то в данном случае он использует значение 0). Следовательно PCCA отправляет строки 1-7 веб-серверу как единый HTTP запрос.
Заметьте, что PCCA заменяет CR CRLF на CR CR CRLF. Но это не влияет на нашу атаку. IIS/5.0 обрабатывает полученные данные как первый запрос (строки 1-3), а остальные данные как второй запрос, но уже незавершенный (строки 4-7). Первый запрос заканчивается CRLF CR CR CRLF. Интересное поведение IIS/5.0 заключается в том, что он следующие полученные данные TCP соединения пытается обработать как HTTP заголовок. Таким образом, если в следующих 2048 байтах он найдет символ “:”, тогда последовательность CRLF CR CR CRLF не будет рассматриваться как маркер конца заголовков. Вот почему нам необходимо 2048 символов “a”. А так как IIS не находит двоеточие, то обрабатывает строки 4-7 как новый HTTP запрос (и конечно отсылает обратно ответ на первый запрос). Строки 4-7 представляются в виде GET запроса с Content-Length N (строка 6 игнорируется, так как IIS не воспринимает Content-Length с пробелом). И теперь IIS ожидает, когда данный запрос будет завершен.
Возвращаемся к PCCA. Он получил ответ на первый GET запрос, и поэтому PCCA направляет следующий запрос (на страницу page_to_poison.html) - строки 8-9. Теперь IIS получает недостающие N символов тела второго запроса (на poison.html), и теперь запрос может быть полностью обработан. PCCA получает контент страницы /poison.html на запрос страницы /page_to_poison.html. Отравление кеша успешно завершено.
Эта техника была нами протестирована на PCCA и ISS/5.0, но, тем не менее, многое из рассказанного может быть применено в атаках на другие пары программ.

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).
b. Вариант атаки, требующий дополнительной вставки:
Squid (мы проверили Squid 2.4stable7, 2.5stable4 и 2.5stable5 для NT) воспринимает CRLF SP CRLF как продолжение заголовка. Однако Squid также проверяет HTTP заголовок на наличие символа “:” (иначе, запрос полностью отвергается). Следовательно, строка, которая сразу же следует за CRLF SP CRLF, должна содержать двоеточие. Однако IIS/5.0 проверяет наличие символа “:” после CRLF SP CRLF и, если таковой находится, IIS/5.0 считает, что это строка является строкой заголовка (т.е. IIS/5.0 не заканчивает секцию заголовков). Поэтому в этом методе в строку добавляются произвольные данные (6000 байт), следующие за символом “:”. Тем самым, заставляя Squid рассматривать ее как строку заголовка, а IIS/5.0 рассматривает ее как новый запрос.
Например:
1 GET http://SITE/static_foobar.asp HTTP/1.0
2 Foo: bar
3 [SP]
4 GET /poison.html?AAAAA … [6000 times]… AAAA: HTTP/1.0
5 Connection: Keep-Alive
6
7 GET http://SITE/page_to_poison.html HTTP/1.0
8
Squid отправляет строки 1-6 веб-серверу (IIS) как простой запрос. Запомните, что строка 4 является правильным заголовком для Squid, так как она содержит символ двоеточие. IIS рассматривает полученные данные как два запроса. Строки 1-3 как первый запрос, заканчивающийся последовательностью CRLF SP CRLF (в интерпретации ISS, несколько тысяч байт справа от CRLF SP CRLF не содержат символ двоеточие). Этот запрос обрабатывается IIS, и ответ возвращается Squid. Затем Squid отправляет строки 7-8, но IIS отсылает обратно ответ на строки 4-6. Следовательно, Squid получает контент /poison.html на запрос с URL /page_to_poison.html.
Но есть несколько тонких моментов:
  • Последовательности запросов этой атаки должен предшествовать запрос на произвольный ресурс с заголовком Connection:Keep-Alive. Этот заголовок укажет IIS, что соединение устойчивое. Бесполезно будет добавлять этот заголовок к первому запросу (например, между 1 и 2 строками), потому что Squid переупорядочивает заголовки и отсылает заголовок Connection среди последних (т.е. после 4 строки). В этом случае IIS увидит первый запрос при новом TCP соединении без заголовка Connection:Keep-Alive и решит, что соединение неустойчивое. А это прервет атаку.
  • Присутствуют также некоторые ограничения в последовательности. Squid увидит второй ответ IIS только после отправки того, что он интерпретировал как второй запрос (строки 7-8). Следовательно, эта атака нуждается в повторении несколько раз, пока событие не произойдет в необходимой последовательности.

6. Преждевременное завершение запросов, чья длина тела превышает 48 KB

Как ясно из заголовка, IIS/5.0 в некоторых случаях ведет себя очень интересно. Так, запрос с большим (>48KB) телом (например, POST с корректным телом и заголовком Content-Length, показывающим длину этого тела), но без заголовка Content-Type будет воспринят как запрос, чей размер тела равен 48 KB (49152). После 49152 байт IIS/5.0 прервет запрос и начнет обрабатывать новый запрос. Это позволяет очень легко провести атаку, так как такое поведение нестандартно и не соответствует RFC.
Мы проведем атаку отравления кеша Squid (2.5stable5 для NT), Apache 2.0.45 и ISA/2000. Мы также обойдем защиту FW-1.
Пример атаки (отравление кеша):
1 POST http://SITE/dynamic_foobar.asp HTTP/1.1
2 Host: SITE
3 Connection: keep-alive
4 Content-Length: 49181
5
6 AAAAA … AAAA[49150 times]
7 GET /poison.html HTTP/1.0
8
9 GET http://SITE/page_to_poison.html HTTP/1.1
10 Host: SITE
11
Кеш сервер отправит веб-серверу строки 1-8. Заметьте, что значение Content-Length (строка 4) включает как раз необходимую подстановку в строке 6 (49150 байт), плюс CRLF в конце 6 строки, плюс 7 и 8 строки (каждая с CRLF). IIS/5.0 прочитает строки 1-6 как первый запрос (тело завершится после 49152 байта и как раз попадет на начало 7 строки), затем перейдет ко второму запросу (строки 7-8). Затем он отправит ответ на первый запрос кеш серверу. После этого кеш сервер отправит второй запрос (/page_to_poison.html) - строки 9-11. IIS/5.0 обработает второй запрос (строки 7-8) и отправит обратно контент /poison.html. Кеш сервер получит контент /poison.html на запрос на /page_to_poison.html.
Пример (обход защиты FW-1):
1 POST /dynamic_page1.asp HTTP/1.1
2 Host: SITE
3 Connection: keep-alive
4 Content-Length: 49230
5
6 AAAAA … AAAA[49150 times]
7 POST /dynamic_page2.asp HTTP/1.0
8 Connection: Keep-Alive
9 Content-Length: 35
10
11 POST /dynamic_page3 HTTP/1.0
12 Bla: GET /malicious_url HTTP/1.0
13
14 GET /some_page HTTP/1.0
15
FW-1 отправит первый запрос (строки 1-10) IIS/5.0. Сервер прочитает строки 1-6 как первый полный запрос. Затем он отправит ответ обратно FW-1. Далее он прочитает строки 7-10 как второй неполный запрос (тело еще не передано).
FW-1 вернет ответ от IIS обратно атакующему и отправит строки 11-13 в качестве второго запроса. Заметьте, что злонамеренные данные в 12 строке являются частью HTTP заголовка (так их воспримет FW-1), и поэтому они не приведут к срабатыванию механизмов обнаружения/защиты у FW-1.
IIS/5.0 получит строку 11 и первые 5 байт 12 строки как тело второго запроса и ответит на второй запрос. FW-1 получит этот ответ и отошлет третий запрос IIS/5.0 - строки 11-15. IIS/5.0 отправит ответ на третий запрос (строки 12-13), который является результатом запроса на /malicious_url.
Заключение: Мы увидели, что многие пары программ (прокси/файрвол сервера и веб-сервера) являются уязвимыми. Уязвимыми являются следующие пары:
  • PCCA
    • IIS/5.0
    • Tomcat 5.0.19 (probably with Tomcat 4.1.x as well)
  • Squid 2.5stable4 (Unix) и Squid 2.5stable5 для NT
    • IIS/5.0
    • WebLogic 8.1 SP1
  • Apache 2.0.45
    • IIS/5.0
    • IS/6.0
    • Apache 1.3.29
    • Apache 2.0.45
    • WebSphere 5.1 и 5.0
    • WebLogic 8.1 SP1
    • Oracle9iAS web server 9.0.2
    • SunONE web server 6.1 SP4
  • ISA/2000
    • IIS/5.0
    • Tomcat 5.0.19
    • Tomcat 4.1.24
    • SunONE web server 6.1 SP4
  • DeleGate 8.9.2
    • IIS/6.0
    • Tomcat 5.0.19
    • Tomcat 4.1.24
    • SunONE web server 6.1 SP4
  • Oracle9iAS cache server 9.0.2
    • WebLogic 8.1 SP1
  • SunONE proxy server 3.6 SP4
    • Tomcat 5.0.19
    • Tomcat 4.1.24
    • SunONE web server 6.1 SP4
  • FW-1 Web Intelligence kernel 55W beta
    • IIS/5.0
Это частичный список. Многие пары мы не протестировали. Также существуют множество других веб- и кеш серверов, которые мы не изучили. Также очень вероятно, что существуют еще множество подобных техник.

Защита Вашего сайта от HRS

Как сайт может защитить себя от HRS? Установка программного файрвола может помочь, но как мы показали на примере FW-1, защиты некоторых файрволов могут быть обойдены (узнайте у поставщика вашего файрвола, защищают ли его продукты от подобных атак).
Другое решение - это использовать те веб-сервера, которые используют очень точные парсеры HTTP, как, например, Apache (он подвержен лишь некоторым видам HRS только тогда, когда используется и как веб-сервер, и как кеш сервер).
Другие не очень практичные методы - это использовать SSL соединения (https вместо http), завершать клиентскую сессию после каждого запроса или сделать все страницы некешируемыми (для защиты от отравления кеша).
Так для некоторых продуктов, упомянутых выше, мы можем дать специальные патчи и конфигурационную информацию:

Squid

Для устранения описанных выше уязвимостей в Squid выпущены патчи, которые распространяются среди поставщиков продуктов Squid.
http://www.squid-cache.org/Versions/v2/2.5/bugs/#squid-2.5.STABLE7-header_parsing
http://www.squid-cache.org/Versions/v2/2.5/bugs/#squid-2.5.STABLE7-response_splitting
http://www.squid-cache.org/Versions/v2/2.5/bugs/#squid-2.5.STABLE8-relaxed_header_parser
Рекомендованная версия: Squid-2.5.STABLE9.
Также советуем отключить для Squid устойчивые соединения:
client_persistent_connection off
server_persistent_connection off

Завершение

Единственным способом полностью обезопаситься от HRS - это сделать так, чтобы все HTTP устройства точно придерживались процесса обработки HTTP. Но, к сожалению, это вряд ли произойдет в ближайшем будущем.

Ссылки

[1] A. Klein, “Divide and Conquer - HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics.” Sanctum White Paper, March 2004. http://www.packetstormsecurity.org/papers/general/whitepaper_httpresponse.pdf
[2] 3APA3A, “Bypassing Content Filtering Whitepaper,” February 2002 (original paper date. The paper was last revised August 2004). http://www.security.nnov.ru/advisories/content.asp
[3] Rain Forest Puppy, “A look at whisker’s anti-IDS tactics,” December 1999. http://www.ussrback.com/docs/papers/IDS/whiskerids.html
[4] J. Gettys, R. Fielding, J. Mogul, H. Frystyk, L. Masinter, P. Leach, and T. Berners-Lee, “Hypertext Transfer Protocol - HTTP/1.1.” RFC 2616, June 1999. http://www.w3.org/Protocols/rfc2616/rfc2616
[5] J. Grossman, “Cross Site Tracing (XST).” WhiteHat Security White Paper, January 2003. http://www.cgisecurity.net/whitehat-mirror/WH-WhitePaper_XST_ebook.pdf
[6] P. Watkins, “Cross Site Request Forgeries (CSRF),” BugTraq posting, June 2001. http://www.securityfocus.com/archive/1/191390
[7] “CERT Advisory CA-2000-02 Malicious HTML Tags Embedded in Client Web Requests.” February 2000. http://www.cert.org/advisories/CA-2000-02.html
[8] A. Klein, “Cross Site Scripting Explained.” Sanctum White Paper, May 2002. http://crypto.stanford.edu/cs155/CSS.pdf
Перевод: Сипягин Максим
Оригинал документа (en) (pdf)

Опубликовано в: Безопасность Февраль 17, 2006

10 Комментариев »

  1. аффтару респект

    Комментарий от Кирилл — Октябрь 18, 2008 @ 5:57 pm

  2. большой…респект ;)

    Комментарий от Настасия — Октябрь 18, 2008 @ 5:57 pm

  3. +1 =)

    Комментарий от Аделина — Октябрь 18, 2008 @ 5:57 pm

  4. Запрос GET не идёт , может ошиблись где-то ?

    Комментарий от Астролог — Февраль 2, 2009 @ 2:01 am

  5. А модель и версия прошивки сервера имеет значение ?

    Комментарий от Holz — Февраль 3, 2009 @ 2:11 am

  6. Я 4й пункт попробовал и сервер лёг :(

    Комментарий от Айболит — Февраль 4, 2009 @ 2:10 am

  7. 2Айболит Как ты так умудрился ? У меня нормально всё.

    Комментарий от Славянинов — Февраль 5, 2009 @ 2:27 am

  8. А как определить что сервер подвергся атаке ?

    Комментарий от фотограф — Февраль 6, 2009 @ 2:41 am

  9. фотограф , в этот момент сервер обычно ложится)))

    Комментарий от Прораб — Февраль 7, 2009 @ 6:23 pm

  10. Млин, мне бы ваши проблемы ))) детсад

    Комментарий от Байкер без шлема — Февраль 13, 2009 @ 2:34 am

Оставить комментарий

You must be logged in to post a comment.

© apachedev.ru, 2005-2011