DAST для веб-приложений: сравнение Burp, Invicti, Acunetix

Зачем сравнивать DAST на своей тестовой среде

DAST для веб-приложений выбирают не ради «красивого отчета», а чтобы закрыть практичные вопросы: какой реальный риск у продукта, что показать аудитору, и как не стопорить релизы постоянными ручными проверками.

Сравнение на собственной тестовой среде переводит разговор из «какой инструмент популярнее» в «какой инструмент дает нужный результат на нашем приложении». Одним командам важнее скорость и стабильность прогонов в CI, другим - глубина проверок в личном кабинете, третьим - низкий процент ложных тревог, чтобы разработчики не перестали доверять отчетам.

Демо и маркетинговые тесты редко совпадают с реальностью. В демо обычно нет сложной авторизации, нестандартных API, реальных ограничений по rate limit, а формы и ошибки сделаны «удобными» для сканера. На живом продукте один инструмент легко «теряет» половину функционала за логином, другой упирается в капчу или редиректы, а третий находит много, но значительная часть находок не подтверждается.

Если сравнить «на скорую руку», вывод почти гарантированно будет неверным. Чаще всего ломают сравнимость такие вещи:

• инструменты запускают с разными настройками и разным временем, а потом пытаются сравнить цифры;
• авторизованные зоны проверяются частично, и это не видно из отчета;
• ложные срабатывания смешиваются с реальными багами, поэтому оценка становится субъективной;
• тестовая среда ведет себя иначе (другая сборка, роли, данные), и эксперимент перестает быть экспериментом.

Ориентир простой: представьте портал с гостевой частью и личным кабинетом, где есть роли «пользователь» и «оператор». Бизнесу важно понимать, увидит ли сканер уязвимости именно там, где обрабатываются персональные данные и платежи, и сколько времени уйдет на разбор результатов после каждого запуска.

Для организаций с требованиями соответствия и госзакупок особенно важно заранее зафиксировать методику сравнения. Тогда выводы можно защищать перед внутренним контролем и внешним аудитом, а не спорить о том, «почему сегодня отчет другой».

Что сравниваем: покрытие, авторизацию и ложные срабатывания

При выборе DAST важны не только «нашел больше» и «сканирует быстрее». В реальной работе инструмент должен (1) пройти по нужным частям сайта, (2) устойчиво работать после входа в учетную запись и (3) давать находки, которым можно доверять.

Покрытие: что реально было проверено

Покрытие отвечает на вопрос: какие участки приложения сканер действительно посетил и попытался протестировать. Причем «посетил» важнее, чем «теоретически мог». Один инструмент откроет страницу, но не отправит форму. Другой уйдет в бесконечные параметры и пропустит важный раздел.

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

• сколько уникальных страниц и эндпоинтов было открыто;
• сколько форм и действий (поиск, создание, загрузка) было отправлено;
• какие методы API реально вызывались (GET, POST и т.д.);
• дошел ли сканер до «глубоких» экранов, а не остановился на главной и логине.

Пример: в кабинете есть «Профиль», «Платежи» и «Заявки». Если отчет выглядит убедительно, но в серверных логах нет обращений к разделу «Заявки», покрытие по сути провалено.

Авторизация: где сканер должен войти и что делает после

Проверка авторизованных зон часто решает исход сравнения. Важно не просто «уметь логиниться», а сохранять сессию, обновлять токены и понимать, что после входа появляется новый набор страниц и действий.

Сразу задайте границы: какие роли нужно проверить (пользователь, оператор, администратор), какие потоки критичны (смена пароля, оформление заказа, управление данными). И отдельно определите, что считается успехом. Например: сканер дошел до страницы, где виден номер договора, и смог выполнить действие «создать заявку».

Ложные срабатывания: как отделить шум от риска

Ложные срабатывания звучат опасно, но не подтверждаются. Они съедают время и быстро убивают доверие к инструменту.

Лучше оценивать не «сколько всего найдено», а долю подтвержденных проблем. Для части находок заранее договоритесь о способе проверки: повтор запроса, сравнение ответа до и после изменения параметра, воспроизведение в браузере.

На результаты сильно влияют ограничения стенда, поэтому их тоже нужно зафиксировать:

• WAF или защитные правила, которые режут «подозрительные» запросы;
• rate limit и блокировки по IP после серии запросов;
• CAPTCHA и дополнительные проверки входа;
• нестабильные тестовые данные (запись уже существует, объект удален);
• случайные ошибки среды, из-за которых сканер теряет маршрут.

