Standoff Bug Bounty Tips

Что скрывается в имени HTML-тега? Может быть, JavaScript?

Gareth Heyes из PortSwigger показал: имя HTML-тега само по себе может стать JS-пэйлоадом. Браузер приводит имя тега к верхнему регистру, но свойство localName отдает его обратно в нижнем — и дальше из этого собирается цепочка.

Схема простая: tabindex + autofocus триггерят onfocus, в хендлер пишется строка из localName, а new onfocus исполняет её как конструктор.

<alert(1) onfocus="attributes[0].value=localName,new onfocus" autofocus tabindex=1>
<JAVASCRIPT:ALERT(1) onfocus=location=localName autofocus tabindex=1>

Что это даёт для байпаса WAF 👇
▪️ JS можно писать капсом — localName всё равно вернёт нижний регистр
▪️ Символы-разделители строк и абзацев браузер в имени тега не трогает, а JS считает их переводом строки
▪️ Если фильтр режет attributes[0].value — есть .textContent, .nodeValue, getAttributeNode(...).value
▪️ Через part/classList имя тега уходит прямо в eval

🔗 Полный набор пэйлоадов ждет тебя в ресерче

Хочешь прокачать своего багбаунти-агента ❓

Обрати внимание на Model-Context-Protocol (MCP) серверы для DevTools в Chrome и Firefox. Они дают ИИ-агенту прямой доступ к браузеру через протокол отладки: от проверки сетевых запросов и элементов DOM до выполнения JS в консоли и создания скриншотов. И все это программно 😎

⛓ Chrome DevTools for agents
⛓ Firefox DevTools MCP

Эксплуатация багов, связанных с ошибками в бизнес-логике 🤔

Логические баги — это когда код работает ровно как написан, но воркфлоу приложения можно вывернуть против логики, которую в него закладывали.

Прогоняй находку через три метрики. Если не задета ни одна — это всего лишь функциональный баг:

♦️ Конфиденциальность: видишь чужие данные?
♦️ Целостность: меняешь защищённые данные?
♦️ Доступность: можешь положить компонент/приложение?

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

Разберем на примерах ⤵️

🔴 Broken Access Control. Например, приложение читает order_initiation_id из тела запроса, но никто не проверил, что ID принадлежит тебе. Подменяешь → чужие конфиденциальные данные.

🔴 Инъекция через непоследовательную валидацию. Основное приложение режет XSS/SSTI/SQLi в email. Но отдельный портал email-настроек валидацию не делает и синхронизирует ввод обратно в кор. Валидация есть в одном месте и отсутствует в другом — ищи такие стыки.

🔴 Манипуляция ценой. Код расчёта цены не учитывает пользовательский код валюты и шлёт его в платёжный шлюз без проверки. Меняешь USD → JPY и платишь копейки.

🔴 Криптографический флоу. JWT с алгоритмом none: разраб не обработал неподписанный токен на аутентифицированном эндпоинте → полный обход аутентификации.

Мы накидали 6 разных вариантов атак для простого GET-запроса на редактирование профиля ⤵️

/edit_profile.php?id=12345 -> /api/user/profile?user_id=12345

Это базовые типы атак. Вот еще несколько интересных векторов 🧠

1️⃣ Изменение метода запроса: GET → POST/PUT/DELETE
Авторизация может проверяться только для GET, а для других методов — нет.

2️⃣ Манипуляция через заголовки, а не параметры: X-User-Id: 12345 → X-User-Id: 12344 или подмена Referer, X-Forwarded-For, X-Original-URL

3️⃣ Удаление параметра полностью: проверь, не возвращает ли API дефолтные данные (например, первого юзера в базе) при отсутствии параметра.

Какой пэйлоад ты еще протестишь в случае такого запроса ❓

Stored XSS через картинку: проверь Content-Type override 😵‍💫

Иногда загрузка изображений выглядит безопасной: проверяется расширение, MIME type, magic bytes и файл сохраняется как image/png.

Но баг может быть не в загрузке, а в выдаче файла. Если приложение хранит пользовательские изображения в S3/MinIO и отдаёт их через reverse proxy, стоит проверить публичный объект с параметром:

?response-content-type=text/html

Пример:

https://cdn.target.com/uploads/avatar.png?response-content-type=text/html

