Peut-on coller un JWT dans un décodeur en ligne sans risque ?

Vous tombez sur un bug. Une requête échoue avec un code 403, et le seul indice est une longue chaîne qui commence par eyJ. Vous voulez voir ce qu’elle contient, alors vous cliquez sur le premier résultat Google : un décodeur JWT en ligne. Vous collez le token, vous lisez la charge utile, vous passez à autre chose.

Était-ce sans risque ? La réponse honnête dépend entièrement du fait que le token était actif ou non, et presque aucun décodeur ne vous le dit.

En bref : décoder un JWT est sans danger. Les données qu’il contient sont encodées, pas chiffrées, donc les lire ne révèle rien de nouveau. Le risque, c’est d’envoyer un token fonctionnel à un serveur que vous ne contrôlez pas, où il peut être enregistré puis rejoué. Ne collez jamais de tokens de production dans des sites qui ne vous appartiennent pas.

Ce qu’est réellement un JWT

Un JSON Web Token comporte trois parties reliées par des points : header.payload.signature. Les deux premières parties sont du JSON encodé en base64url. Le base64url n’est pas du chiffrement. C’est un format texte réversible, de la même famille d’encodage que celle utilisée pour glisser des données binaires dans une URL. N’importe quel ordinateur peut le reconvertir en JSON lisible en une milliseconde, sans clé et sans autorisation.

Donc, quand un décodeur vous affiche la charge utile, il n’a rien cassé. Il a exécuté une transformation publique et déterministe que votre navigateur peut faire tout seul. La charge utile est là, en clair, à l’intérieur de chaque requête qui transporte le token. L’encodage existe pour que les données voyagent sans encombre, pas pour les cacher.

Cette charge utile contient généralement des revendications de ce type :

{
  "sub": "user_8842",
  "email": "[email protected]",
  "role": "admin",
  "exp": 1717459200
}

Identifiant utilisateur, e-mail, rôle et un horodatage d’expiration. Parfois davantage : identifiants de locataire, portées de permissions, identifiants de session. Rien de tout cela n’est secret pour le détenteur du token, car le détenteur du token, c’est censé être vous. Le navigateur le stocke, l’envoie à chaque requête, et le serveur lit ces revendications exactes pour décider ce que vous avez le droit de faire.

La signature, c’est la partie qui compte

Le troisième segment est une signature cryptographique. Le serveur qui a émis le token l’a calculée à l’aide d’une clé secrète (ou d’une clé privée) que lui seul connaît. Quand un token revient, le serveur recalcule la signature et vérifie qu’elle correspond. Si vous modifiez un seul caractère de la charge utile, la signature ne valide plus, et le serveur rejette le token.

C’est le point que les gens comprennent à l’envers. Un décodeur ne vérifie pas la signature. Il se contente de découper la chaîne et de décoder en base64 les deux premières parties. Un décodeur vous affichera donc volontiers un token altéré, un token expiré, ou n’importe quoi qu’aucun serveur n’accepterait jamais. Voir du JSON d’apparence valide dans un décodeur ne vous dit rien sur le fait que le token fonctionne.

Et vous ne pouvez pas forger un token en modifiant la charge utile décodée. Faire passer votre role de user à admin puis ré-encoder produit un token à la signature cassée. Sans le secret du serveur, vous ne pouvez pas en produire une qui corresponde. C’est tout l’intérêt de la signature.

Voici le piège. Vous n’avez besoin de rien forger si vous pouvez voler un token déjà valide. Un token actif et correctement signé est un identifiant fonctionnel. Quiconque le détient peut agir en votre nom jusqu’à son expiration. La signature protège contre l’altération, pas contre le vol.

Alors, où est le vrai danger ?

Il n’est pas dans le décodage. Il est dans la transmission.

Quand vous collez un token dans un décodeur en ligne, vous faites confiance à l’outil pour le décoder localement, dans votre navigateur. Beaucoup ne le font pas. Bon nombre de ces sites envoient le token à leur backend, le décodent côté serveur et vous renvoient le résultat. De votre côté, c’est identique. La charge utile apparaît, vous êtes content. Pendant ce temps, l’opérateur du site vient de recevoir un identifiant parfaitement fonctionnel pour votre compte.

Ce qui se passe ensuite vous échappe :