Если эти условия не описать, Burp Suite Enterprise, Invicti и Acunetix будут выглядеть несравнимо, хотя проблема окажется в окружении, а не в самом DAST.

Подготовка тестовой среды и эталонных проверок

Сравнение DAST имеет смысл только при одинаковых условиях. Самая частая причина «странных» результатов - разные версии приложения, разные данные или случайные элементы интерфейса, из-за которых один сканер проходит дальше, а другой ломается на полпути.

Сначала зафиксируйте один и тот же билд и конфигурацию: одинаковые фиче-флаги, настройки кэша, заголовки безопасности, интеграции (если их нельзя отключить). Если тестовая среда живет рядом со стейджингом, убедитесь, что релиз не меняется в середине прогона. Иначе вы будете сравнивать не Burp Suite Enterprise, Invicti и Acunetix, а два состояния приложения.

Дальше подготовьте данные и доступы. Нужны тестовые учетные записи с разными ролями, чтобы корректно сканировать закрытые зоны. Эти учетные записи должны быть предсказуемыми: одинаковый набор прав, заполненный профиль, стабильная история действий, без «первичного» обязательного изменения пароля и других шагов, которые ломают автоматизацию.

Затем договоритесь, что именно должно быть найдено. Это ваш эталон: небольшой набор уязвимостей или тестовых целей, которые вы можете подтвердить руками. Практичный состав эталона:

• 5-10 известных проблем из бэклога (например, когда-то исправленных и воспроизводимых на тесте) или специально добавленных тестовых точек;
• 2-3 сценария проверок доступа (например, пользователь пытается открыть админ-раздел);
• 2-3 места ввода, где безопасно проверить инъекции и XSS.

Уберите случайные факторы: A/B, динамические баннеры, персональные рекомендации, нестабильные редиректы, «плавающие» параметры в URL, а также ограничения, которые по-разному режут трафик (rate limit, капча). Иначе один сканер начнет получать 403 или неожиданные переходы, и покрытие станет несопоставимым.

Наконец, включите логирование на стороне приложения и инфраструктуры: access-логи, логи ошибок, аудит действий, трассировку запросов с correlation id. Тогда каждую находку можно подтвердить по факту: был ли запрос, какой параметр ушел, какой ответ вернулся, и это уязвимость или ложная тревога.

Единые условия запуска сканирования (без авторизации)

Для начала приведите к общему знаменателю самый простой режим: сканирование без входа в систему. Так вы проверяете базовые возможности краулинга и поиска уязвимостей, не смешивая результат с настройками логина и сессий.

Зафиксируйте стартовую точку и рамки: что именно сканируем (основной домен, тестовые поддомены, базовые пути вроде /, /api, /swagger), и что не сканируем (админки, внешние сервисы, страницы-заглушки). Если у приложения несколько хостов, заранее утвердите список: в результаты идет только то, что входит в scope.

Дальше задайте одинаковые ограничения, чтобы инструменты не получали «фору»:

• время на сканирование и одинаковое окно запуска;
• максимальная глубина обхода и лимит уникальных URL;
• скорость запросов (RPS) и параллельность;
• таймауты, лимит размера ответа и единый режим повторов при сетевых ошибках.

Отдельно согласуйте поведение, которое кажется «мелочью», но меняет покрытие: как обрабатываются редиректы (всегда или только в пределах домена), разрешены ли куки, какие заголовки отправлять (Accept-Language, X-Forwarded-For, кастомные заголовки), какой User-Agent использовать. Если один инструмент идет как «мобильный», а другой как «десктопный», вы можете получить разные страницы и разные находки.

Также заранее решите, что сохраняете как «сырой» результат. Помимо отчета полезно сохранить логи запросов и ответов, список найденных URL и карту обхода. Когда возникнет спорная находка (или ее отсутствие), именно эти данные объясняют причину: инструмент не дошел до нужной страницы, получил 403, застрял в редиректе или не отправил действие.

Сканирование авторизованных зон: пошаговая настройка

Авторизованные разделы почти всегда содержат больше логики и данных, чем публичные страницы. Но именно там DAST чаще всего ломается: инструмент теряет сессию, уходит на страницу логина или сканирует не ту роль. Чтобы сравнение Burp Suite Enterprise, Invicti и Acunetix было корректным, настройку авторизации делайте одинаково и фиксируйте ее.

1) Выберите тип входа

Определите, как приложение реально пускает пользователя внутрь. На тесте это должно быть максимально похоже на прод.

