Falsifier le tier : escalade de privilèges via une revendication JWT non vérifiée
Le défi
Cette plateforme d'IA choisit le modèle que vous pouvez appeler à partir de la revendication tier de votre JWT. Vous êtes sur le niveau gratuit, mais le backend fait confiance à cette revendication sans jamais vérifier la signature du jeton. Dans l'atelier, modifiez la charge utile pour que tier devienne enterprise. Le jeton se reconstruit en direct. Copiez tout le jeton forgé et soumettez-le.
Ce que tu vas apprendre
- Comprendre que les revendications tier et plan ne restreignent l'accès aux fonctionnalités que si le jeton est vérifié
- Modifier une revendication de la charge utile et observer le jeton se ré-encoder en temps réel
- Falsifier un jeton avec des droits élevés en définissant tier sur enterprise
- Identifier la confiance accordée aux revendications côté client comme une faille de facturation et d'autorisation
- Savoir que les droits doivent être vérifiés côté serveur, et non lus depuis un jeton côté client
Compétences testées
Prérequis
- Un JWT est composé de trois parties encodées en base64url : en-tête, charge utile, signature
- Les revendications de droits comme tier et plan se trouvent dans la charge utile
- Notions de base en édition JSON
Comment ça marche
De nombreux produits associent un niveau de facturation à des fonctionnalités : ils lisent la revendication tier du jeton de l'utilisateur pour décider quel modèle, quelle limite de débit ou quelle capacité accorder. Cela n'est sûr que lorsque la signature du jeton a été vérifiée, car la signature est la seule chose qui prouve que la revendication a été émise par le serveur et non modifiée par son détenteur. Ce backend saute la vérification, la preuve fait donc défaut.
Sans vérification de signature, le JWT n'est qu'une liste de revendications encodée en base64url que vous pouvez réécrire à volonté. Le contrôle d'accès repose sur tier, vous changez donc "tier":"free" en "tier":"enterprise". L'atelier ré-encode la charge utile et reconstruit le jeton ; la signature d'origine est conservée telle quelle et devient désormais mathématiquement fausse, mais comme le serveur ne la vérifie jamais, le jeton falsifié est accepté et le modèle enterprise se débloque.
Le problème de fond est de faire confiance à une valeur détenue par le client pour une décision d'autorisation ou de facturation. Même un jeton parfaitement signé peut diverger de l'état réel du compte, c'est pourquoi les droits sensibles sont mieux vérifiés à partir des enregistrements côté serveur.
Erreurs fréquentes
- Se contenter de décoder le jeton. Lire
tierne prouve rien : le bug, c'est que vous pouvez le modifier tout en restant fiable aux yeux du serveur. - Modifier le mauvais champ. Le contrôle lit
tier; définissez-le surenterprise, pas surmodelouuser. - Essayer de corriger la signature. Vous n'avez pas besoin d'une signature valide ici ; le serveur ne la vérifie jamais.
- Soumettre le JSON décodé. Soumettez le jeton reconstruit (ou son segment de charge utile), pas les revendications lisibles.
Comment s'en protéger
Vérifiez la signature avant de lire toute revendication, et traitez les droits comme un état côté serveur plutôt que comme une valeur fournie par le client.
- Vérifiez la signature du JWT avec l'algorithme et la clé attendus à chaque requête ; rejetez
alg:none. - Confirmez tier et plan par rapport à un enregistrement faisant autorité côté serveur (le système de facturation), pas seulement la revendication du jeton.
- Gardez des jetons à durée de vie courte afin qu'un droit périmé ou falsifié ne puisse pas persister.
- Enregistrez et alertez sur les jetons dont le tier revendiqué ne correspond pas au compte, ce qui révèle les tentatives de falsification.