По своей структуре 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