Цель проекта - определить классы уязвимостей (КУ), к которым могут быть
уязвимы Web приложения, а также компоненты нападений (КН), которые эксплуатируют
эту уязвимость. Нападение на систему может быть составлено из нескольких
компонентов, охватывающих множественные классы уязвимостей. КУ не будут
каталогизировать отдельные уязвимости подобно переполнению ISAPI. Вместо этого
проект описывает универсальные нападения на Web приложения и службы.

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

Каждый компонент нападения имеет:

  1. Название
  2. Описание
  3. Анализ
  4. UML Описание
  5. Описание проверки данной проблемы
  6. Типичные Контрмеры

Пример:

В качестве примера выберем проблему защиты, связанную со сценарием Phone Book.
Мы используем этот пример, так как он хорошо изучен, и очень прост в
использовании и хорошо документирован. Нападение обычно описано следующим URL:

http://www.victim.com/cgi-bin/phf?Qalias=x%0a/bin/cat%20/etc/passwd

Сценарий непосредственно использует функцию escape_shell_cmd(), которая
не проверяет ввод символа новой строки '\n'. Атака описана в
OWASP-IV-MC-1.

Кликните, что бы увидеть картинку полностью

Практически нападающий сначала определил бы, существует ли сценарий
непосредственно. Это может быть сделано, используя перебор файл-приложение, как
описано в OWASP-FAE-1. Если
проверка прошла успешно, нападающий может использовать результат для
осуществления цепочки из одной или нескольких нападений, чтобы выполнить команды
операционной системы (OWASP-IV-DOSC-1)
или запросы базы данных (OWASP-IV-DSQLI-1).

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

<RequestHeaders>

<Header >

<Name>Content-Type</Name>

<Value>application/x-www-form-urlencoded</Value>

</Header>

<Header>

<Name>Host</Name>

<Value>test2.test.me</Value>

</Header>

<Cookies>

<Cookie>

<Name>ASPSESSIONIDQGQGQXPY</Name>

<Value>EOFLMPFBJPNHILCIMFNLNHND</Value>

<Path>.victim.com</Path>

<Domain>victim.com</Domain>

<Expires>...expires here if available..</Expires>

<Secure>TRUE (if secure cookie)</Secure>

</Cookie>

</Cookies>

</RequestHeaders>

Русская версия проекта находится здесь:
http://owasp.securitylab.ru

  • Подпишись на наc в Telegram!

    Только важные новости и лучшие статьи

    Подписаться

  • Подписаться
    Уведомить о
    0 комментариев
    Межтекстовые Отзывы
    Посмотреть все комментарии