Les jetons web JSON (JWT) sont devenus la méthode d'authentification préférée de nombreuses organisations. Ils sont faciles à mettre en œuvre, ce qui en fait un choix populaire pour sécuriser les API et les applications web. Toutefois, s'ils ne sont pas correctement gérés, les JWT peuvent présenter des failles de sécurité et mettre vos systèmes en danger. Vous les avez probablement utilisés vous-même.
Mais les avez-vous mis en œuvre et traités de manière sûre ?
Un billet de blog d'Akamai a mis en évidence plusieurs vulnérabilités de sécurité courantes associées aux JWT. Il s'agissait d'un signal d'alarme sur les risques potentiels d'une mauvaise gestion des JWT. Dans ce billet de blog, je souhaite poursuivre sur cette lancée en me concentrant sur une vulnérabilité supplémentaire souvent négligée : les JWT qui n'expirent pas. Nous verrons comment ce problème se pose et quelles sont les failles de sécurité qui y sont associées. Je vous donnerai ensuite quelques conseils pour que vous sachiez comment vous protéger de ces failles de sécurité.
Vue d'ensemble des vulnérabilités courantes des JWT
Avant d'entrer dans le vif du sujet, examinons brièvement les vulnérabilités des JWT mises en évidence dans l'article de blog mentionné ci-dessus. Les six menaces pour les JWT mentionnées par l'auteur sont les suivantes :
- Permettre au serveur d'utiliser un jeton sans validation: Cela peut se produire lorsque le serveur ne vérifie pas l'intégrité du jeton, ce qui permet aux attaquants de le manipuler et de l'exploiter plus facilement. Les attaquants peuvent également définir l'algorithme de vérification (alg) comme étant nul, afin de tenter de manipuler le serveur pour qu'il ne valide pas du tout le jeton.
- Utiliser la même clé privée pour différentes applications: Cette pratique peut compromettre plusieurs applications si la clé est exposée.
- Utilisation d'un algorithme de signature faible: Les algorithmes de signature faibles peuvent être piratés plus facilement, ce qui entraîne un accès non autorisé.
- Choisir une clé privée courte et/ou à faible entropie: Les clés trop courtes ou dépourvues de caractère aléatoire sont plus susceptibles de faire l'objet d'attaques par force brute.
- Conserver des données sensibles dans la charge utile d'un JWT: Les informations sensibles stockées dans la charge utile peuvent être exposées si le jeton est intercepté.
- Confusion des clés: Une mauvaise gestion des clés peut entraîner une validation incorrecte et permettre un accès non autorisé.
Pour une couverture détaillée de ces vulnérabilités, consultez l'article de blog. Passons maintenant à une autre vulnérabilité : le JWT qui n'expire pas.
Vulnérabilité supplémentaire : JWTs n'expirant pas
Examinons le JWT suivant, qui est basé sur un exemple réel que j'ai rencontré il n'y a pas si longtemps :
Il s'agit d'un JWT utilisé pour authentifier et autoriser l'accès d'un utilisateur à une API. Il est signé avec un secret sécurisé pour éviter l'usurpation d'identité. À première vue, cela semble correct. Mais regardons de plus près la charge utile :
{ |
Lorsque vous regardez cette revendication ttl, vous pensez probablement à time-to-live, car c'est ce que TTL signifie généralement. Il s'agit donc probablement de la durée de validité du JWT. Il doit s'agir du délai d'expiration.
Nous pouvons faire quelques calculs simples. Peut-être que 86 400 000 correspond au nombre de secondes, auquel cas l'émetteur souhaite que ce JWT soit valable pendant 1 000 jours. Ou peut-être s'agit-il de millisecondes, auquel cas l'émetteur souhaite que ce JWT soit valable pendant un jour. Cela peut également avoir du sens.
Mais voici le problème : la spécification JWT indique que le délai d'expiration est spécifié comme exp, et non comme ttl :
| L'allégation "exp" (expiration time) identifie l'heure d'expiration à laquelle ou après laquelle le JWT NE DOIT PAS être accepté pour traitement. Le traitement de l'allégation "exp" exige que la date et l'heure actuelles soient antérieures à la date et à l'heure d'expiration indiquées dans l'allégation "exp". Les responsables de la mise en œuvre PEUVENT prévoir une petite marge de manœuvre, généralement pas plus de quelques minutes, pour tenir compte de l'instabilité de l'horloge. Sa valeur DOIT être un nombre contenant une valeur NumericDate. L'utilisation de cette revendication est OPTIONNELLE. |
Il y a donc deux problèmes.
Tout d'abord, l'émetteur de ce JWT utilise ttl pour spécifier l'expiration, mais ttl n'est pas une revendication JWT standard. La plupart des bibliothèques conçues pour gérer les JWT ne reconnaîtront pas ttl comme une instruction relative à l'expiration du jeton. Cela entraînera des problèmes de compatibilité, et le jeton sera très probablement traité comme n'expirant pas.
Deuxièmement, l'allégation exp nécessite un horodatage réel de l'expiration, et non un nombre relatif de millisecondes (ou de secondes) à partir de l'heure d'émission. Cette confusion provient probablement de l'utilisation de ttl au lieu de exp. Néanmoins, l'émetteur doit comprendre le format attendu pour la réclamation exp afin de garantir une expiration correcte du jeton.
Que vous négligiez de définir le délai d'expiration d'un JWT ou que vous le définissiez de manière incorrecte (comme dans notre exemple), votre JWT sera considéré comme n'expirant pas. Cela présente une faille de sécurité importante.
| Sans expiration appropriée, un JWT peut être réutilisé par des attaquantsou fuir au-delà de leur durée de vie prévue,augmenter le risque d'accès non autorisé. |
Atténuer les vulnérabilités de sécurité des JWT
Maintenant que nous avons abordé les vulnérabilités potentielles en matière de sécurité, la question qui se pose est la suivante : que faire à ce sujet ? Heureusement, l'atténuation de cette vulnérabilité est simple et directe !
Utilisez toujours la revendication d'expiration. Définissez un délai d'expiration pour chaque jeton que vous générez. Lorsque vous le faites, assurez-vous d'utiliser la revendication exp standard avec le format de valeur attendue pour vous assurer qu'elle est conforme aux spécifications JWT et qu'elle expire comme prévu.
Mettez à jour les applications et les bibliothèques. Veillez à ce que votre application et toutes les bibliothèques que vous utilisez soient mises à jour et respectent les dernières normes JWT. Des mises à jour régulières permettent de corriger les failles de sécurité et d'améliorer la compatibilité.
C'est tout. En suivant ces simples lignes directrices, vous réduirez considérablement le risque d'accès non autorisé par le biais d'un JWT n'expirant pas. Vous améliorerez ainsi la sécurité globale de vos implémentations de JWT.
Conclusion
Comprendre et traiter les vulnérabilités des JWT est crucial pour maintenir la sécurité de vos applications. Dans cet article, nous avons mis en évidence le risque lié à la non-expiration des jetons. En utilisant correctement l'exp claim et en gardant vos bibliothèques à jour, vous pouvez atténuer ce risque de manière efficace.
Pour plus de solutions de sécurité et de bonnes pratiques, explorez les ressources disponibles dans la documentation Linode. Linode propose des guides complets pour vous aider à éliminer les failles de sécurité de vos applications.
Commentaires