Статья по сценариям злоупотреблений (Abuse Case), архивная

Заявление об архивации

Рецензенты отметили, что abuse case на практике используются редко. Кроме того, материал оформлен как «вводный туториал», что не соответствует формату серии шпаргалок.

Введение

Когда в требованиях упоминается уровень безопасности приложения, часто встречаются такие формулировки:

• Приложение должно быть защищённым.
• Приложение должно противостоять всем атакам против данного класса приложений.
• Приложение должно противостоять атакам из OWASP Top 10
• …

Такие требования к безопасности слишком общие и мало полезны команде разработки…

Чтобы с практической точки зрения выстроить безопасное приложение, важно определить атаки, от которых оно должно защищаться, с учётом бизнес- и технического контекста. Сценарии злоупотреблений (abuse cases) долго рекомендовали как приём моделирования угроз; полезна статья по моделированию угроз. На практике подход с abuse case кажется тяжеловесным, а опубликованных примеров и историй успеха немного.

Цель

Цель статьи — пояснить, что такое abuse case, зачем он важен при анализе безопасности приложения и предложить практичный подход к составлению списка сценариев злоупотреблений и учёту их для каждой функции, запланированной к реализации. Статьёй можно пользоваться независимо от методологии проекта (waterfall или agile).

Важное примечание к статье:

Главная цель — дать практичный подход, чтобы компания или проектная команда
могла начать вести список abuse case и адаптировать предложенные элементы
под свой контекст и культуру и в итоге выстроить собственный метод.

Эту статью можно рассматривать как вводный туториал.

Контекст и подход

Зачем явно перечислять атаки

Явная идентификация атак, от которых приложение должно защищаться, необходима для шагов проекта или спринта:

• Оценить бизнес-риск по каждой атаке и отобрать сценарии с учётом риска и бюджета проекта/спринта.
• Сформулировать требования безопасности и включить их в спецификацию или пользовательские истории и критерии приёмки.
• Оценить накладные расходы в исходной оценке трудозатрат на контрмеры.
• По контрмерам: дать команде возможность их определить и выбрать уровень размещения (сеть, инфраструктура, код…).

Понятие abuse case

Abuse case можно рассматривать двояко: как способ находить атаки (ответ на вопрос «что может пойти не так») и как способ фиксировать атаки (неформально — угрозы, проблемы, риски) в форме, менее пугающей для разработчиков.

Abuse case можно определить так:

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

Synopsys даёт такое определение abuse case:

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

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

Abuse case также помогают формулировать требования безопасности
и защищать критичные бизнес-сценарии использования.

Источник Synopsys

Как составить список abuse case

Способов задать список abuse case для функции (или пользовательской истории в agile) много.

Моделирование угроз — набор приёмов для прогноза сбоев и реагирования на каждый сценарий. Превращение пунктов списка «что с этим делать» в abuse case может помочь инженерным командам переварить результаты.

Проект OWASP SAMM предлагает в потоке B практики Requirements Driven Testing на уровне зрелости 2:

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

Злоупотребление функциональностью, иногда называемое «атакой на бизнес-логику», зависит от проектирования и реализации функций. Пример — использование сценария сброса пароля для перечисления учётных записей. В тестировании бизнес-логики выявляйте важные для приложения бизнес-правила и превращайте их в проверки соблюдения правил. Например, в приложении для торговли акциями: может ли атакующий открыть сделку в начале дня по фиксированной цене, держать транзакцию до конца дня, затем завершить продажу при росте котировки или отменить при падении?

Источник SAMM: Verification — Requirements-driven testing, поток B

Другой путь — снизу вверх и совместно:

Провести воркшоп с участниками таких ролей:

• Бизнес-аналитик — ключевые представители бизнеса, описывающие каждую функцию с бизнес-точки зрения.
• Риск-аналитик — специалисты по рискам компании, оценивающие бизнес-риск от предложенной атаки (иногда это бизнес-аналитик).
• Специалист по пентесту — играет роль атакующего, предлагает атаки на рассматриваемые функции. При отсутствии такого специалиста можно привлечь внешнего эксперта. По возможности — два пентестера с разным бэкграундом, чтобы расширить набор атак.
• Технические лидеры проектов — для обсуждения атак и контрмер.
• QA / функциональный тестировщик — понимание того, как функция должна работать (позитивные тесты), не должна работать (негативные) и при каких условиях ломается.

