Моделирование угроз по STRIDE: первая модель веб-приложения

#Что такое STRIDE

STRIDE — список из шести категорий угроз: spoofing (подмена личности), tampering (подделка данных), repudiation (отказ от совершённых действий), information disclosure (раскрытие информации), denial of service (отказ в обслуживании) и elevation of privilege (повышение привилегий). Microsoft использует его в своих рекомендациях по моделированию угроз. Сам STRIDE угроз не находит. Он даёт шесть вопросов к каждой части проекта, чтобы результат не зависел от того, что вы случайно вспомнили в конкретный день.

Этот метод применяют раньше большинства инструментов безопасности. Сканер смотрит на работающую систему. Модель угроз смотрит на замысел: какие есть компоненты, какие данные между ними движутся и где меняется уровень доверия. Начать можно с бумаги и ручки, когда кода ещё нет.

#Зачем это нужно

Многие сбои веб-безопасности — ошибки проектирования. Сервер верит цене, которую прислал браузер. Админский маршрут проверяет, что пользователь вошёл, но не проверяет, что он админ. В лог-файл попадают токены сессий. Каждую такую проблему можно исправить в коде, но код часто точно соответствует полученному проекту. Проблема начинается с проекта.

OWASP Threat Modeling Cheat Sheet говорит о том же. Чтобы понять, какие угрозы применимы, нужно разобраться в потоках данных, границах доверия и других частях системы. Модель угроз фиксирует это понимание в виде, который могут проверить другие люди.

#Составные части

#Диаграммы потоков данных

В диаграмме потоков данных (DFD) есть четыре вида элементов:

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

Диаграмма должна умещаться на одной странице. Если нужна вторая, вы, вероятно, рисуете две системы.

#Границы доверия

Граница доверия — линия, на которой данные переходят из области с одним уровнем доверия в область с другим. Ваш сервер находится внутри этой линии. Браузер снаружи, потому что его пользователь может изменить любой запрос, прежде чем тот дойдёт до вас. Каждый поток, пересекающий границу, нуждается в валидации, и на этих пересечениях находится большинство интересных угроз. OWASP cheat sheet называет такие пересечения вероятными точками атаки.

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

#Шесть категорий

Каждая категория нарушает одно свойство безопасности.

Это соответствует описаниям в документации Microsoft по моделированию угроз. Spoofing, например, означает использование аутентификационных данных другого пользователя.

Не каждая категория подходит к каждому элементу. Распространённая стартовая карта, которая используется во многих инструментах моделирования угроз, выглядит так: внешним сущностям достаются spoofing и repudiation; процессам все шесть; хранилищам данных tampering, repudiation, information disclosure и denial of service; потокам данных tampering, information disclosure и denial of service. Считайте эту карту подсказкой. Если категория кажется неприменимой к элементу, запишите почему, чтобы проверяющий мог это оспорить.

#Как это работает, шаг за шагом

1. Определите скоуп. Напишите одно предложение, где названы система, версия и то, что в скоуп не входит. Достаточно такого: «Веб-приложение Juice Shop и его API, запущенные локально, без учёта операционной системы хоста».
2. Нарисуйте диаграмму потоков данных. Добавьте внешние сущности, процессы, хранилища данных и потоки. Подпишите на каждом потоке, что он переносит.
3. Нарисуйте границы доверия. Проведите линию везде, где меняется доверие.
4. Проведите каждый элемент через категории. Для каждой применимой категории задайте вопрос из таблицы и запишите угрозу коротким предложением. Удобная форма: кто что делает и что идёт не так. Например: «Украденный токен сессии позволяет атакующему оформлять заказы от имени покупателя».
5. Выберите ответ на каждую угрозу: меру защиты, риск, который вы принимаете с письменным обоснованием, или передачу другой стороне. Угроза без ответа остаётся открытой.
6. Сохраните модель в системе контроля версий рядом с кодом и назначьте дату пересмотра.

