Текст книги "Защити свой компьютер на 100% от вирусов и хакеров"

1.4. Классификация угроз безопасности веб-серверов

Многие из читателей наверняка обратили свое внимание на то, какую важную роль в анализе рисков (см. разд. 1.2) играет такой фактор, как угроза. В этой связи будет более чем уместно ознакомиться с перечнем типичных угроз, которые приведены ниже. Настоящая классификация окажется полезна и подготовленным читателям, и тем, кто углубленно интересуется вопросами компьютерной безопасности.

Очередной раз выходя в Интернет и привычно набирая в браузере дорогой сердцу адрес, мы убеждаемся снова и снова, что не так уж все и плохо: апокалипсис постоянно кто-то переносит, а мы живем в мире высоких технологий, и это не может не радовать. Интернет стал для многих из нас настолько привычным, что иногда кто-нибудь да и допустит мысль о его существовании со времени сотворения мира. Между тем за кажущейся простотой и удобством стоит четкая и отлаженная работа узлов Сети. Было бы наивно полагать, что все совершенно, особенно если речь идет о вещах, сосуществующих в столь динамичной среде. Просматривая горячие двадцатки SANS, предупреждения EEYE, горячий эксклюзив от SecurityLab, убеждаешься снова и снова: безопасность есть процесс, а не состояние.

В рамках данного раздела мы поговорим с вами о безопасности веб-серверов, а точнее постараемся внести ясность и создать некое подобие современной классификации веб-угроз. Предпосылки к созданию подобной классификации очевидны. За последние несколько лет индустрия безопасности веб-приложений адаптировала немалое количество не совсем точных терминов, описывающих уязвимости. Такие названия уязвимостей, как "подделка параметров" (Parameter Tampering), "меж-сайтовое выполнение сценариев" (Cross-site Scripting) и "отравление печений" (Cookie Poisoning) (да-да, именно так), мягко говоря, не совсем точно определяют суть проблемы и возможные последствия атак. Отсутствие четкости в определениях часто вызывает проблемы и взаимонепонимание, даже если стороны согласны с основной идеей.

Когда начинающий специалист безопасности веб-приложений приступает к обучению, его быстро вводит в заблуждение отсутствие стандартного языка. Подобная ситуация не только не способствует профессиональному овладению предметом, но и замедляет понимание картины в целом. Появление классификации угроз безопасности веб-приложений является исключительно важным событием в мире IT.

По известным причинам только система знаний, а не ее разрозненный, дискретный вариант, может служить показателем высшей квалификации разработчиков приложений, специалистов в области безопасности, производителей программных продуктов. На основе классификации в дальнейшем могут быть созданы методики обследования приложений, рекомендации по разработке приложений с учетом безопасности, требования к продуктам и службам. Следующая классификация есть результат проработки различных книг, десятков статей и презентаций. У ее истоков стоит Web Application Security Consortium, представители которой создали базу для разработки и популяризации стандартной терминологии описания подобных проблем (www.webappsec.org).

Представленная классификация окажется полезной прежде всего специалистам, хотя в целом материал направлен на широкий круг читателей, интересующихся проблемами компьютерной безопасности.

Современная классификация имеет иерархическую структуру. Классы атак разбиты по пунктам (1; 2 и т. д.) с соответствующими подпунктами (1); 2) и т. д.). Название класса атаки представлено как в русском варианте, так и в английском.

1. Аутентификация (Authentication):

1) подбор (Brute Force);

2) недостаточная аутентификация (Insufficient Authentication);

3) небезопасное восстановление паролей (Weak Password Recovery Validation).

2. Авторизация (Authorization):

1) предсказуемое значение идентификатора сессии (Credential/Session Prediction);

2) недостаточная авторизация (Insufficient Authorization);

3) отсутствие тайм-аута сессии (Insufficient Session Expiration);

4) фиксация сессии (Session Fixation).

3. Атаки на клиентов (Client-side Attacks):

1) подмена содержимого (Content Spoofing);

2) межсайтовое выполнение сценариев (Cross-site Scripting, XSS);

3) расщепление HTTP-запроса (HTTP Response Splitting).

4. Выполнение кода (Command Execution):

1) переполнение буфера (Buffer Overflow);

2) атака на функции форматирования строк (Format String Attack);

3) внедрение операторов LDAP (LDAP Injection);

4) выполнение команд операционной системы (OS Commanding);

5) внедрение операторов SQL (SQL Injection);

6) внедрение серверных расширений (SSI Injection);

