Планирование проверки и оценка риска

В лабораторном интернет-магазине три роли: гость, покупатель и администратор. С чего начать проверку - запустить сканер, проверить вход или попробовать утянуть чужой заказ? Ответ зависит от того, какие данные нужно защитить и что тестировщику разрешено делать. На этом учебном примере разберём, как выбрать приоритеты, задать границы работы и связать каждый тест с конкретным требованием.

Эта статья - адаптированный перевод разделов 2.4 (Core Principles of Effective Security Testing) и 4.0 (Introduction and Objectives) руководства OWASP Web Security Testing Guide. Цель - показать, как превратить бизнес-риск и согласованный scope в воспроизводимый план проверки, не обещая абсолютной безопасности.

Актив, угроза, уязвимость и цель проверки​

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

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

Актив - ресурс, имеющий ценность. В магазине это данные заказов покупателей (ФИО, адрес, состав корзины) и административная панель управления товарами. Каталог товаров тоже актив: читать его разрешено всем, но изменение цен и доступность каталога требуют отдельной защиты.

Угроза - всё, что может нанести ущерб активу, эксплуатируя уязвимость. По определению OWASP: внешний злоумышленник, внутренний пользователь или системная нестабильность. В нашем сценарии угроза - покупатель B, который пытается прочитать заказ покупателя A через прямое обращение к API.

Уязвимость - дефект в проектировании, реализации, эксплуатации или управлении системой, который можно использовать для нарушения целей безопасности. В магазине - отсутствие проверки авторизации на эндпоинте /api/orders/{id}: сервер отдаёт заказ любому аутентифицированному пользователю, не сверяя владельца.

Тест - действие, позволяющее проверить соответствие приложения требованиям безопасности. Цель проверки задаёт, какое требование нужно подтвердить. Здесь цель - убедиться, что покупатель B не может получить данные заказа покупателя A, а тест - запрос чужого заказа из его учётной записи.

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

WSTG - открытый проект: специалисты совместно обсуждают и описывают методы тестирования, материалы доступны бесплатно. Исчерпывающего списка уязвимостей руководство не обещает, поэтому методы нужно сочетать, а выполненные проверки - документировать. В разделе 4.0 описана модель "чёрного ящика": тестировщик почти ничего не знает о внутреннем устройстве приложения и исследует его с помощью выбранных инструментов и методологии. Описания проверок должны позволять повторить действия и проверить обоснованность выводов.

Шесть принципов тестирования безопасности​

Раздел 2.4 OWASP WSTG формулирует шесть принципов, на которых строится эффективное тестирование. Они помогают выбрать методы проверки и связать их с риском для приложения.

Нет универсального средства​

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

Документация ZAP Active Scan предупреждает об ограничениях обычного сканирования при поиске логических ошибок, включая нарушение контроля доступа (broken access control). Такие сценарии тестировщик проектирует по правилам приложения, а их выполнение можно частично автоматизировать. Например, ZAP Access Control Testing проверяет доступ к URL от разных пользователей после настройки учётных записей и ожидаемых прав.

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

Непрерывное тестирование​

Классический подход - тестировать только после завершения разработки - расточителен. Раздел 2.4 WSTG подчёркивает: позднее обнаружение дефекта усложняет исправление. Проверка при проектировании позволяет изменить решение до того, как на нём построены другие части системы.

Современные практики интегрируют тестирование на всех этапах:

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

В CI/CD-пайплайны можно добавить базовые проверки SAST и зависимостей, чтобы выполнять их при каждой сборке.

Приоритизация по риску и влиянию​

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

Для веб-приложений OWASP предлагает отдельную модель скоринга - OWASP Risk Rating Methodology, где Risk = Likelihood x Impact. Факторы вероятности включают характеристики агента угрозы и уязвимости; факторы воздействия - технический ущерб и бизнес-последствия. Это самостоятельный фреймворк, который не следует путать ни с OWASP ASVS (каталог требований верификации безопасности, версия 5.0.0), ни с самой методологией тестирования WSTG.

