DAST (динамическое тестирование безопасности приложений) тестирует работающее приложение снаружи, чтобы найти слабые места. Эта страница объясняет, чем он отличается от других методов и как использовать его для собственного приложения (тестирование чужих сайтов здесь не рассматривается).
Что такое DAST
DAST расшифровывается как динамическое тестирование безопасности приложений. Руководство OWASP DevSecOps Guideline описывает его как тестирование методом чёрного ящика, которое находит уязвимости безопасности и слабые места в работающем приложении. «Чёрный ящик» означает, что тестируется только то, что видно снаружи, без изучения внутреннего исходного кода.
На практике инструмент переходит по страницам приложения и полям ввода, отправляет тестовые запросы и ищет признаки проблем в ответах. Руководство указывает, что метод особенно полезен для проверки ввода и вывода данных, проблем аутентификации и ошибок конфигурации сервера.
Как это работает
Чем он отличается от SAST, IAST и SCA
| Метод | Что проверяет | Запускает приложение? | Подходит для |
|---|---|---|---|
| DAST | Поведение работающего приложения снаружи | Да | Проверка ввода и вывода, аутентификация, конфигурация сервера |
| SAST | Исходный или скомпилированный код | Нет | Поиск ошибок в коде на ранних этапах разработки |
| IAST | Внутреннее поведение приложения (через датчики) | Да (во время тестов) | Проблемы, которые проявляются во время автоматических тестов |
| SCA | Библиотеки и другие зависимости | Нет | Компоненты с известными уязвимостями (CVE) |
Для SAST OWASP перечисляет ограничения: он находит лишь относительно небольшой процент недостатков безопасности приложений, даёт много ложных срабатываний и пропускает проблемы конфигурации. DAST помогает закрыть этот пробел, но тоже не даёт полной картины. Про SCA см. аудит зависимостей с OSV-Scanner.
Как использовать его для собственного приложения (пример с OWASP ZAP)
ZAP (Zed Attack Proxy; ранее назывался OWASP ZAP) — бесплатный инструмент DAST с открытым исходным кодом. На его официальном сайте теперь указано название «ZAP by Checkmarx».
- Подготовьте URL тестовой среды, которой вы управляете. Используйте тестовую среду, а не боевую
- Запустите базовое сканирование (baseline scan). По документации ZAP оно только пассивное: по умолчанию запускает паук (функцию перехода по страницам) на 1 минуту и не выполняет атак. Занимает не более нескольких минут
- Изучите результаты и убедитесь, что человек подтвердил, какие из них реальны; ложные срабатывания случаются
- При необходимости перейдите к активному сканированию, только в тестовой среде. Оно выполняет известные атаки на цель, и документация указывает, что его нельзя использовать для веб-приложений, которыми вы не владеете
- Повторяйте проверку регулярно, например в CI, после каждого исправления
Только для тестовых сред приложений, которыми вы владеете или управляете
Инструменты DAST отправляют трафик, похожий на реальные атаки. Запуск их против сайта, на тестирование которого у вас нет разрешения, может считаться несанкционированным доступом или нарушением работы сервиса. Документация ZAP также предупреждает, что активное сканирование нельзя использовать для веб-приложений, которыми вы не владеете. Запуск на боевой среде может иметь побочные эффекты, например создание данных или дополнительную нагрузку.
Что пропускает DAST
Документация ZAP указывает, что его активное сканирование не находит логических проблем, например нарушений контроля доступа, поэтому его нужно дополнять ручным тестированием. Такой дефект, как IDOR, когда один пользователь может увидеть данные другого, трудно найти автоматическим инструментом, поскольку он не знает, каким должно быть правильное поведение. Нужно написать собственный тест, который запрашивает ID другого пользователя и проверяет, что доступ отклоняется.
Проверки конфигурации, с другой стороны, — то, что DAST делает хорошо. О том, какие настройки стоит задать, см. заголовки безопасности: что по-прежнему важно.
Точка зрения этого сайта: DAST — последняя линия защиты. Думайте о трёх уровнях: код, компоненты, поведение
Реалистичнее сочетать три метода, которые смотрят в разные места, чем ожидать, что один инструмент найдёт всё: сначала читаем код (SAST), затем проверяем компоненты на известные уязвимости (SCA), затем запускаем приложение и тестируем его снаружи (DAST). То, с чем инструменты плохо справляются, — «кто что может делать», — защищайте тестами, которые пишете сами. Не доверяйте выводам инструментов без проверки; перед исправлением пусть их подтвердит человек.
Источники (первичные)
- OWASP DevSecOps Guideline, «Dynamic Application Security Testing» — owasp.github.io (определение DAST, чёрный ящик)
- OWASP DevSecOps Guideline, «Interactive Application Security Testing» — owasp.github.io (IAST)
- OWASP Community, «Source Code Analysis Tools» — owasp.org (SAST и его ограничения)
- ZAP Documentation, «Active Scan» — zaproxy.org (не для приложений, которыми вы не владеете; не находит логических проблем)
- ZAP Documentation, «Baseline Scan» — zaproxy.org (только пассивное; время работы)
- Описание SCA является общим определением; официальное определение для него не проверялось
Читайте далее
- Глоссарий: Что такое фаззинг · Что такое OWASP Top 10 · Что такое IDOR
- Руководства: Заголовки безопасности: что по-прежнему важно · Аудит зависимостей с OSV-Scanner
- Глоссарий: Что такое CVE