🚀 Простые, но действенные методы разведки для багхантера

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

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

1️⃣ Использование таргетированных словарей для брута неиспользуемых и скрытых хостов, эндпойнтов API, роутов приложения или входных параметров

Собирать словарь под проект может быть важно, потому что каждый разработчик пишет код и называет эндпойнты в своем стиле. У кого-то может быть /users, а у кого-то /show-all-users. Первый путь встретишь в любом словаре, а вот второй — нет. Однако он может встретиться в ходе разведки.

➡️ Алгоритм простой:

• Собираем все домены, пути и параметры с помощью любимых инструментов (katana, URLFinder, waybackurls, LinkFinder, gau) и/или Burp Suite, сохраняем в файл.

• Используем unfurl для парсинга уникальных ключевых данных из stdin:

$ cat urls.txt | unfurl paths
/users
/orgs
/about

• Анализируем результат и обогащаем другими данными.

💡 CeWL также поможет спарсить ключевые слова с целевого ресурса для составления кастомного словаря.

2️⃣ Фаззинг API с использованием различных методов HTTP

Некоторые приложения принимают только определенные HTTP-методы, да и описание API не всегда под рукой. Упростите себе жизнь с помощью следующей команды:

$ ffuf -u https://api.example.com/PATH -X METHOD -w /path/to/wordlist:PATH -w /path/to/http_methods:METHOD

3️⃣ Сканирование с различными заголовками User-Agent

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

gospider -s "https://app.example.com" -c 3 --depth 3 --no-redirect --user-agent "Mozilla/5.0 (iPhone; CPU iPhone OS 15_1_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.0 EdgiOS/46.3.30 Mobile/15E148 Safari/605.1.15" -0 mobile_endpoints. txt

4️⃣ Использование хешей фавиконов для поиска связанных активов

Если ваша цель — небольшая компания, у нее может не быть зарезервированного пула IP-адресов или она регулярно развертывает приложения в облачных сервисах. В этом случае мы все равно можем идентифицировать хосты, которые принадлежат цели, используя хеш фавикона:

• Получаем хеш из URL с помощью Favicon hash generator.

• Используем Shodan для поиска по хешу:

http.favicon.hash:<hash>

5️⃣ Поиск устаревших версий JavaScript-файлов

Анализируя интересный JS-файл, всегда просматривайте любые ранее заархивированные версии этого файла с помощью Wayback Machine или CLI-инструментов.

6️⃣ Мониторинг JavaScript-файлов

Если не хотите получить дубликат, отслеживайте изменения в JS-файлах и ищите баги в новом функционале первым. Вам помогут JSMon, Notify и другие инструменты.

7️⃣ Обнаружение скрытых параметров

Скрытые параметры могут позволить управлять поведением приложения и привести к успешной реализации различных сценариев атак. Для выполнения этой задачи помогут: Arjun, ParamSpider, Param-Miner, x8, ParamPamPam.

🤑 Эксплуатация IDOR через Path Traversal

Наткнулись на API-эндпойнт, как на первом скрине? Не проходите мимо: вполне вероятно, что перед вами IDOR.

Иногда вместо числового ID разработчики используют ключевые слова вроде me или current. API принимает оба варианта: и current, и 1234. Это делает IDOR-уязвимость менее заметной — но не менее опасной.

☑️ Что пробуем

1. Подставляем вместо current свой ID, например 1234.
2. Запрос проходит? Отлично.
3. Теперь вставляем ID другого пользователя.
4. Если эл. почта чужого аккаунта меняется — уязвимость подтверждена.

🧠 Более сложный пример

В больших проектах часто два API-сервера:
• фронтенд — для клиента;
• бэкенд — для внутренней логики.

Проблема в том, что права доступа проверяются только на фронтенде.

🚀 Подключаем Path Traversal

1. Отправляем /users/current/../1234/profile/email.
2. Фронтенд распознает current как ID пользователя и отправляет запрос на бэкенд.
3. Бэкенд получает путь /users/1234.
4. Проверки нет — можно менять чужие данные.

🎯 Что получаем

Возможность изменить эл. почту другого пользователя или получить доступ к его данным. Это полноценная IDOR-уязвимость, усиленная Path Traversal.

🧩 Вывод

Если API позволяет подставлять ID через ../, me, current (и т. п.) — это повод проверить на IDOR. Особенно если бэкенд не валидирует входные данные.

🔍 Пять простых способов найти баги в веб-приложении с GraphQL

Нашел хост GraphQL? Это тот самый строго типизированный язык запросов, который разработчики используют для простого извлечения данных.

💡 Мини-чек-лист для багхантера:

☑️ Запускаем introspection-запрос — получаем карту всех типов, запросов и мутаций.
☑️ Визуализируем структуру через GraphQL Voyager — это упростит анализ.
☑️ Используем BatchQL или расширение InQL — ищем IDOR, SQL-инъекции, SSRF и др.
☑️ Проверяем на CSRF, особенно если авторизация на основе cookie.
☑️ Тестим обход rate limit и DoS через батч-запросы.

🚀 Разберем подробнее

1️⃣ Introspection-запрос

Если включен — bingo. Получаем всю схему: типы, запросы, мутации. Собранную структуру удобно анализировать через GraphQL Voyager: он отлично фильтрует мутации и показывает архитектуру API.

2️⃣ Introspection отключен?

Не беда. GraphQL-серверы вроде Apollo часто поддерживают автодополнение: они подсказывают поля даже без схемы.

Вручную перебирать — боль, поэтому подключаем Clairvoyance: он восстанавливает схему даже без introspection.

3️⃣ CSRF

GraphQL сам по себе не защищен от CSRF. Если сессии на cookie, а не через Authorization-заголовок, — риск высокий. Пример: можно подделать запрос от пользователя без его ведома.

4️⃣ Обход лимитов

Многие лимиты считают HTTP-запросы, а не количество вложенных GraphQL-запросов.

GraphQL позволяет использовать алиасы: шлем кучу запросов в одном теле, сервер в шоке, лимит не триггерится.

5️⃣ DoS через батч-запросы

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

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

• BatchQL — проверка батчей, мутаций, SSRF, SQLi, IDOR и прочего.
• GraphQL Cop — делает 10+ тестов безопасности, включая CSRF.
• InQL — расширение для Burp Suite, идеально интегрируется и помогает в перехвате GraphQL-запросов.

P. S. При подготовке поста вдохновлялись статьей багбаунти-площадки Intigriti.