Second-Order (Stored) IDOR: заметки для багхантера 💡

Обычный IDOR срабатывает сразу: ты меняешь условный user_id=1 на user_id=2 в запросе — и сервер мгновенно отдаёт данные второго юзера. Second-order IDOR работает иначе — с «задержкой».

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

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

➡️ В момент инъекции всё выглядит легитимно
➡️ Эксплуатация происходит совсем в другом контексте

Атака — это всегда два шага:

1⃣ Seed (сохранение): инжектишь ID жертвы в безобидное поле: профиль, настройки, связанный ресурс. Сервер проверяет сессию и спокойно сохраняет данные.

2⃣ Trigger (исполнение): позже происходит асинхронное действие. Система берёт сохранённый ID из базы, слепо ему доверяет и выполняет операцию.

Почему такие баги часто дают высокий импакт:

⚫️ Сканеры почти не находят такие баги — здесь нужно понимать состояние приложения, бизнес-логику и отложенное выполнение
⚫️ Разработчики часто защищают только публичные API
⚫️ Внутренние джобы (генерация PDF, отправка писем и т.д.) считаются «безопасными»
⚫️ Проверки прав доступа на втором этапе просто отсутствуют

Где искать ⏳

Ищи функционал приложения с асинхронной обработкой:

⚫️ Экспорты и отчёты: меняй ID аккаунта → запрашивай CSV/PDF → через время получай данные жертвы
⚫️ Webhooks и интеграции: подменяй ID workspace → при синхронизации (Slack, Jira) получай чужие данные
⚫️ Автоматические саппорт-боты: вставляй ID заказа жертвы → бот подтягивает детали из базы и показывает чужие данные

Что нужно ❓

1⃣ Две учетки: атакующий (User A) и жертва (User B)

2⃣ Терпение: ввел данные → подождал выполнение задачи → проверил результат (почта, webhook и т.д.) → повторил

В Chrome при нажатии на значок очистки (иконка ❌ для быстрой очистки поля) в <input type="search"> запускаются события onsearch и oninput 🔍

Если стилизовать элемент так, чтобы эта иконка покрывала нужную целевую область, на выходе получишь надёжный 1-click вектор эксплуатации XSS ⤵️

<h1>Click here</h1>

<input type=search value=x onsearch=alert('onsearch') oninput=alert('oninput') style=position:fixed;left:50%;top:50%;padding:0;width:10px;z-index:99;transform:scale(9999);opacity:0>

Broken Access Control: с чего начинать охоту 🔓

BAC — это зачастую не про сложные эксплойты. Это про логику и внимательность. Разберемся, с чего вообще начинать ⬇️

1️⃣ Разведка модели авторизации

Прежде чем кидаться менять ID в запросах — разберись, как работает авторизация на таргете. RBAC? Мультитенант? Обычная модель «юзер-админ»?

Это определяет стратегию тестирования.

2️⃣ Тестовые аккаунты

Минимум — два обычных аккаунта (User A и User B). Если RBAC — по аккаунту на каждую роль. Мультитенант? Регистрируй аккаунты в разных организациях/тенантах.

3️⃣ Маппинг

Прогоняй приложение через Burp/Caido под каждым аккаунтом. Лови каждый эндпоинт и роут. Выделяй контролируемые параметры: userId, orderId, accountId, UUID и т. д.

4️⃣ Атака

Берешь токен/куки User B и пробуешь дёрнуть ресурсы User A. Чекни админские эндпоинты из-под обычного юзера.

Не забывай про менее очевидные места — массовые операции, экспорт данных, вебхуки, GraphQL-запросы с вложенными объектами. Там часто забывают про проверки 🤔

P. S. Autorize — расширение для Burp, которое автоматизирует поиск BAC:

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

Материалы и лабы по теме:
🧡 Access control vulnerabilities and privilege escalation
🧡 Testing access controls with Burp Suite
🧡 Начинаем в багбаунти: доступно об уязвимостях типа Broken Access Control

Почему wildcard DNS ломает разведку поддоменов 🚨

Если ты собираешь поддомены и видишь тысячи хостов — есть шанс, что это не находка, а wildcard DNS.

Wildcard DNS (*.example.com) отвечает на любой запрос к несуществующему поддомену.

Собрали краткую методологию, чтобы не тратить время впустую:

генерация → DNS → проверка wildcard → HTTP → кластеризация → анализ «выбросов»

1️⃣ Генерация + DNS-резолв

Не ограничивайся стандартными словарями. Используй мутации (dev → dev-api, api-v2 и т.д.), OSINT (старые DNS-записи, сертификаты, архивы), брутфорс по шаблонам.

Цель — получить максимум кандидатов.

✔️ Проверяй случайные домены → выявляй wildcard
✔️ Фиксируй IP / CNAME / повторяющиеся ответы

2️⃣ Первичная фильтрация

Часть шума можно убрать на уровне DNS: одинаковые IP, одинаковые CNAME.

Но этого недостаточно: реальные хосты могут делить IP с wildcard, CDN усложняют анализ.

При сомнениях переходи к анализу HTTP-ответов.

3️⃣ Анализ HTTP-ответов

Для резолвящихся хостов собери:
🔵 статус-код
🔵 тело ответа
🔵 заголовки
🔵 размер
🔵 title

4️⃣ Кластеризация результатов и анализ «выбросов»

Сгруппируй результаты по:
🔵 IP / CNAME
🔵 IP + статус
🔵 хешу тела
🔵 структуре ответа
🔵 title
🔵 fingerprint (IP + статус + размер + title)

Дальше:
🔵 массовые одинаковые ответы → игнор
🔵 редкие/уникальные → приоритет

Именно «выбросы» чаще всего ведут к реальным сервисам и точкам входа.

Майские — самое время погрузиться в кроличью нору. И 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

Поиск мисконфигов бакетов 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

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.