🛠️ Фаззинг HTTP-заголовков на практике

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

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

Пример простого запроса с заголовком Forwarded (подробнее — в RFC 7239):
GET / HTTP/1.1
Host: redacted.com
Forwarded: example.com


Ответ:
HTTP/1.1 200 OK
Content-type: text/html; charset=utf-8
Content-Length: 8426


Но если изменить Forwarded так:
Forwarded: for=example.com;host=example.com;proto=https


Сервер вернет:
HTTP/1.1 500 Internal Server Error
Content-Length: 764


Если и это не сработает, попробуйте другие варианты из документации nginx.

Подобное поведение — повод начать глубже исследовать причину ошибки и искать соответствующие баги.

Уровень сложности: 🪲🪲🪲

🔄 Реверс приложений на Flutter

Наткнулись на мобильное приложение под управлением Flutter и не понимаете, как перехватить сетевые запросы? ReFlutter — тот самый инструмент для хантеров за мобильными багами 📱

ReFlutter заменяет оригинальный движок Flutter в APK на модифицированный, что позволяет в реальном времени перехватывать сетевой трафик на нативном уровне. Достаточно просто настроить BurpSuite.

После патча APK его нужно заново подписать. Быстрее всего — через uber-apk-signer:

java -jar uber-apk-signer.jar --allowResign -a release.RE.apk


Уровень сложности: 🪲🪲🪲🪲

🔎 Скрытые параметры запросов в действии

Один из способов найти новые параметры запроса с помощью JavaScript-файлов — собрать имена переменных и преобразовать их в параметры запроса.

Иногда это допустимые параметры, которые обрабатываются бэкендом небезопасными способами.

Мы открыли комментарии!

Спасибо, что читаете нас и ставите реакции — ваша поддержка реально драйвит продолжать. Мы делаем контент прежде всего для middle+ специалистов, тщательно отбирая темы, которые считаем полезными и редкими для российского сегмента багбаунти.

Делитесь в комментариях темами, которые вам интересны — будем стараться брать их во внимание при подготовке следующих постов.

Команда Standoff Bug Bounty ❤️

🎯 От XSS к SSRF: эксплуатируем Edge Side Includes

Когда кэширующие серверы и балансировщики нагрузки стали неотъемлемой частью современной инфраструктуры, производители внедрили технологию Edge Side Includes (ESI) — способ управления динамическим контентом на уровне кэша. Эта устаревшая, но до сих пор используемая технология может быть опасна и открывает новую поверхность атак.

Язык ESI состоит из набора XML-инструкций, которые возвращает сервер приложений. Они обрабатываются на Edge-серверах (балансировщиках, прокси-серверах). Поскольку Edge-серверы доверяют тому, что приходит с апстрима, они не различают легитимные и вредоносные ESI-инструкции.

👉 Через ESI можно:

🚀 Выполнить SSRF.
🚀 Получить доступ к куки без использования JavaScript даже с флагом HttpOnly.

Уязвимые при определенных условиях решения: Akamai, Fastly, F5, Squid, Varnish, WebLogic, WebSphere, а также любые кастомные решения на Node.js, Ruby и других языках, которые используют обработку ESI без строгой фильтрации и контроля источников.

«Где пруфы?» — спросите вы. В докладе Louis Dion-Marcil на DEF CON 26! Еще в 2018 году он выступил с темой Edge Side Include Injection: Abusing Caching Servers into SSRF and Transparent Session Hijacking. Этот пост вдохновлен его докладом 🔥

🔍 Пять простых способов найти баги в веб-приложении с 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.

🤢 HTTP request smuggling: подтверждение баги CL.TE через дифференцированные ответы

💡 HTTP request smuggling — атака, направленная на рассинхронизацию фронтенд- и бэкенд-сервера, в результате которой можно внедрить HTTP-запрос мимо фронтенд-сервера. В результате успешной эксплуатации можно сдать критическую багу 🤑

Request smuggling в первую очередь связана с запросами HTTP/1, но некоторые приложения, поддерживающие HTTP/2, также могут быть уязвимы в зависимости от внутренней архитектуры.

При наличии уязвимой конфигурации CL.TE фронтенд-сервер использует заголовок Content-Length, а бэкенд-сервер — Transfer-Encoding:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 13
Transfer-Encoding: chunked

0

SMUGGLED


💡 Как обнаружить баги типа CL.TE

1. Отправляем запрос в Burp Repeater.

• Понижаем версию протокола до HTTP/1.1.
• Отключаем опцию Update Content-Length.
• Устанавливаем заголовок Content-Length в значение 6.
• Добавляем заголовок Transfer-Encoding: chunked.
• Отправляем chunk с некорректным размером.

Если сервер на бэкенде уходит в тайм-аут, это может указывать на потенциально уязвимую конфигурацию CL.TE.

💡 Подтверждаем через дифференцированные ответы

2. Формируем и отправляем вредоносный запрос:

