décodage de la signature web json : Le guide d'un ingénieur en sécurité pour ne pas se faire posséder

Le contrôle d'accès moderne vit et meurt grâce aux jetons basés sur JSON. Lorsque vous inspectez un jeton d'accès OAuth, un jeton d'identification OpenID Connect, ou une session API signée, vous regardez généralement un jeton de type Signature Web JSON (JWS) structure. Les moteurs de recherche renvoient de nombreuses personnes vers des outils de décodage de signatures web json qui semblent transformer comme par magie des chaînes opaques en JSON lisible.

Pour les ingénieurs en sécurité offensive et défensive, ce n'est que la première étape. Le décodage d'un JWS permet de savoir ce que le jeton revendicationsIl ne vous dit pas si ces affirmations sont dignes de confiance, si la signature est correctement appliquée ou si la mise en œuvre figure déjà dans une base de données CVE.

Cet article explique ce qui se passe réellement lorsque vous effectuez un décodage de signature web json, comment des vulnérabilités réelles sont apparues à la suite d'erreurs subtiles dans la vérification de JWS, et comment construire un flux de travail reproductible qui s'intègre dans un pipeline de pentest automatisé et augmenté par l'IA.

Qu'est-ce qu'une signature Web JSON ?

Selon la spécification JWS, une signature Web JSON représente un contenu arbitraire protégé par une signature numérique ou un MAC, à l'aide de structures basées sur JSON. Elle assure l'intégrité et l'authenticité d'une séquence d'octets, indépendamment de ce que ces octets représentent. (IETF Datatracker)

En pratique, la plupart du temps, cette séquence d'octets est un objet JSON de type revendications - qui est ce que nous appelons un jeton Web JSON (JWT). Le JWS lui-même est défini dans le [RFC 7515], tandis que le JWT fait l'objet d'une norme apparentée axée sur la manière dont ces revendications sont structurées et interprétées. (Moyen)

La forme compacte qui nous est familière se présente comme suit :

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiIxMjM0Iwic2NvcGUiOlsicmVhZCIsIndyaXRlIl0sImV4cCI6MTczNDkxMjAwMH0.
ODU5Y...signature-octets-ici...

Conceptuellement, il s'agit de trois parties encodées en Base64URL et reliées par des points :

Une opération de décodage de signature web json, qu'elle soit effectuée par un outil en ligne ou dans vos propres scripts, ne fait qu'inverser le codage Base64URL des deux premières parties et imprimer joliment le JSON. Elle fait pas prouver que la signature est valide, à moins que l'outil n'effectue explicitement une vérification avec une clé connue et un ensemble d'algorithmes contraints. (developer.pingidentity.com)

Comment fonctionnent les outils de décodage des signatures web json

La plupart des décodeurs JWT / JWS - tels que les outils de développement couramment utilisés dans les navigateurs ou les aires de jeux en ligne - mettent en œuvre le même pipeline minimal :

1. Diviser les points en trois segments.
2. Base64URL-décode les deux premiers segments.
3. Les analyser en JSON pour l'en-tête et la charge utile.
4. Si une clé de vérification est fournie, la signature est recalculée à l'aide de l'algorithme annoncé dans l'en-tête et comparée au troisième segment. (developer.pingidentity.com)

Du point de vue d'un ingénieur en sécurité, les étapes 1 à 3 sont suffisamment sûres pour une analyse hors ligne ; c'est à l'étape 4 que se cachent la plupart des vulnérabilités.

Extrait minimal de décodage en Python

Voici un extrait délibérément simple de décodage en Python, utile lorsque vous parcourez les tokens capturés lors d'un pentest :

import base64
import json

def b64url_decode(data : str) -> bytes :
    # Gestion du padding JWT
    padding = '=' * (-len(data) % 4)
    return base64.urlsafe_b64decode(data + padding)

def decode_jws(token : str) :
    header_b64, payload_b64, signature_b64 = token.split('.')
    header = json.loads(b64url_decode(header_b64))
    payload = json.loads(b64url_decode(payload_b64))
    return header, payload, signature_b64

