Un workflow pratique de pentest JWT
Une séquence éprouvée pour tester les JWT: collecte, décodage, claims, clés, replay et rapport.
Un bon pentest JWT n’est pas un sac d’astuces lancées au hasard contre un jeton. C’est un workflow. Tu collectes des jetons issus de vrais flux, classes les émetteurs et audiences, comprends où la vérification se produit, puis testes des modes d’échec précis avec des preuves. Le but n’est pas de prouver que les JWT font peur. Le but est de montrer où cette implémentation fait confiance à la mauvaise chose.
Collecte et inventaire
Commence par capturer les tokens de login, refresh, réinitialisation de mot de passe, liens d’invitation, APIs mobiles, upgrades websocket et requêtes en arrière-plan. Mets-les dans une table avec émetteur, audience, algorithme, kid, durée de vie, scopes et endroits où chaque token est accepté. Ne colle pas de tokens production bruts dans des notes partagées. Stocke des en-têtes et payloads expurgés, et garde les secrets dans le coffre de test.
Décode avant d’attaquer. Beaucoup de constats apparaissent dans les claims: longues durées, absence de aud, scopes larges, identifiants tenant, flags d’email vérifié ou champs debug qui ne devraient pas quitter l’émetteur. Compare les tokens de deux utilisateurs et deux tenants. Les différences révèlent souvent le modèle d’autorisation plus vite que le code source.
Tests de signature et de clés
Teste le pinning d’algorithme, alg: none, la confusion HS256 contre RS256, les kid inconnus, les kid dupliqués et le cache JWKS. Change une variable à la fois. Garde exp, iss et aud valides sauf si tu les testes. Si chaque token modifié reçoit le même rejet précoce, c’est une preuve utile. Si des endpoints échouent différemment, cartographie cette séparation.
Abus de claims et autorisation
Modifie sub, tenant_id, org_id, role, scope et les feature flags. Essaie l’accès inter-tenant avec un token valide peu privilégié. Pour GraphQL, teste l’autorisation au niveau des resolvers, pas seulement l’endpoint HTTP. Pour les téléchargements, sépare création d’URL signée et récupération réelle du fichier. Beaucoup de systèmes autorisent l’un et oublient l’autre.
Replay et cycle de vie
Vérifie si le logout révoque quelque chose côté serveur. Réutilise d’anciens refresh tokens après rotation. Teste des tokens expirés juste dedans et juste hors de la dérive acceptée. Essaie des tokens après changement de mot de passe, reset MFA, retrait de rôle et désactivation utilisateur. Les bugs de cycle de vie sont souvent plus exploitables que les erreurs crypto exotiques, car ils suivent les timelines réelles des attaquants.
Bien rédiger le rapport
Un bon rapport indique la propriété exacte modifiée, l’endpoint, le résultat attendu, le résultat réel et l’impact. Évite de déverser les tokens. Inclue des étapes sûres avec payloads expurgés et timestamps. La remédiation est souvent précise: fixer RS256 pour l’émetteur X, rejeter kid inconnu sans fetch illimité, revérifier la propriété tenant sur la route Y.