Pour les non-initiés, un Décodage de la signature Web JSON L'opération semble triviale - un simple exercice de décodage Base64URL pour visualiser les revendications à l'intérieur d'un jeton. Mais pour les ingénieurs en sécurité, les testeurs de pénétration et les chercheurs en sécurité informatique, le "décodage" n'est que la phase de reconnaissance d'un champ de bataille beaucoup plus complexe.
Alors que les développeurs utilisent le décodage pour déboguer les flux d'authentification, les attaquants s'en servent pour faire de la rétro-ingénierie sur la logique de signature. L'écart entre le décodage un jeton et vérifiant c'est dans son intégrité que se sont logées les vulnérabilités de contournement d'authentification les plus dangereuses de l'histoire moderne de l'API.
Cet article dissèque l'anatomie des JWS, analyse les échecs de vérification critiques, y compris les CVE à fort impact, et explore la manière dont la sécurité pilotée par l'IA - comme les moteurs qui alimentent les JWS - peut être améliorée par l'utilisation d'une technologie de pointe. Penligent-modifie la façon dont nous contrôlons ces mécanismes cryptographiques.
L'anatomie d'un JWS : Plus qu'une simple base64
Avant d'analyser les exploits, nous devons nous aligner sur la structure définie dans RFC 7515. Une signature Web JSON (JWS) représente un contenu sécurisé par une signature numérique ou un code d'authentification de message (MAC).
Une chaîne JWS compacte se compose de trois parties séparées par des points (.):
En-tête.Charge utile.Signature
La logique de décodage
Lorsque vous effectuez une décodage de la signature web jsonvous convertissez essentiellement les deux premiers segments du format Base64URL en JSON.
Voici une implémentation brute en Python pour les chercheurs en sécurité qui préfèrent l'interface de programmation plutôt que les outils en ligne qui pourraient enregistrer des jetons sensibles :
Python
`import sys import json import base64
def padding_fix(data) : missing_padding = len(data) % 4 if missing_padding : data += '=' * (4 - missing_padding) return data
def decode_jws(token) : try : header_b64, payload_b64, signature_b64 = token.split('.')
header = json.loads(base64.urlsafe_b64decode(padding_fix(header_b64)))
payload = json.loads(base64.urlsafe_b64decode(padding_fix(payload_b64)))
return header, payload
except ValueError:
print("[-] Invalid Token Format")
sys.exit(1)
Contexte d'utilisation
header, payload = decode_jws(sys.argv[1])
print(json.dumps(header, indent=2))`
La sortie d'une opération de décodage révèle généralement les métadonnées qui dictent la manière dont la vérification est effectuée. devrait se produisent. Ces métadonnées sont la cible principale des attaquants.
| Paramètre d'en-tête | Description | Implications en matière de sécurité |
|---|---|---|
alg | Algorithme (par exemple, HS256, RS256) | Indique la primitive cryptographique. Cible principale des attaques de déclassement. |
type | Type de jeton (par exemple, JWT) | Souvent ignoré, mais peut être utilisé pour la confusion des types. |
enfant | ID clé | Indication de la touche à utiliser. Peut être manipulé pour Traversée de répertoire ou Injection SQL dans de rares cas. |
jku / x5u | URL de la clé Web JSON | Pointe vers l'URL de la clé publique. Cible du SSRF ou de l'hébergement de clés malveillantes. |
Le fossé "décodage-vérification" : là où se trouvent les vulnérabilités
Le problème principal est que de nombreuses bibliothèques et implémentations personnalisées découplent le système de gestion de l'information du système de gestion de l'information du système de gestion de l'information. décoder de l'étape vérifier pas. Une application peut décoder l'en-tête pour lire l'élément alg et utilise ensuite ces données contrôlées par l'utilisateur pour décider de la manière de vérifier la signature.
1. Le contournement de l'algorithme "Aucun
C'est le "Hello World" des exploits de JWS, mais il persiste dans les systèmes existants. Si l'implémentation d'un backend s'appuie sur la méthode alg du jeton décodé pour déterminer la logique de vérification, un attaquant peut modifier le jeton :
- Décoder l'en-tête.
- Changer
algàaucun(ouAucun,AUCUN). - Dénuder la signature.
Si la bibliothèque prend en charge aucun (destiné au débogage) et qui n'établit pas de liste blanche d'algorithmes, la vérification de la signature est entièrement ignorée.
2. Confusion d'algorithmes (Confusion de clés)
Il s'agit d'une attaque plus sophistiquée. Elle se produit lorsqu'un serveur prend en charge les signatures symétriques (HMAC) et asymétriques (RSA/ECDSA), mais ne parvient pas à valider celle qui est utilisée pour une clé spécifique.
- Scénario : Le serveur attend un jeton RS256 (signé avec une clé privée, vérifié avec une clé publique).
- Attaque : L'attaquant effectue une décodage de la signature web json, changements
algàHS256(HMAC), et signe le jeton à l'aide de l'algorithme Clé publique comme secret HMAC. - Résultat : Comme la clé publique est souvent disponible pour le client (ou facilement accessible), l'attaquant peut falsifier une signature valide que le serveur vérifie à l'aide de sa propre clé publique (en la traitant comme un secret HMAC).
Étude de cas : CVE-2022-21449 ("Psychic Paper")
Si la confusion des algorithmes est un défaut de logique, certaines vulnérabilités existent au plus profond de la mise en œuvre cryptographique elle-même.
CVE-2022-21449 (CVSS 7.5), surnommée "Psychic Paper", a affecté l'implémentation des signatures ECDSA par Java. C'est un excellent exemple de la raison pour laquelle la simple validation de l'existence d'une "signature" est insuffisante.
Le mécanisme
Dans l'ECDSA, la vérification implique une équation mathématique : $v = R'$ (simplifiée). La vulnérabilité réside dans la méthode Java ECDSA où si les parties de la signature $r$ et $s$ sont toutes deux réglées sur 0la logique de vérification renverrait à tort vrai pour tous charge utile.
Un attaquant pourrait :
- Décoder un JWS légitime.
- Modifier la charge utile (par ex,
{"admin" : true}). - Construire une signature où $r=0$ et $s=0$.
- L'envoyer à un backend basé sur Java (exécutant Java 15, 16, 17 ou 18).
Le serveur vérifierait la validité de la signature, ce qui permettrait de contourner complètement l'authentification. Cela montre que même les bibliothèques standard et largement utilisées ne sont pas à l'abri de défaillances catastrophiques.
L'audit des JWS piloté par l'IA : L'approche fondée sur la négligence
L'analyse manuelle des jetons JWS est efficace pour les exploits individuels, mais les architectures modernes de microservices utilisent souvent des centaines de clés, de politiques de rotation et de configurations d'algorithmes différentes. Un ingénieur ne peut pas manuellement décodage de la signature web json et tester toutes les permutations d'injection d'en-tête, de confusion de clé et de contournement spécifique à la bibliothèque sur toute une surface d'attaque.
C'est là que les tests de pénétration automatisés pilotés par l'IA deviennent essentiels.
Penligent exploite les grands modèles de langage (LLM) et l'apprentissage par renforcement pour automatiser cette profondeur de test. Contrairement aux scanners traditionnels qui utilisent des regex statiques pour rechercher les mauvaises chaînes de caractères connues, le moteur de Penligent :
- Décodage contextuel : Il intercepte le trafic, décode les jetons JWS et comprend le contexte (par exemple, "Ce jeton est utilisé pour la passerelle de paiement, pas seulement pour la connexion").
- Génération de charges utiles adaptatives : Il ne se contente pas d'essayer
alg : aucun. Il analyse les réponses d'erreur du serveur pour en déduire la bibliothèque d'arrière-plan. S'il détecte un environnement Java, il peut tenter des variantes de CVE-2022-21449. S'il voitenfantil recherche l'injection de code SQL ou l'injection de commande par l'intermédiaire de Key ID. - Analyse du flux logique : Penligent peut identifier si un jeton est correctement vérifié dans un point de terminaison mais simplement décodé et de confiance sans vérification dans un microservice secondaire - une faille architecturale courante.
En intégrant l'analyse intelligente des JWS, Penligent va au-delà de la simple analyse des vulnérabilités et entre dans le domaine de l'analyse de la sécurité. l'équipe rouge autonomeLa mise en œuvre de la cryptographie doit être robuste à la fois contre les CVE connus et les failles logiques de type "zero-day".
Lignes directrices sur la trempe à l'intention des ingénieurs
Pour sécuriser les applications contre les attaques JWS, nous devons passer de la "confiance implicite" à la "vérification explicite".
1. Appliquer la liste blanche des algorithmes
Ne vous fiez jamais à la alg du jeton décodé pour déterminer la méthode de vérification. Coder en dur l'algorithme attendu dans votre vérificateur.
JavaScript
// Approche sécurisée (bibliothèque Node.jose) const verified = await jose.jwtVerify(token, secretKey, { algorithms : ['RS256'], // Liste blanche explicite UNIQUEMENT RS256 }) ;
2. Valider le enfant (Key ID) STRICTEMENT
Si votre configuration utilise des clés multiples (JWKS), assurez-vous que le paramètre enfant correspond à une clé de votre liste blanche. Ne pas passer l'en-tête enfant directement à une requête de base de données ou à un appel au système de fichiers.
3. Utiliser les bibliothèques modernes
Évitez d'écrire vos propres wrappers cryptographiques. Utilisez des bibliothèques éprouvées comme jose (Node.js), PyJWT (Python), ou jjwt (Java). Toutefois, assurez-vous d'être abonné aux bulletins de sécurité pour ces bibliothèques.
4. Séparer le décodage de la vérification (logiquement)
Comprendre que décodage de la signature web json est pour affichage (interface utilisateur, journalisation). Vérifier est pour autorisation. N'utilisez jamais les données décodées pour la logique commerciale avant que l'étape de vérification ne soit renvoyée vrai.
Conclusion
La capacité à décodage de la signature web json est une compétence fondamentale, mais elle ne fait qu'effleurer la surface. Pour l'ingénieur en sécurité, le JSON brut est une carte des mauvaises configurations potentielles. De l'algorithme classique "None" aux contournements mathématiques tels que CVE-2022-21449, l'intégrité du web repose sur une vérification rigoureuse, et pas seulement sur un décodage réussi.
Au fur et à mesure que la complexité des applications augmente, l'utilisation d'outils alimentés par l'IA tels que le Penligent L'automatisation de la détection de ces subtiles failles cryptographiques devient une nécessité pour assurer la sécurité de l'entreprise.
Références :
