OAuth 2.0 Attack
hackingDéfinition
Les attaques sur OAuth 2.0 ciblent les vulnérabilités dans l'implémentation du protocole d'autorisation OAuth, largement utilisé pour les connexions sociales et les intégrations API. Des erreurs d'implémentation permettent de voler des tokens d'accès, d'usurper des identités, ou de pirater des comptes en détournant les flux OAuth.
Les vulnérabilités OAuth les plus critiques incluent : le state parameter manquant ou prévisible (permettant le CSRF sur le flux OAuth, forçant un utilisateur à lier son compte au compte de l'attaquant), les redirect_uri mal validés (permettant à l'attaquant de rediriger le code d'autorisation ou le token vers son propre serveur), les open redirects dans le chemin OAuth (permettant l'exfiltration du token via un redirect intermédiaire), et la réutilisation des authorization codes (si un serveur accepte le même code plusieurs fois).
L'attaque sur redirect_uri est particulièrement impactante : si le serveur OAuth valide le redirect_uri de manière insuffisante (par exemple, vérifie uniquement que le URI commence par le domaine enregistré), l'attaquant peut enregistrer https://victime.com/callback/../../../attaquant.com/steal ou exploiter un open redirect sur le domaine de la victime pour détourner le code d'autorisation.
D'autres attaques incluent : l'implicit flow token leakage (le token dans le fragment URL peut être exposé via le Referer header ou les logs des serveurs intermédiaires), les attaques de validation de claims JWT sur les tokens d'identité (algorithme 'none', validation insuffisante de l'issuer/audience), et les SSRF via des flux OAuth qui initialisent des connexions vers des URLs contrôlées par l'utilisateur.
Des outils comme Burp Suite Pro avec son module OAuth scanner, et des checklist OWASP Testing Guide pour OAuth facilitent l'audit systématique des implémentations OAuth dans les pentests d'applications web.
Fonctionnement
Attaque redirect_uri : l'attaquant trouve un open redirect sur victime.com (https://victime.com/redirect?url=https://attaquant.com), enregistre ou modifie l'application OAuth avec redirect_uri=https://victime.com/redirect?url=https://attaquant.com/steal. Quand la victime autorise l'application, le code d'autorisation est envoyé à victime.com/redirect qui redirige vers attaquant.com/steal avec le code dans le paramètre URL. L'attaquant échange le code contre un token d'accès au nom de la victime.
Exploitation offensive
Une exploitation OAuth réussie sur une application avec Sign-in with Google/Facebook donne généralement accès complet au compte de la victime sur l'application cible. L'absence du paramètre state (CSRF) permet de forcer l'association du compte de la victime au compte OAuth de l'attaquant ('account hijacking' via OAuth). Ces vulnérabilités sont fréquentes dans les programmes bug bounty.
Détection et mitigation
Valider strictement le redirect_uri contre une liste blanche exacte enregistrée. Rendre le state parameter obligatoire, aléatoire, et lié à la session. Utiliser PKCE (Proof Key for Code Exchange) pour les clients publics. Valider systématiquement issuer, audience, et expiration des JWT tokens. L'utilisation de bibliothèques OAuth certifiées plutôt que d'implémentations custom réduit les risques.
Articles liés
Expert en cybersécurité offensive et intelligence artificielle. Pentest, audit et développement IA sur-mesure.
Services
- Audit Infrastructure
- Audit Kubernetes
- Audit Microsoft 365
- Audit Sécurité Réseau
- Analyse de Risques
- Audit Active Directory
- Audit Application Web
- Audit Cloud (AWS/Azure/GCP)
- Audit Messagerie
- Audit API (OWASP Top 10)
- Audit DevSecOps & CI/CD
- Audit Code Source (SAST)
- Audit Postes de Travail
- Audit Sauvegarde & Résilience
- Audit OT/SCADA (IEC 62443)
- Développement IA
- Formations
Ressources
Projets & Outils
© 2026 Ayi NEDJIMI Consultants. Tous droits réservés.
Un projet cybersécurité ?
Expert dispo · Réponse 24h