Что такое JWT токен и какие есть риски в нём
JWT (JSON Web Token) — это формат для передачи данных между клиентом и сервером. В jwt токене лежат данные клиента и способ их защиты с самой реализацией.
Какие бывают JWT токены
JWT обычно встречается в двух вариантах: JWS и JWE.
1. JWS - Это подписанный токен. Он нужен для того, чтобы сервер мог проверить: токен не подменили - Он состоит из 3 частей: BASE64URL(Protected Header) . BASE64URL(Payload) . BASE64URL(Signature) Header — какой алгоритм используется Payload — данные токена (claims) Signature — подпись
Важный момент: данные в JWS не скрыты. Их можно декодировать и прочитать. Подпись защищает токен от подделки, но не делает его “секретным”.
2. JWE - Это зашифрованный токен. Он нужен, когда данные внутри нужно именно скрыть - Он состоит из 5 частей: BASE64URL(Protected Header) . BASE64URL(Encrypted Key) . BASE64URL(IV) . BASE64URL(Ciphertext) . BASE64URL(Authentication Tag) Header — как шифровали Encrypted Key — чем защитили ключ шифрования IV — служебный nonce для шифрования Ciphertext — зашифрованные данные Tag — проверка целостности и подлинности шифрования
Где начинаются уязвимости
- Одна из самых известных ошибок это alg: none. В заголовке JWT указывается алгоритм подписи. Если сервер настроен неправильно и принимает токены с alg: none, то токен можно отправить вообще без подписи и это приводит к тому, что можно самому собрать токен и вписать себе роль администратора.
- Вторая частая проблема слепое доверие полю alg. Сервер берёт алгоритм из токена и верить ему. Если логика проверки построена на этом, то можно подменить алгоритм и обойти валидацию подписи.
- Ещё одна распространённая ошибка проверяют только подпись, но не проверяют содержимое. exp — не истёк ли токен nbf — можно ли уже использовать токен iss — кто его выпустил aud — для какого сервиса он предназначен
- Следующий риск слабый секретный ключ. Если используется, например, HS256, то подпись строится на общем секрете. Если этот секрет простой, короткий или его можно угадать, то можно начать создавать свои валидные токены.
- Отдельно стоит уязвимость про чувствительные данные в Payload. Разработчики иногда кладут в токен email, роли, ID пользователя, внутренние флаги. Если это JWS, то всё это не зашифровано и оно просто закодировано. Любой, кто получил токен, может его декодировать и посмотреть содержимое. Поэтому класть в обычный signed JWT секреты, внутренние технические детали или чувствительные данные не бест практик.
Главная мысль статьи: JWT сам по себе не является дырой. Дыра появляется в момент, когда его начинают воспринимать как “магическую безопасную штуку” и перестают нормально проверять.
Корректная реализация JWT токена это когда соблюдены все бест практик с ним, а именно: - жёстко зафиксирован допустимый алгоритм - проверяются exp, nbf, iss, aud - используется сильный ключ - в payload нет чувствительных данных - токен живёт ограниченное время - его хранение не позволяет легко украсть его через клиентскую часть
