Web Application Security Consortium:
Классификация угроз
www.webappsec.org
Версия: 1.00
Copyright 2004, Web Application Security Consortium. All rights reserved.
ОПИСАНИЕ
Данная классификация представляет собой совместную попытку собрать воедино и организовать угрозы безопасности Web серверов. Члены Web Application Security Consortium создали данный проект для разработки и популяризации стандартной терминологии описания этих проблем. Это даст возможность разработчикам приложений, специалистам в области безопасности, производителям программных продуктов и аудиторам использовать единый язык для взаимодействия.
ЦЕЛИ
- Определить все известные классы атак на Web-приложения.
- Согласовать названия для каждого из классов.
- Разработать структурированный подход к классификации атак.
- Разработать документацию, содержащую общее описание каждого из классов.
ВОЗМОЖНОЕ ИСПОЛЬЗОВАНИЕ
Содействовать пониманию и разъяснению рисков, связанных с безопасностью Web-приложений. Повышать уровень разработки продуктов для предотвращения возникновения уязвимостей на этом этапе. Выступать в качестве руководства при оценке того, были ли учтены все угрозы при проектировании, разработке и проверке безопасности сайтов.
Помогать в оценке возможностей и выборе решений для защиты 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/.idc
- Установка значения cookie с помощью тега META
Это техника похожа на предыдущую, но может быть использована, когда предприняты меры против внедрения тегов сценариев.
Пример кода:
http://example/.idc
Установка cookie с использованием заголовка ответа HTTP
Злоумышленник использует атакуемый сервер или любой сервер в домене для того, чтобы установить cookie с идентификатором сессии.
Это может быть реализовано различными методами, например:
- Взлом сервера в домене (например, слабо администрируемый сервер WAP).
- Подмена значений в кэше DNS-сервера пользователя с целью добавления сервера атакующего в домен.
- Установка ложного WEB-сервера в домене (к примеру, на рабочей станции в среде Active Directory, где все машины в DNS принадлежат одному домену).
- Использование атаки типа расщепление HTTP ответа (response splitting).
Замечание:
Фиксация сессии на продолжительный промежуток времени может быть осуществлена с использованием постоянных cookie (например, со сроком действия 10 лет), которые сохраняются даже после перезагрузки компьютера.
Пример кода: http://example/.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-кода. К примеру, расположение фрейма () может передаваться в параметре 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 в его браузер загрузится страница следующего содержания:
Пример кода: