Syntax Confusion: эксплуатация в дикой природе 🚨

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

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

Если на двух этапах ввод семантически «означает» разное, валидация, применённая на одном этапе, может перестать действовать на другом — и тогда от «санитизированного» ввода может остаться путь к эксплуатируемому поведению.

☝️ В языке программирования C определенные последовательности символов обрабатываются препроцессором и/или компилятором как один символ (digraphs и trigraphs). Python и Perl поддерживают экранирование Unicode-символов по именам символов.

Content-Disposition

Параметр filename заголовка Content-Disposition предлагает имена файлов для загружаемых или скачиваемых файлов:

HTTP/1.1 200 OK
Content-Type: application/pdf
Content-Disposition: attachment; filename="invoice.pdf"

POST /upload HTTP/1.1
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary

------WebKitFormBoundary
Content-Disposition: form-data; name="file"; filename="myfile.txt"
Content-Type: text/plain

Альтернативный синтаксис с * позволяет указать кодировку и использовать URL-кодирование:

Content-Disposition: form-data; name="file"; filename*=UTF8''myfile%0a.txt

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

file URI и обход фильтров

Схема file URI обычно указывает на локальные файлы (file:///path/to/file), но также допускает указание хоста: file://<host>/<path>. Используя схему URI файла с указанием хоста, можно обойти фильтры или получить DNS-запросы для отслеживания рабочего процесса в целевом приложении.

🔗 The Minefield Between Syntaxes: Exploiting Syntax Confusions in the Wild

Эксплуатация 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 и сравни ответы — иногда цепочка раскрывается сама 💡