Если в ответе видишь:

Content-Type: text/html

это сигнал для дальнейшего ресёрча. Браузер может начать обрабатывать загруженный файл не как картинку, а как HTML.

📌 Для MinIO такой override может сработать сразу: был объект с image/png, добавил параметр — получил text/html.

📌 Для S3 анонимный запрос обычно отвечает ошибкой:

Request specific response headers cannot be used for anonymous GET requests

Но это не тупик, а признак, что override поддерживается, просто S3 не применяет его для анонимного GET-запроса. В райтапе багхантер показал байпас: подписываешь запрос своим AWS-аккаунтом и добавляешь response-content-type=text/html уже в signed URL.

Главное — проверяй origin. Если пэйлоад открывается на случайном storage-домене, импакт может быть низким. Если файл отдаётся с целевого домена:

cdn.target.com/uploads/file.png
target.com/uploads/file.png

то HTML выполняется уже в контексте доверенного origin.

Чек-лист для багхантера ➡️
✅ Добавляй ?response-content-type=text/html к каждому публичному загруженному изображению
✅ Смотри, меняется ли Content-Type
✅ Отдельно проверяй поведение MinIO и S3
✅ Оценивай не только рендер, но и origin

Как воспроизвести 1-day: 3 этапа для багхантера 💡

А ты уже посмотрел наш выпуск про 1-day ❓

В нем Михаил Ключников aka n1 делится тулингом и разбирает, как подходить к таким багам системно: не просто копировать чужой пэйлоад, а понять, что именно изменилось в коде и как это проверить на стенде.

3 ключевых этапа ⤵️

❤️ Подготовь стенд
❤️ Найди две версии софта: с фиксом и без
❤️ Подними локально и загрузи исходники
❤️ Настрой удаленную отладку

Задача этапа — получить контролируемую среду, где можно безопасно сравнивать поведение до и после фикса.

❤️ Сделай diff
❤️ Оставь только файлы приложения
❤️ Декомпилируй при необходимости
❤️ Сравни две версии
❤️ Найди ключевые изменения, которые похожи на публичное описание уязвимости

❤️ Проверь гипотезу на стенде
❤️ Сравни поведение на обеих версиях
❤️ Сформируй пэйлоад на основе исходников
❤️ Оформи минимальный PoC

Что еще ждет тебя в выпуске:
✔️ Жизненный цикл уязвимости
✔️ Что такое 0-day и 1-day
✔️ Как отслеживать и воспроизводить уязвимости
✔️ Какие инструменты использовать при анализе уязвимостей
✔️ Как репортить 1-day

Collaborator Everywhere — одно из самых недооценённых расширений Burp для обнаружения точек входа SSRF/blind RCE 🔥

Расширение инжектит пэйлоад в HTTP-заголовки и параметры URL-адресов. Твоя задача — покрыть весь функционал приложения и ждать отстук в Collaborator 😵

С чего начать поиск мисконфигов в AWS S3 🗑️

1️⃣ Найди целевые S3-бакеты

Начни с разведки: Google-дорки + брутфорс, AWS Eye, S3Enum, cloud_enum.

2️⃣ Проверь конфигурацию

После обнаружения бакета проверь его настройки. Cloud_enum и AWS Extender помогут быстрее выявить типовые мисконфиги: публичный доступ, ошибки в правах и другие проблемы конфигурации.

3️⃣ Прокачай знания

Если хочешь разобраться глубже — смотри выпуск «Начинаем в багбаунти» про S3 misconfigs + в качестве бонуса лови:

🔗 Список заголовков и страниц ошибок популярных S3-совместимых решений
🔗 Расширения для Burp Suite и Caido для работы с подписанными S3-запросами

Как проверять Web Cache Poisoning ❓

Отравление веб-кэша возникает только тогда, когда вредоносный ответ попадает в кэш и потом отдаётся другим пользователям.

Базовая логика проверки:

1️⃣ Понять, кэшируется ли ответ: если ответ вообще не попадает в кэш, poisoning не сработает

2️⃣ Найти часть запроса, которую кэш не учитывает: это часть запроса, которая влияет на ответ, но не входит в cache key

Например: заголовок, параметр, cookie или путь, которые меняют поведение origin-сервера, но игнорируются кэшем.

