Направление К3 · pillar-материал

Тестирование на проникновение веб-приложений и API: процесс, методология, стоимость

Pentest (тестирование на проникновение) — контролируемая имитация реальной атаки, которая показывает, какие уязвимости в вашем веб-приложении или периметре действительно эксплуатируемы и к каким последствиям они ведут. Не сканер, не аудит конфигурации — а ручная работа эксперта, который думает как нападающий и фиксирует каждый шаг в отчёте. Этот материал — подробное руководство для CISO и руководителей разработки среднего бизнеса: когда нужен pentest, какую модель выбрать, что должно быть в отчёте, сколько это стоит и как закрывать findings без срыва релизов.

Что такое pentest и чем он отличается от смежных услуг

В ИБ-индустрии часто путают три разные услуги: vulnerability scan, security audit и penetration test. Различие не косметическое — у них разные цели, методология и итоговый артефакт.

Vulnerability scan — это автоматическое сканирование. Инструмент (Nessus, Qualys, OpenVAS, MaxPatrol) собирает информацию о версиях ПО, открытых портах, конфигурации и сравнивает с базой известных CVE. Результат — список потенциальных проблем с CVSS-оценками. Сканер ничего не эксплуатирует, не проверяет логику, не объединяет уязвимости в цепочки. Подходит как регулярная гигиена (раз в неделю), но не отвечает на вопрос «можно ли реально пробить нашу систему».

Security audit (аудит безопасности) — статическая проверка конфигурации, процессов и документации. Аудитор сверяет вашу систему с требованиями стандарта (ISO 27001, 152-ФЗ, PCI DSS), проверяет наличие политик, журналов, ролевой модели. Это нужно для compliance, но не показывает, выдержит ли система реальную атаку.

Penetration test — активная попытка взломать систему в согласованном scope. Пентестер использует те же инструменты и техники, что злоумышленник: автоматические сканеры, ручной анализ, fuzzing, эксплуатация бизнес-логики, обход WAF, цепочки уязвимостей. Цель не «найти всё», а доказать, какие из найденных проблем реально эксплуатируемы и как они складываются в Critical-сценарий.

Грубый ориентир: сканер найдёт устаревший nginx с известным CVE, аудитор зафиксирует отсутствие политики парольных требований, а пентестер покажет цепочку «утечка .env через misconfigured nginx → доступ к Redis → чтение сессий → захват учётки администратора → доступ к платёжной системе». Все три задачи нужны, но решаются разными инструментами.

Три модели pentest: black-box, grey-box, white-box

Pentest различают по объёму информации, которую заказчик передаёт исполнителю. От этой модели зависят сроки, стоимость и глубина покрытия.

Black-box: имитация внешнего нарушителя

Исполнитель получает только URL приложения. Никаких учётных записей, документации, схем архитектуры. Пентестер начинает с recon — собирает открытые источники (OSINT), сканирует периметр, ищет subdomain takeover, исследует сторонние интеграции. Это максимально реалистичная имитация внешнего нарушителя, но и самая дорогая по часам: 30–40% времени уходит на разведку, которую в grey-box проводит сам заказчик.

Когда выбирать: проверка зрелости периметра, тестирование скрытых от обычного пользователя площадок (партнёрские порталы, admin-зоны), оценка эффективности SOC и WAF.

Grey-box: учётная запись пользователя

Самая распространённая модель. Заказчик выдаёт исполнителю тестовые учётки (обычно 2–3 разных роли: обычный пользователь, премиум, администратор), краткое описание архитектуры и список ключевых бизнес-функций. Пентестер сразу начинает с проверки авторизации, IDOR, BFLA, эскалации привилегий.

Когда выбирать: 80% случаев. Оптимальное соотношение цена/покрытие. Если у вас SaaS с разными уровнями доступа, e-commerce с админкой и личным кабинетом, B2B-портал — это ваш вариант.

White-box: исходный код и архитектура

Исполнитель получает доступ к репозиторию, схемам базы данных, документации API, описанию инфраструктуры. Помимо классического pentest проводится security code review: ручной анализ критичных модулей (авторизация, обработка платежей, работа с файлами). Эта модель максимально глубокая, но и самая трудозатратная — сроки в 1.5–2 раза дольше black-box.

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