NIST SP 800-30 Rev. 1 - отдельное руководство по оценке рисков информационных систем. В учебном примере ниже используется модель OWASP; это выбор для этого разбора, а не обязательная модель для любого веб-приложения.

Сбалансированный подход​

Ни одна техника тестирования не закрывает все потребности в одиночку. План проверки сочетает:

• Ручной анализ и обзор дизайна - оценка политик, архитектуры и процессов безопасности
• Моделирование угроз - раннее выявление векторов атак в жизненном цикле
• Ревью исходного кода - обнаружение тонких дефектов (ошибки бизнес-логики, криптографические слабости, состояния гонки), которые инструменты часто пропускают или которые трудно найти из чёрного ящика
• Пентест - подтверждение эксплуатируемости уязвимостей и понимание реального воздействия
• Автоматизированное сканирование (SAST, DAST, SCA) - поиск распространённых известных уязвимостей в большом объёме кода и запросов

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

Понятный и действенный отчёт​

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

• Объяснять, что тестировалось и как (чтобы результат можно было воспроизвести)
• Описывать корневую причину каждой проблемы (чтобы снизить вероятность повторения)
• Давать конкретные рекомендации по устранению или ссылку на руководство по безопасной разработке
• Присваивать уровень критичности для приоритизации исправлений
• Объяснять бизнес-влияние, чтобы владельцы продукта понимали последствия уязвимости и приоритет исправления

Адаптация к контексту​

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

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

Scope и правила взаимодействия​

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

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


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

Пассивное тестирование: наблюдение без вмешательства​

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

При пассивном тестировании тестировщик стремится понять логику приложения и исследует его как обычный пользователь. Для сбора информации применяются инструменты - например, HTTP(S)-прокси для перехвата всех запросов и ответов.

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

Пример для магазина. Тестировщик проходит полный пользовательский путь: регистрация, просмотр каталога, добавление в корзину, оформление заказа, просмотр истории. В условном примере прокси фиксирует запросы к эндпоинтам: /api/products, /api/cart, /api/orders, /api/users/me. Обнаруживается, что при просмотре заказа URL содержит числовой ID:
Это наблюдение, а не атака. Ни один параметр не изменяется - тестировщик просто картирует поведение. В запросе к /appx?a=1&b=1 параметры a и b - две точки входа, каждая из которых станет целью при активном тестировании.

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

Активное тестирование: гипотеза, запрос, контроль, эффект​

В тексте WSTG 4.0 активные проверки разделены на 12 категорий: сбор информации; конфигурация и управление развёртыванием; управление идентификационными данными; аутентификация; авторизация; управление сессиями; инъекции; обработка ошибок; слабая криптография; бизнес-логика; клиентская часть; API. Это перечень именно из введения 4.0. Отдельный структурный индекс раздела 4 также содержит категорию WebAssembly; содержание этого индекса здесь не переводится целиком.

Логика каждого активного теста: гипотеза -> запрос -> ожидаемый контроль -> наблюдаемый эффект.

Учебный пример: копия приложения с синтетическими заказами и запретом изменения платёжных данных.

Гипотеза: покупатель B может прочитать заказ покупателя A через IDOR.
Ожидаемый контроль: сервер отклоняет доступ к чужому заказу - возвращает HTTP 403 или 404 согласно контракту API и не раскрывает данные заказа. Допустим, в учебном сценарии вместо этого получен HTTP 200 с JSON и адресом доставки покупателя A. Такой результат означал бы нарушение авторизации. Это условие примера; реальный вывод требует сохранённой пары запрос-ответ.

Что не проверяем: изменение платёжных данных (PUT /api/orders/{id}/payment) исключено из scope. В отчёте для этого сценария ставят "Не проверено" и указывают согласованное ограничение.

