Outils de développement · Décodeur JWT
L'attaque alg:none et la confusion des clés : pourquoi les vérificateurs doivent épingler les algorithmes
· Pourquoi c'est important
jwt sécurité cryptographie
Si un vérificateur laisse le jeton choisir son propre algorithme, un attaquant peut n'en choisir aucun ou échanger RSA contre HMAC. Cet article explique les deux attaques et la règle qui les empêche.
Le jeton qui s'est vérifié : comment un champ d'en-tête est devenu une surface d'attaque
Une étiquette d'algorithme se trouve à l'intérieur d'une entrée de jeton contrôlée par l'attaquant. Si un vérificateur traite cette étiquette comme une autorisation de sélectionner n'importe quel mode de validation disponible, le jeton commence à influencer la règle utilisée pour s'auto-évaluer. ToolAcre expose l'étiquette précisément afin que les réviseurs puissent la voir, mais n'agit jamais dessus de manière cryptographique.
La direction sûre est l'inverse : la configuration du service de confiance définit les familles d'algorithmes acceptables et les clés associées, puis les en-têtes entrants doivent correspondre à cette politique. Un panneau de décodage ne peut pas fournir cette politique et ne doit pas être confondu avec une protection simplement parce qu'il met en évidence une valeur suspecte.
Le référentiel signale alg:none mais n'établit pas l'historique des spécifications derrière les JWT non sécurisés
L'implémentation traite `alg: none` comme une déclaration non signée et prévient que l'accepter accepterait un contenu arbitraire. Il signale également un troisième segment vide séparément. Les preuves du référentiel soutiennent le rejet de telles entrées dans les flux de travail authentifiés ; il ne précise pas pourquoi les JWT non sécurisés ont été initialement inclus dans une spécification.
Cette formulation historique est donc corrigée plutôt qu'inventée. Ce qui compte sur le plan opérationnel est clair : un service attendant des informations d'identification signées ne doit pas permettre à un en-tête de jeton de désactiver la vérification de signature. ToolAcre lui-même n'effectue aucune vérification, donc sa capacité à afficher `none` est une détection à des fins d'inspection uniquement.
L'attaque alg:none — supprimant la signature et demandant au vérificateur d'en accepter une vide
Une attaque non signée modifie l'en-tête pour demander `none`, modifie les revendications si vous le souhaitez et ne fournit aucun octet de signature. Chaque segment peut toujours être syntaxiquement valide, et les deux premiers sont décodés en JSON raffiné. Un vérificateur permissif convertirait les préférences de l’attaquant en un contournement d’authentification.
Un vérificateur strict n'a pas de branche qui met à niveau cette entrée vers le statut de confiance lorsque des jetons signés sont requis. L'avertissement de ToolAcre permet d'identifier la forme lors du débogage, mais la lecture du mot `none` n'empêche pas un backend de prendre une mauvaise décision. L'application appartient à l'endroit où les informations d'identification sont consommées.
Confusion de clés : présenter une clé publique comme un secret HMAC afin que les jetons RS256 soient vérifiés comme HS256
Une confusion de clés survient lorsqu'un vérificateur autorise des familles d'algorithmes avec des rôles de clé incompatibles et ne parvient pas à lier chaque choix au type de clé correct. Une clé de vérification RSA publique n'est pas un secret HMAC. Traiter ses octets comme un seul après qu'un attaquant a modifié une étiquette d'algorithme réduit la séparation public/private prévue.
Empêcher cette classe d'erreur nécessite plus que la simple vérification d'un segment en forme de signature. Le service doit associer l'algorithme attendu, le type de clé, l'émetteur et le profil de jeton via une configuration fiable. Un décodeur qui affiche RS256 ou HS256 ne peut pas dire si le backend maintient ces liaisons.
Le correctif : épinglez les algorithmes acceptés dans le vérificateur et ne les dérivez jamais du jeton
Épinglez les algorithmes acceptés dans la configuration du vérificateur et gardez la liste aussi étroite que le permet le contrat de l'émetteur. Rejetez `none` pour les flux d’informations d’identification signées et rejetez les incohérences plutôt que d’essayer un autre algorithme. Ne dérivez pas la liste verte de l’en-tête non vérifié ou d’une réclamation de charge utile.
La recherche de clé suit le même principe. Un `kid` peut sélectionner parmi des candidats déjà fiables, mais ne doit pas créer une nouvelle source de confiance. Les URL d'en-tête ou les clés intégrées ne doivent pas être suivies simplement parce que le jeton le demande. Le vérificateur décide de ses sources de manière indépendante.
Exemple pratique : lire un en-tête dans le décodeur ToolAcre JWT pour repérer alg:none, et pourquoi le repérer n'est pas la même chose qu'être protégé
Créez un en-tête de jeton inoffensif déclarant `none` et laissez le troisième segment vide. ToolAcre décode le JSON, rapporte l'algorithme déclaré, prévient qu'il n'est pas signé et note la signature absente. C’est exactement le comportement attendu d’un outil d’inspection.
L'exercice ne prouve pas qu'une API rejette le jeton. Confirmez cela séparément avec un test négatif contrôlé par rapport au vérificateur et à la configuration réels. Si l'API l'accepte, le correctif appartient à cette limite de vérification ; l'ajout d'un avertissement plus fort à un décodeur ne protégerait pas les demandes.
Ce que cela ne couvre pas : les nombreux correctifs spécifiques à la bibliothèque ; consultez la RFC 8725 et le journal des modifications de votre bibliothèque
Les API de bibliothèque, les valeurs par défaut et les correctifs historiques varient selon le produit et la version. Ce module n'établit pas quel nom d'option épingle les algorithmes dans votre pile, et cet article n'en invente intentionnellement aucun. Lisez la documentation actuelle et le journal des modifications de la bibliothèque sélectionnée, puis exercez les cas de rejet dans votre propre suite de tests.
Testez également les mauvais types de clés, les valeurs `kid` inconnues, les signatures manquantes et les profils de jetons inattendus. L’objectif est de montrer que la configuration l’emporte sur les suggestions de jetons. Un décodage réussi n'a sa place nulle part dans ces assertions d'acceptation car le succès de la syntaxe est compatible avec chaque exemple malveillant.
À retenir : c'est le vérificateur qui décide, pas le jeton : un décodeur vous aide à voir l'en-tête, mais seule la vérification épinglée vous protège
Le vérificateur décide ; le jeton ne le fait pas. ToolAcre peut révéler un en-tête indiquant `none`, un algorithme inconnu ou un identifiant de clé surprenant. Cette visibilité facilite le tri, mais seules les règles d'algorithme épinglées et les clés de confiance correctement liées empêchent l'acceptation.
Ne recommandez jamais d'activer `none`, de choisir une clé de vérification à partir d'un en-tête non fiable ou de traiter une longueur de signature affichée comme une validation. Décodez pour inspection, puis prouvez le comportement de rejet et d’acceptation à la limite cryptographique réelle avec des tests contrôlés.