Чаще всего встречаются форма логина (username/password), SSO, OAuth2, вход по заголовку (через прокси), заранее выданные cookie. Важно, чтобы метод не зависел от ручных шагов (капча, подтверждение по SMS). Если такие шаги есть, на тесте обычно делают отдельный тестовый способ входа.

2) Обеспечьте стабильную сессию

Решите, как сканер будет удерживать авторизацию во время длинного прогона. Сессия обычно рушится из-за таймаута, обновления токена или принудительного логаута при параллельных запросах.

Проверьте три вещи: как обновляется токен (refresh), что происходит при истечении времени, и есть ли ограничения на число активных сессий. На тестовой среде часто разумно увеличить таймаут, иначе вы будете сравнивать не поиск уязвимостей, а «кто дольше удержал cookie».

3) Ограничьте области и роли

Заранее задайте границы, чтобы не смешивать результаты. Например, сканируете только личный кабинет по пути /cabinet или только функции конкретной роли. Практичнее делать отдельный прогон на каждую роль с отдельными учетными данными.

Минимальный набор настроек, который стоит зафиксировать для каждого инструмента:

• учетная запись и роль;
• стартовые URL для входа и для начала обхода;
• правила scope (что включаем и что исключаем);
• лимиты скорости и параллельности;
• поведение при разлогине (останавливать скан или переавторизоваться).

4) Проверьте факт авторизации контрольным URL

Нужен один контрольный адрес, который точно доступен только после входа, и понятный признак успеха. Например, страница профиля с именем пользователя или раздел с балансом, который без входа заменяется на форму логина.

Важно проверять не только код 200, но и ожидаемый контент. Иначе сканер может получать страницу логина с кодом 200 и считать, что он «внутри».

5) Сделайте короткие прогоны и затем полный запуск

Сначала проведите 1-2 коротких теста на узком участке, чтобы убедиться, что переходы идут по нужным страницам, а контрольный URL стабильно подтверждает авторизацию. Только затем запускайте полноценное сканирование и сохраняйте настройки как эталон, чтобы в Burp Suite Enterprise, Invicti и Acunetix их можно было воспроизвести при повторных сравнениях.

Как оценить покрытие: что инструмент действительно прошел

При сравнении DAST важно смотреть не только на количество уязвимостей, но и на то, насколько полно сканер вообще «увидел» приложение. Иначе один инструмент будет казаться «сильнее» просто потому, что дошел до большего числа страниц и функций.

Покрытие - это подтвержденный факт посещения и попыток взаимодействия. Смотрите не на то, что «стояло в цели», а на то, что реально было запрошено и обработано.

Что считать покрытием на практике

Соберите метрики из отчетов и логов сканера и, по возможности, из серверных логов тестовой среды (чтобы подтвердить, что запросы дошли до приложения). Удобно фиксировать:

• уникальные URL и методы: сколько разных страниц и эндпоинтов реально запросили, включая GET/POST/PUT/DELETE;
• параметры и варианты: какие query/path/body параметры встречались и сколько разных значений пробовали (особенно для фильтров, ID, поиска);
• формы: какие формы отправлялись, какие поля заполнялись, были ли попытки отправить «пограничные» значения;
• API и «не-HTML»: учитывались ли JSON, GraphQL, загрузки файлов, скачивание документов, разные типы контента;
• роли и разделы: какие части приложения были достигнуты для каждой роли.

Сравнивать лучше по одинаковым «единицам». Например, количество уникальных комбинаций (URL + метод + набор параметров). Просто число страниц в отчете часто обманчиво.

Сверка с «картой приложения»: что не достигли и почему

Сделайте короткую «карту приложения» как эталон: список ключевых разделов, важных URL, основных форм и API-эндпоинтов (например, из документации, Swagger/OpenAPI, роутов фронтенда или структуры меню). Затем отметьте, что сканер не достиг.

Если участок не покрыт, причина обычно из понятного набора:

• навигация только через сложный JavaScript (выполнение отключено или сканер не справился);
• нужны специфические действия: мастер-форма, многошаговый процесс, подтверждение по кнопке;
• фильтры доступа: редиректы на логин, истекающие сессии, CSRF, ограничение по IP;
• не хватает «правильных» данных: без тестовых записей раздел пустой и ссылки не появляются;
• запреты в настройках: исключения по путям, лимиты глубины, таймауты, слишком строгие правила обхода.

Пример: в кабинете есть «История платежей», которая появляется только после выбора периода. Один сканер может застрять на пустом экране, а другой отправит форму с датами и получит список операций. В отчете это выглядит как «первый ничего не нашел», но на деле у него ниже покрытие.

