Signature JWT non vérifiée

Identifiant de scan	jwt.not_verified
Gravité	Élevée
CVSS 4.0	9.3 — CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N
Classifications	CWE-345: Insufficient Verification of Data Authenticity
Catégorie OWASP	OWASP API2:2023 Broken Authentication

La vulnérabilité « Signature JWT non vérifiée » survient lorsqu’un serveur accepte un JWT dont la signature a été créée avec une clé complètement différente (aléatoire). Si le serveur renvoie la même réponse de succès que pour un token légitimement signé, il ne vérifie pas du tout la signature — ce qui signifie qu’un attaquant peut fabriquer n’importe quel payload et le serveur l’acceptera.

Pour plus de détails, consultez la documentation jwtop sur la signature non vérifiée.

Exemple

VulnAPI prend votre token valide, en extrait l’algorithme et les claims, puis le re-signe avec une clé générée aléatoirement :

Token valide d’origine (signé avec la vraie clé privée) :

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyMTIzIiwicm9sZSI6InVzZXIifQ.<valid_signature>

Token d’attaque (mêmes claims, signé avec une clé aléatoire) :

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyMTIzIiwicm9sZSI6InVzZXIifQ.<random_signature>

Si les deux requêtes renvoient le même code de statut HTTP (ex. 200 OK), le serveur ne vérifie pas la signature.

Comment tester ?

cURL

vulnapi scan curl [url] -H "Authorization: Bearer eyJhbGciOiJSUzI1NiI..." --scans jwt.not_verified

OpenAPI

echo "eyJhbGciOiJSUzI1NiI..." | vulnapi scan openapi [OpenAPI_Path_Or_URL] --scans jwt.not_verified

GraphQL

vulnapi scan graphql -H "Authorization: Bearer eyJhbGciOiJSUzI1NiI..." --scans jwt.not_verified [url]

VulnAPI prend aussi en charge le scan d’autres types de vulnérabilités.

Quel est l’impact ?

Si un attaquant peut forger des JWT arbitraires sans avoir besoin de la clé de signature, il peut :

• Élever ses privilèges : modifier le claim role ou permissions pour obtenir un accès admin
• Usurper l’identité de n’importe quel utilisateur : changer le claim sub ou user_id vers n’importe quelle valeur
• Contourner tous les contrôles d’accès basés sur JWT : l’ensemble du système d’authentification est effectivement désactivé
• Accéder à n’importe quelle ressource : l’attaquant peut prétendre être n’importe quel utilisateur, y compris ceux dont il n’a pas les identifiants

Le score CVSS 9.3 reflète le fait qu’il s’agit d’une faille exploitable réseau, sans authentification préalable requise, donnant un accès complet en lecture/écriture à toutes les données utilisateur.

Comment corriger ?

1. Toujours vérifier les signatures : utilisez une bibliothèque JWT fiable et bien maintenue, et appelez la fonction de vérification — jamais un simple décodage.

2. Fournir la bonne clé : transmettez explicitement la clé publique attendue (pour RS/ES) ou le secret (pour HS) ; ne laissez jamais la bibliothèque auto-détecter la clé depuis l’en-tête du token.

3. Restreindre les algorithmes autorisés : configurez votre bibliothèque pour n’accepter qu’un ensemble spécifique d’algorithmes (ex. ["RS256"]). Cela empêche les attaques de confusion d’algorithme en plus du contournement de signature.

4. Utiliser des algorithmes asymétriques pour les systèmes distribués : RS256 et ES256 permettent à n’importe quel service de vérifier les tokens avec la clé publique, tandis que seul l’émetteur détient la clé privée.

// Exemple Go — toujours passer les algorithmes autorisés
token, err := jwt.Parse(tokenString, keyFunc,
    jwt.WithValidMethods([]string{"RS256"}),
)

# Exemple Python — toujours passer algorithms et verify=True (par défaut)
payload = jwt.decode(token, public_key, algorithms=["RS256"], audience="my-service")