Quelqu'un peut-il expliquer la vulnérabilité "Covert Redirect" dans OAuth et OpenID?
CNet rapporte que tous les sites OpenID et OAuth sont vulnérables à une attaque appelée "Covert Redirect". Qu'est-ce que cette attaque, comment cela fonctionne-t-il et à la fin utilisateur, comment puis-je atténuer le risque?
Ce n'est pas du tout une vulnérabilité de/in OAuth 2.0. Le problème a été exagérément exagéré et déformé par CNET et le Finder d'origine.
Voici en un mot: si votre site Web (example.com) implémente un point de terminaison de redirection ouvert - c'est-à-dire, implémente une URL qui redirigera le navigateur vers tout URL donnée dans les paramètres URL - ET votre redirection copie les paramètres URL de l'URL entrante vers l'URL de redirection sortante, il est alors possible pour des tiers d'exploiter cet artefact de votre site Web d'une grande variété de façons désagréables.
Pire cas: evil.com est en mesure d'obtenir le code d'authentification initialement destiné à votre site Web (exemple.com) et peut être en mesure d'utiliser ce code d'authentification pour extraire les informations utilisateur du fournisseur d'authentification (Google, Facebook, etc.) ou éventuellement prenez même le contrôle du compte de l'utilisateur sur votre site Web.
Evil.com pourrait-il prendre le contrôle du compte Google de l'utilisateur à l'aide de ce code d'accès? Non, car le code d'accès a été créé pour votre site, example.com, et ne fonctionne que là-bas.
C'est qui la faute? Bien à vous, pour avoir implémenté une redirection ouverte sur votre site. Ne blâmez pas Google, Facebook ou autres pour votre mauvaise mise en œuvre.
Il existe quelques cas d'utilisation légitimes pour avoir une redirection sur votre site. Le plus important est de rediriger le navigateur après la connexion à la page Web (sur votre site) que l'utilisateur avait initialement demandée. Il suffit de rediriger votre site Web vers les pages de votre site Web, sur votre domaine.
Comment le réparer? Demandez à votre point de terminaison de redirection (example.com/redirect? & Destination = ht.tp: //foo.com ...) de valider l'URL de destination. Autorisez uniquement les redirections vers les pages de votre site, dans votre domaine.
Plus d'informations sur mon blog: http://dannythorpe.com/2014/05/02/tech-analysis-of-serious-security-flaw-in-oauth-openid-discovered/
Mise à jour: Il existe un problème de redirection ouverte lors de l'utilisation de Facebook pour OAuth connexion utilisateur. Lorsque vous configurez la définition de votre application sur Facebook, assurez-vous de saisir l'URL de redirection spécifique à votre domaine dans le champ de redirection fourni. Facebook permet de laisser ce champ vide. S'il est laissé vide, Facebook lui-même agit comme une redirection ouverte lors du traitement des connexions des utilisateurs pour votre site Web.
Facebook devrait résoudre ce problème en ne permettant tout simplement pas de laisser le champ URL de redirection vide.
Comme d'autres l'ont dit, ce n'est pas une idée nouvelle. Eran Hammer (l'un des créateurs de la spécification Oauth 1.0, qui a démissionné du comité Oauth 2. ) a écrit un bon synopsis) de la vulnérabilité, il y a près de 3 ans. Sa description n'a reçu aucun logo de fantaisie ni aucune couverture médiatique sensationnelle.
http://hueniverse.com/2011/06/21/oauth-2-0-redirection-uri-validation/
Voici une vidéo Youtube que le Finder original a mis en place pour vous guider à travers la vulnérabilité: https://www.youtube.com/watch?v=HUE8VbbwUms .
OpenId et OAuth fournissent tous deux un champ qui permet à un site tiers de spécifier une redirection lorsque l'authentification est terminée et réussie. Par exemple, vous allez dans Good Reads, ils veulent que vous vous connectiez avec votre compte Facebook. Les bonnes lectures diront à Facebook: "Hé, lorsque l'utilisateur s'authentifie avec succès, redirigez-le vers http://goodreads.com ." La vulnérabilité est que certains de ces sites tiers autoriser les redirections à être spécifiées dans leurs URL ( http://google.com/redirect?url=http://attacker.com ) et ne peut pas les valider avant de rediriger l'utilisateur. Ainsi, un l'attaquant pourrait créer un lien "Connexion avec Facebook" pour un site valide comme Good Reads et pourrait spécifier que l'URL de redirection soit quelque chose comme http://goodreads.com/redirect?url=http://attacker.com (en supposant que Good Reads a fait ce type de redirection), votre fenêtre de connexion Facebook montrerait que Good Reads (un site parfaitement normal pour vous) souhaite s'authentifier auprès de Facebook, mais lorsque vous authentifier et rediriger vers Good Reads, si Good Reads ne valide pas l'URL de redirection, vous serez immédiatement redirigé vers http://attacker.com .
Le correctif consisterait à ce que des tiers valident les redirections, mais cela peut prendre un certain temps. L'autre chose est que CNet a rapporté que les attaquants pourraient être en mesure de voler des informations via ce petit échange, mais je ne suis pas sûr que ce soit possible. Quelqu'un d'autre peut commenter la question. Mais, amener un utilisateur sur un mauvais site est probablement assez bon pour lui.
Il s'agit d'une forme d'homme dans l'attaque du milieu où un site peut récupérer vos informations d'identification OpenID. Cela fonctionne parce que les sources d'openID (facebook, google, etc.) n'effectuent pas de vérifications suffisantes lorsque des requêtes openID sont envoyées.
En tant qu'utilisateur, vous ne pouvez rien y faire, tout ce que vous pouvez faire est de vous méfier de l'utilisation d'Oath et openID. Si un site auquel vous ne vous attendez pas à utiliser openID fait apparaître une fenêtre openID, ne le permettez pas. Si vous pensez que vos informations d'identification openID ont été capturées, accédez à la source d'authentification (facebook, google, etc.) et modifiez-la dès que possible.
http://tetraph.com/covert_redirect/
Depuis le site Web,
Covert Redirect est une application qui prend un paramètre et redirige un utilisateur vers la valeur du paramètre SANS SUFFISANCE de validation. C’est souvent le résultat de la confiance excessive d’un site Web envers ses partenaires.
Dans un autre mot, la vulnérabilité Covert Redirect existe parce qu'il n'y a pas de validation suffisante des URL redirigées qui appartiennent au domaine des partenaires.