7) внедрение операторов XPath (XPath Injection).

5. Разглашение информации (Information Disclosure):

1) индексирование директорий (Directory Indexing);

2) идентификация приложений (Web Server/Application Fingerprinting);

3) утечка информации (Information Leakage);

4) обратный путь в директориях (Path Traversal);

5) предсказуемое расположение ресурсов (Predictable Resource Location).

6. Логические атаки (Logical Attacks):

1) злоупотребление функциональными возможностями (Abuse of Functionality);

2) отказ в обслуживании (Denial of Service);

3) недостаточное противодействие автоматизации (Insufficient Anti-automation);

4) недостаточная проверка процесса (Insufficient Process Validation).

Пункт и подчиненные ему подпункты разбиты на разделы. Класс атаки имеет краткое описание и дополняется соответствующим "живым" примером. Ну что ж, начнем по порядку.

Аутентификация

Классифицируем атаки, направленные на обход или эксплуатацию уязвимостей в механизмах реализации аутентификации веб-серверов.

Подбор (Brute Force). Подбор, или просто «брут», как его ласково любят называть хакеры, представляет собой автоматизированный процесс проб и ошибок, основной задачей которого является угадывание имени пользователя, пароля, номера кредитной карты, ключа шифрования и т. д. Многие системы позволяют использовать слабые пароли или ключи шифрования, и пользователи часто выбирают легко угадываемые или содержащиеся в словарях парольные фразы. Трагизм еще и в том, что пользователи намеренно выбирают простые пароли, так как сложные, помимо времени ввода, неудобны еще и тем, что легко забываются. Воспользовавшись данной ситуацией, злонамеренный пользователь может применить электронный словарь (что чаще всего и делается) и попытаться использовать всю мощь содержащихся в нем комбинаций символов в качестве пароля. Если сгенерированный пароль позволяет получить доступ к системе, атака считается успешной, и атакующий может использовать учетную запись.

Подобная техника проб и ошибок может быть с успехом использована для подбора ключей шифрования. В случае использования сервером ключей недостаточной длины злоумышленник может получить используемый ключ, протестировав все возможные комбинации. Существует два вида подбора: прямой и обратный. При прямом подборе используются различные варианты пароля для одного имени пользователя (например, имя пользователя – Lamer, пароли – fuck, world, qwerty, 123321…). При обратном – перебираются различные имена пользователей, а пароль остается неизменным (например, имена пользователей – User, Intel, Sara, Vaviorka…, пароль – 12345678). В системах с миллионами учетных записей вероятность использования различными пользователями одного пароля довольно высока. Несмотря на популярность и высокую эффективность, подбор может занимать несколько часов, дней или лет. Данный вид атак широко используется преимущественно там, где отсутствует блокировка в случае неверного сочетания, – это может быть простой взлом NTLM-хэшей и т. д.

Недостаточная аутентификация (Insufficient Authentication). Данная уязвимость возникает тогда, когда веб-сервер позволяет атакующему получать доступ к важной информации или функциям сервера без должной аутентификации. Атаки подобного рода очень часто реализуются посредством интерфейса администрирования через сеть. Чтобы не использовать аутентификацию, некоторые ресурсы по умолчанию «сидят в укромном месте» по определенному адресу, который не указан на основных страницах сервера или других общедоступных ресурсах.

Однако подобный подход не более чем "безопасность через сокрытие". Важно понимать, что несмотря на то что злоумышленник не знает адреса страницы, она все равно доступна через веб. Необходимый URL может быть найден путем перебора типичных файлов и директорий (таких как /admin/) с использованием сообщений об ошибках, журналов перекрестных ссылок или путем простого чтения документации. Подобные ресурсы должны быть защищены адекватно важности их содержимого и функциональных возможностей.

К примеру, многие веб-приложения по умолчанию используют для административного доступа ссылку в корневой директории сервера (/admin/). Обычно ссылка на эту страницу не фигурирует в содержимом сервера, однако страница доступна с помощью стандартного браузера. Поскольку пользователь или разработчик предполагает, что никто не воспользуется этой страницей, так как ссылки на нее отсутствуют, зачастую реализацией аутентификации пренебрегают. В результате для получения контроля над сервером злоумышленнику достаточно зайти на эту страницу.

Небезопасное восстановление паролей (Weak Password Recovery Validation).