На воркшопе (длительность зависит от числа функций; ориентир — 4 часа) обрабатываются все бизнес-функции проекта или спринта. Результат — список атак (abuse case) по всем функциям; у каждого сценария — оценка риска для фильтрации и приоритизации.

Важно учитывать abuse case типа технический и бизнес и помечать их соответственно.

Примеры:

• Технический abuse case: внедрение XSS в поле комментария.
• Бизнес abuse case: произвольное изменение цены товара в интернет-магазине до оформления заказа, чтобы заплатить меньше.

Когда фиксировать список abuse case

В agile воркшоп определения проводят после планирования, на котором пользовательские истории попали в спринт.

В waterfall — когда бизнес-функции к реализации определены и известны бизнесу.

В любом режиме выбранные к отработке abuse case следует превратить в требования безопасности: в раздел спецификации функции (waterfall) или в критерии приёмки истории (agile), чтобы оценить стоимость/трудозатраты, спроектировать и внедрить контрмеры.

У каждого abuse case должен быть уникальный идентификатор для сквозного учёта в проекте/спринте (подробности — в разделе с предложением).

Пример формата ID: ABUSE_CASE_001.

Схема ниже показывает цепочку шагов (слева направо):

Предложение

Ниже — работа с результатом воркшопа из предыдущего раздела.

Шаг 1: подготовка воркшопа

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

Создайте файл Microsoft Excel (или Google Таблицы и аналог) с листами:

• FEATURES
  • Таблица бизнес-функций, запланированных к разбору.
• ABUSE CASES
  • Таблица всех выявленных на воркшопе abuse case.
• COUNTERMEASURES
  • Таблица возможных контрмер (кратко) для выявленных abuse case.
  • Лист необязателен, но полезен: если исправление простое, это может повлиять на оценку риска.
  • Контрмеры может предлагать специалист AppSec: нужны навыки и атаки, и защиты (у пентестера фокус часто только на атаке; связка пентест + AppSec даёт обзор «на 360°»).

Ниже — вид листов с примером того, что заполняется на воркшопе:

Лист FEATURES:

Лист COUNTERMEASURES:

Лист ABUSE CASES:

Шаг 2: во время воркшопа

Используйте таблицу и пройдите все функции.

Для каждой функции:

1. Представители бизнеса объясняют функцию с бизнес-точки зрения.
2. Пентестеры предлагают набор атак, которые могут выполнить против неё.
3. Для каждой предложенной атаки:
   1. AppSec предлагает контрмеру и предпочтительный уровень (инфраструктура, сеть, код, проектирование…).
   2. Технические специалисты дают обратную связь по реализуемости контрмеры.
   3. Пентестеры считают риск по CVSS v3 (или другому стандарту), например калькулятор CVSS v3.
   4. Руководство по рискам утверждает или корректирует оценку с учётом реального влияния на бизнес.
   5. Бизнес, риски и техника согласовывают фильтрацию списка по текущей функции: что обязательно устранять; в листе ABUSE CASES проставляются отметки (при принятии риска добавьте комментарий с обоснованием).
4. Переходите к следующей функции…

Если пентестеров нет, можно опираться на материалы:

• OWASP Automated Threats to Web Applications
• OWASP Testing Guide
• OWASP Mobile Testing Guide
• CAPEC

Замечание по базе знаний атак и контрмер:

Со временем и по проектам появится собственный словарь атак и контрмер
для типичных приложений вашей предметной области.

Он сильно ускорит следующие воркшопы.

Чтобы его накопить, в конце проекта/спринта можно собрать выявленные атаки и контрмеры
в общее хранилище (вики, БД, файл…) и использовать на следующем воркшопе вместе с вводом пентестеров.

Шаг 3: после воркшопа

