DAST (Dynamic Application Security Testing).

Инструменты DAST взаимодействуют с развернутым приложением, обычно по HTTP, и не требуют исходного кода. Они обходят эндпоинты, отправляют специально подготовленные запросы и анализируют ответы, обнаруживая SQL-инъекции, XSS, SSRF, ошибки аутентификации, некорректный CORS, небезопасные cookie. Видя приложение глазами атакующего, DAST дополняет SAST и выявляет проблемы, существующие только в рантайме, в том числе вызванные конфигурацией, инфраструктурой или сторонними сервисами. Обычно запускается в staging/QA и встраивается в CI/CD как релизные ворота. Среди инструментов — OWASP ZAP, Burp Suite, Invicti, Acunetix, StackHawk.

Как это работает

DAST-сканирование проходит в две фазы. Сначала краулер (spider) составляет карту поверхности атаки приложения, переходя по ссылкам, разбирая JavaScript и воспроизводя записанный трафик, чтобы обнаружить формы, параметры и маршруты API. Затем активный сканер подставляет в каждое поле атакующие полезные нагрузки и делает выводы об уязвимостях по кодам ответа, задержкам, отражённому содержимому или сигнатурам ошибок — например, слепая SQL-инъекция на основе времени подтверждается, когда полезная нагрузка SLEEP() заметно задерживает ответ.

Современный DAST сместился в сторону сканирования по принципу API-first и с аутентификацией: одностраничные приложения (SPA) и бэкенды REST/GraphQL мало что раскрывают наивному краулеру, поэтому сканеры используют спецификации OpenAPI/Swagger и скриптованные последовательности входа, чтобы добраться до защищённой функциональности. Покрытие обычно сопоставляется с OWASP Web Security Testing Guide (WSTG). Ограничения DAST важны не меньше: он не указывает местоположение в строках кода, не видит недостижимые пути выполнения и рискует пропустить уязвимости при сложном клиентском состоянии — именно поэтому команды сочетают его с SAST и IAST, а не полагаются на него в одиночку. Чтобы не сканировать продакшн и не вызывать реальные побочные эффекты (отправку писем, оформление заказов), сканирование ограничивают непродакшн-целями и задают ему чёткую область и список исключений.

flowchart LR
  A[Работающее приложение<br/>staging/QA] --> B[Краулер / spider<br/>карта эндпоинтов]
  B --> C[Активный сканер<br/>внедряет payload'ы]
  C --> D{Аномалия в<br/>ответе?}
  D -->|Да| E[Отчёт о находке<br/>SQLi / XSS / SSRF]
  D -->|Нет| F[Эндпоинт помечен как чистый]
  E --> G[CI/CD-ворота<br/>провалить сборку / триаж]