Безопасность на этапе проектирования: WSTG

В книге Writing Secure Code Ховард и Леблан привели историческую оценку: выпуск одного бюллетеня безопасности обходился Microsoft минимум в $100 000, а совокупные затраты клиентов на внедрение патчей были значительно выше. WSTG ссылается на эту цифру как аргумент в пользу ранних проверок - но принимать её за современную статистику затрат нельзя, книга вышла давно. Ранние проверки помогают обнаружить недостатки до внедрения; стоимость исправления зависит от системы и стадии проекта. OWASP Web Security Testing Guide описывает пять фаз проверки безопасности. Первые две охватывают подготовку к разработке, требования и проектирование — им и посвящена эта статья. Это третья статья в серии по OWASP WSTG.

Фреймворк тестирования OWASP: место ранних проверок в secure SDLC​

OWASP WSTG описывает задачи и методы проверки безопасности для разных этапов жизненного цикла разработки ПО (SDLC). Организация адаптирует их к своей методологии — Waterfall, Agile или собственному процессу разработки.

Цель - построить сквозной процесс тестирования безопасности внутри организации. Пять групп активностей:

1. До начала разработки
2. При определении требований и проектировании
3. При разработке
4. При развёртывании
5. При эксплуатации и сопровождении

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

WSTG дополняет другие подходы к безопасной разработке. NIST SSDF (SP 800-218, версия 1.1, финальная) описывает практики безопасной разработки на всех этапах SDLC вне зависимости от методологии. OWASP SAMM v2 определяет пять бизнес-функций и пятнадцать практик безопасности для оценки зрелости процессов. SSDF помогает выстроить практики разработки, SAMM — оценить их зрелость, а WSTG — спланировать проверки безопасности.

Фаза 1: безопасная разработка ПО начинается до кода​

Определение SDLC и ролей безопасности (Фаза 1.1)​

До начала разработки приложения нужно определить SDLC, в котором безопасность - неотъемлемая часть каждого этапа. Без явного определения процесса и ролей безопасность на этапе проектирования остаётся благим пожеланием.

Для практического применения фазы 1.1 предлагаем зафиксировать:

• Владельцев артефактов безопасности. Кто отвечает за требования безопасности, модель угроз, результаты тестов? Для каждого артефакта - конкретный ответственный за обновление.
• Точки принятия решений. В какой момент дефект безопасности блокирует переход к следующей фазе? Скажем, команда может запретить переход к разработке при необработанных угрозах категории High. Для такого правила заранее определяют шкалу риска, ответственного и порядок принятия исключений.
• Взаимодействие ролей. Как работают вместе QA, разработчики и команда безопасности? Если выделенной роли AppSec нет, задачи можно закрепить за подготовленным security champion - но его полномочия и доступную экспертную поддержку определяют явно, а не «по ситуации».

Политики и стандарты безопасной разработки ПО (Фаза 1.2)​

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

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

При инвентаризации стоит зафиксировать:


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

Метрики и трассируемость: от требования к тесту (Фаза 1.3)​

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

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

Цепочка: Идентификатор требования → Угроза → Тест → Доказательство

Учебный пример цепочки: REQ-AUTH-01 требует аутентификации перед доступом к закрытым документам, а REQ-DOC-01 - проверки владельца документа. Для проектируемого API задаём два ожидаемых ответа: без действительных учётных данных - HTTP 401, с действительным токеном другого пользователя - HTTP 403. Это разные проверки: аутентификации и авторизации. При выполнении теста сохраняют запросы и ответы — по ним можно будет проверить результат.

Метрики, которые стоит определить на старте:

Фаза 2: требования безопасности при проектировании​

Рецензирование требований безопасности (Фаза 2.1)​

Требования безопасности определяют, как приложение работает с точки зрения защиты. Их нужно тестировать - проверять допущения и искать пробелы в определениях.

WSTG приводит характерный пример двусмысленности: требование говорит «пользователь должен быть зарегистрирован для доступа к разделу с документами». Это регистрация в системе или аутентификация? Регистрация и текущая аутентификация - разные условия доступа. Такая неоднозначность может привести к ошибкам контроля доступа; конкретный риск зависит от реализации. Требования должны быть максимально однозначными.

При поиске пробелов проверяются: управление пользователями, аутентификация, авторизация, конфиденциальность данных, целостность, подотчётность (accountability), управление сессиями, безопасность транспортного уровня, сегрегация многоуровневых систем, соответствие законодательным требованиям и стандартам (включая приватность, государственные и отраслевые стандарты).

