⚒️ Автоматизация поиска Client-Side Path Traversals

CSPT — техника, известная с 2007 года, но не все багхантеры с ней знакомы. Давайте это исправим!

Представьте страницу профиля, которая всегда возвращает один и тот же HTML, но в URL есть параметр id. Скрипт на клиенте делает запрос к API по этому id, например:

example.com/profile?id=10 → браузер делает запрос к example.com/api/users/10 и подставляет данные.

Часто багхантеры пытаются найти IDOR, меняя id, но мало кто смотрит, что браузер делает отдельный запрос к API. А если подставить путь с traversal-паттернами, например id=../../hello?

Если браузер запросит example.com/hello — значит есть возможность управлять путями в запросах с клиента!

🤔 Почему это важно?

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

➡️Анализ ответа

Если мы перехватим запрос и проверим ответ, то можем увидеть что-то вроде:

{
    "id": 10,
    "name": "John Doe",
    "pic": "images.example.com/pic-12345.jpg"
}

Что бы мы могли сделать, если бы могли контролировать ответ на этот запрос? По сути, мы могли бы создать ссылку, которая при нажатии жертвы отправляла бы запрос в API, который затем возвращал бы контент, который мы контролируем.

Ценность контроля над этим контентом зависит от того, что с ним делает приложение. В нашем примере pic используется как src тега <img>, а значит, появляется возможность эксплуатации XSS.

➡️Open redirects

Если на сервере есть open redirect, можно заставить браузер сходить на внешний контролируемый ресурс и вернуть вредоносный контент.

Пример:

/profile?id=../../redirect%3Furl%3Dxss.example.com

— теперь ответ API контролируем мы, и можно пытаться эксплуатировать ту же самую XSS.

💡 Автоматизация

Chrome-расширение Gecko перехватывает все запросы, анализирует URL вкладки и проверяет, отражается ли часть текущего URL в запросах — признак CSPT:

▪️Сервис-воркер слушает запросы (chrome.webRequest.onBeforeRequest)
▪️Проверяет совпадения путей и параметров
▪️Хранит данные в локальном хранилище
▪️Показывает результаты в DevTools-панели и через всплывающее окно
▪️Поддерживает частичное совпадение, чтобы ловить случаи с расширениями файлов и вариациями путей

💫 Автоматизация Burp Suite: как сэкономить время и работать эффективнее

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

🚀 Воркфлоу: пассивное и активное сканирование

Пассивные сканеры анализируют результаты активных: если активный вызвал ошибку, пассивный её найдёт и покажет в дашборде.

Ответы от прокси идут и активным, и пассивным сканерам. Ответы с репитера и расширений — только пассивным. Это обеспечивает плавный и синхронизированный процесс.

👉 Активный скан: не взломать все, а максимально покрыть функционал

▪️BCheck — относительно свежая фича для написания скриптов прямо в Burp. Используется как для сложных кейсов, так и для фаззинга файлов/директорий, спрея пэйлоада. Рекомендуется добавлять кастомный заголовок для отслеживания запросов в Logger++.

▪️Burp Bounty — расширение для сложных сканов с гибкой настройкой пэйлоада и правил детекции.

👉 Пассивный скан — второй уровень обнаружения для глубокого анализа ответов и поиска пропущенного активным сканером

▪️Пассивный краулер — строит карту сайта и помогает понять структуру приложения.

▪️Error Message Checks и Response Grepper — ищут ошибки и паттерны, помогают подстроить активные сканы.

▪️BCheck (пассивный режим) — определяет технологии приложения, фильтрует данные и уменьшает нагрузку, исключая неактуальные пэйлоады.

💡 Logger++ — логирует все запросы и ответы, предлагает фильтры и подсветку, упрощая анализ и отладку автоматизации.

🔍 Как найти баги в API: 12 проверенных способов

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

1️⃣ Blind XSS через заголовки: приложения могут логировать ваши данные различными способами, поэтому проверяйте XSS-пэйлоад в HTTP-заголовках (X-Forwarded-For, Referrer, User-Agent и других)

2️⃣ Устаревшие API: /api/v2 → /api/v1, /api/v2 → /api/, api-v2.example.com → api-v1.example.com или api.example.com

3️⃣ SSRF: заменяйте любой URI в запросах на контролируемый вами ресурс через Proxy Interceptor Match & Replace Rule и ждите входящие соединения

4️⃣ Поиск эндпоинтов: используйте GitHub, Google/Yandex дорки, анализируйте JavaScript, Swagger API или другую документацию

5️⃣ CSRF: удалите или замените anti-CSRF токен, меняйте Content-Type и метод запроса

6️⃣ Эксплуатация JWT: ищите слабые алгоритмы подписи, пробуйте манипулировать с токенами

7️⃣ Обход 401/403: попробуйте получить доступ ко вложенному пути (/admin 401 → /admin/system-resources 200), добавьте спецсимволы или измените методы запроса

8️⃣ Неправильная настройка CORS: проверьте правильность настроек CORS и убедитесь, что API позволяет отправлять запросы из любого источника с использованием учётных данных

9️⃣ Тестирование race conditions: проверяйте так называемые high-value транзакции — загрузка файлов, размещение заказов, платежи, переводы

1️⃣0️⃣ XXE: измените Content-Type с application/json на application/xml и проверьте на наличие XXE

1️⃣1️⃣ NoSQL инъекция: манипулируйте параметрами и добавляйте MongoDB (или любой другой NoSQL БД) пэйлоад для обхода ограничений

1️⃣2️⃣ Обход загрузки файлов: пробуйте загрузить файлы с нестандартными расширениями или без них, используйте известные методы обхода (null byte, magic byte и другие)