Burp + JWT et OAuth pas-à-pas : analyser et altérer les tokens (2026)

📍 Article principal du cluster : Burp Suite : le guide pratique 2026
Cet article fait partie du cluster « Burp Suite 2026 ». Pré-requis Repeater : Repeater pas-à-pas.

Cadre éthique préalable. Les attaques décrites se font sur PortSwigger Academy (modules « JWT » et « OAuth » — gratuits), sur des labs maison, ou dans le scope strict d’un programme bug bounty officiel. Manipuler les tokens d’un service tiers sans autorisation est une intrusion. Le rappel n’est pas formel — c’est précisément le genre de tests qui peuvent passer pour de la curiosité innocente et qui finissent en plainte pénale.

JWT et OAuth sont devenus omniprésents en 2026 (informations vérifiées en avril 2026, susceptibles d’évoluer ; vérifier la source officielle avant toute décision technique) : authentification d’applications mobiles, SSO interne, APIs REST et GraphQL, intégrations B2B. Mauvaise nouvelle : leurs implémentations contiennent régulièrement des défauts critiques. Bonne nouvelle : Burp Suite, avec l’extension JWT Editor, devient l’outil de choix pour les tester. Ce tutoriel pas-à-pas couvre les classes d’attaques principales — alg=none, key confusion, JWK injection, signing key exposure pour JWT ; redirect_uri abuse, scope upgrade, state CSRF pour OAuth.

Prérequis

• Burp Suite installé, Proxy fonctionnel, Repeater maîtrisé.
• Extension JWT Editor installée depuis le BApp Store (gratuite, fonctionne sur Community).
• Compte gratuit PortSwigger Academy pour les modules JWT et OAuth.
• Notions cryptographie : HMAC vs RSA, signature numérique, clés publiques/privées.
• Niveau : intermédiaire à avancé.
• Temps estimé : 90 minutes.

Étape 1 — Comprendre la structure d’un JWT

Un JSON Web Token est trois segments séparés par des points : header.payload.signature. Chaque segment est en base64url. Le header contient l’algorithme (« alg »: « HS256 » ou « RS256 ») et le type. Le payload contient les claims — userid, role, expiration, etc. La signature est calculée sur header+payload avec une clé secrète.

Exemple décortiqué :

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
.eyJzdWIiOiJ1c2VyMTIzIiwiaWF0IjoxNzE0NDc2ODAwfQ
.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Header : {"alg":"HS256","typ":"JWT"}
Payload : {"sub":"user123","iat":1714476800}
Signature : HMAC-SHA256(header+"."+payload, clé_secrète)

Cette structure est connue, donc lisible par n’importe qui. Le JWT n’est pas chiffré — il est juste signé. La sécurité repose entièrement sur la clé qui signe et la rigueur de la vérification côté serveur. C’est ce qui ouvre la voie à plusieurs classes d’attaques quand l’implémentation est faillible.

Étape 2 — Installer JWT Editor et inspecter un token

Dans Burp, Extensions → BApp Store, cherchez « JWT Editor » par PortSwigger Research. Cliquez Install. L’extension ajoute un onglet « JWT Editor » global et un nouveau formateur dans Repeater.

Pour inspecter un JWT capturé : Proxy history, ouvrez une requête contenant un Authorization header. Onglet Inspector latéral droit ou Repeater. Cliquez sur la ligne du JWT. Un panneau « JSON Web Token » s’ouvre, affichant header et payload décodés en clair. Vous voyez les claims, l’expiration, l’audience, l’algorithme. Cette vision claire est le point de départ de toute analyse.

Étape 3 — Attaque alg=none

L’attaque historique du JWT. Certaines bibliothèques ont implémenté la spec en supportant "alg": "none" — un JWT sans signature. Si le serveur accepte cet algorithme en validation, vous forgez n’importe quel JWT et il est accepté.

Sur PortSwigger Academy, ouvrez « JWT authentication bypass via unverified signature » (gratuit). Lancez le lab. Loguez-vous avec le compte fourni (wiener:peter). Capturez la requête authentifiée. Onglet Repeater. Sélectionnez le JWT, ouvrez l’éditeur JWT.

Modifiez le payload : "sub": "administrator". Modifiez le header : "alg": "none". Effacez la signature (la troisième partie du token, après le dernier point). Burp produit un JWT du type header.payload. (avec un point final mais rien après). Renvoyez la requête. Si le serveur accepte, vous êtes admin — le lab valide.

Cette vulnérabilité est classique sur des applications qui ont migré d’une lib à une autre sans bien comprendre la sémantique de l’option « algorithms allowed ». Toujours à tester en premier.

Étape 4 — Attaque JWT avec clé HMAC faible (brute force)

Si l’algorithme est HS256 (HMAC + SHA-256) et que la clé secrète est faible, vous pouvez la deviner par brute force. La validation utilise la même clé pour signer et vérifier — donc si vous trouvez la clé, vous forgez n’importe quel JWT.