• Le token peut être inscrit dans un journal serveur, parfois par accident, parfois délibérément.
• Il peut être rejoué contre la véritable API. S’il donne un accès administrateur, la copie aussi.
• Il reste utilisable jusqu’à ce que l’instant exp soit passé. Les tokens à durée de vie courte limitent les dégâts à quelques minutes. Les tokens à longue durée de vie offrent à un attaquant des heures ou des jours.
• Certains tokens n’expirent jamais. Certains sont des tokens de rafraîchissement, capables de générer à la demande de tout nouveaux tokens d’accès. Coller l’un d’eux dans le serveur d’un inconnu revient quasiment à lui remettre le compte de façon permanente.

Vous ne le saurez probablement jamais. Il n’existe aucune notification de fuite pour un identifiant que vous avez offert vous-même. Le décodage avait l’air normal, le bug a été corrigé, et une copie de votre session se trouve dans les journaux de quelqu’un d’autre.

Ce n’est pas de la paranoïa à propos d’un site malveillant en particulier. C’est la structure même de la situation. Vous ne pouvez pas savoir de l’extérieur si un décodeur donné est honnête, et la conséquence, s’il ne l’est pas, c’est le détournement de compte. Quand le coût de l’erreur est aussi élevé, la bonne posture par défaut est de supposer que le token a quitté votre machine.

Comment décoder sans le risque

Quelques habitudes rendent ce problème inexistant.

Utilisez un token sans importance. Si vous voulez seulement comprendre la structure des JWT ou vérifier quelles revendications votre fournisseur d’authentification définit, générez un token d’exemple. Il a l’air réel et se décode de la même manière, mais il ne correspond à aucun compte réel, donc peu importe qui le voit.

Utilisez un token expiré. Si vous déboguez la session d’un utilisateur précis, une copie expirée vous montre quand même les mêmes revendications et ne peut pas être rejouée pour obtenir un accès. Récupérez-en un dans les journaux d’hier plutôt que dans la requête en cours.

Ne collez jamais de tokens de production ou actifs dans un site que vous ne contrôlez pas. C’est la seule règle qui couvre tout. Si le token fonctionne actuellement contre un système réel, traitez-le comme un mot de passe, car concrètement, c’en est un.

Décodez-le vous-même quand vous le pouvez. Votre propre machine peut le faire sans aucun site web. En ligne de commande :

# split on dots, base64-decode the payload (second field)
echo "$JWT" | cut -d. -f2 | base64 -d 2>/dev/null

Cela ne touche jamais le réseau. Le token ne quitte pas votre ordinateur portable.

Comment vérifier qu’un décodeur s’exécute côté client

Si vous tenez à un outil de navigateur pour la commodité, assurez-vous qu’il garde bien le token en local avant de lui confier quoi que ce soit de sensible.

Le test hors ligne est la preuve la plus simple. Chargez la page, puis déconnectez-vous d’Internet (coupez le Wi-Fi ou débranchez le câble). Collez un token. S’il se décode quand même, le travail se fait dans votre navigateur, car il n’y a aucun serveur à joindre.

Le test de l’onglet Réseau est plus précis. Ouvrez les outils de développement de votre navigateur, allez dans l’onglet Réseau, videz-le, et collez un token dans l’outil. Surveillez la liste des requêtes. Un véritable décodeur côté client ne produit aucune nouvelle requête sortante transportant votre token. Si vous voyez une requête partir à l’instant où vous collez, c’est que le token va quelque part, et vous devez supposer que cet endroit le détient désormais.

L’un ou l’autre test prend moins d’une minute et tranche la question une fois pour toutes. Un outil qui réussit les deux est un outil dans lequel vous pouvez coller sans y réfléchir, car rien de ce que vous tapez ne traverse jamais le réseau.

Nous développons pour dev.hivly.net un décodeur JWT qui s’exécute entièrement dans le navigateur : les tokens sont décodés sur votre propre machine et ne sont jamais transmis nulle part. Il arrive bientôt. En attendant, les vérifications hors ligne et par l’onglet Réseau ci-dessus vous permettent d’évaluer n’importe quel décodeur que vous utilisez déjà.

La version courte : le décodage est inoffensif, les données ne sont pas secrètes, et vous ne pouvez pas forger un token en le modifiant. La seule chose qui peut vous nuire, c’est de remettre un identifiant actif et fonctionnel à un serveur que vous ne contrôlez pas. Gardez les tokens actifs sur des machines qui vous appartiennent, testez avec des tokens expirés ou d’exemple, et vérifiez que votre décodeur s’exécute en local. Faites cela et la question de savoir si c’est sans risque cesse tout simplement de se poser.