Standoff Bug Bounty Tips

Как слияние HTML-атрибутов превращается в рабочий XSS-вектор ⚡️

У страницы может быть только один <html> и один <body>. Если определить большее количество, их атрибуты будут объединены с атрибутами первого элемента 🎨

Поскольку некоторые санитайзеры могут не учитывать механизм объединения атрибутов, можно использовать эту фичу для разделения XSS-вектора по нескольким тегам:

<body style=animation:x id='First Body Tag'>
<body onanimationend=alert(this.id)>
<style>@keyframes x{

После парсинга браузер сформирует единый <body>, в результате чего:

1⃣ style=animation:x активирует фиктивную CSS-анимацию.

2⃣ Когда анимация завершается, событие onanimationend вызывает JavaScript.

3⃣ Санитайзер может пропустить такой пэйлоад, так как опасные атрибуты находятся в разных местах и выглядят безвредно по отдельности.

➡️ При написании поста вдохновились этим исследованием

Unicode-суррогаты: как один битый символ превращается в обход валидации 🔡

В некоторых системах одиночные Unicode-суррогаты работают необычно: валидатор пропускает их как обычные буквы, а внутренние сервисы преобразуют их в вопросительный знак.

В ряде баз данных ? — это wildcard. Так и возникает уязвимость, которая даёт доступ к данным 💭

Юникод использует диапазон символов U+0000–U+10FFFF. Но старый формат UTF-16 не мог напрямую закодировать все символы выше U+FFFF, поэтому придумали специальный механизм — суррогаты. Есть два типа:

High surrogates — старшие суррогаты
Диапазон: U+D800–U+DBFF

Low surrogates — младшие суррогаты
Диапазон: U+DC00–U+DFFF

По отдельности они не являются валидными символами. Но если записать их пару (high + low), то вместе они кодируют один символ за пределами базовой области Unicode (например эмодзи).

Пример: эмодзи 😄 — это комбинация двух суррогатов в UTF-16.

Багхантер Krzysztof Balas нашел публичный эндпоинт, который отдавал данные пользователя, если ввести:

⚫️ дату рождения,
⚫️ фамилию,
⚫️ ZIP-код.

Авторизация не требовалась. После первого репорта разрабы закрыли все спецсимволы, URL-encoding и даже «юникодные аналоги» запрещённых символов.

Но осталось кое-что ещё — одиночные Unicode-суррогаты, например \udc2a. Если отправить что-то вроде:

"lastname": "D\udc2a\udc2a",
"zipcode": "1\udc2a\udc2a\udc2a\udc2a"

, то парсеры UTF-8 не смогут корректно отобразить Unicode-суррогаты, которые часто используются в эмодзи с low и high парами. Все, что ты получаешь при попытке их отобразить, — это символ замены Юникода.

Некоторые парсеры, по-видимому, идут еще дальше и упрощают символ замены до вопросительного знака (?), что и приводит к возникновению уязвимости 💡

Необычное поведение href: как ограниченный DOM Clobbering превратить в полноценный Client-Side Path Traversal 🌫

Если в href указать невалидный протокол вроде ftp:: или https::, браузер перестаёт интерпретировать атрибут как URL. Это полностью ломает ожидаемую логику проверки протоколов и открывает дополнительные векторы атак 🚨

🟡 В обычном случае приложение и фильтры (например, DOMPurify) блокируют все протоколы, кроме http и https.

🟡 Но при использовании формы https:: строка уже не считается URL, и проверки протокола не срабатывают.

🟡 Это делает возможным обращение к эндпоинтам или выполнение действий, которые при нормальном парсинге URL были бы невозможны.

Идём дальше: почти любые символы после : приводят к аналогичному результату — браузер прекращает парсинг как URL и оставляет значение как обычный текст 🏃

Если в ходе рекона ты нашел файл package.json, возможно, некоторые внутренние пакеты уязвимы для атаки, связанной с dependency confusion ⤵️

В быстрой проверке поможет NPM Dependency Confusion Validator — новый инструмент от JSMon 🔥

Выполняем JS-код внутри <svg><script> 💨

Внутри тега <svg><script> браузер обрабатывает содержимое не как HTML, а как JavaScript-код. При этом действует важное правило парсера:

Внутри <script> только текстовые узлы становятся JavaScript-кодом.
Комментарии или вложенные SVG/HTML-элементы удаляются парсером.

Это приводит к интересному эффекту. Если написать что-то вроде:

<svg><script>al<//looks like js comment>ert(document.domain)</script>
или
<svg><script>al</h1>ert(document.domain)</script>

то последовательность внутри не считается JS-комментарием, и не считается HTML-элементом, а попадает под категорию «некорректный HTML-тег» 💲

HTML-парсер пытается «исправить» такую конструкцию — он удаляет невалидный HTML,
оставляя от исходного текста только:

al + ert(document.domain) → alert(document.domain)

Упрощаем обработку приложений APK / XAPK / APKM / DEX / JAR / WAR с помощью BFScan ⚡️

Когда разбираешь мобильное приложение, главная боль — собрать карту API. Proxy ловит не всё, OpenAPI нет, код обфусцирован, запросы раскиданы по 20 классам.

📦 BFScan решает эту проблему. Это статический анализатор, который вытаскивает HTTP-запросы, эндпоинты, параметры и даже черновую OpenAPI-спеку прямо из APK / XAPK / APKM / DEX / JAR / WAR.

🎯 Что вытаскивает

⚫️ URL, пути, токены, API-ключи и другие подозрительные строки
⚫️ Сырые HTTP-запросы
⚫️ OpenAPI-спецификацию (по аннотациям и конфигам)
⚫️ Захардкоженные секреты

🔍 Что анализирует

Клиентские библиотеки:

⚫️ Retrofit
⚫️ Ktorfit
⚫️ Feign

Серверные фреймворки и аннотации:

⚫️ Spring Web
⚫️ JAX-RS / Jakarta REST
⚫️ Jakarta Servlets
⚫️ Micronaut
⚫️ Struts 1/2
⚫️ Ktor routing
⚫️ Play Framework
⚫️ Swagger / OpenAPI-аннотации
⚫️ web.xml / jetty.xml

🧵 Что удобно для реверса

⚫️ Автоматически декомпилирует даже обфусцированный код через jadx
⚫️ Сшивает роуты, методы, параметры и тела запросов
⚫️ Даёт готовую базу для тестирования API, даже если приложение — чёрный ящик

🧪 Зачем багхантеру

⚫️ Быстрое перечисление скрытых методов API
⚫️ Поиск забытых эндпоинтов, внутренних роутов, legacy-методов
⚫️ Детект захардкоженных секретов → токены бэкенда, тестовые креды, Firebase-ключи
⚫️ Расширение поверхности атаки для мобилок и веба
⚫️ Отличная база для SSRF, IDOR, авторизационных багов, parameter pollution

Max-Forwards HTTP header ⏳

Во многих приложениях запросы проходят через цепочку прокси, балансировщиков и кэшей. Это скрытый слой инфраструктуры, который часто остаётся «невидимым» — а зря.

Один из способов подсветить эту цепочку — заголовок Max-Forwards. Если отправить запрос с этим заголовком, можно ограничить количество промежуточных узлов, которые обработают запрос.

По стандарту он применяется к методам TRACE и OPTIONS, но в реальных системах встречается куда шире. Вот почему это полезно:

💙 По разным ответам при разных значениях Max-Forwards можно понять, сколько прокси стоит перед приложением

💙 Иногда запросы начинают вести себя по-разному → можно увидеть несогласованную конфигурацию, нестабильные фильтры, проблемные балансировщики

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

Кейс редкий, но в правильный момент — очень показательный. Попробуй отправить TRACE / или OPTIONS / с разными значениями Max-Forwards и сравни ответы — иногда цепочка раскрывается сама 💡

От простой IDOR до критической утечки PII 😓

Когда доступ к файлам «защищён» сложными идентификаторами, это почти всегда означает одно: уязвимость не исправили, а спрятали под ковёр. Кейс из райтапа хорошо показывает, как такие баги выходят наружу ⤵️

Если ты нашёл классическую IDOR — с одного аккаунта можешь получить доступ к файлам другого —

GET /api/v1/files/view/{file_id} HTTP/2

Host: api.example.com
Authorization: Bearer <ACCOUNT_B_JWT>

но file_id имеет сложный формат:

[UserID]_[Filename]_[Timestamp]_[UniqueID]

→ IDOR есть, но как получить другие идентификаторы?

1️⃣ Найди эндпоинты, куда клиент передаёт имя файла:

Подходящие параметры:

* document_key
* file_key
* object_key
* blob_name

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

2️⃣ Попробуй отправить пустой ключ

Частая ошибка бекенда — передавать значение в storage/SDK как есть.

document_key: ""
document_key: " "
document_key: "%20"
document_key: null

S3-совместимые хранилища интерпретируют пустой ключ как ListBucket и возвращают список файлов.

3️⃣ Если получил список — используй пагинацию

S3 и аналоги отдают:

* первые 1000 файлов
* флаг IsTruncated: true
* последний ключ, который можно использовать как ?marker=...

Так можно пройти весь бакет и собрать имена файлов 💭

4️⃣ Подставь полученный ключ в «легитимный» эндпоинт

Если есть эндпоинт, который:

* принимает document_key
* возвращает pre-signed URL или прямой доступ

— подставь туда любой найденный ключ.

Если сервер не проверяет владельца файла, он подпишет URL к чужому объекту. Это и есть полноценный IDOR 💡

От обхода фильтрации email-адресов до SQLi 😓

Если система фильтрует email-адреса и запрещает спецсимволы, попробуй обойти проверку через кавычки перед @. Формат "username"@domain.com валиден по RFC 3696, и большинство валидаторов об этом «забывают» 🤕

Дальше начинается самое интересное — внутри кавычек можно размещать пэйлоад:

“<script src=//xsshere?”@email.com
“1-’or’1'=’1”@email.com
...

Твоя задача — аккуратно сломать валидатор, который определяет корректность адреса по RFC и пропустить вредоносный ввод в бэкенд. Если разработчики привязали фильтрацию email к SQL-запросу без параметров — дорога к SQLi открыта 💨

Если приложение использует magick convert для изменения загруженного изображения, смело пробуй докручивать до LFI с помощью "text:" ⚡️

ImageMagick будет парсить его и пытаться получить ресурс, указанный в атрибуте href. А содержимое файла будет рендериться в выходном изображении ⤵️

💡 При написании поста вдохновились этим ресерчем

При тестировании GraphQL API начинай с graphw00f — это быстрый способ понять, что именно скрывается под капотом 💡

Тулза отправляет серию запросов, на которые разные GraphQL-движки отвечают по-своему: где-то отличаются ошибки, где-то формат схемы, где-то особенности обработки мутаций и подписок.

🎶 Эти микросигналы позволяют точно определить технологию и версию сервера без доступа к коду.

Результат работы — матрица угроз, в которой сразу видны потенциальные векторы атак: от обхода схемы и нестандартных introspection-паттернов до SSRF через directives и уязвимых обработчиков мутаций 🔥

Ошибки бизнес-логики: манипуляции с последовательностью действий 🛁

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

Фронт обычно отдает страницы в определённом порядке, но при перехвате трафика с помощью прокси ты можешь изменять порядок запросов, отправлять их в неожиданных комбинациях и пытаться ввести сервер в состояние, которое он не ожидает.

Такие кейсы часто не покрыты тестами — в лучшем случае это приведёт к странному поведению, в худшем — к уязвимости. Вот несколько способов нарушить порядок:

1️⃣ Пропусти шаги вперед: попробуй обойти проверки и перейти в «будущее» состояние — например, совершив последовательность один раз, на следующую попытку обращаться только к шагам, которые ожидались на первом проходе.

2️⃣ Вернись назад: после выполнения шага попробуй запросить уже завершённый шаг — это может запутать сервер и изменить ответ.

3️⃣ Повтори действия: отправка одного и того же запроса несколько раз может иметь эффект, похожий на возврат назад и привести к неконсистентности.

Эксплуатация JSON web tokens: от теории к практике 🚀

По своей структуре JWT состоит из трёх частей — заголовка, пэйлоада и подписи:

➡️Заголовок (header) передает информацию о типе токена и используемом криптографическом алгоритме.

➡️Пэйлоад (payload) передает содержащиеся в токене так называемые утверждения (claims), которые делятся на три типа:

▪️Стандартные — данные о токене (предназначение, издатель, срок действия).
▪️Пользовательские — данные пользователя токена (имя, электронный адрес, номер телефона).
▪️Нестандартные — специфические поля, необходимые для конкретных приложений.

➡️Подпись (signature) гарантирует, что ни заголовок, ни пэйлоад не были изменены.

Большинство уязвимостей JWT возникают из-за неправильной настройки и некорректной проверки входных данных в процессе реализации. Разберем подробнее:

1️⃣ alg: none (отсутствие подписи) — если сервер принимает алгоритм none, можно отправить unsigned-токен с изменёнными claims и пройти аутентификацию.

2️⃣ Отсутствие проверки подписи — пропуск валидации подписи позволяет любому модифицированному токену считаться валидным.

3⃣ Algorithm confusion (путаница алгоритмов) — смена alg (например, с RS256 на HS256) даёт возможность использовать публичный ключ как HMAC-секрет и подделать подпись.

4⃣ Подмена JWK — динамическая загрузка публичных ключей (jwks.json) может быть использована для подмены ключа и принятия злонамеренно подписанных токенов.

5⃣ Инъекция через kid — небезопасная обработка поля kid может привести к инъекции пути/URL или выбору неподходящего ключа для проверки.

{
    "alg": "RS256",
    "kid": "example-key' OR UNION SELECT 'users'; --"
}

6⃣ Брутфорс слабых секретов — при использовании HMAC слабые или общие секреты можно подобрать перебором.

$ john --wordlist=/path/to/wordlist.txt jwt.txt

7⃣ Захардкоженные ключи — секреты, обнаруженные в исходниках, позволяют создать валидные токены.

Полезные инструменты и ресурсы:

🔗Introduction to JSON Web Tokens
🔗Exploiting JWT vulnerabilities: A complete guide
🔗 The JSON Web Token Toolkit v2
🔗BurpSuite JWT Editor
🔗PortSwigger Web Security Academy: JWT attacks