Такой подход делает сравнение Burp Suite Enterprise, Invicti и Acunetix честным: видно, кто реально прошел больше маршрутов и действий, а кто просто меньше добрался до приложения.

Как измерять ложные срабатывания и подтверждать находки

Сравнивать Burp Suite Enterprise, Invicti и Acunetix по отчетам «как есть» бесполезно: разные движки по-разному формулируют риск, и часто создают дубликаты. Чтобы нормально оценить ложные срабатывания DAST на тестовой среде, заранее задайте правила подтверждения и способ подсчета.

Начните с простой классификации находок по двум осям: критичность (Critical/High/Medium/Low/Info) и тип (XSS, SQLi, SSRF, проблемы конфигурации и заголовков). Так быстрее видно, где инструмент шумит сильнее. Ложные срабатывания часто концентрируются в конфигурациях и «подозрительных» отражениях строк, а не в реальных инъекциях.

Дальше зафиксируйте, что считается доказательством уязвимости. Минимальный набор артефактов, который обычно реалистично получить на тесте:

• снимок запроса и ответа, где видно срабатывание (например, отраженная нагрузка для XSS или характерная ошибка для SQLi);
• повторяемое воспроизведение тем же запросом 2-3 раза;
• признак влияния на сервер: запись в логе приложения, изменение состояния, создание объекта, изменение данных;
• для SSRF и похожих классов - подтверждение сетевого обращения (лог прокси/DNS или запись на тестовом сервисе);
• для конфигураций - проверка факта настройки на нескольких эндпоинтах (например, заголовок действительно отсутствует в разных ответах).

Отдельно выделяйте категории «шума», иначе вы будете спорить о том, что не является уязвимостью. Типовые источники шума: таймауты и обрывы, нестабильные ответы (кэш, балансировщик, разные версии страницы), блокировки WAF, проверки, которые срабатывают из-за редиректа на страницу логина.

Чтобы сравнение стало численным, ведите простую таблицу: находка, тип, критичность, подтверждено/не подтверждено, причина отклонения, артефакт (файл/скрин). Дальше считайте метрики одинаково для всех инструментов:

• доля подтвержденных: confirmed / total;
• доля ложных: false / total (false = «не подтверждено» по правилам);
• доля «неопределено»: когда не хватило данных из-за нестабильности среды;
• количество уникальных находок без дублей;
• время на ручную проверку 10 находок (показатель «цены шума»).

Дубликаты важно срезать, иначе результат будет завышен. Один и тот же reflected XSS может прилететь на 12 URL по одной причине, а одна конфигурационная проблема - повторяться на каждой странице. В таком случае группируйте по первопричине (эндпоинт + параметр + класс) и считайте «уникально».

Пример: сканер сообщает SQLi на поиске, потому что увидел 500 и слово SQL в HTML. По вашим правилам это не доказательство. Вы воспроизводите запрос несколько раз, проверяете логи и видите: 500 вызван не инъекцией, а таймаутом к внешнему сервису. Такая находка уходит в «ложные» с причиной «нестабильность/таймаут». Это честно отражает качество сигнала инструмента в ваших условиях.

Частые ошибки при сравнении Burp Suite Enterprise, Invicti и Acunetix

Главная причина, почему сравнения DAST для веб-приложений расходятся с реальностью, проста: инструменты тестируют не одно и то же. Даже небольшая разница в версии сборки, данных или настройках делает цифры несопоставимыми.

Типичные ошибки:

• меняют приложение по ходу теста (другая ветка, другой конфиг, другие данные, включили или выключили WAF);
• не фиксируют рамки запуска: лимит времени, скорость запросов, число потоков, список исключений, глубину краулинга;
• считают только количество уязвимостей, не проверяя покрытие и качество подтверждения;
• думают, что авторизованная зона проверена, хотя сканер остался гостем (в отчетах нет страниц кабинета, а в логах много редиректов на /login или ответов 401/403);
• откладывают ручную валидацию на конец и затем неделями спорят о спорных отчетах.

Хорошая привычка - короткий протокол сравнения: какая сборка приложения, какие учетные записи, какие лимиты, какие исключения и какие критерии успеха. Тогда результаты Burp Suite Enterprise, Invicti и Acunetix будут не просто разными числами, а понятными выводами.

Пример: вы тестируете портал с личным кабинетом. Если один инструмент вошел под ролью «пользователь» и увидел только профиль, а другой вошел под ролью «оператор» и получил доступ к заявкам и внутренним формам, сравнивать количество проблем бессмысленно. Сначала выравнивают роли и маршруты, а уже потом обсуждают качество находок.

