Vulnérabilités des JWT : alg=none et confusion de clés

Les JWT sont signés cryptographiquement, mais de nombreuses bibliothèques présentaient de graves vulnérabilités. Les attaques les plus exploitées sont l’attaque alg=none, l’attaque de confusion RS256→HS256 et la force brute de secrets faibles. Elles résultent toutes de la confiance accordée à des champs d’en-tête contrôlés par l’attaquant.

La spécification JWT autorise alg:"none" pour les jetons non sécurisés. Des bibliothèques défectueuses l’acceptaient et ignoraient entièrement la vérification de signature. L’attaquant modifie la charge utile (par exemple, "role":"admin"), définit alg:"none", supprime la signature et le serveur accepte le jeton.

Original : eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJ1c2VyIn0.SIG Attaque : eyJhbGciOiJub25lIn0.eyJzdWIiOiJhZG1pbiJ9. (signature vide, point final). Un serveur vulnérable vérifie correctement le jeton et accorde l’accès administrateur.

N’acceptez jamais alg:"none" en production. Établissez explicitement une liste blanche des algorithmes autorisés : jwt.decode(token, key, algorithms=["HS256"]). La plupart des bibliothèques modernes (PyJWT 2+, jsonwebtoken 9+) rejettent alg=none par défaut.

Si un serveur utilise RS256 et qu’un client remplace alg par HS256, le serveur peut effectuer la vérification en utilisant sa clé publique RSA comme secret HMAC. Puisque la clé publique est… publique, l’attaquant signe des charges utiles arbitraires avec celle-ci et le serveur les vérifie.

Étapes : 1) Récupérez la clé publique auprès du point de terminaison JWKS. 2) Construisez une charge utile malveillante. 3) Signez-la avec HMAC-SHA256 en utilisant les octets PEM bruts de la clé publique comme secret HMAC. 4) Définissez alg:"HS256" dans l’en-tête. 5) Le chemin HS256 du serveur vérifie correctement le jeton.

Spécifiez toujours explicitement l’algorithme attendu dans l’appel de vérification. Ne déduisez jamais l’algorithme de l’en-tête du jeton. Utilisez des chemins de code distincts pour RS256 et HS256, de sorte que l’appelant ne puisse pas passer de l’un à l’autre.

HS256 avec des secrets faibles (moins de 256 bits d’entropie) peut être attaqué par force brute hors ligne. Des outils comme hashcat prennent en charge le cassage de JWT : hashcat -a 0 -m 16500 token.txt wordlist.txt. Utilisez des secrets aléatoires sur le plan cryptographique d’au moins 32 octets.

L’en-tête kid (identifiant de clé) sélectionne la clé à utiliser. Si le serveur utilise kid comme paramètre de requête SQL ou comme chemin de système de fichiers sans assainissement : kid="../../dev/null" → HMAC avec une clé vide → jeton falsifié accepté. Assainissez toujours kid.

L’en-tête jwk intègre une clé publique pour la vérification. Un serveur vulnérable pourrait utiliser directement la clé intégrée, ce qui permettrait à l’attaquant de fournir sa propre paire de clés, de signer le jeton avec la clé privée et d’intégrer la clé publique. Effectuez la vérification uniquement avec des clés enregistrées.

Certaines implémentations oubliaient de vérifier la revendication exp ou utilisaient l’heure du serveur de manière incohérente. Validez toujours explicitement exp, nbf et iat. Utilisez une bibliothèque qui vérifie ces éléments par défaut et ne désactivez jamais la validation des revendications en production.

Dans l’attaque de confusion de clés RS256→HS256, qu’utilise l’attaquant comme secret HMAC ?

Les vulnérabilités des JWT résultent de la confiance accordée à l’en-tête alg, de l’acceptation de alg=none et de secrets faibles. Correction : imposez les algorithmes au niveau du vérificateur, utilisez des secrets robustes et assainissez kid. Suite : pratiques d’implémentation sécurisée des JWT.