Для небольшой функции шаги с 1 по 5 могут занять час. В первый раз будьте готовы перерисовать диаграмму хотя бы однажды. Это нормально.

#Практика: модель OWASP Juice Shop

OWASP Juice Shop — намеренно небезопасное веб-приложение для обучения. В этой лабораторной работе вы его не эксплуатируете. Вы рисуете его устройство, перечисляете угрозы и записываете меры защиты. Угрозы берутся из чтения проекта, атаковать приложение для этого не нужно.

Запускайте лабораторию только на своей машине с привязкой к 127.0.0.1. Если вы ещё не настроили контейнер, сначала пройдите OWASP Juice Shop в Docker.

#Что понадобится

Вам нужны:

• Docker, чтобы запустить контейнер лаборатории
• Git, чтобы закоммитить модель
• OWASP Threat Dragon для десктопа, бесплатный и с открытым исходным кодом, из https://github.com/OWASP/threat-dragon/releases
• Пустая папка для репозитория лаборатории

На тестовой машине, использованной для этой статьи, git --version напечатал:

git version 2.49.0.windows.1

#Шаг 1: запустите лабораторию

docker run --rm -d --name juice-shop-lab -p 127.0.0.1:3000:3000 bkimminich/juice-shop

Часть -p 127.0.0.1:3000:3000 публикует порт только на loopback-интерфейсе, поэтому другие компьютеры в вашей сети до него не дотянутся.

Убедитесь, что веб-приложение отвечает:

curl -sI http://127.0.0.1:3000/ | head -n 1

На тестовой машине первая строка вывода была такой:

HTTP/1.1 200 OK

Убедитесь, что отвечает API. Это обычный GET-запрос списка товаров:

curl -s -o /dev/null -w "products %{http_code} %{content_type}\n" http://127.0.0.1:3000/api/Products

Вывод:

products 200 application/json; charset=utf-8

Проверьте версию, которую сообщает приложение:

curl -s http://127.0.0.1:3000/rest/admin/application-version

Вывод:

{"version":"20.3.0"}

Такую версию образ сообщил 8 ноября 2026 года на тестовой машине. Ваш образ может сообщить другую. Запишите версию, которую видите, потому что модель угроз описывает конкретный релиз.

#Шаг 2: установите Threat Dragon

Скачайте сборку для десктопа под вашу операционную систему со страницы релизов, установите её и откройте. Названия пунктов меню в шагах ниже для этой статьи не сверялись со сборкой Threat Dragon, и они меняются от релиза к релизу. Сопоставляйте их с тем, что показывает ваша сборка.

#Шаг 3: нарисуйте диаграмму

Создайте новую модель угроз и добавьте такие элементы:

• Внешний актор Browser с описанием «браузер покупателя, вне нашего контроля».
• Процесс Juice Shop web and API с описанием «веб-приложение и API на 127.0.0.1:3000».
• Хранилище данных SQLite database с описанием «файл данных приложения».
• Два потока от браузера к процессу: HTTP-запросы и HTTP-ответы в обратную сторону.
• Два потока от процесса к хранилищу: SQL-запросы и возвращаемые строки.
• Граница доверия, отделяющая браузер от процесса и хранилища.

Модель должна выглядеть так:

Browser (external actor)
   |  HTTP requests and responses
   v
=================== trust boundary ===================
   Juice Shop web and API (process, 127.0.0.1:3000)
   |  SQL queries and rows
   v
SQLite database (data store)

Текстовый набросок служит только ориентиром. Настоящий файл — тот, что сохранит Threat Dragon.

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

#Шаг 4: перечислите угрозы для каждого элемента

Примените стартовую карту, описанную выше. Браузер — внешняя сущность, поэтому ему достаются spoofing и repudiation. Каждому потоку от браузера к API достаются tampering, information disclosure и denial of service. Процессу API достаются все шесть категорий. Хранилищу SQLite достаются tampering, repudiation, information disclosure и denial of service.

