Уязвимости JWT
Что такое Уязвимости JWT?
Уязвимости JWTКлассы ошибок в реализации проверки JSON Web Token, позволяющие подделывать токены, повышать привилегии или обходить аутентификацию.
JSON Web Token широко применяются для аутентификации и авторизации API, однако гибкость подписи породила ряд повторяющихся классов уязвимостей. Классический баг alg=none возникает, когда верификатор принимает неподписанный токен. Слабые секреты HS256 поддаются офлайн-перебору и позволяют выпускать любые токены. Путаница ключей (key confusion) случается, когда сервер проверяет HS256-токен, используя публичный RSA-ключ как HMAC-секрет. Другие проблемы: отсутствие проверки подписи, приём просроченных токенов, инъекции в kid (path traversal, SQLi) и атаки через jwk/jku. Меры защиты: жёстко фиксировать алгоритм на сервере, использовать стойкие асимметричные ключи, валидировать kid по списку разрешений и считать JWT недоверенным вводом.
● Примеры
- 01
Заголовок {"alg":"none"} принимается неправильно настроенной библиотекой.
- 02
Сервер проверяет RS256-токен, используя свой публичный ключ как HMAC-секрет HS256.
● Частые вопросы
Что такое Уязвимости JWT?
Классы ошибок в реализации проверки JSON Web Token, позволяющие подделывать токены, повышать привилегии или обходить аутентификацию. Относится к категории Безопасность приложений в кибербезопасности.
Что означает Уязвимости JWT?
Классы ошибок в реализации проверки JSON Web Token, позволяющие подделывать токены, повышать привилегии или обходить аутентификацию.
Как работает Уязвимости JWT?
JSON Web Token широко применяются для аутентификации и авторизации API, однако гибкость подписи породила ряд повторяющихся классов уязвимостей. Классический баг alg=none возникает, когда верификатор принимает неподписанный токен. Слабые секреты HS256 поддаются офлайн-перебору и позволяют выпускать любые токены. Путаница ключей (key confusion) случается, когда сервер проверяет HS256-токен, используя публичный RSA-ключ как HMAC-секрет. Другие проблемы: отсутствие проверки подписи, приём просроченных токенов, инъекции в kid (path traversal, SQLi) и атаки через jwk/jku. Меры защиты: жёстко фиксировать алгоритм на сервере, использовать стойкие асимметричные ключи, валидировать kid по списку разрешений и считать JWT недоверенным вводом.
Как защититься от Уязвимости JWT?
Защита от Уязвимости JWT обычно сочетает технические меры и операционные практики, как описано в определении выше.
● Связанные термины
- identity-access№ 574
JWT (JSON Web Token)
Компактный URL-безопасный формат токена (RFC 7519) с подписанными JSON-утверждениями; используется как access token, ID token и контейнер сессии.
- identity-access№ 088
Bearer-токен
Непрозрачный или структурированный мандат (RFC 6750), дающий доступ к ресурсу самим фактом владения, без подтверждения, что обладатель — законный владелец.
- identity-access№ 007
Access-токен
Короткоживущая учётка, выдаваемая сервером авторизации; клиент предъявляет её API, чтобы получить доступ к защищённым ресурсам от имени пользователя или сервиса.
- appsec№ 052
Безопасность API
Дисциплина проектирования, разработки и эксплуатации API так, чтобы аутентификация, авторизация, выдача данных и устойчивость к злоупотреблениям выдерживали атаки.
- identity-access№ 076
Аутентификация
Процесс проверки того, что субъект — пользователь, устройство или сервис — действительно является тем, за кого себя выдаёт, перед предоставлением доступа.
- compliance№ 781
OWASP Top 10
Информационный документ OWASP, перечисляющий наиболее критические риски безопасности веб-приложений и обновляемый по реальным данным о уязвимостях.