Для структурирования требований применяется OWASP ASVS. В версии 5.0.0 - 345 требований в 17 главах и три уровня проверки безопасности (L1, L2, L3). При переходе с 4.x нужно сверить изменившиеся требования и их применимость по таблице соответствия версий; переносить старые номера без проверки нельзя - структура глав изменилась.

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

Учебный пример 1: личный кабинет с документами

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

Потоки: пользователь загружает документ через API; пользователь запрашивает документ по идентификатору.

Требование: REQ-DOC-01 - «Документ доступен только пользователю-владельцу. Запрос документа другим аутентифицированным пользователем возвращает HTTP 403».

Граница доверия: в этом примере она проходит между клиентом и серверным приложением. Проверка доступа к документу выполняется в бизнес-логике за API-шлюзом; клиент не принимает решение об авторизации.

Будущий тест: создать двух пользователей (A и B), загрузить документ от имени A, запросить его от имени B - ожидаемый результат: 403 Forbidden. Для требования назначают ответственного и связывают его с этим тестом.

Отдельная политика доступа: общая инструкция (FAQ) имеет собственную разрешающую политику - доступ открыт всем аутентифицированным пользователям. Это не исключение из REQ-DOC-01, а отдельная запись в матрице авторизации с явным владельцем и обоснованием.

Безопасная архитектура приложений и границы доверия (Фаза 2.2)​

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

Недостатки архитектуры проще исправить до того, как решения закреплены в коде и зависимостях. WSTG приводит два конкретных паттерна:

• Если архитектура предполагает принятие решений об авторизации в нескольких местах - стоит рассмотреть центральный компонент авторизации.
• Если валидация данных выполняется в нескольких точках - целесообразно создать центральный фреймворк валидации. Общий механизм упрощает согласованное исправление правил валидации; конкретная экономия зависит от системы.

Найденные недостатки обсуждают с системным архитектором и подбирают способы их устранения.

На что обращать внимание при security design review:

• Границы доверия. Где данные переходят между компонентами с разным уровнем доверия? Такие границы бывают и внутри системы — например, между сервисами с разными полномочиями. Избыточная сложность механизмов защиты (CWE-637) увеличивает вероятность ошибок - чем хитрее схема, тем больше мест, где можно ошибиться. CWE-561 описывает недостижимый код. Его наличие само по себе не доказывает расширение поверхности атаки, но доступные извне ненужные функции нужно проверять отдельно.
• Управление секретами. Техника Credentials In Files (T1552.001, Credential Access) описывает поиск учётных данных в файлах. При проверке конфигурации оценивают права доступа, попадание секретов в репозиторий, резервные копии и логи. Само наличие конфигурационного файла ещё не означает компрометацию.
• Межсервисная аутентификация. Как сервисы подтверждают идентичность вызывающей стороны и проверяют её полномочия? Выбор взаимного TLS или другого механизма зависит от архитектуры и модели угроз. Главное - чтобы этот выбор был зафиксирован, а не «сервисы ходят друг к другу по HTTP внутри VPC, значит безопасно».
• Сторонние интеграции. Compromise Software Supply Chain (T1195.002, Initial Access) относится к компрометации программных компонентов и цепочки их поставки. Для внешнего API отдельно фиксируют передаваемые данные и последствия компрометации провайдера - не каждый такой сценарий относится к T1195.002, но думать об этом нужно заранее.

Диаграммы потоков и UML как артефакты проверки (Фаза 2.3)​

После завершения проектирования строятся UML-модели (Unified Modeling Language), описывающие работу приложения. Иногда они уже существуют. По моделям проверяющие вместе с проектировщиками уточняют, как работает система.

На диаграмме нужны штатная ветвь (happy path), альтернативные сценарии и ошибочные ветви. Схема успешного потока не показывает, как система обрабатывает отказы, и сама по себе не подтверждает отсутствие уязвимостей.

Учебный пример 2: интеграция с внешним почтовым сервисом

Проектируется интеграция с внешним сервисом отправки email для уведомлений пользователей.

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

Дополнение для проверки - два сценария отказа:

1. Ответ не получен за отведённое время (timeout) либо сервис ответил HTTP 503.
2. Почтовый сервис возвращает неожиданный ответ (невалидный JSON, HTTP 200 с телом ошибки).

Ожидаемое поведение:

