L'algorithme none : forger un JWT qu'un serveur accepte sans signature
Le défi
Cette API vous authentifie à partir des revendications de votre JWT. L'en-tête indique alg:HS256, mais le serveur a une faille classique : il accepte aussi un jeton dont l'en-tête indique alg:none, le considérant comme déjà valide sans signature à vérifier. Dans l'atelier, passez l'algorithme de l'en-tête à none et réécrivez la charge utile pour que role devienne admin. Le jeton se reconstruit en direct. Copiez tout le jeton forgé et soumettez-le.
Ce que tu vas apprendre
- Comprendre ce que contrôle le champ alg de l'en-tête JWT
- Expliquer pourquoi honorer alg:none désactive la vérification de la signature
- Forger un token admin en passant l'algorithme à none et en modifiant la charge utile
- Identifier l'acceptation de alg:none comme un contournement d'authentification critique
- Savoir qu'un serveur doit fixer l'algorithme attendu plutôt que de faire confiance à l'en-tête du token
Compétences testées
Prérequis
- Un JWT est composé de trois parties encodées en base64url : en-tête, charge utile, signature
- Des revendications comme role et user se trouvent dans la charge utile
- Notions de base d'édition JSON
Comment ça marche
Un JSON Web Token porte un nom d'algorithme dans son en-tête, par exemple {"alg":"HS256","typ":"JWT"}. L'intention est que le serveur lise alg, puis vérifie la signature avec cet algorithme et une clé secrète. L'erreur fatale que commettent certaines implémentations est de faire confiance à l'en-tête contrôlé par l'attaquant pour choisir l'algorithme. Si l'en-tête indique alg:none et que la bibliothèque l'honore, le serveur traite le token comme légitimement non signé et n'effectue aucune vérification.
Cela transforme le JWT en une simple liste de revendications modifiable. Comme rien ne contrôle la signature, vous pouvez réécrire n'importe quelle revendication. Ici, la décision d'accès repose sur la revendication role, donc vous passez l'en-tête à {"alg":"none","typ":"JWT"} et changez "role":"user" en "role":"admin". L'atelier ré-encode les deux segments et reconstruit le token. Le troisième segment (la signature) n'a plus d'importance ; un token alg:none est généralement envoyé avec une signature vide, ce qui explique qu'un point final suivi de rien soit aussi accepté.
Toute cette classe de faille existe parce que l'algorithme devrait être une décision côté serveur, jamais quelque chose que l'appelant peut rétrograder. Fixez-le.
Erreurs fréquentes
- Modifier uniquement la charge utile. Si vous laissez l'en-tête à HS256, la signature originale devient invalide : cette attaque nécessite de passer l'en-tête à
nonepour que le serveur saute la vérification. - Essayer de calculer une vraie signature. L'intérêt de
alg:noneest justement de ne pas en avoir besoin ; ne perdez pas de temps à forger un HMAC valide. - Modifier la mauvaise revendication. L'accès ici est décidé par
role; réglez-le suradmin, pas suruserousub. - Soumettre le JSON décodé. Soumettez le token reconstruit et ré-encodé (ou son segment de charge utile admin), pas les revendications lisibles.
Comment s'en protéger
Ne laissez jamais l'en-tête du token décider lui-même s'il faut le vérifier ni comment. Le serveur doit choisir l'algorithme et rejeter tout ce qui désactive la vérification.
- Fixez l'algorithme attendu côté serveur et rejetez d'emblée
alg:none(et tout alg inattendu) avant de traiter les revendications. - Utilisez une version vérifiée de la bibliothèque et passez explicitement l'algorithme à l'appel de vérification ; ne comptez jamais sur le comportement par défaut de la bibliothèque qui lit alg dans le token.
- Ne dérivez l'autorisation qu'à partir des revendications d'un token dont la signature a été vérifiée avec la bonne clé.
- Préférez des tokens de courte durée de vie et, pour les rôles sensibles, des vérifications de session côté serveur, afin qu'un seul token forgé ne compromette pas tout.