Этапы pentest: что происходит каждую неделю

Качественный pentest — это не «дайте URL, через месяц пришлём отчёт». Это структурированный процесс с понятными чек-поинтами для заказчика. Типовая последовательность:

1. Pre-engagement (1–3 дня). Согласование scope: какие домены, IP, поддомены входят в тест, какие исключены, можно ли проводить DDoS-имитацию и социальную инженерию. Подписание NDA, согласование окон тестирования (обычно вне пиковой нагрузки), фиксация контактов для экстренной остановки тестирования.
2. Reconnaissance (1–7 дней). Сбор информации: пассивный (OSINT, поисковые системы, сертификаты, репозитории) и активный (сканирование портов, fingerprinting технологий, поиск поддоменов). Результат — карта атакуемой поверхности.
3. Vulnerability assessment (3–7 дней). Систематическая проверка по чек-листам: OWASP Top 10, OWASP API Security Top 10, CWE Top 25. Параллельно запускаются автоматические инструменты (Burp Suite, OWASP ZAP, ffuf, nuclei) для поиска тривиальных проблем.
4. Exploitation (5–14 дней). Ручная попытка эксплуатации найденных проблем. Пентестер проверяет, действительно ли уязвимость работает, документирует steps to reproduce, делает скриншоты и видео PoC. Цепочки уязвимостей объединяются в Critical-сценарии.
5. Post-exploitation (опционально, 3–10 дней). Если получен первичный доступ — попытка закрепления, lateral movement, эскалации привилегий. Эта стадия особенно важна для внутреннего pentest.
6. Reporting (5–7 дней). Подготовка отчёта: executive summary, технический раздел, приоритизация, рекомендации по фиксу.
7. Debrief (1 день). Видеовстреча с командой заказчика: разбор отчёта, ответы на вопросы, обсуждение приоритетов закрытия. Часто на этой встрече присутствуют разработчики, которым предстоит чинить уязвимости.
8. Re-test (3–5 дней, через 4–8 недель). Повторная проверка закрытых уязвимостей. Включена в стоимость pentest.

OWASP Top 10 и OWASP API Security Top 10: основа чек-листа

OWASP — некоммерческая организация, которая поддерживает открытые стандарты безопасности веб-приложений. Два их главных документа — OWASP Top 10 (для веб) и OWASP API Security Top 10 (для API) — фактически обязательный минимум для любого pentest.

OWASP Top 10:2021 включает: Broken Access Control, Cryptographic Failures, Injection, Insecure Design, Security Misconfiguration, Vulnerable and Outdated Components, Identification and Authentication Failures, Software and Data Integrity Failures, Security Logging and Monitoring Failures, Server-Side Request Forgery.

OWASP API Security Top 10:2023 акцентирует уязвимости, специфичные для API: Broken Object Level Authorization (BOLA), Broken Authentication, Broken Object Property Level Authorization (BOPLA), Unrestricted Resource Consumption, Broken Function Level Authorization (BFLA), Unrestricted Access to Sensitive Business Flows, Server-Side Request Forgery, Security Misconfiguration, Improper Inventory Management, Unsafe Consumption of APIs.

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

Типичные уязвимости в коммерческих приложениях

За 8+ лет работы наша команда видела одни и те же ошибки в десятках компаний. Ниже — топ-7 уязвимостей, которые встречаются на pentest e-commerce, SaaS и B2B-порталов чаще всего.

1. IDOR (Insecure Direct Object Reference)

Пользователь меняет ID в URL и получает доступ к чужим данным. Пример: GET /api/orders/12345 — заказ другого пользователя. Бэкенд проверяет, что пользователь авторизован, но не проверяет, принадлежит ли ему этот ресурс. Простая, частая, разрушительная уязвимость.

2. SQL-инъекции (SQLi)

Несмотря на возраст уязвимости (известна с 1998 года), SQLi встречаются до сих пор — особенно в legacy-модулях, написанных без ORM, или в сложных динамических запросах. Эксплуатация позволяет читать произвольные таблицы, изменять данные, иногда — выполнять команды на сервере БД.

3. XSS (Cross-Site Scripting)

Хранимый XSS позволяет внедрить JavaScript, который выполнится у других пользователей. Reflected XSS требует переход по подделанной ссылке, но в связке с социальной инженерией работает не хуже. DOM-based XSS стал чаще на одностраничных приложениях (SPA).