Вот по одному примеру на категорию. В настоящей модели строк для каждого элемента больше.

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

В Threat Dragon добавьте каждую угрозу к её элементу, указав заголовок, описание и меру защиты. Если в вашей сборке есть поле статуса, ставьте open для мер, которые ещё не реализованы.

#Шаг 5: экспортируйте и закоммитьте

Экспортируйте модель в JSON через меню файла и назовите файл juice-shop-threat-model.json. Затем в папке лаборатории выполните:

git init
cp /path/to/juice-shop-threat-model.json .
git add juice-shop-threat-model.json && git commit -m "First STRIDE model"

Git выводит короткую сводку с именем ветки и сообщением коммита. Точный текст зависит от вашей версии Git и настроек. Если Git спросит об имени автора, задайте своё через git config user.name и git config user.email и коммитьте под своим именем.

Перед коммитом прочитайте файл. В нём не должно быть настоящих имён хостов, токенов или данных клиентов. Эта модель использует только 127.0.0.1.

Закончив, остановите лабораторию:

docker stop juice-shop-lab
curl -s -o /dev/null -w "%{http_code}\n" --max-time 2 http://127.0.0.1:3000/

На тестовой машине вывод был таким:

juice-shop-lab
000

Первая строка — от docker stop. 000 означает, что curl не получил ответа от порта, то есть лаборатория выключена.

#Модель угроз нужно обновлять

Модель угроз описывает проект на день написания. Когда проект меняется, модель устаревает. Типичные поводы для обновления:

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

Threat Modeling Manifesto говорит, что моделирование угроз должно следовать за изменениями проекта, итерациями, каждая из которых охватывает посильную часть системы. На практике это три привычки. Держите JSON-файл в репозитории рядом с кодом. Добавьте в пул-реквесты, затрагивающие аутентификацию, потоки данных или внешние интеграции, вопрос для ревью: модель угроз всё ещё соответствует? Записывайте дату и версию приложения, которые описывает модель. Угрозы с пометкой об устранении остаются полезной историей, поэтому сохраняйте их.

#Частые ошибки

• Рисовать систему своей мечты. Рисуйте ту, что работает, вместе с прокси, кешем и фоновыми задачами.
• Начинать со всей компании. Начните с одной функции и одного потока, а потом расширяйте.
• Перечислять угрозы без мер защиты и ответственных. Угроза без ответа остаётся открытой.
• Писать меру защиты вроде «использовать шифрование» без подробностей. Укажите, что защищается, где и как это проверить.
• Пропускать стрелки. Большинство угроз находится на потоках и границах, внутри прямоугольников их меньше.
• Относиться к шести категориям как к чек-листу, который надо закрыть. Это подсказки. Полезный результат — решение по каждой угрозе.
• Зондировать чужие системы, чтобы подтвердить угрозу. Модели не нужно живое тестирование, а любое тестирование должно проходить в лаборатории, которой вы управляете.

#Что дальше

• Прочитайте список угроз Microsoft и OWASP cheat sheet параллельно. Отметьте, где они сходятся в категориях и где различаются формулировки.
• Смоделируйте одну функцию проекта, который вы поддерживаете, например вход или сброс пароля.
• Перейдите к статье OWASP Top 10 для разработчиков. В ней перечислены слабые места веб-приложений, которые вам будут встречаться чаще всего, и они хорошо ложатся на строки вашей таблицы.
• Узнайте о других методах, например о деревьях атак и методах, ориентированных на приватность: они отвечают на вопросы, на которые STRIDE отвечает менее прямо.

#Источники

• Microsoft: Threat modeling tool threats
• OWASP Threat Modeling Cheat Sheet
• OWASP Threat Dragon
• Threat Modeling Manifesto
• OWASP Juice Shop project
• Docker port publishing