Данная уязвимость реализуется, благодаря тому что веб-сервер позволяет атакующему несанкционированно получать, модифицировать или восстанавливать пароли других пользователей. Часто аутентификация на веб-сервере требует от пользователя запоминания пароля или парольной фразы. Строгая политика безопасности предусматривает, что только пользователь должен знать пароль, причем помнить его отчетливо. Но, как оно всегда бывает, со временем пароль забывается. Ситуация усложняется еще и тем, что у многих по несколько электронных ящиков.

Примером реализации подобной функции является использование "секретного вопроса", ответ на который указывается в процессе регистрации. Вопрос либо выбирается из списка, либо вводится самим пользователем. Еще один механизм позволяет пользователю указать "подсказку", которая поможет ему вспомнить пароль. Другие способы требуют от пользователя указать часть персональных данных – таких как номер паспорта, домашний адрес, почтовый индекс и т. д., – которые затем будут использоваться для установления личности. После того как пользователь докажет свою идентичность, система отобразит новый пароль или перешлет его по почте. Система восстановления пароля может быть скомпрометирована путем использования подбора, уязвимостей системы или из-за легко угадываемого ответа на секретный вопрос.

Многие серверы требуют от пользователя указать его электронный адрес в комбинации с домашним адресом и номером телефона. Эта информация может быть легко получена из сетевых справочников. В результате данные, используемые для проверки, не являются большим секретом. Кроме того, эта информация может быть получена злоумышленником с использованием других методов – таких как межсайтовое выполнение сценариев или фишинг. Одно из слабых звеньев, несомненно, – парольные подсказки. Сервер, использующий подсказки для облегчения запоминания паролей, может быть атакован, поскольку подсказки помогают в реализации подбора паролей. Пользователь может использовать стойкий пароль, например "27Пуаро10", с соответствующей подсказкой: "детектив". Атакующий может заключить, что пользовательский пароль состоит из даты рождения и имени любимого автора пользователя. Это помогает сформировать относительно короткий словарь для атаки путем перебора.

Авторизация

Многие сайты разрешают доступ к некоторому содержимому или функциям приложения только определенным пользователям. Доступ для других должен быть ограничен. Используя различные техники, злоумышленник может повысить свои привилегии и получить доступ к защищенным ресурсам.

Предсказуемое значение идентификатора сессии (Credential/Session Prediction).

Предсказуемое значение идентификатора сессии позволяет перехватывать сессии других пользователей. Подобные атаки выполняются путем предсказания или угадывания уникального идентификатора сессии пользователя. Эта атака, так же как и перехват сессии (Session Hijacking), в случае успеха позволяет злоумышленнику послать запрос веб-серверу с правами скомпрометированного пользователя. Дизайн многих серверов предполагает аутентификацию пользователя при первом обращении и дальнейшее отслеживание его сессии. Для этого пользователь указывает комбинацию имени и пароля. Вместо повторной передачи имени пользователя и пароля при каждой транзакции веб-сервер генерирует уникальный идентификатор, который присваивается сессии пользователя. Последующие запросы пользователя к серверу содержат идентификатор сессии как доказательство того, что аутентификация была успешно пройдена. Если атакующий может предсказать или угадать значение идентификатора другого пользователя, это может быть использовано для проведения атаки.

Так, многие серверы генерируют идентификаторы сессии, используя алгоритмы собственной разработки. Подобные алгоритмы могут просто увеличивать значение идентификатора для каждого запроса пользователя. Другой распространенный вариант – использование функции от текущего времени или других специфичных для компьютера данных. Идентификатор сессии сохраняется в cookie, скрытых полях форм или URL. Если атакующий имеет возможность определить алгоритм, используемый для генерации идентификатора сессии, он может выполнить следующие действия:

♦ подключиться к серверу, используя текущий идентификатор сессии;

♦ вычислить или подобрать следующий идентификатор сессии;

♦ присвоить полученное значение идентификатора cookie/скрытому полю формы/URL.

Недостаточная авторизация (Insufficient Authorization). Недостаточная авторизация возникает, когда веб-сервер позволяет атакующему получать доступ к важной информации или функциям, доступ к которым должен быть ограничен. Успешное прохождение аутентификации пользователем вовсе не означает, что он должен получить доступ ко всем функциям и содержимому сервера. Кроме аутентификации, должно быть реализовано разграничение доступа. Процедура авторизации определяет, какие действия может совершать пользователь, служба или приложение. Грамотно построенные правила доступа должны ограничивать действия пользователя согласно политике безопасности. Доступ к важным ресурсам сайта должен быть разрешен только администраторам.