Outil de référence : jwt_tool (Python, installable via pip ou clone GitHub). Avec une wordlist de clés faibles classiques (jwt.io secrets, GitHub leaks, common passwords) :

jwt_tool eyJhbGc... -C -d wordlist.txt

L’outil teste chaque clé contre la signature. Si une match, vous récupérez la clé et pouvez forger des JWT arbitraires. Sur PortSwigger Academy, le lab « JWT authentication bypass via weak signing key » illustre exactement ce flux. Wordlist gratuite à utiliser : SecLists/Misc/jwt-secrets.txt.

Une fois la clé en main, retour à JWT Editor dans Burp : créez un nouveau « Symmetric Key » avec la valeur récupérée, modifiez payload comme vous voulez, signez le JWT avec cette clé, renvoyez. Le serveur accepte parce que la signature est valide.

Étape 5 — Key confusion (RSA → HMAC)

Attaque sophistiquée mais très impactante. L’application utilise RS256 — algorithme asymétrique : signature avec clé privée, vérification avec clé publique. Vous obtenez la clé publique (souvent exposée sur /jwks.json ou similaire). Vous changez l’algorithme du JWT en HS256, et vous signez avec la clé publique RSA en tant que clé HMAC.

Si le serveur accepte HS256 en mode permissif, il vérifie le JWT avec « la clé qu’il a configurée » — qui est la clé publique RSA. Comme vous avez utilisé cette même clé publique comme HMAC pour signer, la signature valide. Vous venez de signer un JWT comme si vous aviez la clé privée — alors que vous n’avez que la publique.

Sur PortSwigger Academy, le lab « JWT authentication bypass via algorithm confusion » illustre. Récupérez la clé publique exposée sur l’endpoint JWK. Importez-la dans JWT Editor comme « PEM ». Convertissez-la en clé symétrique HMAC. Modifiez le JWT en alg=HS256 et signez avec cette clé symétrique. Renvoyez. Si le lab valide, l’app est vulnérable.

Cette attaque a touché plusieurs frameworks dans les années 2018-2020 et reste possible dans des implémentations héritées. Toujours à tester quand vous voyez RS256 en alg.

Étape 6 — JWK injection

Variante : certains JWT incluent dans leur header une clé publique sous forme de claim « jwk ». Le serveur, si mal codé, utilise cette clé pour vérifier la signature — au lieu d’utiliser sa propre clé configurée. Conséquence : vous fournissez votre propre clé, vous signez avec votre clé privée correspondante, le serveur valide.

JWT Editor automatise. Génère une paire de clés RSA (ou Elliptic Curve). Modifiez le header pour inclure un claim « jwk » avec votre clé publique. Modifiez le payload comme vous voulez. Signez avec votre clé privée. Renvoyez.

Le lab « JWT authentication bypass via jwk header injection » sur Academy guide cette attaque. Pour les implémentations qui supportent à la place « jku » (URL pointant vers une JWK), variante similaire avec un attaquant qui héberge ses clés sur un serveur qu’il contrôle. Le lab « jku header injection » couvre ce cas.

Étape 7 — OAuth : comprendre les flows

OAuth 2.0 standardise les flows d’autorisation pour qu’une app tierce accède à des ressources protégées sans manipuler le mot de passe utilisateur. Trois flows à connaître. Authorization Code (le plus sûr, recommandé pour les apps web et mobiles modernes avec PKCE). Implicit (déprécié, ne plus utiliser, mais encore présent en legacy). Client Credentials (server-to-server, pas d’utilisateur).

Chaque flow a son séquencement de requêtes et ses paramètres clés : client_id, redirect_uri, state, scope, code, access_token. Les vulnérabilités classiques émergent quand un de ces paramètres n’est pas validé sérieusement par le serveur d’autorisation ou l’application cliente.

Étape 8 — OAuth : abuse de redirect_uri

Vulnérabilité fréquente : le serveur d’autorisation valide le redirect_uri de manière laxiste. Vous changez le redirect_uri pour pointer vers un domaine que vous contrôlez, et la victime, après login, est redirigée vers vous avec son code d’autorisation dans l’URL. Vous utilisez ce code pour obtenir un access_token sur son compte.

Test typique en Repeater. Capturez la requête vers l’endpoint d’autorisation : /oauth/authorize?client_id=X&redirect_uri=https://app.exemple.com/callback&.... Modifiez en redirect_uri=https://attaquant.test/callback. Si le serveur valide quand même la requête, l’utilisateur final sera redirigé vers vous après auth.

