Attaque par relais inter-services de token
| Gravité | Élevée |
|---|---|
| Classifications | |
| Catégorie OWASP | OWASP API2:2023 Broken Authentication |
Cette vulnérabilité survient lorsqu’un JSON Web Token (JWT) est signé par le même service (ex. un fournisseur d’identité social) mais que l’application qui le reçoit ne vérifie pas le claim iss (émetteur) et/ou aud (audience). De nombreux fournisseurs d’identité utilisent la même paire de clés de signature pour tous leurs clients. Si une application ne vérifie que la signature mais pas le claim aud, un attaquant peut créer son propre projet chez le même fournisseur, obtenir un token valablement signé pour son propre projet, et le « relayer » vers l’application victime. L’application victime verra une signature valide provenant d’un fournisseur de confiance et acceptera le token à tort.
Services impactés
Section titled “Services impactés”Fournisseurs d’identité sociale
Section titled “Fournisseurs d’identité sociale”La plupart des fournisseurs d’identité sociale (Google, Facebook, Microsoft, Apple) utilisent des paires de clés partagées. Vous devez vérifier le claim aud pour vous assurer que le token était destiné à votre application.
Services IAM / d’autorisation
Section titled “Services IAM / d’autorisation”Des services comme Firebase ou Google Identity Platform utilisent aussi des clés partagées. iss et aud doivent tous deux être vérifiés.
Exemple
Section titled “Exemple”Un attaquant crée un projet chez le même fournisseur que la victime et obtient un token :
{ "iss": "https://accounts.google.com", "aud": "attacker-project-id.apps.googleusercontent.com", "sub": "user-to-impersonate", "email": "victim@example.com"}Si l’application victime (avec client_id = victim-project-id) vérifie seulement que le token est signé par Google, elle acceptera ce token, permettant à l’attaquant d’usurper l’identité de la victime.
Comment tester ?
Section titled “Comment tester ?”Vous pouvez utiliser jwtop decode pour inspecter les claims iss et aud des tokens que vous recevez :
jwtop decode [token]Pour tester cette vulnérabilité :
- Créez un second projet avec le même fournisseur d’identité.
- Obtenez un token valide pour ce second projet.
- Envoyez-le à l’API de votre projet original.
- Si l’API accepte la requête, elle est vulnérable aux attaques par relais inter-services.
Quel est l’impact ?
Section titled “Quel est l’impact ?”Un attaquant peut usurper l’identité de n’importe quel utilisateur possédant un compte chez le fournisseur d’identité partagé. Cela mène à une prise de contrôle complète de compte et à un accès non autorisé.
Comment corriger ?
Section titled “Comment corriger ?”- Vérifiez le claim
aud: assurez-vous qu’il correspond au Client ID ou à l’identifiant de votre application. - Vérifiez le claim
iss: assurez-vous qu’il correspond à l’URL d’émetteur attendue. - Utilisez des bibliothèques standard : la plupart des bibliothèques JWT fournissent un support intégré pour vérifier ces claims. Assurez-vous qu’il est activé et correctement configuré.