В прошлом многие веб-серверы сохраняли важные ресурсы в скрытых директориях – таких как /admin или /Log. Если атакующий запрашивал эти ресурсы напрямую, он получал к ним доступ и мог перенастроить сервер, получить доступ к важной информации либо полностью скомпрометировать систему. Некоторые серверы после аутентификации сохраняют в cookie или скрытых полях идентификатор «роли» пользователя в рамках веб-приложения. Если разграничение доступа основывается на проверке данного параметра без верификации принадлежности к роли при каждом запросе, злоумышленник может повысить свои привилегии, просто модифицировав значение cookie. К примеру, значение cookie: Session Id = 12345678; Role = User заменяется на SessionId = 12345678; Role = Admin.

Отсутствие тайм-аута сессии (Insufficient Session Expiration). Если для идентификатора сессии или учетных данных не предусмотрен тайм-аут или его значение слишком велико, злоумышленник может воспользоваться старыми данными для авторизации. Это повышает уязвимость сервера для атак, связанных с кражей идентификационных данных. Поскольку протокол HTTP не предусматривает контроль сессии, веб-серверы обычно используют идентификаторы сессии для определения запросов пользователя. Таким образом, конфиденциальность каждого идентификатора должна быть обеспечена, чтобы предотвратить множественный доступ пользователей с одной учетной записью. Похищенный идентификатор может использоваться для доступа к данным пользователя или осуществления мошеннических транзакций. Отсутствие тайм-аута сессии увеличивает вероятность успеха различных атак. К примеру, злоумышленник может получить идентификатор сессии, используя сетевой анализатор или уязвимость типа «межсайтовое выполнение сценариев». Хотя тайм-аут не поможет, в случае если идентификатор будет использован немедленно, ограничение времени действия поможет при более поздних попытках использования идентификатора. В другой ситуации, если пользователь получает доступ к серверу с публичного компьютера (библиотека, интернет-кафе и т. д.), отсутствие тайм-аута сессии может позволить злоумышленнику воспользоваться историей браузера для просмотра страниц пользователя. Большое значение тайм-аута увеличивает шансы подбора действующего идентификатора. Кроме того, увеличение этого параметра ведет к увеличению одновременно открытых сессий, что еще больше повышает вероятность успешного подбора.

При использовании публичного компьютера, когда несколько пользователей имеют неограниченный физический доступ к машине, отсутствие тайм-аута сессии позволяет злоумышленнику просматривать страницы, посещенные другим пользователем. Если функция выхода из системы просто перенаправляет на основную страницу веб-сервера, а не завершает сессию, страницы, посещенные пользователем, могут быть просмотрены злоумышленником. Поскольку идентификатор сессии не был отмечен как недействительный, атакующий получит доступ к страницам сервера без повторной аутентификации.

Фиксация сессии (Session Fixation). Используя данный класс атак, злоумышленник присваивает идентификатору сессии пользователя заданное значение. В зависимости от функциональных возможностей сервера существует несколько способов зафиксировать значение идентификатора сессии. Для этого могут использоваться атаки типа «межсайтовое выполнение сценариев» или подготовка сайта с помощью предварительного HTTP-запроса. После фиксации значения идентификатора сессии атакующий ожидает момента, когда пользователь войдет в систему. После входа пользователя злоумышленник использует идентификатор сессии для получения доступа к системе от имени пользователя.

Существуют два механизма управления сессиями на основе идентификаторов. Первый из них – так называемый разрешающий – основан на том, что конкретный идентификатор сессии присваивается браузером. Механизмы второго типа – строгого – функционируют с идентификаторами, сгенерированными сервером. В случае разрешающих механизмов злонамеренный пользователь может выбрать любой идентификатор сессии. При условии отсутствия спецзащиты от фиксации сессии данная атака может быть использована против любого сервера, аутентифицирующего пользователей с помощью идентификатора сессии. Не секрет, что большинство веб-серверов сохраняют ID в cookie, но это значение также может присутствовать в URL или скрытом поле формы. К сожалению, системы, использующие cookie, являются наиболее уязвимыми.

Большинство известных в настоящий момент вариантов фиксации сессии направлено именно на значение cookie (кстати, не грех будет напомнить, что сохраненные пароли вашего электронного ящика, входа на персональный сайт и прочие сохраняются все в тех же пресловутых cookie, которые можно найти по адресу: and SettingsUsernameCookies). После описанного выше нетрудно догадаться, каким именно образом программы, предназначенные для шпионажа, похищают ваши конфиденциальные данные.