3️⃣ Проверить влияние на ответ

Найденная часть запроса должна приводить к «опасному» результату: отражению вредной строки, подмене ссылки на скрипт, перенаправлению, изменению meta-тега, ошибке 500 или другому поведению с понятным импактом.

4️⃣ Проверить, отдаётся ли отравленный ответ другим пользователям

Если изменённый ответ видите только вы, это ещё не полноценное отравление кэша. Нужен сценарий, где тот же кэшированный ответ получает другой клиент.

Главное правило при тестировании: всегда используй cache buster.

Например:

?cb=random-value

Но cache buster должен попадать именно в ключ кэша. Если кэш не учитывает строку запроса, случайный параметр в URL не поможет: можно получить false negative или случайно затронуть реальных пользователей.

Что проверять в отчёте:

✅ Как долго живёт отравленная запись в кэше
✅ получают ли её другие пользователи
✅ Зависит ли импакт от региона или CDN-ноды
✅ Влияет ли баг на конфиденциальность, целостность или доступность
✅ Можно ли безопасно воспроизвести проблему без вреда для пользователей

Где искать баги, связанные с совместимостью JSON 🤔

JSON кажется простым форматом: ключ, значение, объект, массив. Но в реальных системах всё сложнее.

Один и тот же JSON может пройти через несколько сервисов:

API Gateway → бэкенд → платежный сервис → воркер

И каждый сервис может использовать свой парсер.

Проблема начинается, когда разные парсеры по-разному понимают один и тот же пэйлоад.

Например:

{
  "role": "user",
  "role": "admin"
}

Один парсер возьмёт первое значение.
Другой — последнее. Третий может вернуть ошибку или сохранить оба.

Для багхантера это интересный класс багов: JSON interoperability vulnerabilities.

Что стоит проверять:
1️⃣ Несогласованный приоритет дублирующих ключей
2️⃣ Конфликт ключей: усечение символов и комментарии
3️⃣ Особенности сериализации JSON
4️⃣ Представление чисел с плавающей запятой и целых чисел
5️⃣ Необязательный синтаксический анализ и другие ошибки

Почему это опасно ❓

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

Итог: приложение вроде валидирует JSON, но разные части системы видят разные данные.

🔗 Подробнее читай в ресёрче Bishop Fox
🔗 Решить лабу по теме

CSPT незаметно встроен практически во все основные фронтенд-фреймворки 🚨

@xssdoctor разобрал, как Client Side Path Traversal проявляется в React, Angular, Vue и других фронтенд фреймворках/библиотеках.

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

Что важно багхантеру:
➡️ Если traversal-пэйлоад уходит в клиентский fetch — возможен Client Side Path Traversal
➡️ Если он попадает в серверный контекст — возможен secondary context path traversal
➡️ Опасные шаблоны есть почти в каждом популярном фреймворке. Главное — знать особенности их дефолтных настроек

🔗 Полный разбор — в ресёрче CTBB Labs

Auth Bypass через Session Stuffing: что проверить багхантеру 🤔

Session Stuffing — баг, при котором одна функциональность приложения перезаписывает сессионные переменные, уже используемые для авторизованного пользователя.

Импакт может быть уровня P1: входишь под одним аккаунтом, дёргаешь другую фичу — и внезапно оказываешься в чужом профиле.

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

1️⃣ Логинишься под одним юзером

session.isLoggedIn = true
session.userName = "attacker"
session.userId = 123

2️⃣ В этой же сессии открываешь forgot password

Форма просит username, чтобы показать контрольный вопрос или отправить reset flow.

username = "victim"

3️⃣ Бэкенд временно пишет это значение в session

session.userName = "victim"

4️⃣ Пользователь возвращается в личный кабинет и обновляет страницу

Если приложение проверяет только:

session.isLoggedIn == true

А данные подтягивает по:

session.userName

то профиль может открыться уже для victim. Вот и весь auth bypass.

Что происходит 🤔

Разрабы могут использовать одну и ту же переменную сессии и для страницы восстановления пароля, и для логина, и не сделать принудительный выход из системы при использовании сброса пароля.

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

Поиск мисконфигов бакетов AWS S3: пошаговый гайд 🚀