Пример сценария: портал с личным кабинетом и разными ролями

Представьте корпоративный портал: публичная часть (новости, контакты, каталог услуг) и личный кабинет, где пользователи подают заявки и оплачивают услуги. Такой стенд хорошо подходит, чтобы сравнить DAST не по «скорости сканера», а по тому, что он реально находит внутри закрытых зон.

В кабинете есть три роли, и у каждой свой набор страниц и действий:

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

Цель сравнения простая: понять, способен ли инструмент пройти ключевые пути в кабинете и корректно проверить формы (заявка, профиль, оплата), а не только «обстрелять» главную страницу.

Есть ограничения, которые часто ломают честное сравнение. На стенде включен rate limit (после N запросов в минуту возвращается 429), часть интерфейса отрисовывается на JavaScript, а сессия живет 15 минут. Это значит, что любой сканер будет ошибаться, если не умеет поддерживать авторизацию, повторно входить или работать по записанному сценарию.

Чтобы сравнение было одинаковым, задайте общие правила: один и тот же набор учеток для всех инструментов, одинаковое окно времени (например, 2 часа на роль пользователя и 2 часа на роль администратора), и единый список исключений. В исключения логично добавить то, что гарантированно создаст шум или не относится к цели: logout, страницы с тестовыми данными, health-эндпоинты, тяжелые выгрузки, если они «роняют» стенд.

Дальше важно, как вы принимаете решение. Удобно оценивать не «сколько находок», а три практичных показателя:

• подтверждение: сколько находок удается быстро воспроизвести вручную и доказать (особенно в оплате и заявках);
• покрытие: прошел ли сканер ключевые шаги (логин, создание заявки, переход к оплате, просмотр истории);
• трудозатраты: сколько времени уходит на настройку авторизации, разбор ложных срабатываний и повторные прогоны из-за истекшей сессии.

Если один инструмент «видит» кабинет, но 70% результатов не подтверждаются, а другой находит меньше, зато почти все воспроизводится и покрывает оплату и статусы заявок, то второй чаще оказывается полезнее в ежедневной работе.

Быстрый чек-лист и следующие шаги

Сравнение DAST полезно воспринимать как небольшой эксперимент: один и тот же билд, одинаковые правила, понятные метрики. Тогда результаты будут пригодны для решения, а не «как получилось».

Перед стартом зафиксируйте условия в одном документе:

• один и тот же тестовый билд для всех прогонов и включенное логирование (запросы, ошибки, авторизация);
• роли и учетные записи (гость, пользователь, администратор) без шагов, которые ломают автоматизацию (2FA/капча, обязательная смена пароля);
• контрольный набор URL и действий: 10-20 ключевых страниц и форм, которые должны быть пройдены;
• лимиты: длительность скана, глубина обхода, скорость запросов, окно запусков;
• где смотреть следы сканирования: логи приложения, WAF/прокси, журналы авторизации.

После прогона не ограничивайтесь подсчетом «уязвимостей». Сначала проверьте, что инструмент реально сделал:

• сопоставьте покрытие: какие разделы были посещены, какие формы отправлялись, где обход остановился;
• разделите находки на подтвержденные и неподтвержденные и отметьте способ проверки;
• уберите дубликаты (по первопричине, а не по количеству строк в отчете);
• зафиксируйте причины пропусков: редиректы, CSRF, капча, SPA-навигация, нестабильность среды, ограничения скорости;
• сохраните артефакты: конфиги сканера, версии, время запуска, сырые логи запросов.

Итог удобнее оформлять таблицей метрик: покрытие (сколько пунктов из контрольного набора достигнуто), время скана, число подтвержденных уязвимостей по уровням, процент ложных срабатываний, список пропусков с причиной. Добавьте 5-10 коротких примеров подтвержденных кейсов в формате «запрос - ответ - почему это уязвимость». Это обычно убеждает быстрее, чем сотни строк отчета.

Дальнейшая схема обычно простая: пилот на одном приложении и одной команде, затем расширение на 3-5 приложений, и только потом регламент (когда запускать, кто делает триаж, кто подтверждает, какой SLA на исправления).

Если под регулярные тесты нужен отдельный стенд, его разумно строить на выделенных серверах и рабочих станциях, чтобы сканы были стабильными и воспроизводимыми. В таких задачах, связанных с подбором инфраструктуры и системной интеграцией, может пригодиться опыт GSE.kz (gse.kz) как производителя и интегратора, особенно когда важно организовать надежную среду и поддержку для непрерывных проверок.