Quel est le but de la vérification OAuth 2.0 redirect_uri?
Le mécanisme de code d'autorisation de la spécification OAuth 2.0 inclut la vérification de l'URI de redirection depuis le site vers lequel vous redirigez. Voir étapes D et E dans la section 4.1 de la spécification . En outre, - section 4.1. décrit en détail que le client redirigé vers doit transmettre redirect_uri, et qu'il doit correspondre à celui de la demande d'autorisation initiale.
Je ne peux penser à aucun vecteur d'attaque atténué par le fait qu'il fasse partie du protocole. Pourquoi cette vérification de redirect_uri est-elle nécessaire?
En ne validant pas le redirect_uri an OAuth peut être utilisé comme vecteur de phishing idéal. Le redirect_uri est une adresse utilisée par les fournisseurs OAuth comme emplacement de livraison du access_token au moyen d'une redirection de navigateur. Le fournisseur populaire OAuth Facebook a rencontrénombreuses vulnérabilités concernant la redirection OAuth).
Dans cette attaque, l'attaquant présente à la victime une URL vers un portail d'authentification auquel elle fait confiance (comme Facebook), et en utilisant ce portail d'authentification, le jeton d'accès secret de la victime est remis à un serveur HTTP contrôlé par l'attaquant.
L'authentification est une question d'intention, inciter un utilisateur à autoriser l'accès à une ressource non intentionnelle est une vulnérabilité.
Modifié sur la base des commentaires. Je pensais auparavant que l'OP faisait référence à la validation redirect_uri lors de la demande d'autorisation, et lié à un exemple d'attaque ici . J'ai mis à jour la réponse ci-dessous.
TL; DR: Si une URL de redirection statique doit être enregistrée et est strictement mise en correspondance par le fournisseur, je ne pense pas que le redirect_uri serait requis lors de la demande de jeton d'accès.
Les conditions d'enregistrement (3.1.2.2) indiquent que l'URI de redirection doit être enregistré. Cependant, tous les fournisseurs n'effectuent pas de correspondances exactes de l'URI de redirection, bien que la spécification l'exige. La spécification OAuth essaie plusieurs contre-mesures pour se prémunir contre ces possibilités, avec l'exigence de liaison du code d'autorisation redirect_uri <-> décrite dans le Threat Model and Security Considersations RFC (5.2.4.5) .
Par exemple, GitHub correspondait aux préfixes d'URL, ce qui a conduit à l'attaque décrite ici par Egor Homakov. En particulier, les bogues 1 et 2 permettaient à un attaquant d'utiliser un URI de redirection sur liste blanche pour obtenir un code, puis d'utiliser ce code pour terminer le flux de rappel et accéder au compte de la victime. Dans ce cas, le client (Gist) a envoyé l'URI de redirection correcte au fournisseur (GitHub) et GitHub n'aurait pas accordé le jeton d'accès s'il avait vérifié que l'URI de redirection était le même que celui utilisé lors de la demande d'autorisation:
Il était imparfait: quelle que soit la redirect_uri envoyée par le client pour obtenir un jeton, le fournisseur a répondu avec un access_token valide.
L'attaquant pourrait détourner le code d'autorisation émis pour un redirect_uri "qui fuit", puis appliquer le code divulgué lors du rappel du client réel pour se connecter au compte de la victime.
Pour résumer, le redirect_uri est requis lors de l'obtention d'un jeton d'accès pour garantir qu'un code divulgué depuis une redirection vers une page dans laquelle l'attaquant peut insérer du code ne compromet pas immédiatement le flux OAuth. A more un aperçu complet du vecteur d'attaque est décrit ici par Egor également:
L'attaque est simple: trouvez une page qui fuit sur le domaine du client, insérez une image interdomaine ou un lien vers votre site Web, puis utilisez cette page comme redirect_uri. Lorsque votre victime chargera une URL spécialement conçue, elle l'enverra à leaking_page? Code = CODE et l'agent utilisateur de la victime exposera le code dans l'en-tête du référent.
Vous pouvez maintenant réutiliser le code d'autorisation divulgué sur le redirect_uri réel pour vous connecter au compte victime.
Correction: la redirect_uri flexible est une mauvaise pratique. Mais si vous en avez besoin, stockez redirect_uri pour chaque code que vous émettez et vérifiez-le lors de la création de access_token.
Comme l'a dit Egor, lien 1 :
tous les exploits oauth sont basés sur la falsification du paramètre redirect_uri.
et lien 2 :
Vecteur 2. Si la spécification a été implémentée correctement, la falsification de redirect_uri vers d'autres valeurs "fuite" est inutile. Parce que pour obtenir un jeton d'accès, vous devez envoyer la valeur redirect_uri avec les identifiants client. Si redirect_uri réel était "fuite" et différent de vrai redirect_uri, le client ne pourra pas obtenir access_token pour ce code.
redirect_uri est le rappel pour que le Client reçoive Authorization Code. Le client traite toute personne qui apporte le code comme le propriétaire de la ressource.
L'attaquant peut remplacer le redirect_uri avec un code malveillant à l'étape A pour obtenir le code. Ensuite, il peut reconstruire et déclencher l'URI pour détourner la session appartient au propriétaire de la ressource.
Cependant, chaque code a un redirect_uri il a été émis pour , c'est-à-dire que le code sera calculé en fonction de la pollution redirect_uri à l'étape C.
Notez que la demande à l'étape D est faite par le client. Il utilisera toujours la bonne forme de redirect_uri. Enfin, le serveur d'autorisation se révèle que le code ne correspond pas à l'uri, donc aucun jeton ne sera répondu à l'étape E.