Прежде чем сообщать о потенциальном мисконфиге в настройках безопасности, всегда проверяй импакт. Некоторые бакеты AWS S3 предназначены для публичного доступа.

Для тестирования S3-бакетов тебе потребуется активная учетка AWS и установленный клиент AWS CLI.

Чек-лист по мотивам гайда от Intigriti:

1️⃣ List permissions

aws s3 ls s3://{BUCKET_NAME} --no-sign-request

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

2️⃣ Read permissions

aws s3api get-object --bucket {BUCKET_NAME} --key filename ./OUTPUT --no-sign-request

3️⃣ Download permissions

aws s3 cp s3://{BUCKET_NAME}/filename ./ --no-sign-request

4️⃣ Write permissions

aws s3 cp filename s3://{BUCKET_NAME}/filename-{RANDOM} --no-sign-request

5️⃣ Чтение ACL

Для бакета:

aws s3api get-bucket-acl --bucket {BUCKET_NAME} --no-sign-request

Для конкретного объекта:

aws s3api get-object-acl --bucket {BUCKET_NAME} --key index.html --no-sign-request

Иногда сам бакет закрыт, но отдельные объекты доступны публично через ACL.

6️⃣ Ограничения на типы файлов

Если приложение позволяет загружать файлы напрямую в S3, проверь, можно ли загрузить «опасный» тип файла. Классический импакт: stored XSS через загруженный SVG/HTML.

7️⃣ Версионирование S3

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

aws s3api get-bucket-versioning --bucket {BUCKET_NAME} --no-sign-request

🔗 Пример ошибки, допущенной при интеграции AWS S3, за которую багхантер получил $20,000

Секрет долголетия раскрыт

Майские — самое время погрузиться в кроличью нору. И JWT — одна из тех тем, где глубина напрямую конвертируется в баги 💪

Мы уже разбирали атаки на JWT — вам зашло. Но это только верхушка айсберга.

У @rmrf_0 есть серия гайдов, которая закрывает тему: от разбора токена побайтово до постквантовой крипты. Врывайся ⤵️

1. Почему JWT сломан by design
2. Анатомия токена
3. alg:none - одна строчка и ты admin
4. Algorithm Confusion - публичный ключ как пароль
5. kid injection - SQLi через заголовок токена
6. jku/x5u/jwk/x5c - весь заголовок это attack surface
7. Брутфорс секретов на GPU - 150 млн HS256/сек
8. Psychic Signatures - нулевая подпись на Java 15-18
9. Криптография JWT для хакеров - ECDSA, RSA-PSS, EdDSA и где ломается математика
10. JWE — зашифрованные токены, Bleichenbacher, Invalid Curve, PBES2 DoS
11. JWT-библиотеки — рейтинг дырявости, Top 5 CVE, fingerprinting по токену
12. JWT в OAuth 2.0 и OIDC — token confusion, cross-service relay, ALBeast, DPoP bypass
13. XSS + JWT — кража токенов из localStorage, sessionStorage, cookies
14. Продвинутые криптоатаки — lattice, side-channels, fault injection
17. Hardcoded secrets - CVE-2025-20188 (CVSS 10.0), 17% JWT CVE за 2024-2026, где искать секреты
18. Что вместо JWT - PASETO, Macaroons, opaque tokens, server-side sessions
19. RFC 8725 - чеклист из 15 правил, который никто не читает
20. Постквантовый JWT - ML-DSA подписи по 2.4 KB, SD-JWT, Harvest Now Decrypt Later

Как правильно работать со скоупом в Burp Suite ⁉️

Скоуп помогает убрать лишний трафик от браузера и сервисов, которые не относятся к цели. Так проще смотреть только нужные запросы и не тонуть в шуме.

Есть два удобных подхода ⬇️

1️⃣ Через HTTP history и Site map

Изучи историю HTTP-запросов:

Proxy → HTTP history

Добавь в скоуп нужные хосты:

Target → Site map → Add to scope
или
Proxy → HTTP history → Add to scope

Включи фильтр:

Show only in-scope items

Так Burp будет показывать только то, что относится к цели.

2️⃣ Через регулярные выражения

В разделе Target → Scope включи эту фичу флажком

Use advanced scope control

Примеры:
🧡 Все поддомены: .*\.target\.com$
🧡 Только нужные поддомены: (api|web)\.target\.com$