Variantes à tester : sous-domaines (https://app.exemple.com.attaquant.test/), parameters tagged (https://app.exemple.com/callback#@attaquant.test/), open redirect dans l’app cliente combiné. Sur PortSwigger Academy, plusieurs labs OAuth sont gratuits — le module « Authentication vulnerabilities » et « OAuth 2.0 authentication vulnerabilities » couvrent ces cas.

Étape 9 — OAuth : scope upgrade

Une fois un access_token obtenu pour un scope limité (lecture seule par exemple), certains serveurs d’autorisation permettent de demander un nouveau token avec un scope plus large via le refresh token, sans revérifier l’autorisation utilisateur. Vous capturez le refresh, vous demandez un access_token avec scope=« admin », et selon la qualité du serveur, vous obtenez les permissions admin.

Test : capturez la requête de refresh token. Repeater. Modifiez le paramètre scope pour ajouter des permissions. Renvoyez. Si la réponse contient un nouveau access_token avec les nouvelles permissions, vous avez le finding.

Variante : certains apps clients stockent le scope dans un cookie ou localStorage, sans le revérifier sur chaque requête. Vous éditez ce cookie, vous obtenez un comportement « admin » côté frontend même si le backend ne le voit pas — ce qui expose des fonctions cachées qui sont l’angle d’attaque pour la suite.

Étape 10 — Vérifier votre maîtrise par les labs PortSwigger

Pour valider, complétez les labs gratuits : « JWT authentication bypass via unverified signature », « JWT authentication bypass via flawed signature verification », « JWT authentication bypass via weak signing key », « JWT authentication bypass via jwk header injection », « OAuth account hijacking via redirect_uri ».

Chaque lab prend 15 à 45 minutes. Si vous bouclez les cinq, vous tenez les attaques JWT et OAuth principales. Vous êtes prêt pour les vrais bug bounties — ce sont précisément les classes qui paient bien et restent fréquentes en production.

Erreurs fréquentes

Adaptation au contexte ouest-africain

Les apps mobiles et web ouest-africaines sérieuses utilisent largement JWT pour leur authentification, en particulier les fintech (Wave, fintechs neobank, plateformes de prêt P2P) et les marketplaces. Le pattern le plus fréquent : un access_token JWT court terme, un refresh_token longue durée. Plusieurs implémentations vues en mission présentent des défauts récurrents — pas de validation de la claim « aud », expiration trop longue, refresh non rotatif, secret HMAC dérivé d’une chaîne devinable.

Pour les intégrations OAuth des connexions sociales (Google, Facebook, Apple Sign-In) sur les apps locales, l’erreur classique est un redirect_uri trop permissif côté l’app — tous les sous-domaines acceptés, ou même un wildcard. Test rapide : capturez la requête vers l’authorize endpoint, modifiez le redirect_uri en sous-domaine fictif. Si l’app continue le flow, la vulnérabilité est confirmée.

Pour le rapport client local, formulez les findings dans un langage business : « un attaquant peut prendre le contrôle de n’importe quel compte utilisateur de votre app », plutôt que « JWT alg=none accepted ». Le décideur PME comprend l’impact, le détail technique reste en annexe pour son équipe ou son prestataire dev.

Tutoriels frères

• Repeater pas-à-pas — pour rejouer les requêtes avec tokens modifiés.
• Extensions BApp essentielles — JWT Editor + autres extensions auth.
• Workflow bug bounty — où JWT/OAuth findings paient le plus.

Pour aller plus loin

• 🔝 Retour au pilier : Burp Suite : le guide pratique 2026
• Module JWT PortSwigger Academy : portswigger.net/web-security/jwt
• Module OAuth PortSwigger Academy : portswigger.net/web-security/oauth
• jwt_tool : github.com/ticarpi/jwt_tool
• Suggestion : enchaînez avec Workflow bug bounty pour rentabiliser ces compétences.

FAQ

Toutes les apps modernes utilisent-elles JWT ?
Non. Beaucoup utilisent encore des sessions cookies classiques côté backend (Rails, Django, Laravel par défaut). JWT s’est imposé sur les apps SPA, mobiles, et architectures microservices. Vous tomberez sur les deux en mission.

Comment savoir si l’app que je teste utilise JWT ?
Cherchez dans Proxy history un header Authorization commençant par « Bearer eyJ… ». Le préfixe « eyJ » est la signature visuelle d’un JWT (base64url de « { »). Présent partout en pratique.

OAuth 2.1 change-t-il quelque chose ?
OAuth 2.1 standardise les bonnes pratiques de 2.0 — PKCE obligatoire pour Authorization Code, suppression d’Implicit, exigences strictes sur redirect_uri. Les implémentations qui suivent OAuth 2.1 sont moins vulnérables. Mais beaucoup d’apps en prod sont encore en OAuth 2.0 lax — votre cible, statistiquement.

Faut-il connaître la cryptographie pour ces tests ?
Pas en profondeur, mais comprendre la différence entre symétrique et asymétrique, signature et chiffrement, est indispensable. Sans ces bases, vous pouvez rejouer des recettes mais pas adapter aux cas non documentés. Les modules « Cryptography » de la PortSwigger Academy donnent ce qu’il faut.

JWT Editor est-il disponible sur Community ?
Oui, l’extension est gratuite et compatible Community. Toutes les attaques JWT décrites ici se font sur Community.

Mots-clés secondaires : Burp JWT, JWT Editor, alg=none, key confusion, OAuth pentest, redirect_uri abuse, jwk injection.