Une attaque de redirection OAuth 2 se produit lorsqu’une application malicieuse parvient à authentifier des utilisateurs auprès d’un serveur d’autorisation tiers en se faisant passer pour une autre application déclarée sur ce serveur d’autorisation. De ce fait, l’application malicieuse utilise frauduleusement un serveur d’autorisation qui a la confiance des utilisateurs. Elle peut ainsi récupérer le code d’autorisation et l’échanger contre des jetons d’accès valides. Ce faisant, cette applications aura accès aux données des utilisateurs, mais pourra aussi utiliser ces jetons pour accéder à des ressources protégées.
Une attaque de redirection OAuth 2 exploite l’URL de redirection de OAuth2. Les clients publics OAuth2 sont les plus vulnérables.
Lorsqu’un client OAuth2 correspondant à une interface utilisateur est enregistré dans un serveur d’autorisation, une ou plusieurs URLs de redirection sont renseignées pour le client Ces URLs indiquent au serveur OAuth où est-ce que l’utilisateur peut être redirigé après son authentification. L’URL exacte de redirection est inclus par le client lors de la requête d’authentification et doit être compatible avec les URLs renseignées préalablement dans le serveur d’autorisation.
Toute requête d’authentification utilisant une URL de redirection incompatible avec l’URL renseignée sur le serveur OAuth2 est rejetée par le serveur d’autorisation. C’est un mécanisme de sécurité. Mais ce mécanisme fonctionne à condition que l’URL de redirection suffisamment restrictive. A défaut, une application malicieuse qui possède une URL compatible avec l’URL de redirection d’une application existante pourra se faire passer pour cette application auprès du serveur d’autorisation.
Un client public s’exécute sur un appareil accessible à l’utilisateur. Pour cela, il dispose d’un client_id mais pas de secret. Ainsi le SA ne peut pas authentifier une telle application. Par conséquent, le SA s’appuie sur trois informations pour autoriser l’interaction avec le client publique: le client_id, l’URL de redirection, et l’origine de la requête. L’origine de la requête est aussi une URL et partage les mêmes risques que l’URL de redirection.
Pour usurper un client publique, deux conditions sont donc à remplir:
Trouver le client_id de l’application déclarée dans le Serveur d’Autorisation. Cette condition est facile à remplir: le client_id d’un client public se trouve dans le code qui s’exécute sur l’appareil de l’utilisateur.
Utiliser une URL de redirection compatible avec l’URL déclarée dans le Serveur d’Autorisation pour ce client public. Cela est trivial dans certains cas, par exemple si l’URL de redirection déclaré dans le Serveur d’Autorisation est “*”, localhost. L’utilisation de regex permissif pose aussi un risque. “Path traversal” et pollution HTTP sont aussi des techniques utilisées.
Une fois ces conditions remplies, l’application malicieuse pourra utiliser le client_id et sa propre URL pour la requête d’authentification. Une fois authentifié, les utilisateurs seront redirigés vers l’application malicieuse.