Skip to content

Исследование backend и API ​

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

1. Соберите первоначальную модель API ​

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

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

2. Определите модель авторизации ​

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

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

3. Обогащайте API и проектные списки ​

Продолжайте тестировать API, просматривая причины, отмеченные чекерами, и связанные HTTP-доказательства. По мере подтверждения новых сведений дополняйте:

  • ID — идентификаторами, принадлежащими конкретным пользователям или сессиям;
  • PARAMS, HEADERS и COOKIE — кандидатами для discovery;
  • HOSTS — известными приложениями и окружениями;
  • BASE_URLS — подтверждёнными базовыми маршрутами.

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

4. Ищите новые API по строкам и фрагментам ответов ​

Сравните строки старых и новых версий JavaScript и HTML-ресурсов: исчезнувшие маршруты и чувствительные значения иногда заметны только в таком сравнении. Отложите нерелевантные результаты, а оставшиеся строки и чувствительные JavaScript-конструкции передайте на ИИ-анализ.

Для строк PATH_LIKE запустите route discovery: WebVulnFinder сопоставит найденные пути с известными базовыми URL и поможет обнаружить API, которые не встретились при обычной работе с интерфейсом. Если путь неоднозначен, используйте сохранённый исходный код и задачу ИИ для поиска полного запроса.

Если в ответе найден код построения запросов, выделите значимый фрагмент и запустите создание OpenAPI через контекстное меню Burp. WebVulnFinder даст ИИ ограниченный поиск по уже сохранённым исходникам, подготовит операции и покажет их как рекомендацию с HTTP-запросами. Перед запуском добавьте разрешённые origin в HOSTS: только для них выполняется проверка endpoint-ов. Подробный порядок проверки и применения описан в главе «OpenAPI».

5. Повторяйте проверки с новым контекстом ​

Новые API, идентификаторы, параметры, хосты и базовые URL расширяют область применимых проверок. После существенного изменения модели повторно запускайте тесты над затронутыми API и проверяйте новые рекомендации.

Цикл можно продолжать, пока новые обходы интерфейса, строки и тесты перестают давать значимые дополнения. Результатом становится прослеживаемая цепочка: HTTP-обмен → API-наблюдение → проверка → HTTP-доказательство → рекомендация → решение пользователя → обновлённая база знаний.

Используйте WebVulnFinder только в согласованном scope.