В таблице на этом этапе — список abuse case к отработке и при возможности — контрмеры.

Остаются две задачи:

1. Представители бизнеса обновляют спецификацию каждой функции (waterfall) или пользовательские истории (agile), включая связанные abuse case как требования безопасности или критерии приёмки.
2. Технические лидеры оценивают накладные расходы на контрмеры.

Шаг 4: реализация — учёт отработки abuse case

Для сквозного учёта можно применить:

Если один или несколько abuse case закрываются на уровне:

• Проектирования, инфраструктуры или сети
  • В документации или схеме указать: Данное проектирование/сеть/инфраструктура учитывает abuse case ABUSE_CASE_001, ABUSE_CASE_002, ABUSE_CASE_xxx.
• Кода
  • В классах/модулях/скриптах — комментарий: Данный модуль учитывает abuse case ABUSE_CASE_001, ABUSE_CASE_002, ABUSE_CASE_xxx.
  • Можно использовать аннотацию вроде @AbuseCase(ids={"ABUSE_CASE_001","ABUSE_CASE_002"}) для поиска в IDE.

Так несложно скриптами найти, где отработаны abuse case.

Шаг 5: реализация — проверка отработки abuse case

После определения abuse case можно ввести автоматические или ручные проверки, что:

• Все выбранные abuse case отработаны.
• Каждый отработан полностью и корректно.

Варианты проверок:

• Автоматические (регулярно при коммите, ежедневно или еженедельно в CI):
  • Пользовательские правила в SAST/DAST.
  • Целевые модульные, интеграционные или функциональные тесты безопасности.
  • …
• Ручные:
  • Обзор кода коллегами на этапах проектирования или реализации.
  • Передать пентестерам список отработанных abuse case для проверки эффективности защит при тесте на проникновение (подтверждение, что исходные атаки не проходят, и поиск новых векторов).
  • …

Автотесты помогают отслеживать, что контрмеры остаются в силе при сопровождении и исправлении ошибок (защита от случайного удаления/отключения). Это полезно и при непрерывной поставке: убедиться, что защиты по abuse case на месте до открытия доступа к приложению.

Пример: abuse case как пользовательские истории

Ниже — пример вывода abuse case из OWASP Top 10.

Персонажи в терминах угроз:

• Злонамеренный пользователь
• Злоупотребляющий пользователь
• Неосведомлённый пользователь

A1:2017 — Injection

Эпик:

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

Abuse case:

Как атакующий, выполняю инъекцию (SQL, LDAP, XPath, запросы NoSQL, команды ОС, парсеры XML, заголовки SMTP, языки выражений, ORM) в полях ввода пользовательского или API-интерфейса.

A2:2017 — Broken Authentication

Эпик:

У атакующих есть доступ к сотням миллионов пар логин/пароль для credential stuffing, спискам учёток по умолчанию, инструментам автоматического перебора и словарным атакам. Атаки на управление сеансами хорошо изучены, в том числе с неистёкшими токенами сеанса.

Abuse case:

Как атакующий, использую миллионы валидных пар логин/пароль для credential stuffing.

Abuse case:

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

Abuse case:

Как атакующий, манипулирую токенами сеанса (истёкшими и поддельными) для получения доступа.

A3:2017 — Sensitive Data Exposure

Эпик:

Вместо прямого взлома криптографии атакующие крадут ключи, проводят атаки «человек посередине» или похищают данные в открытом виде с сервера, в канале или с клиента (например браузера). Часто нужна ручная работа. Ранее украденные базы паролей могут перебираться на GPU.

Abuse case:

Как атакующий, краду ключи, случайно раскрытые приложением, для несанкционированного доступа.

Abuse case:

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

Abuse case:

Как атакующий, похищаю открытый текст с сервера, из канала или с клиента (например браузера).

Abuse case:

Как атакующий, ищу слабые или устаревшие криптоалгоритмы, перехватываю трафик и взламываю шифрование.

A4:2017 — XML External Entities (XXE)

Эпик:

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

Abuse case:

Как атакующий, эксплуатирую места, где пользователь или система загружает XML, чтобы извлечь данные, выполнить удалённый запрос с сервера, сканировать внутренние системы, провести DoS и др.

Abuse case:

Как атакующий, внедряю вредоносное содержимое в загружаемый XML для тех же целей.

Abuse case:

Как атакующий, внедряю вредоносный XML для эксплуатации кода, зависимостей или интеграций (в т.ч. DoS вроде Billion Laughs).

A5:2017 — Broken Access Control

Эпик:

Обход контроля доступа — базовый навык атакующих. Нарушения контроля доступа находят вручную или частично автоматически (отсутствие контролей в некоторых фреймворках).

Abuse case:

Как атакующий, обхожу проверки доступа, меняя URL, внутреннее состояние приложения или HTML, либо через произвольный инструмент к API.

Abuse case:

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

Abuse case:

Как атакующий, манипулирую сеансами, токенами доступа или иными механизмами, чтобы действовать без входа или с правами администратора при входе как обычный пользователь.

Abuse case:

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

Abuse case:

Как атакующий, эксплуатирую ошибочную конфигурацию CORS для несанкционированного доступа к API.

Abuse case:

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

Abuse case:

Как атакующий, обращаюсь к API без контроля доступа для POST, PUT и DELETE.

Abuse case:

Как атакующий, ищу слабые или переиспользуемые криптоключи и отсутствие ротации.

Abuse case:

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

A6:2017 — Security Misconfiguration

Эпик:

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

Abuse case:

Как атакующий, нахожу отсутствие нужной настройки безопасности в стеке приложения или неверные права облачных сервисов.

Abuse case:

Как атакующий, нахожу лишние включённые функции (порты, службы, страницы, учётки, привилегии) и эксплуатирую их.

Abuse case:

Как атакующий, использую учётки и пароли по умолчанию для доступа к системам и интерфейсам.

Abuse case:

Как атакующий, использую избыточно подробные сообщения об ошибках (stack trace и т.п.) для дальнейших атак.

Abuse case:

Как атакующий, нахожу отключённые или небезопасно настроенные новые средства защиты после обновлений.

Abuse case:

Как атакующий, нахожу небезопасные значения в серверах приложений, фреймворках (Struts, Spring, ASP.NET), библиотеках, СУБД и т.д.

Abuse case:

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

A7:2017 — Cross-Site Scripting (XSS)

Эпик:

XSS — вторая по распространённости позиция в OWASP Top 10; встречается примерно в двух третях приложений.

Abuse case:

Как атакующий, выполняю отражённый XSS: приложение или API вставляет непроверенный и неэкранированный ввод пользователя в HTML. Успех позволяет выполнить произвольный HTML и JavaScript в браузере жертвы; обычно нужна ссылка на контролируемую атакующим страницу (водящие сайты, реклама и т.п.).

Abuse case:

Как атакующий, выполняю сохранённый XSS: приложение хранит неочищенный ввод, который позже видит другой пользователь или администратор.

Abuse case:

Как атакующий, выполняю DOM XSS: уязвимы фреймворки, SPA и API, динамически подмешивающие управляемые атакующим данные в страницу.

A8:2017 — Insecure Deserialization

Эпик:

Эксплуатация небезопасной десериализации сложна: готовые эксплойты редко работают без доработки.

Abuse case:

Как атакующий, нахожу места в приложении и API, где можно подсунуть враждебный или подменённый объект при десериализации, и добиваюсь изменения логики или RCE при наличии опасных классов; либо фокусируюсь на подмене данных и атаках на контроль доступа.

A9:2017 — Using Components with Known Vulnerabilities

Эпик:

Для многих известных уязвимостей есть готовые эксплойты; для других нужна целенаправленная разработка.

Abuse case:

Как атакующий, нахожу распространённые открытые или проприетарные пакеты со слабостями и атакую по известным CVE.

A10:2017 — Insufficient Logging & Monitoring

Эпик:

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

Abuse case:

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

Источники схем

Рисунки подготовлены на draw.io и экспортированы в PNG.

XML-описания схем доступны в архиве (редактирование снова в draw.io):

Архив описаний схем