Автотестирование

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

Автоматические проверки помогают выделить подозрительное поведение и сформировать рекомендации. Изменения наблюдений, свойств API и проектных списков остаются отдельным пользовательским решением. Тег TESTED отмечает выполненные проверки и не меняет статус наблюдения. Во время исследования API пайплайн ставит «В работе», а после полного прохода — «Подтверждён», если есть связанный ответ 2xx или 3xx, иначе «Отложено».

Откуда запускаются тесты

Автотестирование доступно для:

• отдельных HTTP-запросов;
• API-наблюдений;
• наблюдений поддерживаемых заголовков и кук;
• обнаруженных строк и маршрутов.

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

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

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

Первичное тестирование куки или заголовка использует все пригодные прикреплённые запросы. Для каждого origin (схема, домен и порт) сохраняется первый запрос с параметром, а затем добавляются GET-запросы с ответами HTML, JSON и XML — по одному на каждый тип. Поэтому наблюдение, впервые найденное в запросе JS или CSS, дополняется примерами для проверки по мере поступления трафика. Новый пример возвращает наблюдение в работу, сохраняя прежний комментарий. При необходимости прикреплённые запросы можно изменить вручную.

Панель «Планируемые тесты»

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

Выбор теста открывает его HTTP-шаги и результаты.

Вкладка «Запросы» панели тестов

Вкладка содержит уже выполненные тестовые HTTP-обмены. Для каждого запроса видны исходный и новый ответ, тип теста, изменённая позиция и payload. Выбор строки открывает фактически отправленный запрос и полученный ответ.

Над выполненными запросами доступны стандартные действия HTTP-редактора. Выбранные результаты можно передать на анализ с использованием ИИ.

Настройки генерации и исполнения

Профиль объединяет настройки состава и выполнения тестов. В нём можно:

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

В настройках проекта также задаются ограничение частоты запросов и значения для discovery-проверок.

Доступные группы проверок

Профиль включает проверки, направленные на разные классы поведения приложения:

Группа	Возможности
Ввод и обработка данных	XSS, SSTI, SQL-инъекции, OAST SQLi с внешним откликом, path traversal, переполнение, непечатаемые символы, пустые и изменённые значения.
Авторизация и доступ	Удаление данных авторизации, проверка обязательности параметров, межсессионный доступ и IDOR.
HTTP и инфраструктура	CORS, доверие к IP-заголовкам, Host и SSRF-проверки, альтернативные Content-Type и HTML-ответы.
Discovery	Поиск поддерживаемых параметров, заголовков, cookie, базовых URL и маршрутов.
ИИ-проверки	Контролируемые HTTP-пробы, создаваемые AI-задачами в пределах разрешённых инструментов.

Как найти источник отклика Collaborator

Новые отклики группируются по домену: расширение отправляет в Telegram одно уведомление на домен в каждой порции откликов. Если позднее на тот же домен придёт новый отклик, уведомление повторится. Если домен определить не удалось, расширение уведомляет о каждом таком отклике отдельно.

Уведомление сразу показывает время создания нагрузки в UTC и доступные фрагменты ID наблюдения/API и исходного запроса для поиска. К уведомлению приложен файл collaborator-interactions.json с данными отклика: сведения о DNS-запросе, HTTP-запрос и ответ либо SMTP-разговор. Исходные DNS- и HTTP-пакеты сохранены в Base64; если подпись не помещается рядом с файлом, текст приходит отдельно. Предпросмотр ссылок отключён. После временной ошибки отправки данные остаются доступны для повторной доставки.

Отклики на адреса расширения не появляются автоматически во встроенной панели Collaborator в Burp. Для их исследования используйте содержимое уведомления и историю исходных запросов.

Первая часть адреса до первой точки показывает время выдачи домена и источник нагрузки:

Известные ID	Первая часть адреса
Наблюдение и исходный запрос	<время>-<хвост ID наблюдения>-<хвост ID запроса>-<базовый payload>
Только исходный запрос	<время>-r-<хвост ID запроса>-<базовый payload>
Только наблюдение	<время>-o-<хвост ID наблюдения>-<базовый payload>

<время> — время выдачи домена в секундах Unix, записанное в системе счисления с основанием 36. Это время создания адреса, а не время отклика. При двух ID следующий фрагмент относится к наблюдению, затем идёт фрагмент ID исходного запроса. При одном ID префикс o- означает наблюдение, r- — запрос. Для поиска копируйте только соответствующий фрагмент ID между дефисами. Например, по <время>-c783a4b55129-d9591e68a947-<базовый payload> ищите c783a4b55129 среди наблюдений и d9591e68a947 среди исходных запросов.

Используется только последняя группа UUID после его последнего дефиса: при двух ID берётся от 3 до 12 её символов для каждого ID, при одном — от 5 до 12. Точная длина зависит от длины базового Collaborator payload: его сгенерированная часть не сокращается, а вся DNS-метка остаётся не длиннее 63 символов. Для базового payload длиной 30 символов оба ID сохраняют по 12 символов. Если наблюдение определить не удалось, в адресе остаётся ID запроса. По найденному источнику проверьте историю запросов и причину отклика; сам отклик не означает подтверждённую уязвимость.

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

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