Моделирование угроз веб-приложения: как устроен разбор

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

Модель угроз — это не список страшных атак

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

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

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

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

Как схема превращается в сценарии угроз

Для каждого компонента и потока задают практические вопросы. Кто может отправить эти данные? Может ли он подменить их? Что произойдёт, если компонент недоступен или скомпрометирован? Может ли пользователь выполнить действие от имени другого? Ответы становятся сценариями, которые разработчики и команда безопасности могут проверить.

Один из распространённых способов упорядочить вопросы — STRIDE: Spoofing (подмена личности), Tampering (изменение данных), Repudiation (отказ от совершённого действия), Information disclosure (раскрытие информации), Denial of service (отказ в обслуживании) и Elevation of privilege (повышение привилегий). Это не готовая оценка риска и не автоматический сканер. Метод помогает не забыть разные классы проблем, но не решает за команду, что действительно важно для конкретного приложения.

Для потока «пользователь запрашивает заказ» разбор может выглядеть так:

• Подмена личности: можно ли повторно использовать или похитить сессию, чтобы войти как другой пользователь?
• Изменение данных: можно ли заменить идентификатор заказа в запросе и повлиять на чужую запись?
• Раскрытие информации: проверяет ли сервер право на каждый заказ, а не только факт входа в аккаунт?
• Повышение привилегий: может ли обычная учётная запись вызвать действие, доступное оператору?
• Отказ в обслуживании: можно ли заставить обработчик выполнять слишком дорогие запросы?
• Отказ от действия: останутся ли записи, по которым можно установить, кто и когда изменил заказ?

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

Границы доверия важнее красивой диаграммы

Граница доверия — это место, где данные пересекают область с другим уровнем контроля или доверия^[1]. Например, переход от браузера к серверу, от серверного приложения к внешнему API или от обычного пользователя к административной функции. Границы не обязательно совпадают с сетевыми сегментами: один и тот же сервер может обрабатывать действия с разными правами.

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

^[1] Граница доверия — переход между компонентами или зонами, для которых отличаются предположения о том, кто может отправлять данные и выполнять действия.

Риск: почему не каждой угрозе нужен одинаковый приоритет

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

Записывайте оценку вместе с основаниями: какой актив затронут, какие условия нужны атакующему и что произойдёт при успехе. Если используются баллы, закрепите критерии уровней и применяйте их последовательно. Число без объяснения создаёт ложную точность и мешает сравнивать риски между командами.

Практичный результат разбора — не толстый документ, а список сценариев с владельцами и дальнейшими действиями:

1. Зафиксируйте компонент, поток и границу доверия, к которым относится угроза.
2. Опишите действия атакующего и ожидаемое последствие для пользователя или бизнеса.
3. Укажите существующую защиту и то, чего не хватает.
4. Назначьте проверку: тест доступа, анализ настройки, изменение архитектуры или наблюдение в продакшене.
5. Назначьте ответственного и решите, когда пересмотреть сценарий.

Если риск принимают, это тоже стоит записать: кто принял решение, почему и при каких изменениях его нужно пересмотреть. Иначе временный компромисс легко становится постоянным просто потому, что о нём забыли.

Что измерять и где модель перестаёт помогать

Универсальных цифр «до и после» для моделирования угроз нет: результат зависит от архитектуры, полноты схемы и того, как команда использует выводы. Вместо выдуманного процента покрытия измеряйте конкретные вещи: сколько сценариев превратились в тесты или задачи, какие высокорисковые вопросы остались без владельца и сколько времени проходит от изменения архитектуры до обновления модели.

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

У подхода есть границы. Схема быстро устаревает, если в неё не вносят новые интеграции, фоновые задачи и административные интерфейсы. Обсуждение только «внешнего хакера» пропускает ошибки конфигурации, скомпрометированную учётную запись и злоупотребление внутренними полномочиями. А STRIDE не заменяет анализ приватности, соответствия требованиям или проверку кода.

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

Что делать дальше

Возьмите один критичный пользовательский сценарий — например, просмотр и изменение заказа — и нарисуйте его путь от клиента до хранилища. Отметьте входные данные, проверки личности и прав, внешние вызовы и границы доверия. Затем сформулируйте несколько сценариев STRIDE, выберите наиболее опасные и превратите их в тесты или задачи с ответственными.

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