По данным OWASP, 94% протестированных веб-приложений содержат ту или иную форму нарушения контроля доступа. Но вот что не попадает в статистику: большинство этих уязвимостей остаются невидимыми для автоматических сканеров. OWASP ZAP честно отрабатывает свой чеклист, Nuclei прогоняет тысячи шаблонов - а потом пентестер открывает Burp Suite Repeater, вручную меняет один параметр в запросе и получает доступ к чужим данным через банальный IDOR. Именно здесь проходит граница между "отчётом сканера" и "результатом пентеста". Эта статья - карта всего процесса тестирования безопасности веб-приложений: от выбора методологии и подготовки окружения до эксплуатации конкретных классов уязвимостей и написания отчёта.
Карта темы: навигация по руководству
| # | Подтема | Подробнее |
|---|---|---|
| 1 | Методология: OWASP WSTG, PTES и как выбрать подход | Раздел ниже |
| 2 | Фазы пентеста веб-приложений от разведки до отчёта | Раздел ниже |
| 3 | OWASP Top 10: что изменилось и почему это важно для пентестера | Пентест веб-приложений по OWASP Top 10: что пропускают сканеры |
| 4 | Инструменты: Burp Suite, Nuclei, sqlmap и когда чего не хватает | Burp Suite Extensions: шпаргалка по OWASP Top 10 2026 |
| 5 | Injection-атаки: SQL, CRLF, Command Injection | SQL инъекция в 2026 |
| 6 | XSS: поиск, эксплуатация и реальный импакт | XSS уязвимость на практике |
| 7 | SSRF: от чтения метаданных до RCE через цепочку | SSRF уязвимость: поиск и цепочки атак |
| 8 | Нарушение контроля доступа и обход аутентификации | CVE-2026-41940: обход аутентификации cPanel/WHM (проверьте актуальность ссылки перед публикацией) |
| 9 | Path Traversal и файловые уязвимости | Grav CMS: 0-day path traversal |
| 10 | Ручное тестирование vs автоматизация: когда что работает | Раздел ниже |
| 11 | Как выбрать вектор атаки: decision tree для пентестера | Раздел ниже |
Что такое пентест веб-приложений и чем он отличается от сканирования
Тестирование безопасности веб-приложений - контролируемая имитация атаки на веб-систему с разрешения владельца. Цель - обнаружить уязвимости до того, как их найдёт реальный злоумышленник. Отличие от автоматизированного сканирования (DAST) принципиальное: сканер ищет паттерны, пентестер ищет логику.
Типичный пример: автоматический сканер обнаружит отражённый XSS в параметре поиска, но полностью пропустит Broken Object Level Authorization, при которой замена
order_id=1234 на order_id=1235 в API-запросе отдаёт чужой заказ. Этот класс уязвимостей - Broken Access Control (A01:2021 по OWASP Top 10) - обнаруживается только при ручном анализе бизнес-логики. Сканеру попросту неоткуда знать, что 1235 - это не ваш заказ.Пентест веб-приложений делится по уровню знаний тестировщика:
- Black box - пентестер не имеет учётных данных и внутренней документации. Имитирует внешнего атакующего. Подходит для проверки периметра и публичных сервисов.
- Grey box - пентестер получает учётные данные обычного пользователя (low-privileged) или частичную документацию API. Самый частый сценарий в реальных проектах: заказчик выдаёт тестовые аккаунты, чтобы сосредоточить усилия на проверке авторизации и эскалации привилегий.
- White box - полный доступ к исходному коду и архитектуре. Позволяет совмещать SAST (статический анализ) с ручной проверкой. Требует больше времени, даёт максимальное покрытие.
3 методологии пентеста, которые реально используют на проектах
Выбор методологии определяет структуру всего проекта. По данным deepstrike.io, зрелый провайдер тестирования должен быть "полиметодологом", комбинируя подходы под конкретный контекст.
OWASP Web Security Testing Guide (WSTG)
WSTG - открытый стандарт от сообщества OWASP. Это не полная методология жизненного цикла проекта, а исчерпывающий чеклист технических проверок для веб-приложений. Текущая стабильная версия - 4.2, в разработке - 5.0. Каждый тест-кейс имеет идентификатор форматаWSTG-<категория>-<номер>, например WSTG-INFO-02 для fingerprinting веб-сервера.На практике WSTG используется как технический справочник на этапах обнаружения и эксплуатации уязвимостей. Надо проверить Broken Access Control - открываешь соответствующую секцию WSTG и последовательно выполняешь тест-кейсы. Пересказывать спеку в сотый раз не вижу смысла - она хорошо структурирована и доступна бесплатно.
PTES (Penetration Testing Execution Standard)
PTES охватывает весь жизненный цикл проекта - от предварительных переговоров до финального отчёта. Семь фаз: Pre-engagement Interactions, Intelligence Gathering, Threat Modeling, Vulnerability Analysis, Exploitation, Post-Exploitation, Reporting. Из всех стандартов - самый практикоориентированный, написанный пентестерами для пентестеров. Без бюрократического жира.NIST SP 800-115
Формальная методология, востребованная в проектах с требованиями комплаенса (PCI DSS, FedRAMP). Обеспечивает структурированный аудиторский след и документирование каждого действия. Если заказчик - банк или госструктура, без NIST не обойтись. Для остальных - избыточна.Какую выбрать. Для типового проекта по тестированию веб-приложения оптимальная комбинация: PTES как рамка проекта + WSTG как технический чеклист внутри фаз Vulnerability Analysis и Exploitation. Для проектов с PCI DSS или другими стандартами добавляется NIST SP 800-115 как документационный каркас.
Подробный разбор того, как работать с OWASP-чеклистом на практике: Пентест веб-приложений по OWASP Top 10: что пропускают сканеры и как находить уязвимости в Burp Suite
7 фаз пентеста веб-приложений: от разведки до отчёта
Каждая фаза встраивается в цепочку атаки: разведка даёт входные точки, маппинг определяет поверхность атаки, обнаружение уязвимостей выявляет кандидатов на эксплуатацию, эксплуатация подтверждает импакт, пост-эксплуатация показывает масштаб ущерба.
Фаза 1: Pre-engagement и юридическое оформление
Без письменного разрешения владельца системы любое тестирование незаконно. Точка. Оформляется документ Rules of Engagement (RoE), в котором фиксируются: scope (какие домены, IP, API-эндпоинты тестируются), временные окна, экстренные контакты, перечень запрещённых действий (нагрузочное тестирование, DDoS). Это гарант того, что не прилетит звонок от заказчика в 2 ночи с вопросом "почему у нас лёг продакшн".Фаза 2: Разведка и сбор информации (OSINT + активная)
Цель - собрать максимум данных о цели. Пассивная разведка: поиск поддоменов черезsubfinder, анализ DNS-записей, Google Dorks для обнаружения индексированных конфигурационных файлов и админок. Активная разведка: fingerprinting технологий через Wappalyzer, сканирование портов с nmap -sV, перебор директорий с ffuf или feroxbuster.На этом этапе определяется стек технологий приложения: язык, фреймворк, веб-сервер, WAF. Это критически влияет на выбор дальнейших векторов - PHP-приложение и SPA на React тестируются совершенно по-разному.
Фаза 3: Маппинг приложения
Ползание (spidering) через Burp Suite для построения карты всех эндпоинтов, параметров и форм. Ручной обход функциональности приложения с включённым прокси для перехвата каждого запроса. Результат - полная карта поверхности атаки: где приложение принимает пользовательский ввод, где происходит аутентификация, где передаются идентификаторы объектов.Тут торопиться не стоит. Чем полнее карта - тем меньше шансов пропустить скрытый эндпоинт, в котором и сидит критическая уязвимость.
Фаза 4: Обнаружение уязвимостей
Комбинация автоматического и ручного подхода. Автоматика (Nuclei, Burp Scanner, Nikto) выявляет низковисящие плоды: известные CVE, стандартные мисконфигурации, отсутствие заголовков безопасности. Ручной анализ фокусируется на бизнес-логике: проверка горизонтальной и вертикальной эскалации привилегий, тестирование race conditions, анализ JWT-токенов через JWT Editor в Burp Suite.Фаза 5: Эксплуатация
Подтверждение уязвимости через controlled exploit. SQL-инъекция проверяется извлечением конкретных данных (не деструктивнымDROP TABLE, а SELECT version()). XSS - через proof-of-concept без кражи реальных сессий. SSRF - через обращение к контролируемому сервису (Burp Collaborator, interactsh). Правило простое: доказать импакт, ничего не сломав.Фаза 6: Пост-эксплуатация
Ответ на вопрос "и что дальше?". Получили доступ к базе данных через SQLi - какие данные можно извлечь? Обнаружили SSRF - можно ли через него прочитать метаданные облачной инфраструктуры и получить IAM-ключи? Именно эта фаза определяет реальный бизнес-импакт уязвимости. Без неё отчёт превращается в список технических находок без контекста "а что с этим может сделать атакующий".Фаза 7: Отчёт
Две аудитории - два раздела. Executive Summary для руководства: бизнес-риски, финансовый импакт, приоритеты исправления. Technical Findings для разработчиков: описание уязвимости, шаги воспроизведения, PoC, рекомендации по исправлению с примерами кода. Отчёт без PoC - это мнение. Отчёт с PoC - это факт.OWASP Top 10: почему пентестеру мало знать список наизусть
OWASP Top 10 - стандарт осведомлённости о наиболее критичных рисках безопасности веб-приложений. Текущая стабильная версия - OWASP Top 10 2021. Версия 2025 находится в стадии разработки (Release Candidate). Это не методология тестирования и не чеклист уязвимостей, а ранжированный список категорий рисков.
Для пентестера OWASP Top 10 работает как фильтр приоритетов: при ограниченном бюджете проекта в первую очередь проверяются категории с наибольшим импактом.
Broken Access Control (A01:2021) - лидер списка, обнаружен в 94% протестированных приложений (по данным OWASP). Включает IDOR, отсутствие проверки привилегий на серверной стороне, манипуляцию JWT-токенами. Автоматические сканеры почти бесполезны для этой категории: нужно понимать бизнес-логику и вручную проверять каждый эндпоинт с разными уровнями привилегий. Расширение Autorize для Burp Suite автоматизирует часть работы, но не заменяет ручной анализ.
Как это выглядит на практике: Autorize перехватывает запрос администратора и автоматически переигрывает его с токеном обычного пользователя. Если ответ сервера идентичен - Broken Access Control подтверждён. Просто и больно (для заказчика).
Injection (A03:2021) - SQL, NoSQL, OS Command, LDAP Injection. Несмотря на десятилетия борьбы, инъекции не исчезают: меняются контексты (ORM-инъекции, GraphQL), появляются новые WAF-обходы. Log4Shell (CVE-2021-44228, CVSS 10.0) - пример инъекции нового типа через JNDI lookup в Apache Log4j2, позволяющей выполнить произвольный код удалённо. Уязвимость затронула миллионы систем и включена в CISA KEV (10.12.2021) с подтверждённой эксплуатацией in-the-wild и использованием в ransomware-кампаниях; CISA SSVC decision - Act (EPSS: вероятность эксплуатации 0.94).
Детальный разбор SQL-инъекций с техниками обхода WAF: SQL инъекция в 2026: техники эксплуатации, обход WAF и автоматизация с sqlmap
Cryptographic Failures (A02:2021) - передача чувствительных данных открытым текстом, слабые алгоритмы хеширования паролей, утечки через API-ответы. Проверяется анализом HTTP-трафика в Burp Suite: наличие HTTPS, заголовки HSTS, содержимое ответов API на предмет избыточных данных. Иногда достаточно посмотреть на ответ
/api/user/profile, чтобы увидеть в нём хеш пароля - разработчики забывают фильтровать поля при сериализации.Insecure Design (A04:2021) - категория, которую не закрыть патчем. Дефекты архитектуры: отсутствие rate limiting на формах восстановления пароля, предсказуемые OTP-коды, недостаточная валидация бизнес-правил (отрицательная цена в корзине - да, такое встречается).
Разбор того, какие уязвимости пропускают сканеры и как работать с OWASP Top 10 через Burp Suite: Пентест веб-приложений по OWASP Top 10: что пропускают сканеры и как находить уязвимости в Burp Suite
Инструменты для пентеста веб-приложений: что выбрать и где каждый проседает
Нет универсального инструмента, закрывающего все фазы пентеста. Ниже - рабочий стек на реальных проектах с явными ограничениями каждого.| Инструмент | Фаза kill chain | Сильные стороны | Ограничения | Когда не использовать |
|---|---|---|---|---|
| Burp Suite Pro | Маппинг, обнаружение, эксплуатация | Интерактивный анализ, расширения (Autorize, JWT Editor, Turbo Intruder), работа с бизнес-логикой | Community Edition сильно урезана (нет активного сканера, ограничен Intruder); сканер даёт false positives на динамических приложениях | Для массового сканирования тысяч хостов |
| OWASP ZAP | Автоматическое сканирование, маппинг | Бесплатный, хорошая интеграция в CI/CD, API-сканирование | Слаб в тестировании бизнес-логики; не заменяет ручной анализ авторизации; требует ручной настройки контекстов для аутентифицированного сканирования | Как единственный инструмент при grey box пентесте |
| Nuclei | Обнаружение уязвимостей, проверка CVE | Тысячи шаблонов, быстрый, легко писать свои шаблоны в YAML; активно поддерживается ProjectDiscovery | Детектит только то, для чего есть шаблон; не обнаружит zero-day логические уязвимости; false negatives на нестандартных конфигурациях | Для тестирования авторизации и бизнес-логики |
| sqlmap | Эксплуатация SQL-инъекций | Автоматизация всех типов SQLi (Union, Error-based, Blind, Time-based, Stacked), обход WAF | Шумный - легко детектируется WAF; не понимает контекст ORM-запросов; может повредить данные при агрессивном режиме | На продакшн-системах без явного согласования; на приложениях с ORM без ручной верификации точки инъекции |
| ffuf / feroxbuster | Разведка, обнаружение контента | Быстрый перебор директорий и файлов; поддержка фильтрации по статус-коду, размеру, количеству слов | Не понимает JavaScript-роутинг (SPA); бесполезен на API без wordlist'а с эндпоинтами | На SPA-приложениях без предварительного анализа JS-файлов |
| Nikto | Разведка, базовое сканирование | Быстрая проверка конфигураций, default-страницы, устаревшие версии ПО | Устаревшая база сигнатур; много false positives; обновляется не так активно, как Nuclei | Как основной сканер на современных приложениях - скорее ностальгия, чем рабочий инструмент |
Управление окружением: для стека ProjectDiscovery (Nuclei, subfinder, httpx) рекомендуется
pdtm - менеджер, который ставит, обновляет и контролирует версии всех инструментов из одной точки. Избавляет от ситуации "а у меня nuclei 2.x, а шаблон для 3.x".Подробнее о расширениях Burp Suite под каждую категорию OWASP Top 10: Burp Suite Extensions: шпаргалка по OWASP Top 10 2026 - какой плагин ставить и зачем
Ключевые классы уязвимостей: где искать и как эксплуатировать
XSS: не "alert(1)", а реальный импакт
Cross-Site Scripting остаётся одной из самых распространённых уязвимостей. Разница между Stored XSS, Reflected XSS и DOM-based XSS - не академическая: она определяет импакт и подход к эксплуатации.Stored XSS встраивает вредоносный скрипт в базу данных приложения. Каждый пользователь, открывающий страницу с отравленным контентом, исполняет скрипт. Импакт максимальный: массовая кража сессий, дефейс, фишинг от имени легитимного домена. Место в kill chain: initial access (через пользовательский ввод) -> persistence (скрипт хранится в БД) -> exfiltration (кража сессий/данных).
DOM-based XSS исполняется полностью на стороне клиента, без отправки payload'а на сервер. WAF тут бесполезен - payload никогда не проходит через серверную сторону. Для обнаружения нужен ручной анализ JavaScript-кода приложения. Сканеры слепы, WAF слеп, только глаза и DevTools.
Подробный разбор с payload'ами и обходами фильтров: XSS уязвимость на практике: поиск, эксплуатация и обход фильтров
SSRF: от чтения файлов до компрометации облака
Server-Side Request Forgery позволяет заставить сервер отправить запрос от своего имени. В облачных инфраструктурах (AWS, GCP) это критично: SSRF к metadata-сервису (http://169.254.169.254/) может вернуть IAM-ключи с полным доступом к инфраструктуре. Один HTTP-запрос - и ты в облаке заказчика. Место в kill chain: initial access (через параметр URL/API) -> lateral movement (обращение к внутренним сервисам) -> exfiltration (получение credentials из метаданных).[Применимо: внешний пентест - классический blind SSRF; внутренний пентест - SSRF к внутренним API и метаданным облака]
Детальный разбор цепочек атак через SSRF: SSRF уязвимость: поиск, эксплуатация и цепочки атак в пентесте
Path Traversal и File Inclusion
Уязвимости обхода пути позволяют читать (а иногда и записывать) произвольные файлы на сервере. Классический../../etc/passwd - лишь отправная точка. В реальных кейсах Path Traversal комбинируется с другими уязвимостями: чтение конфигурационных файлов (DB credentials), чтение исходного кода приложения, цепочка с file upload для RCE.Свежий пример - 0-day в Grav CMS: уязвимость Path Traversal в механизме FormFlash без аутентификации позволяла записывать произвольные файлы. Разбор: Grav CMS уязвимость path traversal: 0-day в FormFlash без аутентификации
CRLF Injection и HTTP Response Splitting
CRLF Injection часто недооценивают, а зря - она может привести к фиксации сессии, обходу CSP и отравлению кэша. Суть: внедрение символов\r\n (CR LF) в HTTP-заголовки позволяет инжектить произвольные заголовки или даже полностью контролировать тело ответа. Выглядит несерьёзно, пока не увидишь, как через неё угоняют сессии.Подробнее об эксплуатации и реальных CVE: CRLF Injection: от HTTP Response Splitting до захвата сессий
Обход аутентификации
Уязвимости аутентификации - отдельный класс, где автоматика практически слепа. Тестирование включает: проверку логики восстановления пароля, обход OTP, session fixation, предсказуемость токенов, race conditions при регистрации. Реальный пример - CVE-2026-41940 (CVSS 9.3) в cPanel/WHM: authentication bypass в login flow (CWE-306) позволяет неаутентифицированному атакующему получить доступ к панели управления. По данным CISA KEV, уязвимость используется в ransomware-кампаниях.Разбор кейса: CVE-2026-41940: обход аутентификации cPanel/WHM - authentication bypass в login flow
Ручное тестирование vs автоматизированный пентест: 5 ситуаций, когда сканер бесполезен
Автоматизация экономит время на начальных фазах, но не заменяет ручной анализ. Вот конкретные ситуации, где сканер гарантированно пропустит уязвимость:
- IDOR и горизонтальная эскалация привилегий. Сканер не знает, что ответ
200 OKс чужими данными - это уязвимость, а не нормальное поведение. Нужна ручная проверка: запрос от пользователя A к данным пользователя B. Для сканера оба ответа - просто200 OK. - Race conditions. Двойное списание бонусов, двойная отправка формы, TOCTOU-уязвимости. Для обнаружения используется Turbo Intruder в Burp Suite - рассылка десятков параллельных запросов с микросекундной точностью. На одном проекте через race condition удалось применить один и тот же промокод 14 раз.
- Бизнес-логика. Приложение позволяет применить купон на уже купленный товар? Позволяет установить отрицательную цену? Позволяет обойти многошаговый процесс верификации, пропустив шаг? Сканер этого не проверяет - он не знает бизнес-правил.
- DOM-based XSS. Payload не покидает браузер, WAF не видит, серверный сканер не видит. Нужен ручной анализ JavaScript.
- Цепочки уязвимостей. По отдельности: low-severity open redirect + low-severity self-XSS. Вместе: цепочка с кражей OAuth-токена = critical. Сканеры не комбинируют находки - это задача пентестера.
Как выбрать вектор атаки: decision tree для пентестера
Выбор техники зависит от контекста: технологический стек, модель доступа, наличие WAF. Вместо перечисления техник - алгоритм принятия решений.Настройка лаборатории: требования к окружению
Перед первым практическим пентестом нужна среда для отработки техник. Без неё теория так и останется теорией.Минимальные требования:
- RAM: 8 ГБ (хост + одна VM с Kali Linux + одно целевое приложение)
- Рекомендуется: 16 ГБ для одновременной работы нескольких контейнеров
- ОС хоста: Windows 10/11, macOS, GNU/Linux
- Гипервизор: VirtualBox (бесплатный) или VMware Workstation
- Kali Linux - предустановлен Burp Suite Community, Nmap, Nikto, sqlmap
- Docker - для развёртывания целевых приложений (DVWA, Juice Shop, WebGoat)
Bash:
docker pull bkimminich/juice-shop
docker run -d -p 3000:3000 bkimminich/juice-shophttp://localhost:3000. Настройте Burp Suite как прокси (по умолчанию 127.0.0.1:8080) и начните исследовать функциональность с включённым перехватом.Для отработки конкретных классов уязвимостей дополнительно: PortSwigger Web Security Academy (бесплатные лаборатории в браузере), HackTheBox и TryHackMe (машины с веб-уязвимостями). Потренировавшись на этих стендах, можно уверенно браться за реальные проекты.
Куда движется пентест веб-приложений
Три тренда определяют ближайший год. Во-первых, API-first архитектура: всё больше приложений строятся как набор микросервисов с REST/GraphQL API. Фокус смещается с классического веб-тестирования (формы, cookies) на тестирование API-эндпоинтов - авторизация на уровне объектов, rate limiting, schema validation. OWASP отреагировала выпуском отдельного API Security Top 10.Во-вторых, рост AI-инструментов не отменяет ручного тестирования - наоборот, усложняет его. Приложения с LLM-интеграцией открывают новую поверхность атаки: prompt injection, indirect prompt injection через контент, обработанный моделью. OWASP уже выпустила Top 10 для Large Language Models. Это не "перспективы" - это то, что уже встречается на проектах.
В-третьих, DevSecOps и shift-left: пентест встраивается в CI/CD через DAST-сканеры (ZAP, Nuclei) на каждом merge request. Но это не замена полноценному пентесту - это фильтр, который отлавливает регрессии. Ежегодный (или ежеквартальный) ручной тест бизнес-логики остаётся необходимостью.
Возьмите OWASP WSTG как чеклист и пройдите хотя бы первые три категории тестов на ближайшем проекте. Разница между "сканер ничего не нашёл" и "мы проверили вот эти 47 тест-кейсов" - это разница между галочкой и реальной безопасностью.
Практикуйте пентест в легальной среде
Хотите пройти путь от теории до реальных кейсов на стендах, приближённых к production? Курсы Codeby Academy по тестированию на проникновение дают практику на уязвимых веб-приложениях с разбором каждого класса уязвимостей из OWASP Top 10 - от первого запроса в Burp Suite до оформления отчёта.Большинство команд тратят бюджет на автоматические сканеры и ждут от них результатов, которые по определению может дать только человек. Сканер - масштабируемый инструмент, но не мыслящий. Он не задаст вопрос "а что будет, если я отправлю этот же запрос, но от имени другого пользователя?" - а именно этот вопрос открывает 80% критических находок на реальных проектах.
За годы работы в bug bounty и коммерческих пентестах я наблюдаю один устойчивый паттерн: компании, которые проводят только автоматическое сканирование, уверены в своей безопасности ровно до первого ручного теста. И дело не в том, что сканеры плохие - Nuclei, Burp Scanner, ZAP делают свою работу. Дело в том, что уязвимости бизнес-логики - IDOR, broken access control, race conditions - живут в зоне, которую автоматика конструктивно не способна покрыть. Autorize в Burp Suite автоматизирует часть проверок авторизации, но кто-то должен понять, какие именно запросы критичны, и интерпретировать результат.
OWASP Top 10 2021 (и готовящаяся версия 2025) лишь подтверждает этот тренд: Broken Access Control на первом месте не потому, что разработчики не умеют писать код, а потому, что сложность бизнес-правил растёт быстрее, чем возможности автоматических проверок. Через два года, когда каждое второе приложение будет содержать LLM-компонент, поверхность атаки расширится ещё больше - и разрыв между тем, что видит сканер, и тем, что находит пентестер, станет только шире. Кто сейчас инвестирует в методологию ручного тестирования и обучение людей, а не в очередную лицензию на "AI-сканер нового поколения", тот через год будет находить уязвимости у соседей. А не читать о своих в новостях. На WAPT в Codeby Academy эту цепочку - от разведки до отчёта - проходят целиком, с лабами на каждый класс уязвимостей.
Последнее редактирование модератором:
