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

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

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

Что даёт STRIDE и чего от него не ждать

Microsoft описывает шесть категорий: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service и Elevation of Privilege. Они направляют обсуждение, но сами по себе не измеряют вероятность инцидента и не подтверждают наличие уязвимости.

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

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

Сначала нарисуйте границы системы

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

Упрощённую DFD можно зафиксировать текстом:

Пользователь → браузер → HTTPS → веб-приложение
Веб-приложение → API заказов → база заказов
Веб-приложение → механизм входа и сессий
API заказов → журнал значимых действий
Сотрудник поддержки → отдельные разрешённые операции API

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

Следующие границы зависят от развёртывания. Если API и база имеют разные учётные записи и сетевые доступы, это важно отразить. Если роли поддержки и администратора различаются, нельзя рисовать их одним безымянным «сотрудником». Зафиксируйте допущения: кто управляет инфраструктурой, где хранятся секреты, какие внешние сервисы пока вне модели.

Шесть категорий на одном приложении

Категория	Учебный сценарий	Что обсуждает команда
S — подмена личности	Злоумышленник использует украденные данные входа	Защита входа и сессий, дополнительные факторы там, где оправданы риском
T — изменение данных	Клиент меняет переданную стоимость заказа	Расчёт цены по серверным данным и проверка разрешённых изменений
R — отрицание действия	Сотрудник отрицает изменение статуса, а запись не позволяет установить действие	События аудита, субъект, время, объект и защита журнала от изменения
I — раскрытие информации	API возвращает заказ другого пользователя	Проверка доступа к конкретному объекту и состава ответа
D — отказ в обслуживании	Повтор тяжёлого запроса исчерпывает ресурсы	Ограничения нагрузки и стоимости операции, наблюдение и восстановление
E — повышение привилегий	Пользователь получает административную операцию	Серверная проверка роли для каждого привилегированного действия

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

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

Как записать угрозу без расплывчатости

Плохая запись: «Возможна утечка, исправить безопасность». Полезная запись содержит действующего субъекта, условие, действие, нарушенную границу и последствие. Например: «Авторизованный покупатель подставляет чужой order_id в запрос чтения; если API проверяет только наличие сессии, получает чужой адрес доставки».

Дайте записи идентификатор, например TM-07, и свяжите её с потоком «браузер → API заказов» и активом «адрес доставки». Отдельно зафиксируйте, что предположение ещё нужно проверить. Если сервер уже проверяет владельца, модель должна отражать существующий контроль и требуемое подтверждение, а не сохранять вымышленную уязвимость как факт.

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

Приоритет без магического балла

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

Для TM-07 автор предлагает высокий приоритет, если проверка владельца отсутствует и API доступен всем покупателям. Обоснование — персональные данные, достижимый интерфейс и отсутствие подтверждённого контроля. Это условное решение, а не универсальный балл, одинаковый для всех компаний.

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

Перенос в backlog

Задачу для разработчика можно сформулировать так: «На чтении заказа проверять принадлежность текущему пользователю либо явно предоставленное полномочие поддержки; не возвращать данные чужого заказа при отсутствии права». Это конкретнее требования «добавить авторизацию».

Критерии проверки для учебного сервиса: покупатель A читает собственный заказ; не получает данные заказа B; запрос без сессии не получает защищённые сведения; поддержка выполняет только разрешённые операции. Точные коды ответов команда выбирает по контракту API. Тесты выполняют в разрешённой среде с подготовленными данными.

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

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