Для исключённых областей план должен содержать безопасные эквиваленты (если возможно) и явный перечень непроверенных сценариев. Если scope допускает отдельную проверку валидации платёжного эндпоинта без изменения записей, её можно провести на подготовленном тестовом объекте. Само по себе невалидное значение не гарантирует отсутствия побочных эффектов. Если безопасный вариант не согласован, сценарий остаётся непроверенным; проверка валидации не заменяет проверку запрета изменения суммы.

Приоритизация по риску и матрица покрытия​

Приоритеты помогают распределить ограниченное время тестировщика между сценариями. Матрица строится по принципу: актив -> угроза -> сценарий проверки -> артефакт доказательства.

Учебная матрица для лабораторного магазина: три роли, четыре актива.

Владелец перечисленных рисков в этом примере - владелец магазина. Он согласует допуск: чтение синтетических заказов, проверку доступа к админ-панели и изменение тестового товара; операции с платёжными записями исключены. Приоритеты условны и требуют оценки для конкретного приложения.

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


Три статуса, которые нельзя путать:

• Проверено (PASS / FAIL) - тест выполнен, есть артефакт. Для каждого риска зафиксированы владелец, допуск и наблюдаемое условие успеха
• N/A - сценарий не является угрозой в этом контексте. Общедоступный каталог, доступный гостю, - ожидаемое поведение, не утечка
• Не проверено - тест не выполнен из-за ограничений scope, времени или доступа. Это не PASS. Каждый такой сценарий попадает в отчёт с указанием причины

Шаблон доказательства для того же учебного сценария IDOR.


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

Выходной пакет плана проверки​

Перед началом работы план должен содержать следующие сведения.

Доступы. Учётные записи, токены и VPN-подключения для каждой роли. Если доступ не предоставлен, в плане указывают зависимые от него сценарии.

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

Порядок тестов. Сначала картируют обычное поведение приложения (пассивная фаза). Активные тесты следуют по приоритету из матрицы рисков: сначала высокорисковые (авторизация, аутентификация), затем средние и низкие. Так наиболее важные сценарии получают время в начале окна. Если выполнить их не удалось, причина и оставшийся риск должны попасть в отчёт.

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

Условия повторной проверки. После устранения уязвимости заказчик запрашивает retest. План фиксирует: какие находки подлежат повторной проверке, в какой срок и какой артефакт подтверждает исправление.

Непроверенные области. Отдельный раздел с перечнем сценариев, которые не были выполнены, причиной исключения и рекомендацией - проверить в следующей итерации или запросить расширенный scope.

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

Попробуйте взять свой ближайший проект и заполнить матрицу покрытия хотя бы для трёх активов. Сколько сценариев окажется в статусе "Не проверено"?



Источники и лицензия

Основа: OWASP Web Security Testing Guide, OWASP Foundation.

Использованные разделы:

• 2.4 Core Principles of Effective Security Testing - снимок 2026-10-17
• 4. Web Application Security Testing - структурный индекс категорий, снимок 2026-10-17
• 4.0 Introduction and Objectives - снимок 2026-10-17

Дополнительные источники:

• OWASP Risk Rating Methodology - модель Risk = Likelihood x Impact
• OWASP ASVS - каталог требований верификации безопасности (v5.0.0)
• NIST SP 800-30 Rev. 1 - руководство по оценке рисков информационных систем
• ZAP Active Scan - ограничения активного сканирования
• ZAP Access Control Testing - проверка доступа по заданным пользователям и правилам

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

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

• Добавлен сквозной сценарий лабораторного магазина с тремя ролями
• Добавлена учебная матрица покрытия с тремя статусами (Проверено / N/A / Не проверено); её результаты условны
• Добавлен пример заполнения шаблона доказательства; реальных результатов проверки он не содержит
• Раздел scope расширен: разрешённые действия, ограничения и условия остановки
• Уточнены ограничения автоматического сканирования по документации ZAP
• OWASP Risk Rating Methodology и ASVS разграничены как самостоятельные проекты

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

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