jws = "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...."
h, p, sig = decode_jws(jws)
print("En-tête :", h)
print("Payload :", p)

Notez que cette fonction jamais appelle une routine de vérification ; il ne fait que décoder. C'est souvent exactement ce que l'on souhaite lors de l'évaluation d'une nouvelle cible : une inspection rapide sans aucune hypothèse cryptographique.

Extrait de Node.js avec vérification

Lorsque l'on passe du décodage à la vérification, chaque détail compte :

import jwt de "jsonwebtoken" ;
import fs from "fs" ;

const publicKey = fs.readFileSync("public.pem", "utf-8") ;

function verifyJws(token) {
  // Critique : verrouiller explicitement les algorithmes supportés
  return jwt.verify(token, publicKey, {
    algorithmes : ["RS256"],
  }) ;
}

Si vous omettez le algorithmes et laisser la bibliothèque déduire l'algorithme de l'en-tête non fiable, vous reproduisez exactement les conditions qui ont conduit à de multiples CVE JWT.

Le décodage est inoffensif, la confiance dans les données décodées ne l'est pas.

Les rapports d'incidents et les CVE révèlent un schéma récurrent : les développeurs traitent leurs clients comme des criminels de guerre, ce qui n'est pas toujours le cas. décodé Les données JWT / JWS comme s'il s'agissait de données déjà existantes. vérifié. De nombreux articles récents sur les problèmes de sécurité des JWT soulignent que le décodage de Base64URL est trivial et que le secret d'un jeton n'est pas dû au fait qu'il est "difficile à lire". (PortSwigger)

Trois classes de bogues récurrentes se distinguent :

1. Le champ "alg" est traité comme une source de vérité. Si votre code de vérification tire l'algorithme à utiliser de l'en-tête - qui est contrôlé par l'utilisateur - vous vous exposez à des attaques par confusion d'algorithmes.
2. Les aucun est accepté par erreur. La norme JWT a toujours exigé la prise en charge des éléments suivants "aucun" comme un algorithme signifiant "pas de protection de l'intégrité". L'analyse classique d'Auth0 a montré comment plusieurs bibliothèques ont naïvement honoré ce choix, permettant aux jetons non signés de passer les contrôles. (Auth0)
3. Conseils clés (enfant, incorporé jwk, x5u) ne sont pas validés. Le RFC JWS et les guides de test soulignent tous deux que le fait de permettre au jeton de choisir sa propre clé de vérification sans liste blanche stricte permet aux attaquants d'introduire clandestinement des clés publiques arbitraires ou de forcer la consultation de clés dans des endroits contrôlés par les attaquants. (PortSwigger)

En d'autres termes, le décodage de la signature web json vous donne l'observabilité. Il ne vous donne pas la confiance. Cette distinction est ce qui sépare une configuration de débogage sûre d'une ligne de tête d'exécution de code à distance.

Quand le décodage rencontre les CVE : les modes d'échec concrets des JWS

Pour comprendre à quel point les choses peuvent mal tourner lorsque le décodage et la vérification sont confondus, il est utile d'examiner quelques CVE qui tournent autour de la logique de vérification de JWS.

CVE-2015-9235 - Confusion de clé HS/RS dans jsonwebtoken

Dans l'application Node.js jsonwebtoken avant la version 4.2.2, une erreur de conception permettait de contourner la vérification de la signature en passant d'un algorithme asymétrique (familles RS256 / ES256) à un algorithme symétrique (HS256). Le chemin de code vulnérable réutilisait la même valeur - la clé publique RSA - comme secret HMAC lorsque l'attaquant modifiait la clé publique RSA. alg à HS256. (nvd.nist.gov)

Du point de vue de l'attaquant, le processus est simple :

1. Décoder le jeton original et inspecter l'en-tête.
2. Extraire la clé publique du serveur (par exemple, à partir d'un point de terminaison JWK ou d'un certificat).
3. Forger un nouveau jeton avec un en-tête HS256, en utilisant la clé publique comme secret HMAC.
4. Présenter le faux jeton ; le serveur le considère par erreur comme valide.

