* Travaillez-vous dans une **entreprise de cybersécurité** ? Voulez-vous voir votre **entreprise annoncée dans HackTricks** ? ou voulez-vous avoir accès à la **dernière version de PEASS ou télécharger HackTricks en PDF** ? Consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop) !
* Découvrez [**The PEASS Family**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFTs**](https://opensea.io/collection/the-peass-family)
* Obtenez le [**swag officiel PEASS & HackTricks**](https://peass.creator-spring.com)
* **Rejoignez le** [**💬**](https://emojipedia.org/speech-balloon/) [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe telegram**](https://t.me/peass) ou **suivez** moi sur **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Partagez vos astuces de piratage en soumettant des PR au** [**repo hacktricks**](https://github.com/carlospolop/hacktricks) **et au** [**repo hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
Dans cet article, nous nous concentrerons sur le flux le plus courant que vous rencontrerez aujourd'hui, qui est le [type de subvention de code d'autorisation OAuth 2.0](https://oauth.net/2/grant-types/authorization-code/). En substance, OAuth fournit aux développeurs un **mécanisme d'autorisation pour permettre à une application d'accéder à des données ou d'effectuer certaines actions contre votre compte, à partir d'une autre application** (le serveur d'autorisation).
Par exemple, supposons que le site web _**https://yourtweetreader.com**_ ait une fonctionnalité pour **afficher tous les tweets que vous avez jamais envoyés**, y compris les tweets privés. Pour ce faire, OAuth 2.0 est introduit. _https://yourtweetreader.com_ vous demandera d'**autoriser leur application Twitter à accéder à tous vos tweets**. Une page de consentement apparaîtra sur _https://twitter.com_ affichant les **autorisations demandées**, et qui est le développeur qui le demande. Une fois que vous avez autorisé la demande, _https://yourtweetreader.com_ sera **en mesure d'accéder à vos tweets en votre nom**.
* **propriétaire de la ressource** : Le `propriétaire de la ressource` est l'**utilisateur/entité** accordant l'accès à sa ressource protégée, telle que ses tweets de compte Twitter. Dans cet exemple, ce serait **vous**.
* **serveur de ressources** : Le `serveur de ressources` est le **serveur qui gère les demandes authentifiées** après que l'application a obtenu un `jeton d'accès` au nom du `propriétaire de la ressource`. Dans cet exemple, ce serait **https://twitter.com**
* **application cliente** : L'`application cliente` est l'**application qui demande l'autorisation** du `propriétaire de la ressource`. Dans cet exemple, ce serait **https://yourtweetreader.com**.
* **serveur d'autorisation** : Le `serveur d'autorisation` est le **serveur qui délivre les `jetons d'accès`** à l'`application cliente` **après avoir authentifié avec succès** le `propriétaire de la ressource` et obtenu l'autorisation. Dans l'exemple ci-dessus, ce serait **https://twitter.com**
* **client_id** : Le `client_id` est l'**identifiant de l'application**. Il s'agit d'un identifiant unique public, **non secret**.
* **client_secret** : Le `client_secret` est un **secret connu uniquement de l'application et du serveur d'autorisation**. Cela est utilisé pour générer des `jetons d'accès`.
* **response_type** : Le `response_type` est une valeur pour détailler **quel type de jeton** est demandé, tel que `code`
* **redirect_uri** : Le `redirect_uri` est l'**URL vers laquelle l'utilisateur est redirigé après la fin de l'autorisation**. Cela doit généralement correspondre à l'URL de redirection que vous avez précédemment enregistrée auprès du service
* **state** : Le paramètre `state` peut **persister les données entre la redirection de l'utilisateur vers le serveur d'autorisation et le retour**. Il est important que cela soit une valeur unique car il sert de **mécanisme de protection CSRF** s'il contient une valeur unique ou aléatoire par demande
* **code** : Ce `code` est le code d'autorisation reçu du `serveur d'autorisation` qui sera dans le paramètre de chaîne de requête "code" dans cette demande. Ce code est utilisé conjointement avec le `client_id` et le `client_secret` par l'application cliente pour récupérer un `jeton d'accès`
* **access_token** : Le `access_token` est le **jeton que l'application cliente utilise pour effectuer des demandes API** au nom d'un `propriétaire de la ressource`
* **refresh_token** : Le `refresh_token` permet à une application d'**obtenir un nouveau `jeton d'accès` sans demander à l'utilisateur**
1. Vous visitez [https://yourtweetreader.com](https://yourtweetreader.com) et cliquez sur le bouton "Intégrer avec Twitter".
2. [https://yourtweetreader.com](https://yourtweetreader.com) envoie une demande à [https://twitter.com](https://twitter.com) vous demandant, le propriétaire de la ressource, d'autoriser l'application Twitter de https://yourtweetreader.com à accéder à vos tweets. La demande ressemblera à :
5\. Ensuite, [https://yourtweetreader.com](https://yourtweetreader.com) prendra ce `code` et, en utilisant l'`client_id` et le `client_secret` de leur application, fera une demande depuis le serveur pour récupérer un `access_token` en votre nom, ce qui leur permettra d'accéder aux autorisations auxquelles vous avez consenti :
6\. Enfin, le flux est complet et [https://yourtweetreader.com](https://yourtweetreader.com) fera un appel API à Twitter avec votre `access_token` pour accéder à vos Tweets.
Maintenant, la partie intéressante ! Il y a de nombreuses choses qui peuvent mal tourner dans une implémentation OAuth, voici les différentes catégories de bugs que je vois fréquemment :
Le `redirect_uri` est très important car des données sensibles, telles que le `code`, sont ajoutées à cette URL après l'autorisation. Si le `redirect_uri` peut être redirigé vers un serveur **contrôlé par un attaquant**, cela signifie que l'attaquant peut potentiellement **prendre le contrôle du compte d'une victime** en utilisant le `code` lui-même et en accédant aux données de la victime.
La façon dont cela va être exploité va varier en fonction du serveur d'autorisation. **Certains** n'accepteront que le **même chemin exact de `redirect_uri` spécifié dans l'application cliente**, mais certains accepteront **n'importe quoi** dans le même domaine ou sous-répertoire de `redirect_uri`.
En fonction de la logique gérée par le serveur, il existe plusieurs techniques pour contourner un `redirect_uri`. Dans une situation où un `redirect_uri` est [https://yourtweetreader.com](https://yourtweetreader.com)/callback, celles-ci incluent :
* **client_uri** - URL de la page d'accueil de l'application cliente
* **policy_uri** - URL que l'application cliente Relying Party fournit afin que l'utilisateur final puisse lire comment ses données de profil seront utilisées.
* **tos_uri** - URL que l'application cliente Relying Party fournit afin que l'utilisateur final puisse lire les conditions d'utilisation de la Relying Party.
* **initiate_login_uri** - URI utilisant le schéma https qu'un tiers peut utiliser pour initier une connexion par le RP. Doit également être utilisé pour la redirection côté client.
Tous ces paramètres sont **optionnels selon les spécifications OAuth et OpenID** et ne sont pas toujours pris en charge sur un serveur particulier, il est donc toujours utile d'identifier quels paramètres sont pris en charge sur votre serveur.
Si vous ciblez un serveur OpenID, le point de découverte à \*\*`.well-known/openid-configuration`\*\* contient parfois des paramètres tels que "_registration\_endpoint_", "_request\_uri\_parameter\_supported_" et "_require\_request\_uri\_registration_". Cela peut vous aider à trouver le point de terminaison d'enregistrement et d'autres valeurs de configuration de serveur.
Comme mentionné dans ce rapport de chasse aux bugs [https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html](https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html), il est possible que l'URL de redirection soit **réfléchie dans la réponse** du serveur après que l'utilisateur s'authentifie, étant **vulnérable à XSS**. Charge utile possible à tester :
Très souvent, le **paramètre `state` est complètement omis ou utilisé de manière incorrecte**. Si un paramètre d'état est **inexistant**, ou une valeur statique qui ne change jamais, le flux OAuth sera très probablement **vulnérable aux attaques CSRF**. Parfois, même s'il y a un paramètre `state`, l'**application pourrait ne pas valider le paramètre** et une attaque réussira. La façon d'exploiter cela serait de passer par le processus d'autorisation sur votre propre compte, et de faire une pause juste après l'autorisation. Vous rencontrerez alors une demande telle que:
Après avoir reçu cette demande, vous pouvez **abandonner la demande car ces codes sont généralement à usage unique**. Vous pouvez ensuite envoyer cette URL à un **utilisateur connecté, et cela ajoutera votre compte à leur compte**. Au début, cela peut ne pas sembler très sensible car vous ajoutez simplement votre compte au compte d'une victime. Cependant, de nombreuses implémentations OAuth sont destinées à des fins de connexion, donc si vous pouvez ajouter votre compte Google qui est utilisé pour la connexion, vous pourriez potentiellement effectuer une **prise de contrôle de compte** en un seul clic, car la connexion avec votre compte Google vous donnerait accès au compte de la victime.
Vous pouvez trouver un **exemple** à ce sujet dans ce [**write-up CTF**](https://github.com/gr455/ctf-writeups/blob/master/hacktivity20/notes\_surfer.md) et dans la **boîte HTB appelée Oouch**.
J'ai également vu le paramètre d'état utilisé plusieurs fois comme une valeur de redirection supplémentaire. L'application utilisera `redirect_uri` pour la redirection initiale, mais ensuite le paramètre `state` comme une deuxième redirection qui pourrait contenir le `code` dans les paramètres de requête, ou le header referer.
Une chose importante à noter est que cela ne s'applique pas seulement aux situations de connexion et de prise de contrôle de compte. J'ai vu des erreurs de configuration dans :
* Les intégrations Slack permettant à un attaquant d'ajouter son compte Slack en tant que destinataire de toutes les notifications/messages
* Les intégrations Stripe permettant à un attaquant de remplacer les informations de paiement et d'accepter des paiements des clients de la victime
* Les intégrations PayPal permettant à un attaquant d'ajouter son compte PayPal au compte de la victime, ce qui déposerait de l'argent sur le compte PayPal de l'attaquant
L'un des autres problèmes les plus courants que je vois est lorsque les applications permettent de "Se connecter avec X" mais aussi un nom d'utilisateur/mot de passe. Il y a 2 façons différentes d'attaquer cela :
1. Si l'application ne **nécessite pas de vérification d'e-mail lors de la création de compte**, essayez de **créer un compte avec l'adresse e-mail de la victime et un mot de passe d'attaquant** avant que la victime ne se soit inscrite. Si la **victime** essaie ensuite de s'inscrire ou de se connecter **avec un tiers**, comme Google, il est possible que l'application effectue une recherche, voie que l'e-mail est déjà enregistré, puis **lie leur compte Google au compte créé par l'attaquant**. C'est une "pré-prise de contrôle de compte" où un attaquant aura accès au compte de la victime s'il l'a créé avant que la victime ne s'inscrive.
2. Si une **application OAuth ne nécessite pas de vérification d'e-mail**, essayez de vous inscrire avec cette application OAuth avec l'adresse e-mail de la **victime**. Le même problème que ci-dessus pourrait exister, mais vous attaqueriez dans l'autre sens et accéderiez au compte de la victime pour une prise de contrôle de compte.
Il est très important de reconnaître **lesquels des nombreux paramètres OAuth sont secrets**, et de les protéger. Par exemple, divulguer le `client_id` est parfaitement acceptable et nécessaire, mais divulguer le **`client_secret` est dangereux**. Si cela est divulgué, l'**attaquant** peut potentiellement **abuser de la confiance et de l'identité de l'application client de confiance pour voler les `access_tokens` des utilisateurs et les informations/accès privés pour leurs comptes intégrés**. Revenons à notre exemple précédent, un problème que j'ai vu est d'effectuer cette étape depuis le client, au lieu du serveur :
_5._ [_https://yourtweetreader.com_](https://yourtweetreader.com) _prendra ensuite ce `code`, et en utilisant l'`client_id` et le `client_secret` de leur application, fera une demande depuis le serveur pour récupérer un `access_token` en votre nom, ce qui leur permettra d'accéder aux autorisations auxquelles vous avez consenti._
**Si cela est fait depuis le client, le `client_secret` sera divulgué et les utilisateurs pourront générer des `access_tokens` au nom de l'application**. Avec un peu d'ingénierie sociale, ils peuvent également **ajouter plus de portées à l'autorisation OAuth** et tout cela semblera légitime car la demande viendra de l'application client de confiance.
Vous pouvez essayer de **bruteforcer le secret client** d'un fournisseur de services avec le fournisseur d'identité afin d'essayer de voler des comptes.\
Une fois que le client a le **code et l'état**, s'il est **reflété dans l'en-tête Referer** lorsqu'il navigue sur une autre page, alors il est vulnérable.
Le **code d'autorisation ne doit vivre que pendant un certain temps pour limiter la fenêtre de temps pendant laquelle un attaquant peut le voler et l'utiliser**.
Dans ce rapport de prime de bug: [**https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/**](https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/), vous pouvez voir que le **jeton** que **AWS Cognito** renvoie à l'utilisateur peut avoir **suffisamment de permissions pour écraser les données utilisateur**. Par conséquent, si vous pouvez **changer l'e-mail de l'utilisateur pour un e-mail d'utilisateur différent**, vous pourriez être en mesure de **prendre le contrôle** d'autres comptes.
### Deux liens et un cookie <a href="#bda5" id="bda5"></a>
Selon [**cet article**](https://medium.com/@metnew/why-electron-apps-cant-store-your-secrets-confidentially-inspect-option-a49950d6d51f), il était possible de faire ouvrir une page à une victime avec un **returnUrl** pointant vers l'hôte de l'attaquant. Cette information serait **stockée dans un cookie (RU)** et à une **étape ultérieure**, la **fenêtre de dialogue** demandera à l'**utilisateur** s'il veut donner accès à cet hôte d'attaquant.
Pour contourner cette fenêtre de dialogue, il était possible d'ouvrir un onglet pour initier le **flux Oauth** qui définirait ce cookie RU en utilisant le **returnUrl**, fermer l'onglet avant que la fenêtre de dialogue ne s'affiche, et ouvrir un nouvel onglet sans cette valeur. Ensuite, la **fenêtre de dialogue n'informera pas sur l'hôte de l'attaquant**, mais le cookie sera défini sur celui-ci, de sorte que le **jeton sera envoyé à l'hôte de l'attaquant** dans la redirection.
L'un des URL cachés que vous pouvez manquer est le **point d'extrémité d'enregistrement de client dynamique**. Pour authentifier avec succès les utilisateurs, les serveurs OAuth ont besoin de détails sur l'application cliente, tels que le "client_name", "client_secret", "redirect_uris", et ainsi de suite. Ces détails peuvent être fournis via une configuration locale, mais les serveurs d'autorisation OAuth peuvent également avoir un **point d'extrémité d'enregistrement spécial**. Cet endpoint est normalement mappé sur "/register" et accepte des requêtes POST avec le format suivant:
Il y a deux spécifications qui définissent les paramètres de cette requête: [RFC7591](https://tools.ietf.org/html/rfc7591) pour OAuth et [Openid Connect Registration 1.0](https://openid.net/specs/openid-connect-registration-1\_0.html#rfc.section.3.1).
Comme vous pouvez le voir ici, un certain nombre de ces valeurs sont transmises via des références d'URL et ressemblent à des cibles potentielles pour [Server Side Request Forgery](https://portswigger.net/web-security/ssrf). En même temps, la plupart des serveurs que nous avons testés ne résolvent pas immédiatement ces URL lorsqu'ils reçoivent une demande d'enregistrement. Au lieu de cela, ils **enregistrent simplement ces paramètres et les utilisent plus tard pendant le flux d'autorisation OAuth**. En d'autres termes, il s'agit plutôt d'une SSRF de deuxième ordre, ce qui rend la détection en boîte noire plus difficile.
* **logo\_uri** - URL qui fait référence à un **logo pour l'application cliente**. **Après avoir enregistré un client**, vous pouvez essayer d'appeler le point de terminaison d'autorisation OAuth ("/authorize") en utilisant votre nouveau "client\_id". Après la connexion, le serveur vous demandera d'approuver la demande et **peut afficher l'image de "logo\_uri"**. Si le **serveur récupère l'image par lui-même**, la SSRF devrait être déclenchée à cette étape. Alternativement, le serveur peut simplement inclure le logo via une **balise "\<img>" côté client**. Bien que cela ne conduise pas à une SSRF, cela peut conduire à une **XSS si l'URL n'est pas échappée**.
***jwks\_uri** - URL pour le document JSON Web Key Set \[JWK\] du client. Ce jeu de clés est nécessaire sur le serveur pour valider les demandes signées effectuées vers le point de terminaison de jeton lors de l'utilisation de JWT pour l'authentification du client \[RFC7523\]. Pour tester la SSRF dans ce paramètre, **enregistrez une nouvelle application cliente avec un "jwks\_uri" malveillant**, effectuez le processus d'autorisation pour **obtenir un code d'autorisation pour n'importe quel utilisateur, puis récupérez le point de terminaison "/token"** avec le corps suivant:
Si vulnérable, le **serveur devrait effectuer une requête HTTP serveur à serveur vers le "jwks\_uri"** fourni car il a besoin de cette clé pour vérifier la validité du paramètre "client\_assertion" dans votre demande. Ce sera probablement seulement une **vulnérabilité SSRF aveugle cependant**, car le serveur s'attend à une réponse JSON appropriée.
* **sector\_identifier\_uri** - Cette URL fait référence à un fichier avec un seul **tableau JSON de valeurs redirect\_uri**. Si pris en charge, le serveur peut **récupérer cette valeur dès que vous soumettez la demande d'enregistrement dynamique**. Si cela n'est pas récupéré immédiatement, essayez d'effectuer une autorisation pour ce client sur le serveur. Comme il doit connaître les redirect\_uris pour terminer le flux d'autorisation, cela forcera le serveur à faire une demande à votre sector\_identifier\_uri malveillant.
***request\_uris** - Un tableau des **request\_uris autorisées pour ce client**. Le paramètre "request\_uri" peut être pris en charge sur le point de terminaison d'autorisation pour fournir une URL qui contient un JWT avec les informations de demande (voir [https://openid.net/specs/openid-connect-core-1\_0.html#rfc.section.6.2](https://openid.net/specs/openid-connect-core-1\_0.html#rfc.section.6.2)).
Même si l'enregistrement dynamique du client n'est pas activé, ou s'il nécessite une authentification, nous pouvons essayer de réaliser une SSRF sur le point de terminaison d'autorisation simplement en utilisant "request\_uri":\\
Note: ne confondez pas ce paramètre avec "redirect\_uri". Le "redirect\_uri" est utilisé pour la redirection après l'autorisation, tandis que **"request\_uri" est récupéré par le serveur au début du processus d'autorisation**.
En même temps, de nombreux serveurs que nous avons vus n'autorisent pas des valeurs "request\_uri" arbitraires: ils n'autorisent que des URL figurant sur une liste blanche qui ont été préenregistrées lors du processus d'enregistrement du client. C'est pourquoi nous devons fournir "request\_uris": "https://ybd1rc7ylpbqzygoahtjh6v0frlh96.burpcollaborator.net/request.jwt" au préalable.
* Travaillez-vous dans une **entreprise de cybersécurité**? Voulez-vous voir votre **entreprise annoncée dans HackTricks**? ou voulez-vous avoir accès à la **dernière version de PEASS ou télécharger HackTricks en PDF**? Consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop)!
* Découvrez [**The PEASS Family**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFTs**](https://opensea.io/collection/the-peass-family)
* Obtenez le [**swag officiel PEASS & HackTricks**](https://peass.creator-spring.com)
* **Rejoignez le** [**💬**](https://emojipedia.org/speech-balloon/) [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe telegram**](https://t.me/peass) ou **suivez** moi sur **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Partagez vos astuces de piratage en soumettant des PR au** [**repo hacktricks**](https://github.com/carlospolop/hacktricks) **et au** [**repo hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
