JWT Inspector

Anatomie d’un JWT

Un JSON Web Token (RFC 7519) transporte des affirmations, appelées claims, entre deux parties. Sous sa forme la plus répandue, la signature JWS compacte (RFC 7515), il se compose de trois segments séparés par des points : l’en-tête, la charge utile et la signature. L’en-tête indique l’algorithme (alg) et parfois la clé à utiliser (kid). La charge utile contient les claims : sujet, émetteur, audience, dates. La signature couvre les deux premiers segments et garantit qu’ils n’ont pas été modifiés.

Chaque segment est encodé en base64url : l’alphabet base64 où + et / deviennent - et _, sans caractère de remplissage =. Cet encodage ne protège rien. Toute personne qui intercepte le jeton lit son contenu, d’où l’intérêt de ne jamais y placer de mot de passe ou de donnée personnelle sensible.

Les attaques classiques

alg « none »

La spécification prévoit un jeton non signé, avec "alg": "none". Des bibliothèques ont longtemps accepté ces jetons dès lors que l’en-tête le demandait. Un attaquant modifiait alors la charge utile, retirait la signature, et le serveur l’acceptait.

Confusion d’algorithme RS256 vers HS256

Un serveur qui vérifie en RS256 détient une clé publique. Si la bibliothèque laisse l’en-tête choisir l’algorithme, l’attaquant signe un jeton en HS256 en prenant cette clé publique comme secret HMAC. Le serveur vérifie avec la même clé et valide le jeton forgé. La parade consiste à fixer l’algorithme attendu côté serveur.

Secrets faibles

Un jeton HS256 permet de tester des secrets hors ligne, sans limite de débit : il suffit d’un seul jeton valide. hashcat (mode 16500) ou jwt_tool trouvent en quelques secondes les secrets issus de tutoriels ou de fichiers d’exemple. Un secret HMAC doit être aléatoire et faire au moins 256 bits.

Injection par kid, jku et x5u

Le paramètre kid sert souvent à chercher une clé dans un fichier ou une base. Sans validation, il devient un vecteur de path traversal (../../dev/null pour obtenir une clé vide) ou d’injection SQL. Les paramètres jku et x5u désignent une URL où récupérer la clé : un serveur qui les suit sans liste blanche télécharge la clé de l’attaquant.

Absence d’expiration

Sans claim exp, un jeton volé dans un log, un historique de navigateur ou un dépôt Git reste valide indéfiniment. Comme un JWT se révoque mal, l’expiration courte est la principale protection.

Bonnes pratiques

• Fixez côté serveur la liste des algorithmes acceptés et refusez none.
• Vérifiez systématiquement exp, nbf, iss et aud.
• Utilisez un secret HMAC aléatoire d’au moins 256 bits, ou une paire de clés asymétriques quand plusieurs services vérifient les jetons.
• Ne placez dans la charge utile que des identifiants et des rôles, jamais de secret.
• Validez kid contre une liste fermée et ignorez jku, x5u et jwk si vous n’en avez pas besoin.