Общий цикл исследования

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

Карта исследования

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

Карта показывает поступившие объекты по этапам и число обработанных за текущий запуск Burp. Колонка «Другие статусы» показывает объекты, которые сейчас не имеют статуса «Готов» или «Обработан»; выберите строку, чтобы увидеть их состояния и подробности. Подпункты API 2.1–2.4 и анализа исходника 3.1.1–3.1.2 имеют отдельные строки и счётчики; заголовки разделов их не суммируют. Текущий шаг отмечен в первой таблице, текущий объект — во второй. Карта показывает и этапы, для которых автоматизация ещё не готова: созданные вручную в Burp наблюдения, включая API из принятой OpenAPI-рекомендации, появляются на карте после сохранения. Для объектов, возникших при обработке трафика, доступно «Обновить с сервера». Когда локальная очередь доступного анализа заканчивается, карта также сверяет с сервером уже известные объекты и добавляет новые. Счётчики сбрасываются после перезапуска Burp; сохранённые решения остаются в проекте.

На большом проекте группы появляются на карте по мере загрузки. Как только появились доступные объекты, можно запускать их анализ, пока остальные группы ещё загружаются. Загрузка карты не задерживает другие задания общей очереди.

«Запустить доступный анализ» проводит через готовые этапы исследование портов и роли Host (1.1), авторизации доменов, API, исходников JavaScript и HTML и чувствительных JavaScript-конструкций. Для исследования портов нужен локальный nmap: через PATH либо стандартную установку nmap.app или Homebrew на macOS. Его наличие проверяется при загрузке данных; статус «Ожидает» и колонка «Причина» объясняют блокировку. После установки достаточно обновить данные с сервера. Сервер создаёт наблюдение Host при анализе первого запроса с новым origin, поэтому его можно исследовать до API. Анализ API начинается после завершения анализа авторизации домена с тем же origin; до этого API виден как ожидающий. Пайплайн подаёт ИИ задачи по одной: после анализа объекта разбирает его рекомендации, затем переходит к следующему. В таблице объектов задача различается как стоящая в очереди ИИ или уже исполняемая. Задача, ожидающая решения человека, не задерживает другие готовые объекты; перед следующим объектом карта сверяет такие ожидания. После завершения всех связанных API может поступить отдельное задание анализа их бизнес-группы 2.4. Незавершённое задание группы сохраняется при перезапуске Burp. Кнопка «Остановить» прекращает запуск следующих стадий: текущая ИИ-задача завершается без отмены. Работу можно продолжить; после ошибки объект остаётся отложенным до явной команды «Продолжить». В контекстном меню строки объекта можно открыть наблюдение или поставить его следующим на анализ.

Перед запуском или продолжением исследования дашборд проверяет доступность парсера JavaScript. Если он недоступен, можно запустить JSParser и повторить проверку, продолжить без него или отменить запуск. При продолжении без парсера анализ JavaScript может завершиться ошибкой. Если сам сервер недоступен, дашборд покажет ошибку подключения и исследование не начнётся.

Выделите шаг в первой таблице: вторая покажет только его объекты, а третья — сводку принятых и отклонённых рекомендаций по типам этого шага. Во второй таблице для каждого объекта видны числа созданных, решённых и ожидающих рекомендаций; ручное решение меняет эти числа. Над списком объектов доступны обычные фильтры таблицы с историей условий, сортировкой и экспортом. Сеансовые числа сбрасываются при перезапуске Burp, затем восстановленные незавершённые задания 2.4 снова учитываются как поступившие.

Если Burp закрылся посреди этапа, при следующем запуске объект снова войдёт в этот этап по сохранённому состоянию. Запуск анализа повторит незавершённый шаг; подтверждённые этапы не повторяются.

Ручные правки наблюдений в Burp и принятые рекомендации передают карте обновлённые данные. Маркеры выполненных шагов учитываются в счётчиках; снятие маркера возвращает соответствующий шаг к анализу. Создание, дублирование, смена типа и объединение учитывают появившиеся наблюдения. Удалённые объекты и объекты, которые больше не подходят под условия отбора, исключаются из доступного анализа. При необходимости используйте «Обновить с сервера» для повторной сверки.

1. Соберите исходный трафик

Создайте проект и пройдите основные пользовательские сценарии через Burp Proxy: экраны, роли, формы и операции с объектами. Откройте инструменты разработчика браузера, чтобы получить доступные source map и связанные ресурсы. Внешний краулер можно использовать как дополнительный источник трафика через Burp. Из доступной OpenAPI-спецификации можно импортировать API, даже если они ещё не встречались в Proxy.

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

2. Подготовьте авторизацию и границы ИИ

Через произвольный диалог попросите помощника предложить правила захвата авторизационных заголовков, CSRF-токенов и ID объектов по сохранённым ответам. Проверьте предпросмотр извлечённого значения и примите нужные рекомендации. Добавьте имена чувствительных cookies в SECURE_COOKIE, а нестандартных авторизационных заголовков — в SECURE_HEADERS; обычный Authorization WebVulnFinder учитывает автоматически. Это делает проверки снятия авторизации и работу с Pwn-сессиями точнее.

Если сессии истекают, настройте их обновление через Burp Session Handling Rule и, при необходимости, собственный скрипт Turbo Intruder. Назначьте запросы проверки сессии, чтобы остановить автоматизацию при потере доступа. Порядок удержания сессии описан отдельно.

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

3. Уточните модель приложения

Если известны язык backend или СУБД, задайте правила технологий для соответствующих областей URL. Уточняйте их по мере появления новых свидетельств: так WebVulnFinder не будет предлагать неприменимые проверки.

Разберите обнаруженные строки из HTML и JavaScript. Сравнение ответов помогает увидеть изменения между версиями ресурсов, включая исчезнувшие маршруты и секреты. Старые или нерелевантные строки можно отложить, исключить либо отметить для дальнейшей работы; особое внимание уделяйте PATH_LIKE и SECRET. Для оставшихся кандидатов запускайте ИИ-анализ строк, чтобы найти новые API.

4. Проверьте API и гипотезы

Для API-наблюдений выберите подходящий уровень доступа: «Только чтение» для изучения опасных операций и «Полный доступ» там, где разрешены активные пробы. Запускайте пассивный либо активный ИИ-анализ и автотесты, сверяя сигналы с исходными и фактически отправленными HTTP-запросами. Чувствительные JavaScript-конструкции можно отдельно передать на ИИ-анализ; очевидный шум отсейте до запуска.

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

Для строк PATH_LIKE можно запустить поиск маршрутов, поиск осуществляется с учетом уже зафиксированных API и наполнения списка BASE_URL. Если по исходному коду непонятно, как строится запрос, используйте создание OpenAPI по фрагменту ответа. Полученные API проходят тот же цикл анализа и тестов.

5. Повторите цикл с новыми данными

После добавления API, параметров, сессий или технологий повторите применимые проверки. Для новых целей могут понадобиться другие контрольные запросы и уровни доступа. Внешний анализ JAR или WAR, например через BFScan, может дать OpenAPI-спецификацию для импорта.

Результат работы — прослеживаемая цепочка от HTTP-обмена и наблюдения до теста, ответа, рекомендации и принятого решения. Примеры интерфейса: наблюдения, тестовые запросы и журнал ИИ-задачи.