Эксплуатация 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

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

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

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

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

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

От простой 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 💡

Max-Forwards HTTP header ⏳

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

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

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

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

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

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

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

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 парами. Все, что ты получаешь при попытке их отобразить, — это символ замены Юникода.

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

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

Активная 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, часто можно получить все домены в зоне и сразу получить качественные точки старта для перечисления.

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