• При тайм-ауте результат отправки неизвестен: сервис мог принять запрос, а ответ — потеряться. Повтор допустим после подтверждения, что операция не выполнена, либо с поддерживаемым провайдером ключом идемпотентности, одинаковым для всех попыток одного уведомления. Если API не позволяет безопасно повторить запрос, автоматический повтор не выполняется. Для повторяемых временных ошибок, включая HTTP 503, задают задержку и предел попыток. Пока результат неизвестен, клиенту показывают «ожидаем подтверждение»; при постановке в очередь повтора — «уведомление отложено». Детали внутренней инфраструктуры (имя хоста, порт, стек вызовов) в ответ не попадают.
• При неожиданном ответе приложение не отображает содержимое ответа внешнего сервиса клиенту - это снижает риск утечки через этот ответ. CWE-209 описывает раскрытие чувствительных сведений в сообщении об ошибке. Защиту транспортного канала проверяют отдельно: CWE-319 относится к передаче чувствительных данных без шифрования.

Проверка ошибочных ветвей: успешная отправка письма не заменяет проверки отказов. В модель включают потерю ответа, HTTP 503 и некорректный ответ. Для каждой ветви задают ожидаемый статус, условия повтора и отсутствие дубликатов.

Threat modeling на этапе проектирования (Фаза 2.4)​

На основе обзора архитектуры и моделей работы системы команда строит модель угроз и разбирает реалистичные сценарии. В этой главе WSTG перечислены три способа обработки риска:

1. Митигация - техническая или процессная мера снижения риска.
2. Принятие бизнесом - осознанное решение принять риск с документированным обоснованием.
3. Передача части риска третьей стороне — например, страхование финансовых последствий. Саму техническую угрозу это не устраняет.

Если для выявленной угрозы нет стратегии обработки - архитектура пересматривается совместно с системным архитектором.

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

1. Над чем мы работаем? - описание системы, активов, потоков данных.
2. Что может пойти не так? - идентификация угроз через STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege), деревья атак или kill chains.
3. Что мы будем с этим делать? - выбор стратегии для каждой угрозы.
4. Хорошо ли мы справились? - валидация полноты и адекватности.

Моделирование угроз применяется непрерывно на протяжении проекта. На разных уровнях абстракции процесс одинаков, но детализация нарастает по мере продвижения по жизненному циклу.

Из модели угроз получают конкретные задачи. Для риска доступа к чужому документу через IDOR нужна серверная проверка владельца. Её проверяют тестом: пользователь B запрашивает документ пользователя A и получает отказ. Решение по каждой угрозе фиксируют в реестре с ответственным. Для мер снижения риска определяют способ проверки; принятое бизнесом решение не обязательно оформлять как задачу разработки; обоснование этого решения сохраняют в реестре.

Цепочка трассируемости на практике​

В практическом примере ниже каждой фазе сопоставлены артефакт и результат проверки. Это один из способов организовать работу по WSTG:


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

Источник: The Web Security Testing Framework, OWASP Foundation и авторы WSTG. Перевод и адаптация фаз 1–2; ссылка ведёт на обновляемую ветку master официального репозитория.

Дополнительные первичные материалы:

• NIST SSDF 1.1, SP 800-218, модель OWASP SAMM, уровни OWASP ASVS 5.0.0.
• OWASP Threat Modeling, предотвращение IDOR.
• RFC 9110: идемпотентность и повтор запросов.
• MITRE ATT&CK: Credentials In Files, T1552.001, Compromise Software Supply Chain, T1195.002.
• MITRE CWE: недостижимый код, CWE-561, избыточная сложность защиты, CWE-637, данные в сообщении об ошибке, CWE-209, передача без шифрования, CWE-319.

Русский перевод и редакционная актуализация: Codeby.

Изменения относительно оригинала:

• Перевод на русский язык с сохранением структуры.
• Добавлены таблицы метрик и артефактов.
• Добавлены два учебных примера (личный кабинет, интеграция с почтовым сервисом) со штатными и негативными ветвями, отсутствующие в оригинале.
• Уточнены ссылки на смежные фреймворки: NIST SSDF 1.1 (SP 800-218), OWASP ASVS 5.0.0, OWASP SAMM v2, OWASP Threat Modeling.
• Добавлены ссылки на MITRE ATT&CK и CWE для контекста угроз.

Лицензия перевода и адаптации: CC BY-SA 4.0.

Вся серия WSTG · Предыдущая статья