FixVibe
Covered by FixVibehigh

JWT Sécurité : risques de jetons non garantis et de validation de réclamation manquante

Les jetons Web JSON (JWT) fournissent une norme pour le transfert des revendications, mais la sécurité repose sur une validation rigoureuse. L’incapacité de vérifier les signatures, les délais d’expiration ou les publics visés permet aux attaquants de contourner l’authentification ou de rejouer les jetons.

CWE-347CWE-287CWE-613

Impact de l'attaquant

Une validation incorrecte de JWT permet aux attaquants de contourner les mécanismes d'authentification en falsifiant des revendications ou en réutilisant des jetons [S1] expirés. Si un serveur accepte des jetons sans signature valide, un attaquant peut modifier la charge utile pour élever les privilèges ou usurper l'identité de n'importe quel utilisateur [S1]. De plus, le fait de ne pas appliquer la revendication d'expiration (exp) permet à un attaquant d'utiliser indéfiniment un jeton compromis [S1].

Cause première

Un jeton Web JSON (JWT) est une structure basée sur JSON utilisée pour représenter les revendications signées numériquement ou protégées en intégrité [S1]. Les failles de sécurité proviennent généralement de deux principales lacunes de mise en œuvre :

  • Acceptation des JWT non sécurisés : si un service n'applique pas strictement la vérification de la signature, il peut traiter les "JWT non sécurisés" lorsque la signature est absente et l'algorithme est défini sur "aucun" [S1]. Dans ce scénario, le serveur approuve les revendications dans la charge utile sans vérifier leur intégrité [S1].
  • Validation de réclamation manquante : La réclamation exp (délai d'expiration) identifie le délai à partir duquel ou après lequel le JWT ne doit pas être accepté pour le traitement du [S1]. La revendication aud (audience) identifie les destinataires prévus du jeton [S1]. Si ces cases ne sont pas cochées, le serveur peut accepter des jetons expirés ou destinés à une autre application [S1].

Réparations concrètes

  • Appliquer les signatures cryptographiques : configurez l'application pour rejeter tout JWT qui n'utilise pas un algorithme de signature fort et pré-approuvé (tel que RS256).
  • Valider l'expiration : mettez en œuvre une vérification obligatoire pour garantir que la date et l'heure actuelles sont antérieures à l'heure spécifiée dans la réclamation exp [S1].
  • Vérifier l'audience : assurez-vous que la revendication aud contient une valeur identifiant le service local ; si le service n'est pas identifié dans la réclamation aud, le token doit être rejeté [S1].
  • Empêcher la relecture : utilisez la revendication jti (JWT ID) pour attribuer un identifiant unique à chaque jeton, permettant au serveur de suivre et de rejeter les jetons réutilisés [S1].

Stratégie de détection

Les vulnérabilités dans la gestion de JWT peuvent être identifiées en analysant la structure du jeton et le comportement de réponse du serveur :

  • Inspection de l'en-tête : vérification de l'en-tête alg (algorithme) pour s'assurer qu'il n'est pas défini sur « aucun » et qu'il utilise les normes cryptographiques attendues [S1].
  • Vérification des réclamations : confirmation de la présence et de la validité des réclamations exp (expiration) et aud (audience) dans la charge utile JSON [S1].
  • Test de validation : test si le serveur rejette correctement les jetons qui ont expiré conformément à la revendication exp ou sont destinés à un public différent tel que défini par la revendication aud [S1].