Pourquoi le décodage des JWS n'est que le point d'entrée
Dans les architectures d'identité modernes, en particulier OAuth 2.0 et OpenID Connect, les jetons signés sont souvent considérés comme des "conteneurs de confiance" qui peuvent être transmis entre les services. Mais pour les ingénieurs en sécurité, les red teamers et les chercheurs en sécurité de l'IA, un JWS est mieux compris comme une entrée compacte, contrôlée par l'attaquant, qui se situe à l'intersection de la cryptographie et de la logique d'entreprise. La capacité d'effectuer un décodage de la signature web json n'est pas l'objectif ; c'est l'instrumentation qui vous permet de raisonner sur ce que le vérificateur pense qu'il valide, ce que l'application en fait pour l'autorisation, et quelles parties du jeton sont traitées comme une configuration plutôt que comme des données non fiables.
Cette distinction est importante car la "sécurité des jetons" n'est pas une propriété du format des jetons. C'est une propriété du pipeline de vérification et de validation des demandes-sélection de l'algorithme, sélection de la clé, contrôles de l'émetteur/du public, réclamations basées sur le temps et, de manière critique, comment le code en aval utilise les réclamations une fois qu'il les a obtenues. Dès lors qu'un système traite les revendications décodées comme la "vérité" avant que la vérification ne soit terminée (ou même exécutée), le jeton cesse d'être une limite de sécurité et devient un paramètre contrôlé par l'utilisateur.
L'ingénierie derrière la chaîne : Base64url sans remplissage
Lorsque les gens disent "décoder un JWS", ce qu'ils font généralement, c'est inverser une étape d'encodage base64url. Dans la sérialisation compacte de JWS, chacun des trois segments est encodé en base64url, en utilisant l'alphabet URL-safe et en omettant généralement les éléments suivants = rembourrage. Le RFC 7515 définit le format compact et utilise explicitement le format BASE64URL(...) pour la construction de l'en-tête et de la charge utile, puis concatène avec . séparateurs. (Rédacteur du RFC)
La convention "no padding" semble mineure jusqu'à ce que vous construisiez des outils ou analysiez le trafic capturé à grande échelle. De nombreuses routines génériques base64 partent du principe que le padding est présent et, en cas d'absence de padding, elles génèrent des erreurs ou des résultats ambigus. Un décodeur robuste doit réajuster le padding de manière déterministe et utiliser une routine de décodage compatible avec base64url, sinon votre analyse devient non reproductible, en particulier lorsque vous avez affaire à des jetons malformés ou intentionnellement corrompus pendant le fuzzing.
JWS vs JWT : ce que chaque point signifie réellement
Un jeton JWS Compact est toujours :
BASE64URL(header) . BASE64URL(payload) . BASE64URL(signature)
Le troisième segment n'est pas "hexagonal". Il s'agit de la base64url des octets de signature (ou MAC). Considérez-le comme opaque, à moins que vous ne procédiez à une vérification ou à un triage cryptographique.
JWT (RFC 7519) est une convention d'ensemble de revendications qui est généralement incluse dans la charge utile JWS, ce qui explique pourquoi les gens confondent "JWT" et "JWS". La RFC 7519 définit les revendications enregistrées comme iss, sous, aud, expet nbfet décrit comment ces demandes sont représentées sous la forme d'un objet JSON. (IETF Datatracker)
En pratique, cela signifie qu'une étape de décodage uniquement peut vous dire ce que le jeton revendicationsmais il ne peut pas vous dire si ces affirmations sont fondées ou non. vrai. La vérité n'apparaît qu'après la vérification de la signature et la validation de la demande.
L'en-tête est la surface d'attaque : alg, enfant, jku en tant qu'intrants non fiables
Dans les systèmes bien conçus, l'en-tête du jeton est une métadonnée qui aide le vérificateur à sélectionner une stratégie de vérification connue et efficace. Dans les systèmes mal conçus, l'en-tête devient un canal de configuration contrôlé par l'attaquant. C'est pourquoi, lors d'une décodage de la signature web jsonDe nombreux professionnels se concentrent d'abord sur l'en-tête.
Les alg est particulièrement sensible car elle peut influencer la méthode de vérification invoquée. La confusion d'algorithme (également appelée confusion de clé) se produit lorsqu'un attaquant peut forcer le serveur à vérifier un JWT en utilisant un algorithme différent de celui prévu par le développeur, ce qui peut permettre de créer de faux jetons sans connaître la clé de signature du serveur. La Web Security Academy de PortSwigger décrit clairement cette classe et l'associe à une mauvaise configuration ou à une mauvaise gestion des choix d'algorithmes. (PortSwigger)
Les enfant n'est pas de la cryptographie, mais de la récupération de clés. Si le enfant Si l'on ne tient pas compte des influences des chemins d'accès aux fichiers, des requêtes de bases de données, des clés de cache ou des résolveurs dynamiques sans liste d'autorisation stricte, cela devient une surface d'injection générale à l'intérieur de la limite de gestion des clés.
Les jku est encore plus dangereux lorsqu'il est mal utilisé. Si un serveur récupère un JWKS à partir d'une URL spécifiée par l'en-tête du jeton (ou à partir d'une variante insuffisamment contrainte), l'attaquant peut tenter de remplacer l'ancre de confiance en orientant le vérificateur vers des clés contrôlées par l'attaquant. Même lorsqu'un système "ne récupère que du HTTPS", l'absence de listes d'autorisation strictes, de liaison avec l'émetteur, de politique de mise en cache et de pistes d'audit transforme la récupération des clés en un problème de chaîne d'approvisionnement, et non en un problème de cryptographie.
Un décodeur hors ligne de niveau production en Python (décodage uniquement, sécurité du remplissage)
Les débogueurs de jetons basés sur le Web sont pratiques, mais ils sont souvent une mauvaise idée dans le cadre d'un travail de sécurité professionnel. Les jetons peuvent contenir des identifiants sensibles, des courriels, des identifiants de locataires internes ou même des informations confidentielles intégrées. Vous voulez un outil hors ligne, scriptable, déterministe et sûr pour les entrées malformées. L'implémentation ci-dessous ne "vérifie" intentionnellement rien ; elle décode seulement ce qui est présent et rend les modes d'échec observables.
import base64
import json
from typing import Any, Dict, Tuple, Optional
def _b64url_decode(data : str) -> bytes :
# RFC 7515 base64url omet généralement le padding "=" ; rétablissez-le de manière déterministe.
pad = (-len(data)) % 4
return base64.urlsafe_b64decode((data + "=" * pad).encode("ascii"))
def _parse_json(b : bytes) -> Tuple[Optional[Dict[str, Any]], Optional[str]] :
try :
return json.loads(b.decode("utf-8")), None
except Exception as e :
return None, f"{type(e).__name__} : {e}"
def jws_decode(token : str) -> Dict[str, Any] :
parts = token.split(".")
if len(parts) != 3 :
return {"error" : "Format compact JWS non valide (3 parties attendues)", "parts" : len(parts)}.
header_b = _b64url_decode(parts[0])
payload_b = _b64url_decode(parts[1])
header, he = _parse_json(header_b)
payload, pe = _parse_json(payload_b)
out : Dict[str, Any] = {
"header_raw" : header_b.decode("utf-8", errors="replace"),
"payload_raw" : payload_b.decode("utf-8", errors="replace"),
"signature_b64url_sample" : parts[2][:16] + "..."
}
si l'en-tête n'est pas None :
out["header"] = header
sinon :
out["header_error"] = he
si payload n'est pas None :
out["payload"] = payload
sinon : out["payload_error"] = he
out["payload_error"] = pe
retourner out
Cela est conforme à l'utilisation de base64url de la RFC 7515 (et au fait que JWS compact est conçu pour les contextes d'en-tête URL/HTTP), tout en vous offrant un comportement stable lorsque le jeton est malformé, tronqué ou intentionnellement altéré. (Rédacteur du RFC)
Le fossé critique : décodage et vérification (et le vrai modèle de bogue)
L'erreur de sécurité la plus persistante concernant les JWS/JWT consiste à confondre décodage et vérification. Le décodage est un formatage réversible ; la vérification est une validation cryptographique et l'application d'une politique.
Dans les incidents réels, le modèle d'échec courant est "utiliser avant de vérifier" plutôt qu'une course littérale. Une application décode le jeton, lit rôle, user_id, locataireou champ d'applicationL'OWASP souligne que les algorithmes et la logique de vérification sont mal gérés, ce qui permet des attaques à fort impact, notamment la confusion entre les flux de vérification asymétriques et symétriques. Les orientations de l'OWASP sur les tests JWT soulignent comment une mauvaise manipulation des attentes des algorithmes et de la logique de vérification permet des attaques à fort impact, y compris la confusion entre les flux de vérification asymétriques et symétriques. (Fondation OWASP)
Même si la signature est valide, un jeton doit encore être validé. La RFC 7519 définit aud en tant qu'audience, et note que si le principal qui traite le jeton ne s'identifie pas à l'audience visée, le jeton doit être rejeté lorsque aud est présent. (IETF Datatracker) Cela nous rappelle que la validité cryptographique n'est pas équivalente à la validité contextuelle.
Exploitation avancée : au-delà de "alg : none"
L'argument "alg : none" est historiquement important, mais la plupart des bibliothèques modernes le bloquent par défaut. Les défaillances les plus intéressantes aujourd'hui se répartissent en deux catégories : les défauts d'implémentation des fournisseurs de crypto-monnaie et les contournements logiques complexes causés par des pipelines de vérification flexibles.
Signatures psychiques (CVE-2022-21449) : lorsque la vérification ECDSA est erronée
CVE-2022-21449 - popularisée sous le nom de "Psychic Signatures" - est une vulnérabilité cryptographique Java grave où la vérification de la signature ECDSA pourrait être contournée sous certaines conditions dans les versions Java concernées (notamment introduite dans Java 15 et corrigée dans l'unité centrale d'avril 2022). Les analyses soulignent à quel point cette vulnérabilité affaiblit les systèmes reposant sur les signatures ECDSA, y compris les scénarios impliquant des JWT ou des mécanismes WebAuthn signés ECDSA. (Neil Madden)
La leçon la plus importante pour la sécurité des jetons n'est pas l'intelligence du contournement ; c'est la réalité opérationnelle : "J'ai choisi ES256" n'est pas une garantie. Votre version d'exécution, l'implémentation du fournisseur de sécurité et l'état des correctifs font partie de votre modèle de menace. Les équipes de sécurité doivent traiter les "régressions du fournisseur de cryptographie" comme des risques de premier ordre, avec des accords de niveau de service explicites pour les correctifs et des tests de régression qui exercent une vérification par rapport à des signatures malformées.
Confusion d'algorithmes / confusion de clés : lorsque le serveur laisse le jeton choisir les règles.
Les attaques par confusion d'algorithme se produisent lorsque le vérificateur permet au jeton d'influencer l'algorithme utilisé pour la vérification et que la gestion des clés n'est pas clairement séparée entre les modes asymétriques et symétriques. PortSwigger note que si ce cas n'est pas traité correctement, les attaquants peuvent falsifier des JWT valides contenant des valeurs arbitraires sans connaître la clé de signature secrète du serveur. (PortSwigger)
Dans la pratique, la défense est conceptuellement simple mais souvent manquée : ne jamais permettre "l'agilité de l'algorithme" à la limite où les décisions d'authentification sont prises. Si votre service attend RS256, vous appliquez RS256. Vous ne devez pas "accepter n'importe quel algorithme dans l'en-tête et voir s'il est validé".
Récupération de clés à partir d'en-têtes : enfant/jku en tant que chaîne d'approvisionnement de vérification
Dès lors que l'on admet que l'en-tête est une entrée de l'attaquant, on admet également que la sélection des touches fait partie de la surface d'attaque. A enfant doit correspondre à une liste prédéfinie de clés, et non à des clés arbitraires récupérées, chargées ou construites au moment de l'exécution. A jku ne devrait jamais permettre à un jeton de redéfinir l'origine des ancres de confiance. Si vous prenez en charge la récupération JWKS pour l'OIDC, elle doit être liée à une configuration d'émetteur de confiance et renforcée par des listes d'autorisations, une mise en cache et une surveillance.
Des stratégies de durcissement qui survivent aux dérives de la production
Une approche de défense en profondeur de la validation des JWS peut sembler ennuyeuse sur le papier, mais c'est exactement ce qui permet d'éviter la majorité des échecs de jetons.
Vous épinglez explicitement les algorithmes acceptés et exigez du vérificateur qu'il s'assure que l'algorithme attendu a été utilisé. Les conseils de l'OWASP sur les JWT pour Java soulignent directement ce point en tant que mesure préventive. (Série d'aide-mémoire de l'OWASP)
Vous validez l'émetteur et le destinataire de manière cohérente. Les définitions de la RFC 7519 pour les réclamations enregistrées ne sont pas académiques ; elles existent parce que "signature valide, mauvais contexte" est une classe commune d'échecs. En particulier, la non-concordance des publics est l'un des moyens les plus faciles d'accepter accidentellement un jeton créé pour un service différent. (IETF Datatracker)
Vous traitez les identifiants de clé comme des données, et non comme une requête de consultation. A enfant doit être résolue par une correspondance délimitée - alias KMS, registre de clés statiques ou magasin de clés étroitement contrôlé - et non par un chemin de système de fichiers ou une requête de base de données élaborée à partir d'une entrée non fiable.
Vous patchez les runtimes cryptographiques de manière agressive et vous testez contre les classes catastrophiques connues. La CVE-2022-21449 rappelle que le "choix d'un algorithme correct" ne peut pas compenser des implémentations de vérification défectueuses. (Neil Madden)
Vous surveillez les anomalies qui indiquent un sondage actif. Des volumes importants d'erreurs de remplissage base64url, des jetons invalides répétés, ou un taux de renouvellement élevé dans le système enfant peuvent indiquer des tentatives de fuzzing ou de confusion en cours. La surveillance ne résoudra pas le problème, mais elle peut réduire le temps de détection et vous aider à corréler l'activité suspecte avec des points finaux et des vérificateurs spécifiques.
Automatisation de l'audit de la logique de vérification : la place de Penligent
Dans les environnements réels, le plus difficile n'est pas de décoder un jeton une seule fois. Il s'agit de découvrir où les jetons sont acceptés, d'identifier les services qui appliquent les règles de vérification et de prouver que l'autorisation en aval dépend prématurément des revendications décodées. Cette boucle "décoder → interpréter → muter → valider l'impact" est répétitive, et c'est exactement le type de travail que les plateformes de sécurité modernes assistées par l'IA peuvent aider à industrialiser.
Une plateforme comme Penligent peut être positionnée de manière crédible en tant que couche d'automatisation pour les tests centrés sur les tokens : elle peut effectuer un décodage hors ligne pour classer les tokens et extraire les champs à haut signal (émetteur, audience, scopes, rôles), déduire les piles de vérification probables à partir du comportement de la réponse et des empreintes digitales du service, et ensuite tester systématiquement les dérives de la politique - les échecs des listes d'autorisation des algorithmes, l'application incohérente de l'émetteur/audience à travers les microservices, et les modèles de sélection de clés non sécurisés. Il ne s'agit pas de " jetons magiques de rupture ", mais d'une génération de preuves répétables et de contrôles de régression continus qui détectent les régressions subtiles de la vérification avant qu'elles ne se produisent.
Si vous considérez la vérification des JWS comme une limite d'API critique pour la sécurité, un flux de travail piloté par l'IA est plus puissant lorsqu'il vous aide à garantir que cette limite reste cohérente entre les versions, les environnements et les propriétaires de services.
Conclusion
L'ordre de décodage de la signature web json est la ligne de départ, pas la ligne d'arrivée. Le décodage vous donne l'observabilité, mais la sécurité provient d'une vérification stricte et d'une validation des revendications, d'une gestion disciplinée des clés et d'une hygiène d'exécution résiliente.
Des défaillances catastrophiques des fournisseurs de crypto-monnaies comme les "signatures psychiques" (CVE-2022-21449) à la confusion des algorithmes et aux risques liés à la chaîne d'approvisionnement des clés à en-tête, la sécurité des systèmes d'authentification conjointe est une propriété du système. Les équipes qui combinent une analyse manuelle minutieuse avec une automatisation qui détecte les dérives de la vérification peuvent maintenir la robustesse de leurs couches d'authentification, même lorsque les écosystèmes évoluent et que de nouveaux modes de défaillance apparaissent.
Ressources fiables et lectures complémentaires
RFC 7515 : Signature Web JSON (JWS). (Rédacteur du RFC)
RFC 7519 : Jeton Web JSON (JWT). (IETF Datatracker)
PortSwigger : Attaques par confusion d'algorithmes. (PortSwigger)
OWASP WSTG : Testing JSON Web Tokens (Fondation OWASP)
Aide-mémoire de l'OWASP : JSON Web Token pour Java. (Série d'aide-mémoire de l'OWASP)
Neil Madden : Signatures psychiques en Java. (Neil Madden)
Analyse JFrog de CVE-2022-21449. (JFrog)
Explication cryptomathique de CVE-2022-21449. (Cryptomathique)
