Меню
Статьи

Методики пентестинга веб-приложений

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

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

По каким стандартам работают

OWASP WSTG — руководство по тестированию веб-приложений: больше сотни сценариев по разделам, от управления сессиями до бизнес-логики. Основной рабочий документ для веба.

PTES — стандарт процесса: как договариваются о границах, как ведут разведку, что входит в отчёт. Отвечает не за то, что проверять, а за то, как устроена работа целиком.

NIST SP 800-115 — техническое руководство по проверкам безопасности; используется, когда пентест встраивается в программу управления рисками и его нужно описать на языке аудита.

Классы уязвимостей берутся из OWASP Top 10, но список — не чек-лист: это категории по частоте, а не порядок проверок. Что из него встречается на практике, разобрано в статье OWASP Top 10 2024.

Этапы работы

  1. Согласование. Границы, окно работ, допустимые техники, контакт на стороне заказчика, порядок действий при критичной находке.
  2. Разведка. Поддомены, открытые сервисы, версии, забытые тестовые стенды, утёкшие учётные данные, публичные репозитории.
  3. Перечисление. Точки входа: формы, параметры, конечные точки API, роли и права, порядок аутентификации.
  4. Поиск уязвимостей. Автоматика по известному, руки — по логике: доступ к чужим объектам, обход шагов сценария, повторное использование токенов.
  5. Эксплуатация. Подтверждение находки с доказательством. Деструктивные действия — только по отдельному согласованию.
  6. Развитие доступа. Куда ведёт находка: соседние сервисы, инфраструктура, данные других клиентов.
  7. Отчёт и ретест. Каждая находка с шагами воспроизведения и оценкой по CVSS, затем повторная проверка исправлений.

Модели доступа

Модель Что знает команда Когда выбирают
Чёрный ящик Только адрес приложения Нужна картина «как снаружи», бюджет позволяет платить за разведку
Серый ящик Учётные записи ролей, схема, список адресов Основной вариант: время идёт на поиск, а не на угадывание
Белый ящик Код, конфигурации, доступ к команде разработки Логика оплаты, права, редкие ветки исполнения

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

Что находят на практике

Уязвимости веба редко экзотические. Три случая из белорусской практики показывают повторяющиеся классы.

В июле 2023 года у сети салонов связи в интернете оказались данные 16 тысяч покупателей: файл создали через админ-панель сайта и получили несанкционированный доступ к базе, сообщал Office Life. Проверка доступности служебных интерфейсов снаружи — первый шаг любой методики.

Осенью 2024 года центр кибербезопасности хостинг-провайдера нашёл цепочку взломов сайтов на 1С-Битрикс с шаблонами «Аспро»: три уязвимых скрипта корзины, через них загружали веб-шеллы и майнеры. Один уязвимый компонент, размноженный по десяткам клиентов, — то, что ловится анализом зависимостей и версий.

В феврале 2025 года ОАЦ выявил критические уязвимости в сайтах, сделанных одним разработчиком больше двенадцати лет назад, и доступ к части из них был закрыт. Разработчик предупреждал владельцев об обновлении ещё в 2016 году.

Инструменты по этапам

  • Разведка: Amass и Sublist3r для поддоменов, crt.sh для сертификатов, Shodan и Censys для открытых сервисов.
  • Прокси и ручная работа: Burp Suite или OWASP ZAP — основной инструмент на всех этапах после разведки.
  • Перебор и фаззинг: ffuf, wfuzz, Burp Intruder для параметров и скрытых путей.
  • Инъекции: sqlmap для подтверждения, дальше руками.
  • Код и зависимости: Semgrep, Bandit, Brakeman, OWASP Dependency-Check, Retire.js.
  • Сборка: сканирование контейнеров Trivy или Grype, автозапуск ZAP в конвейере.

Инструмент подтверждает гипотезу, а не заменяет её. Логику доступа и обход сценариев не находит ни один сканер: разница разобрана в статье сканер уязвимостей и пентест.

Автоматика отвечает на вопрос «что известно об этой версии». На вопрос «что здесь можно сделать» отвечает человек.

Что готовит заказчик

  • Список адресов и приложений в границах проверки и вне её.
  • Учётные записи на каждую роль: пользователь, менеджер, администратор.
  • Решение по среде: продуктив или стенд, и чем стенд отличается от боевой системы.
  • Исключения в WAF и системах обнаружения для адресов команды, если проверяется приложение, а не средства защиты.
  • Контакт, который отвечает в течение часа, и порядок действий при критичной находке.

Что делать

  1. Выбрать модель доступа под вопрос: внешняя картина — чёрный ящик, логика личного кабинета — серый, расчёты и права — белый.
  2. Зафиксировать границы и окно работ письменно, отдельно оговорить деструктивные техники.
  3. Выдать тестовые учётные записи за два дня до старта.
  4. Договориться о ретесте и его дате до начала работ.

Заказать пентест веб-приложения — hello@cyberiti.by.

Обсудить задачу и объём работ

Ответим в течение рабочего дня.