4. SSRF (Server-Side Request Forgery)

Атакующий заставляет бэкенд сделать HTTP-запрос на внутренний адрес (например, http://169.254.169.254/ в AWS — IMDS, или http://localhost:6379 — Redis без пароля). Через SSRF часто получают AWS-токены, доступ к админкам внутренних сервисов, конфигурацию Kubernetes.

5. Race conditions в платежах

Параллельная отправка нескольких запросов на списание баланса до того, как первый успел зафиксироваться. В купонах: применить один купон 100 раз. В банковских переводах: перевести больше, чем есть на счёте. Уязвимость логики — её не находят сканеры, только ручной pentest.

6. Утечка секретов в репозитории

Боевые ключи API, токены доступа, пароли БД в коммитах, в .env-файлах на сервере, в JS-бандлах фронтенда. На pentest почти всегда находим хотя бы один забытый ключ.

7. Уязвимости в зависимостях (CVE)

Устаревшие версии библиотек с известными уязвимостями — log4shell в Java, prototype pollution в Node.js, Werkzeug debug PIN в Python. SCA-инструменты (Software Composition Analysis) находят это автоматически, но без процесса регулярного обновления уязвимости копятся годами.

Сколько стоит pentest: реалистичные диапазоны

Стоимость pentest зависит от объёма приложения, количества ролей пользователей, наличия API, мобильных клиентов, сложности бизнес-логики. Ниже — диапазоны для коммерческого среднего бизнеса (без КИИ и государственных систем).

Тип проекта	Сроки	Бюджет
Лендинг или простой сайт без личного кабинета	1–2 недели	250 000 – 500 000 ₽
Веб-приложение с 1–2 ролями (e-commerce, блог-платформа)	3–4 недели	500 000 – 1 200 000 ₽
SaaS среднего размера (админка, ЛК, API, 3+ роли)	5–7 недель	1 200 000 – 2 500 000 ₽
Крупная платформа (микросервисы, мобильное приложение, интеграции)	8–12 недель	2 500 000 – 5 000 000 ₽
Только API (REST/GraphQL, 20–50 эндпоинтов)	3–5 недель	800 000 – 1 800 000 ₽
Security code review (без активного pentest)	3–6 недель	900 000 – 3 000 000 ₽

В стоимость нашего pentest всегда включён re-test после закрытия Critical и High findings. Это страховка от ситуации, когда команда «починила, но не доконца» — мы перепроверяем и подтверждаем закрытие в дополнительном отчёте.

Структура хорошего отчёта по pentest

Отчёт — главный артефакт, который остаётся у заказчика. Хороший отчёт должен быть полезен трём аудиториям: руководству (для принятия решений по бюджету и приоритетам), CISO (для управления остаточным риском) и разработчикам (для устранения уязвимостей).

• Executive summary (1–2 страницы). Без жаргона. Сколько уязвимостей какого уровня найдено, какие бизнес-риски они создают, что нужно сделать в первую очередь, какие ресурсы потребуются.
• Scope и методология. Точное описание тестировавшихся систем, использованной модели (black/grey/white), стандартов (OWASP Top 10, PTES, NIST SP 800-115).
• Findings. Каждая уязвимость — отдельная карточка: название, CVSS v3.1 score, описание, шаги воспроизведения, скриншоты/видео PoC, потенциальное воздействие, рекомендации.
• Цепочки эксплуатации. Отдельный раздел: как несколько Medium-уязвимостей складываются в Critical-сценарий. Это самая ценная часть отчёта.
• Приоритизация. Roadmap закрытия: что чинить за 24–72 часа (Critical), что за неделю-две (High), что в плановых спринтах (Medium), что в backlog (Low/Informational).
• Приложения. Сырые логи запросов, использованные payloads, список инструментов и версий.

Когда нужен pentest: триггеры и периодичность

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

• Запуск нового продукта в production.
• Крупный релиз с изменением авторизации, ролевой модели, обработки платежей.
• Миграция инфраструктуры (переход в облако, смена дата-центра, новый Kubernetes-кластер).
• Получение compliance-сертификата (ISO 27001, PCI DSS, требования банков).
• После инцидента безопасности (даже мелкого) — чтобы понять, не пропустили ли вы другие векторы.
• Перед сделкой M&A — security due diligence приобретаемого продукта.

Pentest vs bug bounty: дополняют, а не заменяют

Bug bounty — публичная программа, где исследователи получают вознаграждение за найденные уязвимости. На первый взгляд может показаться, что это замена pentest: больше людей ищут, дешевле в моменте. На практике это инструменты разных классов.

Pentest даёт системное покрытие в фиксированные сроки с обязательным отчётом и re-test. Исполнитель обязан проверить всё в scope, а не только то, что «легко найти». Bug bounty эффективен как непрерывный процесс после pentest: исследователи мониторят появление новых уязвимостей в выпущенных релизах, но фокусируются на «громких» проблемах с большим вознаграждением и могут пропустить логические ошибки в редко используемых модулях.

Зрелая модель: pentest раз в год + bug bounty между ними + автоматическое SAST/DAST/SCA в CI/CD.

Кейс: что нашли на pentest e-commerce платформы

Реальный пример из практики (имя клиента не разглашается по NDA). Маркетплейс одежды, ~150 000 активных пользователей в месяц, 12 человек в команде разработки, до этого pentest не проводился. Формат — grey-box, 5 недель, 3 роли (покупатель, продавец, администратор).

Что нашли (всего 23 findings):

• 1 Critical. IDOR в endpoint /api/seller/orders: подмена seller_id давала доступ к чужим заказам, включая адреса доставки и контакты покупателей. Эксплуатация — 30 секунд через Burp.
• 3 High. SSRF в импорте товаров через URL (доступ к AWS IMDS), race condition в применении промокодов (использование одного кода многократно), хранимый XSS в описании товара (срабатывал у администратора при модерации).
• 8 Medium. Отсутствие rate-limiting на login, утечка stack trace в production, предсказуемые ID заказов, JWT с алгоритмом «none» как fallback, отсутствие CSRF-защиты в админке, и др.
• 11 Low/Informational. Missing security headers, verbose error messages, устаревшие версии библиотек без известных уязвимостей.

Команда заказчика закрыла Critical за 18 часов после получения отчёта, High — за 6 дней. Re-test через 5 недель подтвердил все фиксы. Полная цепочка эксплуатации Critical-сценария (захват аккаунта администратора через XSS в описании товара) была разобрана на debrief с разработчиками — это запустило внутренний процесс обязательной санитизации пользовательского ввода во всех формах.

Decision tree: когда нужен pentest, vulnerability scan или security audit

Три инструмента часто путают. На практике у них разные цели и они дополняют друг друга. Чек-лист для выбора инструмента под конкретную задачу:

• Регулярный контроль известных уязвимостей (CVE) в продакшен-инфраструктуре → vulnerability scan (Nessus, MaxPatrol VM, Qualys) еженедельно или после каждого деплоя. Стоимость: 100–500 тыс. ₽/год за лицензию + 0.3–1 чел/мес поддержки.
• Готовимся к compliance-проверке (ISO 27001, PCI DSS, 152-ФЗ) → security audit. Аудитор сверяет процессы и документы со стандартом, проверяет наличие политик, журналов, ролевой модели. 400 тыс. – 2 млн ₽ за проект.
• Запускаем новый продукт, обновили платёжный модуль, провели M&A, после инцидента → pentest. Реальная проверка эксплуатируемости и логических ошибок в boundary conditions. 500 тыс. – 5 млн ₽ за проект.
• Поддерживаем зрелый продукт между pentest-ами → bug bounty + continuous penetration testing. Дополнение, не замена.
• Хотим встроить безопасность в процесс разработки → Secure SDLC: SAST/DAST/SCA в CI, threat modeling новых фич, security champions в командах.

Сравнение инструментов pentest

На рынке коммерческих и open-source инструментов десятки имён. Ниже — практический срез того, что реально работает в 2026 году в проектах среднего масштаба:

Класс	Решения	Когда выбирать
Proxy / manual testing	Burp Suite Pro, OWASP ZAP, Caido	Burp — индустриальный стандарт, обязателен для коммерческого pentest; ZAP — open-source альтернатива для бюджета; Caido — современный UX для команд с фокусом на API
Vulnerability scanner	Nessus Professional, MaxPatrol VM, OpenVAS, nuclei	Nessus — для perimeter scan; MaxPatrol — для крупного парка с интеграцией в SIEM; nuclei — для быстрого custom-template сканирования веба
Web fuzzing	ffuf, gobuster, dirsearch, wfuzz	ffuf — самый быстрый и гибкий; gobuster — стандарт для recon; dirsearch — для подключения custom wordlists
SAST	Snyk, Semgrep, SonarQube, Solar appScreener	Snyk — GitHub-native + dependency scan; Semgrep — для custom rules; SonarQube — для общего code quality; Solar appScreener — отечественный, для импортозамещения
Reporting	Dradis, Faraday, Pwndoc, custom Markdown + Pandoc	Dradis/Faraday — для централизованной командной работы; Pwndoc — open-source альтернатива; Markdown+Pandoc — для небольших команд

Расширенный кейс: pentest финтех-стартапа перед запуском

Финтех-стартап «Заказчик Б» — сервис микрозаймов с лицензией МФО, бэкенд на Go + PostgreSQL, фронтенд React Native (iOS/Android) + личный кабинет на Vue. До публичного запуска — 6 недель. Заказали white-box pentest с security code review критичных модулей (KYC, расчёт лимита, выдача займа, погашение, интеграция с СПФС/НСПК).

Формат — 7 недель, команда 3 пентестера + security code reviewer, scope: 4 микросервиса (всего ~38 эндпоинтов), 2 мобильных приложения, 1 web-кабинет, интеграции с 3 платёжными провайдерами.

Что нашли (всего 41 finding):

• 2 Critical. BOLA в API расчёта лимита (подмена user_id давала просмотр одобренной суммы займа другого клиента — раскрытие финансовой истории). Race condition при погашении займа (двойное списание баланса с задержкой 50ms между запросами).
• 6 High. Утечка JWT-секрета в исходниках мобильного приложения (можно было выпустить любой токен), отсутствие certificate pinning (MITM на public Wi-Fi), SSRF в загрузке скан-копии паспорта, IDOR в скачивании выписки, отсутствие rate-limit на восстановление пароля, и др.
• 14 Medium. Слабая проверка БИК, отсутствие journaling финансовых операций в иммутабельный лог, предсказуемые ID займов, использование зеркала Redis без пароля для cache, и др.
• 19 Low/Informational. Missing security headers, weak TLS configuration, verbose error messages, устаревшие зависимости без известных CVE.

Команда заказчика закрыла Critical за 36 часов, High — за 11 дней, Medium вписали в roadmap первого месяца после запуска. Re-test через 4 недели подтвердил все Critical/High фиксы. Запуск отложили на 3 недели, что в случае финтеха однозначно дешевле компрометации лимитов в первую неделю работы с реальными клиентами.

Стандарты и регуляторы

Pentest и связанные практики безопасности опираются на международные и российские стандарты:

• OWASP Top 10 — топ-10 наиболее критичных рисков веб-приложений (обновление 2021, готовится 2025).
• OWASP API Security Top 10 — топ-10 угроз API (актуальная редакция 2023).
• OWASP ASVS — Application Security Verification Standard, набор контрольных требований к безопасности приложений (3 уровня).
• cve.org — глобальный реестр известных уязвимостей.
• nvd.nist.gov — National Vulnerability Database, метрики CVSS, метаданные CVE.
• NIST SP 800-115 — методические рекомендации по техническому тестированию безопасности.
• fstec.ru — ФСТЭК России, требования к pentest при работе с гостайной и КИИ.

Связанные материалы

Pentest — одна часть комплексной программы безопасности. Смежные направления:

• Защита веб-приложений: WAF, DDoS-mitigation, bot protection — что строить после pentest для снижения остаточного риска.
• Безопасность API: разбор OWASP API Security Top 10, авторизации, rate-limiting на уровне эндпоинтов.
• Secure SDLC: как встроить безопасность в процесс разработки, чтобы pentest не находил одни и те же ошибки год за годом.
• 152-ФЗ и защита персональных данных: правовой контекст, в котором pentest становится не выбором, а обязанностью.

FAQ о тестировании на проникновение

Обсудить pentest Бесплатная 30-минутная встреча: scope, модель, ориентировочный бюджет.