Falsifier le jeton : forger un JWT quand la signature n'est pas vérifiée
Le défi
Ce tableau de bord décide de ce que vous pouvez voir à partir de la revendication role dans votre JWT - et il ne vérifie jamais la signature, donc la revendication est à vous de modifier. Dans l'atelier, modifiez la charge utile pour que role devienne admin. Le jeton se reconstruit en direct. Copiez tout le jeton forgé (les trois parties, avec les points) et soumettez-le.
Ce que tu vas apprendre
- Comprendre qu'une signature JWT ne protège les revendications que si le serveur la vérifie
- Modifier une revendication de la charge utile et observer le jeton se ré-encoder en temps réel
- Forger un jeton avec élévation de privilèges en changeant la revendication role en admin
- Reconnaître les failles de vérification de signature (contrôles ignorés, alg:none) comme des failles d'authentification critiques
Compétences testées
Prérequis
- Savoir que les JWT transportent des revendications comme role et user id
- Notions de base d'édition JSON
Comment ça marche
Un JSON Web Token se divise en trois parties encodées en base64url : l'en-tête, la charge utile et la signature. La signature est la seule chose qui rend la charge utile fiable - c'est un hash à clé calculé sur l'en-tête et la charge utile, donc si quelqu'un modifie une revendication, la signature ne correspond plus et un serveur correct rejette le jeton. Retirez cette vérification et le JWT redevient ce qu'il est physiquement : une simple liste de revendications modifiable, avec une chaîne inutile agrafée à la fin.
C'est la faille ici. Le tableau de bord lit role directement dans la charge utile pour décider de l'accès, mais il ne vérifie jamais la signature (un bug réel courant, au même titre que l'acceptation de alg:none). Vous pouvez donc simplement réécrire la revendication. Dans l'atelier, vous décodez la charge utile, changez "role":"guest" en "role":"admin", et l'outil ré-encode la charge utile et reconstruit le jeton en direct. La signature d'origine, désormais mathématiquement fausse, est conservée telle quelle, et comme le serveur ne la vérifie pas, votre jeton forgé vous authentifie comme administrateur.
L'objectif de l'exercice est l'acte de forger, pas de lire. Décoder seul ne vous apprend rien qu'un jeton honnête ne révélerait pas déjà ; la vulnérabilité n'apparaît que lorsque vous modifiez une revendication et que le serveur continue à lui faire confiance.
Erreurs fréquentes
- Se contenter de lire la charge utile. Décoder est gratuit et ne prouve rien - le bug, c'est que vous pouvez modifier une revendication et rester malgré tout digne de confiance.
- Modifier le mauvais champ. La décision d'accès repose sur la revendication
role; changez sa valeur enadmin, pas l'utilisateur ni le sub. - Soumettre le JSON décodé. La réponse attendue est le jeton reconstruit et ré-encodé (ou son segment de charge utile), pas les revendications lisibles que vous avez tapées.
- Essayer de corriger la signature. Vous n'avez pas besoin d'une signature valide ici - tout l'intérêt est que le serveur ne la vérifie jamais.
Comment s'en protéger
La correction n'est pas négociable : vérifiez toujours la signature avec l'algorithme et la clé attendus avant de faire confiance à la moindre revendication, et rejetez purement et simplement alg:none. Ne prenez jamais de décision d'autorisation sur un jeton non vérifié.
- Vérifiez la signature du JWT à chaque requête, en figeant l'algorithme côté serveur (pas de
none, pas d'alg choisi par le client). - Basez l'autorisation uniquement sur des revendications vérifiées, et privilégiez des jetons de courte durée.
- Envisagez des sessions côté serveur ou la révocation de jetons pour les rôles sensibles, afin qu'un seul jeton forgé ou volé ne soit pas fatal.