Ici, le décodage a fourni à l'attaquant la matière première (en-tête, algorithme, emplacements clés) ; la logique de vérification a fait le reste.

CVE-2018-1000531 - acceptation de l'option aucun algorithme

Cette vulnérabilité a permis de repérer les cas où les bibliothèques ont accepté des jetons signés avec l'extension aucun les considérant comme valides malgré l'absence de signature. Le schéma d'exploitation est d'une simplicité presque comique : modifier "alg" : "RS256" à "alg" : "none", supprimer la partie signature, et voir si l'API cible accepte le jeton. (0xn3va.gitbook.io)

CVE-2023-48238 - Confusion d'algorithme dans json-web-token

Les json-web-token pour JavaScript s'est révélée vulnérable à une autre attaque par confusion d'algorithmes. Le problème principal : l'algorithme utilisé pour la vérification était tiré directement de l'en-tête du jeton, qui, à ce stade, n'était pas fiable. Cela a permis aux attaquants de choisir un algorithme plus pratique que celui que l'opérateur du serveur pensait appliquer. (nvd.nist.gov)

CVE-2024-54150 - confusion dans l'implémentation d'un JWT en C

Plus récemment, le cjwt La bibliothèque C a souffert d'un défaut critique de confusion d'algorithme, désormais répertorié sous le nom de CVE-2024-54150. Un examen du code a révélé que l'implémentation ne distinguait pas correctement les algorithmes basés sur HMAC de ceux basés sur RSA / EC lors de la vérification des jetons, ce qui ouvre à nouveau la porte à la confusion des clés. (nvd.nist.gov)

Ces cas ne sont pas des curiosités historiques ; ils montrent que même en 2023-2024, des erreurs subtiles dans le parcours de vérification des JWS restent une source active de vulnérabilités graves.

Pour ne pas se tromper lors d'une évaluation, de nombreuses équipes créent une antisèche comme celle qui suit :

Lors d'un exercice de décodage de signature web json, la mise en correspondance explicite des jetons observés avec cette table est un moyen rapide de repérer les playbooks à essayer.

Un processus pratique de décodage en premier pour les pentesters

Lors de l'évaluation d'une API ou d'un système SSO reposant sur JWS, un processus de décodage rigoureux permet d'éviter les zones d'ombre et les suppositions hasardeuses.

1. Capturer et cataloguer les jetons. Utilisez votre proxy ou votre harnais de test pour capturer tous les jetons : En-têtes d'autorisation, cookies, paramètres d'URL. Regroupez-les par émetteur et par public.
2. Décoder l'en-tête et la charge utile hors ligne. Utilisez des scripts tels que l'extrait Python ci-dessus ou jwt_tool à décoder uniquement ; ne vous fiez jamais à un service en ligne pour les jetons sensibles dans le cadre d'engagements réels. (GitHub)
3. Construire une matrice d'en-tête. Pour chaque famille de jetons, enregistrer alg, enfant, présence de jku / jwk / x5uet tout champ d'en-tête personnalisé. C'est ici que les conseils de PortSwigger sur les JWK intégrés et les clés fournies par les attaquants deviennent directement exploitables. (PortSwigger)
4. Déduire des modèles de gestion des clés. Sur la base des champs d'en-tête et des points d'extrémité bien connus (/.well-known/jwks.json), esquisser la manière dont les clés sont distribuées et tournées.
5. Tester les classes de bogues connues.
   • Essayez la signature nulle / aucun si la bibliothèque ou la pile les supporte historiquement.
   • Effectuer des tentatives de confusion des clés HS/RS lorsque les alliés ne sont pas verrouillés.
   • Sonde enfant pour la traversée des répertoires ou l'inclusion de fichiers.
   • Tenter l'injection de JWK intégré lorsque la spécification le permet mais que l'implémentation ne le contraint pas.
6. Ensuite, et seulement ensuite, passez aux tentatives d'exploitation complète. À ce stade, vous devez savoir précisément ce que vous essayez de prouver, et ne pas vous contenter de lancer des charges utiles sur une boîte noire.

