🔐 JWT: надёжная защита или дыра в безопасности?
Как неконтролируемые токены превращаются в повышенные привилегии
📘 Что такое JWT?
JWT (JSON Web Token) - это компактный и самодостаточный формат передачи информации между сторонами в виде JSON-объекта. Он состоит из трёх частей:
1⃣ Header — заголовок, где указывается алгоритм подписи (например, HS256 или RS256);
2⃣ Payload — полезная нагрузка: ID пользователя, роль, логин и пр.;
3⃣ Signature — цифровая подпись, подтверждающая целостность и подлинность токена.
JWT широко используется в системах аутентификации и авторизации, но при неправильной реализации может стать уязвимостью — вплоть до полного компрометирования прав доступа.
💥 Уязвимость alg: none: отсутствие подписи
Если сервер не проверяет алгоритм, указанный в заголовке токена, злоумышленник может заменить значение alg на "none", удалить подпись и изменить payload, например:
"role": "admin"
Сервер может принять такой токен как действительный — и предоставить доступ к закрытым функциям, считая пользователя администратором.
Это одна из самых известных, но всё ещё встречающихся уязвимостей, особенно в нестандартных или устаревших библиотеках.
🔁 Подмена алгоритма: RS256 → HS256
Интересный кейс с «путаницей алгоритмов».
Предположим:
Сервер ожидает токен, подписанный с помощью асимметричного RS256;
Злоумышленник меняет alg на HS256 и использует публичный ключ как секретный HMAC-ключ;
Затем он подписывает поддельный токен и отправляет его.
Если сервер не проверяет алгоритм строго, то он принимает токен как действительный.
🔓 Слабые ключи и брутфорс
Если секрет, используемый для подписи токенов (HS256), недостаточно надёжен, его можно подобрать:
➖с помощью словарных атак (например, через jwt2john + John the Ripper);
➖через брутфорс (crackjwt.py, Hashcat и др.).
🧪 Распространённые ошибки при работе с JWT
🤦♂ Использование decode() без verify() — токен расшифровывается, но подпись не проверяется;
🙈 Отсутствие проверки exp, iss, aud, nbf, jti — позволяет повторно использовать устаревшие или "чужие" токены;
🤷♂ Передача токена в URL вместо HTTP-заголовка — приводит к утечкам через логи, историю браузера, рефереры;
⏳ Слишком долгий срок действия токенов — особенно без возможности отзыва;
✍ Логирование JWT в лог-файлы сервера — прямой путь к компрометации.
✅ Меры предосторожности
➖Не доверяйте значению alg из заголовка — задавайте допустимый алгоритм жёстко в конфигурации сервера.
➖Отключите поддержку алгоритма none — даже если он доступен в библиотеке.
➖Предпочитайте асимметричную криптографию (RS256) вместо симметричной (HS256) — это исключает некоторые виды атак.
➖Используйте длинные и криптоустойчивые секреты — не менее 256 бит.
➖Проверяйте все критически важные поля в payload — exp (время истечения), nbf (не раньше), iss (issuer), aud (аудитория), jti (идентификатор токена).
➖Передавайте токены в заголовках (Authorization: Bearer), а не в URL.
➖Не логируйте JWT в логи, особенно при ошибках или 5xx-ответах.
➖Ограничьте срок действия токенов и внедрите механизм их отзыва (например, с помощью blacklist или короткого TTL и refresh-токенов).
➖Аудируйте кодовую базу и зависимости — некоторые библиотеки могут игнорировать верификацию по умолчанию.
🧩 Вывод
JWT создавался как безопасный и самодостаточный формат. Но при ошибочной конфигурации или недостатке контроля он превращается в настоящий эксплойт, особенно в условиях, где разработчики не до конца понимают логику работы алгоритмов и доверяют библиотеке "по умолчанию".
Stay secure and read SecureTechTalks 📚
#JWT #веббезопасность #уязвимости #хакеры #инфобез #RS256 #HS256 #noneattack #pentest #SecureTechTalks
