OWASP Web Security Testing Guide (WSTG) — открытый стандарт, который превращает хаотичный перебор техник в структурированный процесс. Без него пентестер рискует пропустить целые классы уязвимостей или потратить часы на проверку того, что не относится к scope. Гайд не заменяет опыт и не содержит готовых эксплойтов — он задаёт систему координат: что проверять, в каком порядке и как документировать результат.
Актуальная версия доступна на сайте проекта: OWASP Web Security Testing Guide | OWASP Foundation и в репозитории GitHub - OWASP/wstg: The Web Security Testing Guide is a comprehensive Open Source guide to testing the security of web applications and web services..
WSTG — это не чек-лист в привычном смысле. Это методология, разбитая на категории, каждая из которых содержит набор тестовых сценариев (test cases). Каждый сценарий описывает конкретную проверку: цель, технику, инструменты и критерии оценки результата.
Гайд решает три задачи:
WSTG организует тесты по двенадцати категориям. Каждая категория соответствует определённому аспекту безопасности приложения:
Порядок категорий в гайде отражает типичную последовательность пентеста: сначала разведка, затем аутентификация и авторизация, потом работа с вводом и логикой.
Каждый тестовый сценарий в WSTG имеет унифицированную структуру:
При чтении важно понимать: раздел «How to Test» описывает технику, а не готовый эксплойт. Пентестер адаптирует её под конкретное приложение, контекст и scope.
До начала тестирования необходимо зафиксировать scope (какие хосты, пути, роли и функции входят в разрешение). Затем выполняется mapping: какие категории WSTG релевантны для данного приложения.
Не каждый тест применим к каждому приложению. Например, если приложение не использует сессии (stateless API с JWT), тесты из Session Management частично теряют смысл, но API Testing становится приоритетом.
Разведка по WSTG включает:
Результат этого этапа — карта приложения, которая определяет, какие тесты выполнять дальше.
Тесты выполняются в логическом порядке. Аутентификация проверяется до авторизации, потому что для тестирования privilege escalation нужны учётные записи с разными ролями. Input Validation тестируется после того, как найдены все точки входа.
Для каждого теста фиксируется:
Идентификаторы WSTG удобно использовать в отчёте как ссылки на методологию. Вместо длинного описания техники достаточно указать: «Проверка выполнена по WSTG-INPV-05 (Testing for SQL Injection)». Это делает отчёт воспроизводимым и понятным для заказчика.
WSTG и OWASP Top 10 — разные документы с разными задачами. Top 10 — рейтинг наиболее критичных рисков, ориентированный на разработчиков и менеджеров. WSTG — операционная методология для пентестера.
Каждый тест WSTG содержит ссылку на соответствующий элемент Top 10 и CWE. Это позволяет:
Гайд не привязан к конкретному инструменту, но в каждом тесте перечислены подходящие. Типичный набор:
Burp Suite Community Edition позволяет выполнять большинство тестов WSTG бесплатно. Для автоматизированного сканирования и расширенных возможностей нужна Professional-версия.
Дополнительный ресурс для практики — PortSwigger Web Security Academy (Web Security Academy: Free Online Training from PortSwigger). Она содержит интерактивные лаборатории, которые соотносятся с категориями WSTG и позволяют отработать техники на учебных целях без риска для реальных систем.
Слепое следование порядку без учёта контекста. WSTG предлагает структуру, но не требует механического прохождения всех тестов подряд. Если приложение — одностраничный SPA с JWT, начинать стоит с API Testing и Client-side Testing, а не с классической разведки серверных заголовков.
Подмена тестирования сканированием. Автоматический сканер покрывает часть тестов WSTG, но не заменяет ручную проверку. Business Logic, Authorization, сложные цепочки Input Validation — всё это требует понимания контекста приложения.
Отсутствие фиксации «не применимо». Если тест не выполнен, потому что не относится к приложению, это нужно задокументировать. Иначе при повторном тестировании или аудите отчёта возникнет вопрос: проверка пропущена или не релевантна?
Игнорирование remediation-секции. Раздел с рекомендациями по исправлению помогает понять, что именно считается уязвимостью, а что — допустимым поведением. Без этого пентестер может записать false positive или пропустить реальную проблему.
Использование WSTG как единственного источника. Гайд не покрывает специфичные технологии (например, особенности безопасности WebSocket, gRPC, serverless-функций) в полной мере. Для них нужны дополнительные источники и понимание архитектуры.
WSTG развивается: сообщество добавляет новые тесты, обновляет существующие под современные угрозы. При использовании гайда стоит проверять, что вы работаете с актуальной версией. Репозиторий на GitHub содержит историю изменений и позволяет отслеживать, какие тесты добавлены или переработаны.
Основные изменения в последних версиях касались расширения категории API Testing (в связи с ростом популярности REST и GraphQL), добавления тестов для client-side storage и уточнения техник для современных фреймворков.
WSTG не делает пентестера экспертом — он даёт систему, внутри которой опыт накапливается предсказуемо. Начинать стоит с одной-двух категорий, доводить тесты до конца, фиксировать результаты и постепенно расширять покрытие.
Актуальная версия доступна на сайте проекта: OWASP Web Security Testing Guide | OWASP Foundation и в репозитории GitHub - OWASP/wstg: The Web Security Testing Guide is a comprehensive Open Source guide to testing the security of web applications and web services..
Что WSTG из себя представляет
WSTG — это не чек-лист в привычном смысле. Это методология, разбитая на категории, каждая из которых содержит набор тестовых сценариев (test cases). Каждый сценарий описывает конкретную проверку: цель, технику, инструменты и критерии оценки результата.
Гайд решает три задачи:
- Полнота покрытия. Категории охватывают весь жизненный цикл веб-приложения: от разведки до клиентской логики и API.
- Воспроизводимость. Два пентестера, following WSTG, проверят один и тот же набор векторов и смогут сравнить результаты.
- Документирование. Идентификаторы тестов (например, WSTG-ATHN-01) позволяют ссылаться на конкретную проверку в отчёте без длинных описаний.
Структура категорий
WSTG организует тесты по двенадцати категориям. Каждая категория соответствует определённому аспекту безопасности приложения:
| Категория | Что покрывает | Примеры тестов |
|---|---|---|
| Information Gathering | Разведка, fingerprinting, поиск точек входа | Определение веб-сервера, перечисление приложений |
| Configuration and Deployment Management | Настройки сервера, инфраструктуры, CI/CD | Проверка дефолтных учётных данных, анализ файлов конфигурации |
| Identity Management | Роли, регистрация, управление пользователями | Тестирование механизмов регистрации и provisioning |
| Authentication | Механизмы входа, устойчивость к брутфорсу | Проверка политик паролей, обход аутентификации |
| Authorization | Контроль доступа, privilege escalation | Горизонтальное и вертикальное повышение привилегий |
| Session Management | Создание, хранение, инвалидация сессий | Предсказуемость токенов, фиксация сессии |
| Input Validation | Обработка пользовательского ввода | SQL-инъекции, XSS, command injection, SSRF |
| Error Handling | Поведение при ошибках, утечка информации | Анализ stack trace, кодов ошибок |
| Cryptography | Защита данных при передаче и хранении | Проверка TLS, анализ хранения секретов |
| Business Logic | Логические уязвимости бизнес-процессов | Обход ограничений, манипуляция потоками |
| Client-side Testing | Безопасность на стороне браузера | DOM XSS, проверка postMessage, локальное хранение |
| API Testing | Специфика REST/GraphQL/SOAP endpoints | Проверка rate limiting, mass assignment, BOLA |
Порядок категорий в гайде отражает типичную последовательность пентеста: сначала разведка, затем аутентификация и авторизация, потом работа с вводом и логикой.
Анатомия test case
Каждый тестовый сценарий в WSTG имеет унифицированную структуру:
- Идентификатор — формат
WSTG-XXXX-NN, где XXXX — код категории, NN — порядковый номер. Например, WSTG-INPV-05 относится к Input Validation.
- Objective — что именно проверяется и почему это важно.
- How to Test — пошаговое описание техники. Здесь указываются конкретные действия: какие запросы отправлять, какие параметры менять, на что обращать внимание в ответе.
- Remediation — рекомендации по устранению найденной проблемы. Полезно для отчёта и для понимания, что именно считается уязвимостью.
- References — ссылки на стандарты (CWE, OWASP Top 10), RFC и дополнительные материалы.
- Tools — перечень инструментов, которые упрощают проверку.
При чтении важно понимать: раздел «How to Test» описывает технику, а не готовый эксплойт. Пентестер адаптирует её под конкретное приложение, контекст и scope.
Рабочий процесс применения WSTG
Шаг 1: Определение scope и mapping
До начала тестирования необходимо зафиксировать scope (какие хосты, пути, роли и функции входят в разрешение). Затем выполняется mapping: какие категории WSTG релевантны для данного приложения.
Не каждый тест применим к каждому приложению. Например, если приложение не использует сессии (stateless API с JWT), тесты из Session Management частично теряют смысл, но API Testing становится приоритетом.
Шаг 2: Information Gathering
Разведка по WSTG включает:
- Определение технологий (веб-сервер, фреймворк, WAF, CDN).
- Поиск скрытых путей и файлов (directory brute-force, анализ robots.txt, sitemap).
- Идентификация точек входа: формы, параметры URL, заголовки, API endpoints.
- Сбор информации из публичных источников (DNS-записи, сертификаты, архивные версии).
Результат этого этапа — карта приложения, которая определяет, какие тесты выполнять дальше.
Шаг 3: Последовательное прохождение категорий
Тесты выполняются в логическом порядке. Аутентификация проверяется до авторизации, потому что для тестирования privilege escalation нужны учётные записи с разными ролями. Input Validation тестируется после того, как найдены все точки входа.
Для каждого теста фиксируется:
- Что проверялось (идентификатор WSTG).
- Какой запрос или действие выполнялось.
- Какой результат получен.
- Классификация: уязвимость найдена / не найдена / не применимо.
Шаг 4: Документирование и отчёт
Идентификаторы WSTG удобно использовать в отчёте как ссылки на методологию. Вместо длинного описания техники достаточно указать: «Проверка выполнена по WSTG-INPV-05 (Testing for SQL Injection)». Это делает отчёт воспроизводимым и понятным для заказчика.
Связь с OWASP Top 10
WSTG и OWASP Top 10 — разные документы с разными задачами. Top 10 — рейтинг наиболее критичных рисков, ориентированный на разработчиков и менеджеров. WSTG — операционная методология для пентестера.
Каждый тест WSTG содержит ссылку на соответствующий элемент Top 10 и CWE. Это позволяет:
- В отчёте для разработки ссылаться на CWE-идентификаторы.
- В отчёте для менеджмента привязывать находки к Top 10.
- При планировании тестирования расставлять приоритеты на основе актуального Top 10.
Инструменты и WSTG
Гайд не привязан к конкретному инструменту, но в каждом тесте перечислены подходящие. Типичный набор:
- Прокси и перехват запросов — Burp Suite (Community или Professional), OWASP ZAP.
- Сканеры — Nikto, Nuclei (с шаблонами, маппинг на WSTG поддерживается сообществом).
- Fuzzing и брутфорс — ffuf, Gobuster, Hydra (для аутентификации).
- Анализ JavaScript — LinkFinder, JSBeautifier, встроенные возможности Burp.
Burp Suite Community Edition позволяет выполнять большинство тестов WSTG бесплатно. Для автоматизированного сканирования и расширенных возможностей нужна Professional-версия.
Дополнительный ресурс для практики — PortSwigger Web Security Academy (Web Security Academy: Free Online Training from PortSwigger). Она содержит интерактивные лаборатории, которые соотносятся с категориями WSTG и позволяют отработать техники на учебных целях без риска для реальных систем.
Типичные ошибки при работе с WSTG
Слепое следование порядку без учёта контекста. WSTG предлагает структуру, но не требует механического прохождения всех тестов подряд. Если приложение — одностраничный SPA с JWT, начинать стоит с API Testing и Client-side Testing, а не с классической разведки серверных заголовков.
Подмена тестирования сканированием. Автоматический сканер покрывает часть тестов WSTG, но не заменяет ручную проверку. Business Logic, Authorization, сложные цепочки Input Validation — всё это требует понимания контекста приложения.
Отсутствие фиксации «не применимо». Если тест не выполнен, потому что не относится к приложению, это нужно задокументировать. Иначе при повторном тестировании или аудите отчёта возникнет вопрос: проверка пропущена или не релевантна?
Игнорирование remediation-секции. Раздел с рекомендациями по исправлению помогает понять, что именно считается уязвимостью, а что — допустимым поведением. Без этого пентестер может записать false positive или пропустить реальную проблему.
Использование WSTG как единственного источника. Гайд не покрывает специфичные технологии (например, особенности безопасности WebSocket, gRPC, serverless-функций) в полной мере. Для них нужны дополнительные источники и понимание архитектуры.
Версионирование и обновления
WSTG развивается: сообщество добавляет новые тесты, обновляет существующие под современные угрозы. При использовании гайда стоит проверять, что вы работаете с актуальной версией. Репозиторий на GitHub содержит историю изменений и позволяет отслеживать, какие тесты добавлены или переработаны.
Основные изменения в последних версиях касались расширения категории API Testing (в связи с ростом популярности REST и GraphQL), добавления тестов для client-side storage и уточнения техник для современных фреймворков.
Практический чек-лист перед началом тестирования
- Scope зафиксирован письменно, границы определены.
- Выбрана актуальная версия WSTG.
- Выполнен mapping: какие категории применимы к целевому приложению.
- Настроены инструменты (прокси, сканер, fuzzing).
- Определён формат фиксации результатов (таблица, трекер, шаблон отчёта).
- Для каждого теста planned статус: будет выполнен / не применим / отложен.
- Согласованы правила взаимодействия с заказчиком при обнаружении критичных уязвимостей.
WSTG не делает пентестера экспертом — он даёт систему, внутри которой опыт накапливается предсказуемо. Начинать стоит с одной-двух категорий, доводить тесты до конца, фиксировать результаты и постепенно расширять покрытие.