Dans ce processus, le décodage de la signature web json constitue la couche d'observabilité pour le reste de votre méthodologie d'attaque.

Intégration du décodage des signatures web json dans un pipeline de pentest piloté par l'IA (Penligent.ai)

L'analyse manuelle fonctionne pour un seul engagement ; à grande échelle, les équipes ont besoin de quelque chose de plus proche d'un pipeline. Une plateforme assistée par l'IA comme Penligent.ai peut intégrer le décodage des signatures web json directement dans ses phases de reconnaissance et d'exploitation.

Dans une configuration type, la plateforme ingère le trafic HTTP à partir d'un navigateur sandbox ou d'un proxy, extrait automatiquement les jetons candidats et effectue un décodage JWS en masse sur les en-têtes et les charges utiles. L'agent d'intelligence artificielle regroupe ensuite les jetons en fonction de l'émetteur, de l'algorithme et des indices clés, en recherchant des anomalies telles que la diversité inattendue des algorithmes, les enfant ou des combinaisons de revendications inhabituelles.

Une fois cette base construite, le moteur d'attaque de Penligent peut automatiquement exécuter des playbooks JWT / JWS : tentatives de signature nulle, scénarios de confusion d'algorithme, JWK ou JWS intégrés, etc. jku les abus et les sondes connues inspirées des CVE. Au lieu de laisser ces vérifications à la mémoire d'un humain, le système les traite comme des cas de test répétables qui s'exécutent sur chaque cible, en renvoyant les résultats dans une liste de risques fondée sur des preuves et dans un rapport lisible par une machine.

Pour les ingénieurs en sécurité qui mettent en place une capacité interne d'"équipe rouge d'IA", le décodage des signatures web json dans un tel pipeline automatisé est souvent l'un des éléments les plus utiles de la plomberie de bas niveau.

Liste de contrôle du durcissement et autres lectures

Si votre travail quotidien consiste à émettre ou à vérifier des jetons JWS / JWT, vous pouvez considérer qu'il s'agit d'une barre minimale :

• Appliquer une liste stricte, côté serveur, d'algorithmes autorisés ; ne jamais lire de données sur le serveur. alg d'un jeton non approuvé en tant que politique.
• Séparer les clés entre les signatures asymétriques et les secrets HMAC ; ne jamais réutiliser une clé publique RSA comme clé HMAC.
• Désactivation permanente aucun dans les bibliothèques de production et rejette tout jeton qui en fait la publicité.
• Traiter tous les champs d'en-tête (enfant, jku, jwk, x5u) en tant qu'entrée non fiable et les valider par rapport à un ensemble de clés épinglées ou à une liste blanche.
• Veillez à ce que vos bibliothèques JWT soient corrigées ; examinez régulièrement les CVE comme CVE-2015-9235, CVE-2018-1000531, CVE-2023-48238 et CVE-2024-54150 pour voir si votre pile est affectée. (Laboratoire de Swissky)
• Ajouter des tests de régression qui exercent explicitement des scénarios de non-confusion/confusion d'algorithme.

Pour aller plus loin, ces références en langue anglaise méritent d'être mises en signet et de faire l'objet d'un lien à partir de vos runbooks internes :

• Le noyau [JSON Web Signature (JWS) RFC 7515] de l'IETF. (IETF Datatracker)
• Section de l'OWASP sur [Testing JSON Web Tokens] dans le Web Security Testing Guide. (Fondation OWASP)
• Les laboratoires de la Web Security Academy de PortSwigger sur les [attaques JWT] et la [confusion des algorithmes]. (PortSwigger)
• L'article classique de Tim McLean sur Auth0 [vulnérabilités critiques dans les bibliothèques de jetons Web JSON]. (Auth0)
• L'évolution du projet [JWT Best Current Practices] du groupe de travail OAuth de l'IETF. (IETF)

Utilisé correctement, le décodage de la signature web json n'est pas seulement une commodité de débogage ; c'est la porte d'entrée d'une méthode systématique de compréhension, d'attaque et de renforcement du tissu d'authentification de vos applications.