Уязвимости JWT: alg=none и путаница ключей

JWT подписываются криптографически, но во многих библиотеках обнаруживались серьёзные уязвимости. Наиболее часто эксплуатируются атака alg=none, атака со смешением RS256→HS256 и перебор слабых секретов. Все они возникают из-за доверия к полям заголовка, контролируемым злоумышленником.

Спецификация JWT допускает alg:"none" для незащищённых токенов. Уязвимые библиотеки принимали такие токены и полностью пропускали проверку подписи. Злоумышленник изменяет полезную нагрузку (например, "role":"admin"), устанавливает alg:"none", удаляет подпись — и сервер принимает токен.

Исходный токен: eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJ1c2VyIn0.SIG Атака: eyJhbGciOiJub25lIn0.eyJzdWIiOiJhZG1pbiJ9. (пустая подпись, точка в конце). Уязвимый сервер успешно выполняет проверку и предоставляет доступ администратора.

Никогда не принимайте alg:"none" в рабочей среде. Явно задавайте список разрешённых алгоритмов: jwt.decode(token, key, algorithms=["HS256"]). Большинство современных библиотек (PyJWT 2+, jsonwebtoken 9+) по умолчанию отклоняют alg=none.

Если сервер использует RS256, а клиент меняет alg на HS256, сервер может выполнить проверку, используя открытый ключ RSA как секрет HMAC. Поскольку открытый ключ... открыт, злоумышленник подписывает им произвольные полезные нагрузки, и сервер принимает их.

Шаги: 1) Получите открытый ключ из конечной точки JWKS. 2) Создайте вредоносную полезную нагрузку. 3) Подпишите её с помощью HMAC-SHA256, используя необработанные байты открытого ключа PEM как секрет HMAC. 4) Установите alg:"HS256" в заголовке. 5) Сервер успешно выполняет проверку по пути HS256.

Всегда явно указывайте ожидаемый алгоритм в вызове проверки. Никогда не определяйте алгоритм на основе заголовка токена. Используйте отдельные пути выполнения для RS256 и HS256, которые вызывающая сторона не может переключить.

Секреты HS256 со слабой энтропией (менее 256 бит) можно подобрать офлайн. Инструменты вроде hashcat поддерживают взлом JWT: hashcat -a 0 -m 16500 token.txt wordlist.txt. Используйте криптографически случайные секреты длиной не менее 32 байт.

Заголовок kid (ID ключа) выбирает ключ, который нужно использовать. Если сервер использует kid как параметр SQL-запроса или путь к файловой системе без очистки: kid="../../dev/null" → HMAC с пустым ключом → подделанный токен принимается. Всегда очищайте kid.

Заголовок jwk содержит открытый ключ для проверки. Уязвимый сервер может напрямую использовать встроенный ключ, позволяя злоумышленнику предоставить собственную пару ключей, подписать токен закрытым ключом и встроить открытый ключ. Выполняйте проверку только по зарегистрированным ключам.

Некоторые реализации забывали проверять утверждение exp или непоследовательно использовали время сервера. Всегда явно проверяйте exp, nbf и iat. Используйте библиотеку, которая проверяет их по умолчанию, и никогда не отключайте проверку утверждений в рабочей среде.

Уязвимости JWT возникают из-за доверия к заголовку alg, принятия alg=none и слабых секретов. Исправление: фиксируйте алгоритмы на стороне проверяющей системы, используйте надёжные секреты и очищайте kid. Далее: безопасные методы реализации JWT.