• Заменяем предыдущий chunk на завершающий (terminating) chunk.
• Добавляем контрабандный запрос после тела chunked-запроса.
• Добавляем строку X-ignore: X (без перевода строки в конце) и отправляем.

3. Сразу после вредоносного отправляем обычный запрос в Repeater и понижаем его до HTTP/1.1.

Если в ответ на обычный запрос приходит 404 вместо 200, значит — бэкенд был «отравлен»!

👉 Потренироваться на лабораторной работе PortSwigger

🔍 Blind XSS в приложениях, разработанных с помощью JavaScript-фреймворков

Если тестируете SPA-приложения на Angular или Vue, обычные XSS-пейлоады могут «не стрельнуть» — фреймворки используют шаблонизацию и просто экранируют HTML.

👆 Используйте template injection с constructor.constructor, чтобы исполнить свой код даже в слепых кейсах.

🤑 Эксплуатация 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. Особенно если бэкенд не валидирует входные данные.

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

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

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


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

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

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

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

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

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

🔎 Перечисление поддоменов: как расширить поверхность атаки с помощью активных и пассивных методов

Мы решили запустить экспериментальный формат, в котором будем делиться полезными советами от опытных багхантеров — не ежедневно, но регулярно. Начинаем с самой базы — можно унести ее в сохраненки и возвращаться к ней по необходимости. Не забывайте ставить реакции под постом, чтобы мы понимали, был ли материал полезен. А если у вас есть предложения о контенте, не стесняйтесь рассказать об этом в комментариях. Enjoy!

Что делает убитый горем багхантер, который не может найти хоть какую-нибудь зацепку? Правильно — проводит разведку по новой: пассивный и активный поиск поддоменов, брут путей и файлов, использование дорков, исследование используемых в приложении технологий и т. д. Каждая тема здесь достойна отдельного поста, поэтому начнем по порядку с простого — сбора поддоменов.

⭐️ Описанное ниже особенно полезно, когда в скоупе багбаунти-программы есть DNS-записи wildcard (*.domain.tld).

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

➡️ Пассивный сбор поддоменов: вы не взаимодействуете с целевым узлом и получаете информацию из открытых источников (DNS-записи, логи сертификатов SSL и TLS или веб-архивы).

Примеры используемых инструментов:

�� Censys, Shodan, SecurityTrails, DNSDumpster и другие онлайн-сервисы.

🟢 Инструменты вроде subfinder, amass или waybackurls, которые сами опросят множество публичных баз данных и выведут результат в удобном для вас формате (останется только добавить API-ключи):

$ subfinder -d example.com -oJ domains-example.com.json
или
$ amass enum -d example.com -o domains-amass.example.com.txt -timeout 12 -v


🟢 Google-дорки — это база:

site:*.example.com -site:www.example.com


➡️ Активный сбор поддоменов включает поиск любых поддоменов, которые не проиндексированы публично, но активно используются. Разберемся с ключевыми методами:

🟢 Брутфорс DNS — перебор поддоменов по словарю, который должен быть составлен отдельно исходя из полученных в ходе разведки данных. Про общедоступные словари тоже не стоит забывать (SecLists, fuzzdb, Assetnote Wordlists). Важно не останавливаться на доменах 3-го уровня, а искать дальше. В этом поможет инструмент mksub, с помощью которого можно сгенерировать дополнительные вариации поддоменов:

$ gobuster dns -d example.com -w wordlist.txt
$ mksub -d example.com -l 2 -w dns-wordlist.txt


🟢 Фаззинг виртуальных хостов (vhosts), которые имеют тот же IP-адрес, что и другой домен на веб-сервере. Полезные инструменты для работы — ffuf и wfuzz.

$ ffuf -c -r -u 'https://www.example.com/' -H 'Host: FUZZ.example.com' -w dns-wordlist.txt


🟢 Reverse DNS (rDNS): преобразует IP-адрес в связанное с ним доменное имя. Этот способ особенно полезен при исследовании диапазона целевых IP-адресов. На помощь придут инструменты Linux (dig, host) или общеизвестный dnsx.

$ dig -x 8.8.4.4 +short
$ cat ips.txt | dnsx -ptr -resp-only


➡️ Веб-краулинг с помощью Burp Suite или других инструментов: просто укажите кастомный скоуп, ходите по ссылкам и отслеживайте новые поддомены.

.*\.example\.com$


⭐️ Последняя задача — определить активные веб-узлы и избавиться от фолзов. Самый простой способ — использовать httpx или httprobe. Собираем поддомены в отдельный файл и выполняем:

$ cat domains.txt | httpx -o domains-webserver.txt
или
$ cat domains.txt | httprobe >> domains-webserver.txt


💡 Хотите еще сильнее упростить себе жизнь? Используйте anew для добавления уникальных строк в файл из stdin. Инструмент выводит новые строки в stdout, что делает его немного похожим на команду tee -a.

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