Lire la revendication JWT : décoder un jeton extrait du stockage d'une application
Le défi
Vous avez extrait ce jeton du stockage local d'une application mobile. Cela ressemble à du charabia aléatoire, mais la charge utile d'un JWT n'est pas chiffrée - c'est juste du base64, que n'importe qui peut décoder. Dans l'atelier, la charge utile est présentée pour vous. Lisez-la et soumettez l'adresse e-mail qu'elle contient.
Ce que tu vas apprendre
- Comprendre qu'une charge utile JWT est encodée en base64, et non chiffrée
- Décoder une charge utile JWT pour lire ses revendications sans clé ni cassage
- Identifier et extraire la revendication email d'un jeton
- Expliquer pourquoi les secrets et les données personnelles ne doivent jamais être stockés dans une charge utile JWT
- Reconnaître que les jetons stockés côté client sont lisibles par quiconque y a accès
Compétences testées
Prérequis
- Un JWT est composé de trois parties en base64url séparées par des points
- Le base64 est un encodage réversible, pas un chiffrement
Comment ça marche
Un JSON Web Token est composé de trois segments en base64url réunis par des points : l'en-tête, la charge utile et la signature. Fait essentiel, la charge utile est encodée, pas chiffrée. Le base64 est une représentation réversible conçue pour transporter des données binaires sous forme de texte en toute sécurité ; l'inverser ne nécessite ni clé ni effort. Le segment du milieu, d'apparence aléatoire, est donc entièrement lisible par quiconque détient le jeton.
Décodez la charge utile ici et vous obtenez {"sub":"9f2","email":"[email protected]","plan":"pro"}. L'e-mail et le plan n'ont jamais été cachés, ils étaient simplement encodés. La signature à la fin protège l'intégrité (elle empêche que les revendications soient modifiées sans que cela se remarque), mais n'offre aucune confidentialité.
Cela compte surtout côté client. Un jeton présent dans le stockage local d'une application mobile, dans un navigateur, ou capturé sur le réseau peut être décodé par quiconque y accède. Considérez chaque revendication d'un JWT comme publique. Si vous devez transporter un véritable secret, chiffrez-le séparément ou gardez-le côté serveur : ne présumez jamais que le JWT lui-même cache quoi que ce soit.
Erreurs fréquentes
- Penser que le jeton est chiffré. C'est du base64, pas du texte chiffré : aucune clé n'entre en jeu, inutile d'essayer de le casser.
- Essayer de casser la signature par brute force. La signature n'est pas du tout nécessaire pour lire les revendications ; la charge utile se décode d'elle-même.
- Lire la mauvaise revendication. La réponse est la valeur de
email, pas l'identifiantsubni leplan. - Reformater la réponse. Soumettez l'e-mail exactement tel qu'il apparaît :
[email protected].
Comment s'en protéger
Comme chaque revendication d'un JWT est lisible, concevez vos jetons pour qu'ils ne transportent que des données non sensibles et protégez les secrets ailleurs.
- Ne mettez jamais de mots de passe, de clés d'API, de données personnelles complètes ou de secrets de session dans une charge utile JWT.
- Ne transportez que le minimum nécessaire pour l'autorisation (un identifiant utilisateur opaque, des scopes) et récupérez le reste côté serveur.
- Si une charge utile doit vraiment rester confidentielle, utilisez un jeton chiffré (JWE), pas un simple JWT signé.
- Stockez les jetons avec soin côté client et gardez-les de courte durée de vie, afin qu'un jeton dérobé ait une valeur limitée.