Рассмотрим подробно атаку, направленную на фиксацию сессии. Атака осуществляется в три этапа. На первом этапе злонамеренный пользователь устанавливает на атакуемом сервере так называемую сессию-заглушку и получает (или выбирает произвольный в зависимости от механизма) от него идентификатор. На втором этапе, собственно, и происходит фиксация сессии, когда злоумышленник передает значение идентификатора сессии-заглушки браузеру пользователя и фиксирует его идентификатор. Данный пункт реализуется посредством модификации значения cookie с помощью пресловутого XSS.

Следующим шагом атакующего является собственно подключение к сессии. Атакующий ожидает аутентификации пользователя на сервере. После захода пользователя на сайт злоумышленник подключается к серверу, используя зафиксированный идентификатор, и получает доступ к сессии пользователя. Как вы уже поняли, "гвоздем программы" является фиксация ID, которая реализуется посредством следующих действий.

♦ При наличии уязвимости типа "межсайтовое выполнение сценариев" злоумышленник получает возможность установить определенное значение cookie на стороне клиента посредством следующего кода: httр://example/<script> document.cookie="sessionid=12 34;%2 0domain=.example.dom"; </ script>.idc.

♦ Второй вариант предусматривает установку нужного значения cookie с помощью тега META. Кроме того, возможна установка cookie с использованием заголовка HTTP-ответа.

Атаки на клиентов

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

Подмена содержимого (Content Spoofing). Наверное, многие из читателей встречались с выражением «дефейс сайта». Так вот, дефейс – это грубая подмена содержимого. Однако это не есть самое интересное. В отличие от дефейса, следующий способ подмены не преследует цели обескуражить посетивших сайт нецензурными выражениями. Его задачи другие. Используя определенную технику подмены содержимого, злоумышленник заставляет пользователя поверить, что страницы сгенерированы веб-сервером, а не переданы из внешнего источника. Как это происходит?

Некоторые веб-страницы создаются с использованием динамических источников HTML-кода. К примеру, расположение фрейма <frame src="http://foo. example/file.html"> может передаваться в следующем параметре URL:

httр://foo.example/page?frame_src=http://foo.example/file.html

Атакующий может заменить исходное значение параметра framesrc на frame_ src= http://attacker.example/spoof.html.

Когда будет отображаться результирующая страница, в строке адреса браузера пользователя начнет отображаться адрес сервера (foo.example), но на странице также будет присутствовать внешнее содержимое, загруженное с сервера атакующего (attacker.example), замаскированное под легальный контент. Получается довольно оригинальная ситуация. Пользователь может и не подозревать, что вводит секретные данные, становящиеся достоянием того, кто умело подделал оригинальную страницу. Задача злонамеренного пользователя, как вы уже догадались, сводится к тому, чтобы он перенаправился по специально созданной ссылке. Последняя в виде спама может быть прислана по электронной почте, системе моментального обмена сообщениями, опубликована на доске сообщений или открыта в браузере пользователя с применением межсайтового выполнения сценариев. В качестве примера реализации данной атаки с успехом подойдет создание ложного пресс-релиза. Предположим, что веб-сервер динамически генерирует фреймы на странице с пресс-релизами компании. Когда пользователь перейдет по ссылке http://foo.exampLe/pr?pg=http://foo.exampLe/pr/01012003.htmL, в его браузер загрузится страница следующего содержания (листинг 1.7).

Листинг 1.7. Код, перенаправляющий пользователя на подложную страницу

<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-код будет иметь следующий вид (листинг 1.8).

Листинг 1.8. Результирующий 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.

Межсайтовое выполнение сценариев (Cross-site Scripting или XSS). Наличие уязвимости Cross-site Scripting позволяет атакующему передать серверу исполняемый код, который будет перенаправлен браузеру пользователя. Для написания подобного кода обычно используются HTML/JavaScript, но могут быть применены и VBScript, ActiveX, Java, Flash и др. Переданный код исполняется в контексте безопасности (или зоне безопасности) уязвимого сервера. Используя текущие привилегии, код получает возможность читать, модифицировать или передавать важные данные, доступные с помощью браузера (здесь совсем не грех будет вспомнить, что, если вы работаете с правами администратора, шансов попасться на такой крючок больше). При данном виде атаки у атакованного пользователя может быть скомпрометирована учетная запись (кража cookie), его браузер может быть перенаправлен на другой сервер или осуществлена подмена содержимого сервера. В результате тщательно спланированной атаки злоумышленник может использовать браузер жертвы для просмотра страниц сайта от имени атакуемого пользователя. Передача кода в таких случаях осуществляется через URL, в заголовках HTML-запроса (cookie, user-agent, refferer), значениях полей форм и т. д. Существует два типа атак, приводящих к межсайтовому выполнению сценариев:

♦ постоянные (сохраненные);

♦ непостоянные (отраженные).

Основным различием между ними является то, что в отраженном варианте передача кода серверу и возврат его клиенту осуществляются в рамках одного HTTP-запроса, а в сохраненном – в разных. Осуществление непостоянной атаки требует, чтобы пользователь перешел по ссылке, сформированной злоумышленником (ссылка может быть передана по электронной почте, ICQ и т. д.). В процессе загрузки сайта код, внедренный в URL или заголовки запроса, будет передан клиенту и выполнен в его браузере. Сохраненная разновидность уязвимости возникает, когда код передается серверу и сохраняется на нем на некоторый промежуток времени. Наиболее популярными целями атак в этом случае являются форумы, почта с веб-интерфейсом и чаты. Что самое интересное в данном случае? Следующее: для атаки пользователю не обязательно переходить по ссылке – достаточно посетить уязвимый сайт!

За примерами далеко ходить не приходится: многие сайты имеют доски объявлений и форумы, которые позволяют пользователям оставлять сообщения. Зарегистрированный пользователь обычно идентифицируется по номеру сессии, сохраняемому в cookie. Если атакующий оставит сообщение, содержащее код на языке JavaScript, он получит доступ к идентификатору сессии пользователя. Многие серверы предоставляют пользователям возможность поиска по содержимому сервера. Как правило, запрос передается в URL и содержится в результирующей странице. К примеру, при переходе по URL http://portaLexample/search?q="fresh beer" пользователю будет отображена страница, содержащая результаты поиска и фразу По вашему запросу fresh beer найдено 0 страниц. Если в качестве искомой фразы будет передан JavaScript-код, он выполнится в браузере пользователя.

Расщепление HTTP-запроса (HTTP Response Splitting). Для эксплуатации данной уязвимости злоумышленник должен послать серверу специальным образом сформированный запрос, ответ на который интерпретируется целью атаки как два разных ответа. Второй ответ полностью контролируется злоумышленником, что дает ему возможность подделать ответ сервера. Возможность осуществления атаки возникает, когда сервер возвращает данные, предоставленные пользователем в заголовках HTTP-ответа. Обычно это происходит при перенаправлении пользователя на другую страницу (коды HTTP 3xx) или когда данные, полученные от пользователя, сохраняются в cookie.

В первой ситуации URL-адрес, на который происходит перенаправление, является частью заголовка Location HTTP-ответа, а во втором случае значение cookie передается в заголовке Set-Cookie. Основой расщепления HTTP-запроса является внедрение символов перевода строки (CR и LF) таким образом, чтобы сформировать две HTTP-транзакции, в то время как реально будет происходить только одна. Перевод строки используется, чтобы закрыть первую (стандартную) транзакцию и сформировать вторую пару вопрос/ответ, полностью контролируемую злоумышленником и абсолютно не предусмотренную логикой приложения. В результате успешной реализации этой атаки злоумышленник может выполнить следующие действия.

♦ Межсайтовое выполнение сценариев.

♦ Модификация данных кэша сервера-посредника. Некоторые кэширующие серверы-посредники (Squid 2.4, NetCache 5.2, Apache Proxy 2.0 и ряд других) сохраняют подделанный злоумышленником ответ на жестком диске и на последующие запросы пользователей по данному адресу возвращают кэшированные данные. Это приводит к замене страниц сервера на клиентской стороне. Кроме этого, злоумышленник может переправить себе значение cookie пользователя или присвоить им определенное значение. Эта атака может быть также направлена на индивидуальный кэш браузера пользователя.

♦ Межпользовательская атака (один пользователь, одна страница, временная подмена страницы). При реализации этой атаки злоумышленник не посылает дополнительный запрос. Вместо этого используется тот факт, что некоторые серверы-посредники разделяют одно TCP-соединение с сервером между несколькими пользователями. В результате второй пользователь получает в ответ страницу, сформированную злоумышленником. Кроме подмены страницы, злоумышленник может также выполнить различные операции с cookie пользователя.

♦ Перехват страниц, содержащих пользовательские данные. В этом случае злоумышленник получает ответ сервера вместо самого пользователя. Таким образом, он может получить доступ к важной или конфиденциальной информации. Приведу пример 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) (листинг 1.9).