mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-22 12:43:23 +00:00
Translated ['pentesting-web/oauth-to-account-takeover.md'] to fr
This commit is contained in:
Translator
parent
76d909ea3f
commit
acbdcb6842
1 changed files with 97 additions and 88 deletions
|
|
@ -1,16 +1,16 @@
|
|||
# OAuth vers la prise de contrôle de compte
|
||||
# OAuth to Account takeover
|
||||
|
||||
<details>
|
||||
|
||||
<summary><strong>Apprenez le piratage AWS de zéro à héros avec</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (Expert en équipe rouge AWS de HackTricks)</strong></a><strong>!</strong></summary>
|
||||
<summary><strong>Apprenez le hacking AWS de zéro à héros avec</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
||||
|
||||
Autres façons de soutenir HackTricks :
|
||||
Autres moyens de soutenir HackTricks :
|
||||
|
||||
* Si vous souhaitez voir votre **entreprise annoncée dans HackTricks** ou **télécharger HackTricks en PDF**, consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop) !
|
||||
* Obtenez le [**swag officiel PEASS & HackTricks**](https://peass.creator-spring.com)
|
||||
* Découvrez [**La famille PEASS**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* **Rejoignez le** 💬 [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe Telegram**](https://t.me/peass) ou **suivez-nous** sur **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Partagez vos astuces de piratage en soumettant des PR aux** [**HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) dépôts GitHub.
|
||||
* Si vous souhaitez voir votre **entreprise annoncée sur HackTricks** ou **télécharger HackTricks en PDF**, consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop) !
|
||||
* Obtenez les [**produits dérivés officiels PEASS & HackTricks**](https://peass.creator-spring.com)
|
||||
* Découvrez [**The PEASS Family**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* **Rejoignez le** 💬 [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe telegram**](https://t.me/peass) ou **suivez-nous** sur **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
|
||||
* **Partagez vos astuces de hacking en soumettant des PRs aux dépôts github** [**HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
|
||||
|
||||
</details>
|
||||
|
||||
|
|
@ -18,36 +18,35 @@ Autres façons de soutenir HackTricks :
|
|||
|
||||
{% embed url="https://websec.nl/" %}
|
||||
|
||||
|
||||
## Informations de base <a href="#d4a8" id="d4a8"></a>
|
||||
|
||||
OAuth propose différentes versions, avec des informations fondamentales accessibles sur la [documentation OAuth 2.0](https://oauth.net/2/). Cette discussion se concentre principalement sur le largement utilisé [type de subvention de code d'autorisation OAuth 2.0](https://oauth.net/2/grant-types/authorization-code/), fournissant un **cadre d'autorisation qui permet à une application d'accéder ou d'effectuer des actions sur le compte d'un utilisateur dans une autre application** (le serveur d'autorisation).
|
||||
OAuth propose différentes versions, avec des informations de base accessibles sur [OAuth 2.0 documentation](https://oauth.net/2/). Cette discussion se concentre principalement sur le très utilisé [OAuth 2.0 authorization code grant type](https://oauth.net/2/grant-types/authorization-code/), fournissant un **cadre d'autorisation qui permet à une application d'accéder ou d'effectuer des actions sur le compte d'un utilisateur dans une autre application** (le serveur d'autorisation).
|
||||
|
||||
Considérez un site web hypothétique _**https://exemple.com**_, conçu pour **présenter tous vos messages sur les réseaux sociaux**, y compris les privés. Pour ce faire, OAuth 2.0 est utilisé. _https://exemple.com_ demandera votre autorisation pour **accéder à vos messages sur les réseaux sociaux**. Par conséquent, un écran de consentement apparaîtra sur _https://reseauxocial.com_, détaillant les **autorisations demandées et le développeur faisant la demande**. Après votre autorisation, _https://exemple.com_ acquiert la capacité d'**accéder à vos messages en votre nom**.
|
||||
Considérons un site web hypothétique _**https://example.com**_, conçu pour **présenter tous vos posts sur les réseaux sociaux**, y compris ceux privés. Pour ce faire, OAuth 2.0 est utilisé. _https://example.com_ demandera votre permission pour **accéder à vos posts sur les réseaux sociaux**. Par conséquent, un écran de consentement apparaîtra sur _https://socialmedia.com_, décrivant les **autorisations demandées et le développeur faisant la demande**. Après votre autorisation, _https://example.com_ obtient la capacité de **consulter vos posts en votre nom**.
|
||||
|
||||
Il est essentiel de comprendre les composants suivants dans le cadre OAuth 2.0 :
|
||||
|
||||
- **propriétaire de la ressource** : Vous, en tant qu'**utilisateur/entité**, autorisez l'accès à votre ressource, comme vos messages de compte sur les réseaux sociaux.
|
||||
- **serveur de ressources** : Le **serveur gérant les demandes authentifiées** après que l'application a obtenu un `jeton d'accès` au nom du `propriétaire de la ressource`, par exemple, **https://reseauxocial.com**.
|
||||
- **application cliente** : L'**application demandant l'autorisation** du `propriétaire de la ressource`, telle que **https://exemple.com**.
|
||||
- **serveur d'autorisation** : Le **serveur qui délivre des `jetons d'accès`** à l'`application cliente` après l'authentification réussie du `propriétaire de la ressource` et la sécurisation de l'autorisation, par exemple, **https://reseauxocial.com**.
|
||||
- **client\_id** : Un identifiant public et unique pour l'application.
|
||||
- **client\_secret** : Une clé confidentielle, connue uniquement de l'application et du serveur d'autorisation, utilisée pour générer des `jetons d'accès`.
|
||||
- **response\_type** : Une valeur spécifiant **le type de jeton demandé**, comme `code`.
|
||||
- **scope** : Le **niveau d'accès** demandé par l'`application cliente` au `propriétaire de la ressource`.
|
||||
- **redirect\_uri** : L'**URL vers laquelle l'utilisateur est redirigé après autorisation**. Cela doit généralement correspondre à l'URL de redirection préalablement enregistrée.
|
||||
- **state** : Un paramètre pour **conserver des données lors de la redirection de l'utilisateur vers et depuis le serveur d'autorisation**. Sa singularité est cruciale pour servir de **mécanisme de protection CSRF**.
|
||||
- **grant\_type** : Un paramètre indiquant **le type de subvention et le type de jeton à renvoyer**.
|
||||
- **code** : Le code d'autorisation du `serveur d'autorisation`, utilisé conjointement avec `client_id` et `client_secret` par l'application cliente pour acquérir un `jeton d'accès`.
|
||||
- **access\_token** : Le **jeton que l'application cliente utilise pour les requêtes API** au nom du `propriétaire de la ressource`.
|
||||
- **refresh\_token** : Permet à l'application d'**obtenir un nouveau `jeton d'accès` sans redemander à l'utilisateur**.
|
||||
* **resource owner** : Vous, en tant qu'**utilisateur/entité**, autorisez l'accès à votre ressource, comme les posts de votre compte de réseau social.
|
||||
* **resource server** : Le **serveur gérant les requêtes authentifiées** après que l'application a sécurisé un `access token` au nom du `resource owner`, par exemple, **https://socialmedia.com**.
|
||||
* **client application** : L'**application cherchant l'autorisation** du `resource owner`, telle que **https://example.com**.
|
||||
* **authorization server** : Le **serveur qui émet des `access tokens`** à l'`application cliente` après l'authentification réussie du `resource owner` et l'obtention de l'autorisation, par exemple, **https://socialmedia.com**.
|
||||
* **client\_id** : Un identifiant public et unique pour l'application.
|
||||
* **client\_secret** : Une clé confidentielle, connue uniquement de l'application et du serveur d'autorisation, utilisée pour générer des `access_tokens`.
|
||||
* **response\_type** : Une valeur spécifiant **le type de jeton demandé**, comme `code`.
|
||||
* **scope** : Le **niveau d'accès** que l'`application cliente` demande au `resource owner`.
|
||||
* **redirect\_uri** : L'**URL vers laquelle l'utilisateur est redirigé après l'autorisation**. Cela doit généralement correspondre à l'URL de redirection préenregistrée.
|
||||
* **state** : Un paramètre pour **maintenir les données lors de la redirection de l'utilisateur vers et depuis le serveur d'autorisation**. Son unicité est cruciale pour servir de **mécanisme de protection CSRF**.
|
||||
* **grant\_type** : Un paramètre indiquant **le type de subvention et le type de jeton à retourner**.
|
||||
* **code** : Le code d'autorisation du `authorization server`, utilisé en tandem avec `client_id` et `client_secret` par l'application cliente pour acquérir un `access_token`.
|
||||
* **access\_token** : Le **jeton que l'application cliente utilise pour les requêtes API** au nom du `resource owner`.
|
||||
* **refresh\_token** : Permet à l'application de **obtenir un nouveau `access_token` sans redemander à l'utilisateur**.
|
||||
|
||||
### Flux
|
||||
|
||||
Le **flux OAuth réel** se déroule comme suit :
|
||||
|
||||
1. Vous accédez à [https://exemple.com](https://exemple.com) et sélectionnez le bouton "Intégrer avec les réseaux sociaux".
|
||||
2. Le site envoie ensuite une demande à [https://reseauxocial.com](https://reseauxocial.com) demandant votre autorisation pour permettre à l'application de https://exemple.com d'accéder à vos messages. La demande est structurée comme suit :
|
||||
1. Vous naviguez vers [https://example.com](https://example.com) et sélectionnez le bouton “Intégrer avec les réseaux sociaux”.
|
||||
2. Le site envoie alors une demande à [https://socialmedia.com](https://socialmedia.com) demandant votre autorisation pour permettre à l'application de https://example.com d'accéder à vos posts. La demande est structurée comme suit :
|
||||
```
|
||||
https://socialmedia.com/auth
|
||||
?response_type=code
|
||||
|
|
@ -57,63 +56,61 @@ https://socialmedia.com/auth
|
|||
&state=randomString123
|
||||
```
|
||||
3. Vous êtes ensuite présenté avec une page de consentement.
|
||||
|
||||
4. Après votre approbation, les médias sociaux envoient une réponse à l'`redirect_uri` avec les paramètres `code` et `state`:
|
||||
4. Après votre approbation, Social Media envoie une réponse à l'`redirect_uri` avec les paramètres `code` et `state` :
|
||||
```
|
||||
https://example.com?code=uniqueCode123&state=randomString123
|
||||
```
|
||||
5. https://example.com utilise ce `code`, ainsi que son `client_id` et `client_secret`, pour effectuer une requête côté serveur afin d'obtenir un `access_token` en votre nom, permettant l'accès aux autorisations auxquelles vous avez consenti :
|
||||
5. https://example.com utilise ce `code`, ainsi que son `client_id` et `client_secret`, pour faire une requête côté serveur afin d'obtenir un `access_token` en votre nom, permettant l'accès aux permissions auxquelles vous avez consenti :
|
||||
```
|
||||
POST /oauth/access_token
|
||||
Host: socialmedia.com
|
||||
...{"client_id": "example_clientId", "client_secret": "example_clientSecret", "code": "uniqueCode123", "grant_type": "authorization_code"}
|
||||
```
|
||||
6. Enfin, le processus se termine lorsque https://example.com utilise votre `access_token` pour effectuer un appel API vers les médias sociaux afin d'accéder
|
||||
6. Enfin, le processus se termine lorsque https://example.com utilise votre `access_token` pour effectuer un appel API à Social Media pour accéder
|
||||
|
||||
## Vulnérabilités <a href="#323a" id="323a"></a>
|
||||
## Vulnérabilités <a href="#id-323a" id="id-323a"></a>
|
||||
|
||||
### Open redirect\_uri <a href="#cc36" id="cc36"></a>
|
||||
|
||||
Le `redirect_uri` est crucial pour la sécurité dans les implémentations OAuth et OpenID, car il indique où les données sensibles, telles que les codes d'autorisation, sont envoyées après l'autorisation. S'il est mal configuré, il pourrait permettre aux attaquants de rediriger ces requêtes vers des serveurs malveillants, facilitant la prise de contrôle de compte.
|
||||
Le `redirect_uri` est crucial pour la sécurité dans les implémentations OAuth et OpenID, car il dirige où les données sensibles, comme les codes d'autorisation, sont envoyées après l'autorisation. S'il est mal configuré, il pourrait permettre aux attaquants de rediriger ces requêtes vers des serveurs malveillants, permettant ainsi la prise de contrôle de compte.
|
||||
|
||||
Les techniques d'exploitation varient en fonction de la logique de validation du serveur d'autorisation. Elles peuvent aller de la correspondance stricte des chemins à l'acceptation de n'importe quelle URL dans le domaine ou le sous-répertoire spécifié. Les méthodes d'exploitation courantes incluent les redirections ouvertes, la traversée de chemin, l'exploitation de regex faibles et l'injection HTML pour le vol de jetons.
|
||||
Les techniques d'exploitation varient en fonction de la logique de validation du serveur d'autorisation. Elles peuvent aller de la correspondance stricte des chemins à l'acceptation de toute URL dans le domaine ou le sous-répertoire spécifié. Les méthodes d'exploitation courantes incluent les redirections ouvertes, la traversée de chemin, l'exploitation de regex faibles et l'injection HTML pour le vol de jetons.
|
||||
|
||||
Outre `redirect_uri`, d'autres paramètres OAuth et OpenID tels que `client_uri`, `policy_uri`, `tos_uri` et `initiate_login_uri` sont également susceptibles d'être attaqués par redirection. Ces paramètres sont facultatifs et leur prise en charge varie selon les serveurs.
|
||||
En plus de `redirect_uri`, d'autres paramètres OAuth et OpenID comme `client_uri`, `policy_uri`, `tos_uri`, et `initiate_login_uri` sont également susceptibles aux attaques de redirection. Ces paramètres sont optionnels et leur support varie selon les serveurs.
|
||||
|
||||
Pour ceux ciblant un serveur OpenID, le point de découverte (`**.well-known/openid-configuration**`) liste souvent des détails de configuration précieux tels que `registration_endpoint`, `request_uri_parameter_supported` et "`require_request_uri_registration`. Ces détails peuvent aider à identifier le point de registre et d'autres spécificités de configuration du serveur.
|
||||
Pour ceux ciblant un serveur OpenID, le point de découverte (`**.well-known/openid-configuration**`) liste souvent des détails de configuration précieux comme `registration_endpoint`, `request_uri_parameter_supported`, et "`require_request_uri_registration`. Ces détails peuvent aider à identifier le point d'enregistrement et d'autres spécificités de configuration du serveur.
|
||||
|
||||
### XSS dans l'implémentation de redirection <a href="#bda5" id="bda5"></a>
|
||||
|
||||
Comme mentionné dans ce rapport de prime de bug [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 reflétée dans la réponse** du serveur après l'authentification de l'utilisateur, étant **vulnérable aux XSS**. Charge utile possible à tester:
|
||||
Comme mentionné dans ce rapport de bug bounty [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 reflétée dans la réponse** du serveur après l'authentification de l'utilisateur, étant **vulnérable à XSS**. Payload possible à tester :
|
||||
```
|
||||
https://app.victim.com/login?redirectUrl=https://app.victim.com/dashboard</script><h1>test</h1>
|
||||
```
|
||||
### CSRF - Gestion incorrecte du paramètre d'état <a href="#bda5" id="bda5"></a>
|
||||
### CSRF - Mauvaise gestion du paramètre state <a href="#bda5" id="bda5"></a>
|
||||
|
||||
Dans les implémentations OAuth, l'utilisation incorrecte ou l'omission du **paramètre `state`** peut augmenter considérablement le risque d'attaques de **falsification de requête intersite (CSRF)**. Cette vulnérabilité survient lorsque le paramètre `state` n'est **pas utilisé, utilisé comme une valeur statique, ou non correctement validé**, permettant aux attaquants de contourner les protections CSRF.
|
||||
Dans les implémentations OAuth, la mauvaise utilisation ou l'omission du **paramètre `state`** peut augmenter considérablement le risque d'attaques par **Cross-Site Request Forgery (CSRF)**. Cette vulnérabilité survient lorsque le paramètre `state` est soit **non utilisé, utilisé comme une valeur statique, ou non correctement validé**, permettant aux attaquants de contourner les protections CSRF.
|
||||
|
||||
Les attaquants peuvent exploiter cela en interceptant le processus d'autorisation pour lier leur compte à celui d'une victime, entraînant des **prises de contrôle de compte potentielles**. Cela est particulièrement critique dans les applications où OAuth est utilisé à des fins d'**authentification**.
|
||||
Les attaquants peuvent exploiter cela en interceptant le processus d'autorisation pour lier leur compte à celui de la victime, conduisant à des **prises de contrôle de compte** potentielles. Cela est particulièrement critique dans les applications où OAuth est utilisé à des **fins d'authentification**.
|
||||
|
||||
Des exemples concrets de cette vulnérabilité ont été documentés dans divers **défis CTF** et **plateformes de piratage**, mettant en évidence ses implications pratiques. Le problème s'étend également aux intégrations avec des services tiers tels que **Slack**, **Stripe** et **PayPal**, où les attaquants peuvent rediriger des notifications ou des paiements vers leurs comptes.
|
||||
Des exemples concrets de cette vulnérabilité ont été documentés dans divers **défis CTF** et **plateformes de hacking**, soulignant ses implications pratiques. Le problème s'étend également aux intégrations avec des services tiers comme **Slack**, **Stripe**, et **PayPal**, où les attaquants peuvent rediriger des notifications ou des paiements vers leurs comptes.
|
||||
|
||||
Une gestion et une validation appropriées du **paramètre `state`** sont cruciales pour se protéger contre les CSRF et sécuriser le flux OAuth.
|
||||
|
||||
### Préprise de contrôle de compte <a href="#ebe4" id="ebe4"></a>
|
||||
### Prise de contrôle de compte préalable <a href="#ebe4" id="ebe4"></a>
|
||||
|
||||
1. **Sans vérification d'email lors de la création de compte** : Les attaquants peuvent créer préventivement un compte en utilisant l'email de la victime. Si la victime utilise ultérieurement un service tiers pour se connecter, l'application pourrait involontairement lier ce compte tiers au compte pré-créé de l'attaquant, entraînant un accès non autorisé.
|
||||
|
||||
2. **Exploitation de la vérification d'email laxiste d'OAuth** : Les attaquants peuvent exploiter les services OAuth qui ne vérifient pas les emails en s'inscrivant avec leur service, puis en changeant l'email du compte pour celui de la victime. Cette méthode comporte également des risques d'accès non autorisé au compte, similaire au premier scénario mais à travers un vecteur d'attaque différent.
|
||||
1. **Sans vérification de l'email lors de la création de compte** : Les attaquants peuvent créer un compte de manière préventive en utilisant l'email de la victime. Si la victime utilise plus tard un service tiers pour se connecter, l'application pourrait par inadvertance lier ce compte tiers au compte pré-créé par l'attaquant, conduisant à un accès non autorisé.
|
||||
2. **Exploitation d'une vérification d'email OAuth laxiste** : Les attaquants peuvent exploiter des services OAuth qui ne vérifient pas les emails en s'inscrivant avec leur service puis en changeant l'email du compte pour celui de la victime. Cette méthode présente un risque similaire d'accès non autorisé, semblable au premier scénario mais via un vecteur d'attaque différent.
|
||||
|
||||
### Divulgation de secrets <a href="#e177" id="e177"></a>
|
||||
|
||||
Identifier et protéger les paramètres secrets OAuth est crucial. Alors que le **`client_id`** peut être divulgué en toute sécurité, révéler le **`client_secret`** pose des risques importants. Si le `client_secret` est compromis, les attaquants peuvent exploiter l'identité et la confiance de l'application pour **voler les `access_tokens`** des utilisateurs et des informations privées.
|
||||
Identifier et protéger les paramètres secrets OAuth est crucial. Bien que le **`client_id`** puisse être divulgué en toute sécurité, révéler le **`client_secret`** pose des risques significatifs. Si le `client_secret` est compromis, les attaquants peuvent exploiter l'identité et la confiance de l'application pour **voler les `access_tokens`** des utilisateurs et des informations privées.
|
||||
|
||||
Une vulnérabilité courante survient lorsque les applications gèrent incorrectement l'échange du `code` d'autorisation pour un `access_token` côté client plutôt que côté serveur. Cette erreur conduit à l'exposition du `client_secret`, permettant aux attaquants de générer des `access_tokens` sous l'apparence de l'application. De plus, via l'ingénierie sociale, les attaquants pourraient augmenter les privilèges en ajoutant des étendues supplémentaires à l'autorisation OAuth, exploitant davantage le statut de confiance de l'application.
|
||||
Une vulnérabilité courante survient lorsque les applications gèrent par erreur l'échange du `code` d'autorisation pour un `access_token` côté client plutôt que côté serveur. Cette erreur conduit à l'exposition du `client_secret`, permettant aux attaquants de générer des `access_tokens` sous l'apparence de l'application. De plus, par ingénierie sociale, les attaquants pourraient escalader les privilèges en ajoutant des portées supplémentaires à l'autorisation OAuth, exploitant davantage le statut de confiance de l'application.
|
||||
|
||||
### Bruteforce du secret client
|
||||
### Bruteforce du Client Secret
|
||||
|
||||
Vous pouvez essayer de **bruteforcer le `client_secret`** d'un fournisseur de services avec le fournisseur d'identité afin de tenter de voler des comptes.\
|
||||
La requête de BF peut ressembler à :
|
||||
Vous pouvez essayer de **bruteforcer le client\_secret** d'un fournisseur de services avec le fournisseur d'identité afin d'essayer de voler des comptes.\
|
||||
La requête pour BF peut ressembler à :
|
||||
```
|
||||
POST /token HTTP/1.1
|
||||
content-type: application/x-www-form-urlencoded
|
||||
|
|
@ -123,29 +120,29 @@ Connection: close
|
|||
|
||||
code=77515&redirect_uri=http%3A%2F%2F10.10.10.10%3A3000%2Fcallback&grant_type=authorization_code&client_id=public_client_id&client_secret=[bruteforce]
|
||||
```
|
||||
### En-tête Referer divulguant le Code + State
|
||||
### Referer Header leaking Code + State
|
||||
|
||||
Une fois que le client a le **code et l'état**, s'il est **reflété à l'intérieur de l'en-tête Referer** lorsqu'il navigue vers une autre page, alors il est vulnérable.
|
||||
Une fois que le client a le **code et l'état**, s'ils sont **réfléchis dans l'en-tête Referer** lorsqu'il navigue vers une autre page, alors c'est vulnérable.
|
||||
|
||||
### Jeton d'accès stocké dans l'historique du navigateur
|
||||
### Access Token Stored in Browser History
|
||||
|
||||
Allez dans **l'historique du navigateur et vérifiez si le jeton d'accès est enregistré là-dedans**.
|
||||
Allez dans l'**historique du navigateur et vérifiez si le jeton d'accès y est enregistré**.
|
||||
|
||||
### Code d'autorisation éternel
|
||||
### Everlasting Authorization Code
|
||||
|
||||
Le **code d'autorisation ne devrait vivre que pendant un certain temps pour limiter la fenêtre temporelle où un attaquant peut le voler et l'utiliser**.
|
||||
Le **code d'autorisation ne devrait vivre que pendant un certain temps pour limiter la fenêtre de temps où un attaquant peut le voler et l'utiliser**.
|
||||
|
||||
### Jeton d'autorisation/rafraîchissement non lié au client
|
||||
### Authorization/Refresh Token not bound to client
|
||||
|
||||
Si vous pouvez obtenir le **code d'autorisation et l'utiliser avec un client différent, alors vous pouvez prendre le contrôle d'autres comptes**.
|
||||
|
||||
### Chemins heureux, XSS, Iframes & Post Messages pour divulguer les valeurs du code & de l'état
|
||||
### Happy Paths, XSS, Iframes & Post Messages to leak code & state values
|
||||
|
||||
**[Consultez ce post](https://labs.detectify.com/writeups/account-hijacking-using-dirty-dancing-in-sign-in-oauth-flows/#gadget-2-xss-on-sandbox-third-party-domain-that-gets-the-url)**
|
||||
[**Consultez cet article**](https://labs.detectify.com/writeups/account-hijacking-using-dirty-dancing-in-sign-in-oauth-flows/#gadget-2-xss-on-sandbox-third-party-domain-that-gets-the-url)
|
||||
|
||||
### AWS Cognito <a href="#bda5" id="bda5"></a>
|
||||
|
||||
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** qu'**AWS Cognito** renvoie à l'utilisateur pourrait 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.
|
||||
Dans ce rapport de bug bounty : [**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 pourrait avoir **suffisamment de permissions pour écraser les données de l'utilisateur**. Par conséquent, si vous pouvez **changer l'email de l'utilisateur pour un autre email**, vous pourriez être capable de **prendre le contrôle** d'autres comptes.
|
||||
```bash
|
||||
# Read info of the user
|
||||
aws cognito-idp get-user --region us-east-1 --access-token eyJraWQiOiJPVj[...]
|
||||
|
|
@ -162,71 +159,83 @@ aws cognito-idp update-user-attributes --region us-east-1 --access-token eyJraWQ
|
|||
]
|
||||
}
|
||||
```
|
||||
Pour plus d'informations détaillées sur la manière d'abuser d'AWS Cognito, consultez :
|
||||
Pour plus d'informations détaillées sur la manière d'abuser de AWS cognito, consultez :
|
||||
|
||||
{% embed url="https://cloud.hacktricks.xyz/pentesting-cloud/aws-pentesting/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum" %}
|
||||
|
||||
### Abuser des jetons d'autres applications <a href="#bda5" id="bda5"></a>
|
||||
### Abuser des tokens d'autres applications <a href="#bda5" id="bda5"></a>
|
||||
|
||||
Comme [**mentionné dans cet article**](https://salt.security/blog/oh-auth-abusing-oauth-to-take-over-millions-of-accounts), les flux OAuth qui s'attendent à recevoir le **jeton** (et non un code) pourraient être vulnérables s'ils ne vérifient pas que le jeton appartient à l'application.
|
||||
Comme [**mentionné dans cet article**](https://salt.security/blog/oh-auth-abusing-oauth-to-take-over-millions-of-accounts), les flux OAuth qui s'attendent à recevoir le **token** (et non un code) pourraient être vulnérables s'ils ne vérifient pas que le token appartient à l'application.
|
||||
|
||||
Cela est dû au fait qu'un **attaquant** pourrait créer une **application prenant en charge OAuth et se connecter avec Facebook** (par exemple) dans sa propre application. Ensuite, une fois qu'une victime se connecte avec Facebook dans l'**application de l'attaquant**, l'attaquant pourrait obtenir le **jeton OAuth de l'utilisateur donné à son application, et l'utiliser pour se connecter à l'application OAuth de la victime en utilisant le jeton de l'utilisateur de la victime**.
|
||||
Cela est dû au fait qu'un **attaquant** pourrait créer une **application supportant OAuth et se connecter avec Facebook** (par exemple) dans sa propre application. Ensuite, une fois qu'une victime se connecte avec Facebook dans l'**application de l'attaquant**, l'attaquant pourrait obtenir le **token OAuth de l'utilisateur donné à son application, et l'utiliser pour se connecter à l'application OAuth de la victime en utilisant le token utilisateur de la victime**.
|
||||
|
||||
{% hint style="danger" %}
|
||||
Par conséquent, si l'attaquant parvient à obtenir l'accès de l'utilisateur à sa propre application OAuth, il pourra prendre le contrôle du compte des victimes dans les applications qui attendent un jeton et ne vérifient pas si le jeton a été accordé à leur ID d'application.
|
||||
Par conséquent, si l'attaquant parvient à faire accéder l'utilisateur à sa propre application OAuth, il pourra prendre le contrôle du compte de la victime dans les applications qui attendent un token et ne vérifient pas si le token a été accordé à leur ID d'application.
|
||||
{% endhint %}
|
||||
|
||||
### Deux liens & 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 en sorte qu'une victime ouvre une page avec une **returnUrl** pointant vers l'hôte de l'attaquant. Ces informations seraient **stockées dans un cookie (RU)** et à **une étape ultérieure**, le **prompt** demandera à l'**utilisateur** s'il souhaite donner accès à cet hôte d'attaquant.
|
||||
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 victime une page 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**, le **prompt** demandera à l'**utilisateur** s'il souhaite donner accès à cet hôte de l'attaquant.
|
||||
|
||||
Pour contourner ce prompt, il était possible d'ouvrir un onglet pour initier le **flux OAuth** qui définirait ce cookie RU en utilisant le **returnUrl**, de fermer l'onglet avant l'affichage du prompt, et d'ouvrir un nouvel onglet sans cette valeur. Ensuite, le **prompt ne mentionnera pas 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.
|
||||
Pour contourner ce prompt, il était possible d'ouvrir un onglet pour initier le **flux OAuth** qui définirait ce cookie RU en utilisant le **returnUrl**, de fermer l'onglet avant que le prompt ne soit affiché, et d'ouvrir un nouvel onglet sans cette valeur. Ensuite, le **prompt n'informera pas de l'hôte de l'attaquant**, mais le cookie serait défini pour celui-ci, donc le **token sera envoyé à l'hôte de l'attaquant** dans la redirection.
|
||||
|
||||
### Paramètres SSRF <a href="#bda5" id="bda5"></a>
|
||||
### Contournement de l'interaction du prompt <a href="#bda5" id="bda5"></a>
|
||||
|
||||
**[Consultez cette recherche](https://portswigger.net/research/hidden-oauth-attack-vectors) pour plus de détails sur cette technique.**
|
||||
Comme expliqué dans [**cette vidéo**](https://www.youtube.com/watch?v=n9x7\_J\_a\_7Q), certaines implémentations OAuth permettent d'indiquer le paramètre GET **`prompt`** comme None (**`&prompt=none`**) pour **empêcher les utilisateurs d'être invités à confirmer** l'accès donné dans un prompt sur le web s'ils sont déjà connectés à la plateforme.
|
||||
|
||||
L'enregistrement dynamique du client dans OAuth sert de vecteur moins évident mais critique pour les vulnérabilités de sécurité, en particulier pour les attaques de type **Server-Side Request Forgery (SSRF)**. Ce point de terminaison permet aux serveurs OAuth de recevoir des détails sur les applications clientes, y compris des URL sensibles qui pourraient être exploitées.
|
||||
### response\_mode
|
||||
|
||||
Comme [**expliqué dans cette vidéo**](https://www.youtube.com/watch?v=n9x7\_J\_a\_7Q), il pourrait être possible d'indiquer le paramètre **`response_mode`** pour indiquer où vous souhaitez que le code soit fourni dans l'URL finale :
|
||||
|
||||
* `response_mode=query` -> Le code est fourni dans un paramètre GET : `?code=2397rf3gu93f`
|
||||
* `response_mode=fragment` -> Le code est fourni dans le paramètre fragment de l'URL `#code=2397rf3gu93f`
|
||||
* `response_mode=form_post` -> Le code est fourni dans un formulaire POST avec un input appelé `code` et la valeur
|
||||
* `response_mode=web_message` -> Le code est envoyé dans un message post : `window.opener.postMessage({"code": "asdasdasd...`
|
||||
|
||||
### Paramètres SSRFs <a href="#bda5" id="bda5"></a>
|
||||
|
||||
[**Consultez cette recherche**](https://portswigger.net/research/hidden-oauth-attack-vectors) **pour plus de détails sur cette technique.**
|
||||
|
||||
L'enregistrement dynamique des clients dans OAuth sert de vecteur moins évident mais critique pour les vulnérabilités de sécurité, spécifiquement pour les attaques **Server-Side Request Forgery (SSRF)**. Ce point de terminaison permet aux serveurs OAuth de recevoir des détails sur les applications clientes, y compris des URL sensibles qui pourraient être exploitées.
|
||||
|
||||
**Points clés :**
|
||||
|
||||
- L'**enregistrement dynamique du client** est souvent associé à `/register` et accepte des détails tels que `client_name`, `client_secret`, `redirect_uris`, et des URLs pour des logos ou des ensembles de clés Web JSON (JWKs) via des requêtes POST.
|
||||
- Cette fonctionnalité se conforme aux spécifications énoncées dans **RFC7591** et **OpenID Connect Registration 1.0**, qui incluent des paramètres potentiellement vulnérables aux SSRF.
|
||||
- Le processus d'enregistrement peut exposer involontairement les serveurs aux SSRF de plusieurs manières :
|
||||
- **`logo_uri`** : Une URL pour le logo de l'application cliente qui pourrait être récupérée par le serveur, déclenchant un SSRF ou conduisant à une XSS si l'URL est mal gérée.
|
||||
- **`jwks_uri`** : Une URL vers le document JWK du client, qui s'il est malveillamment conçu, peut amener le serveur à effectuer des requêtes sortantes vers un serveur contrôlé par l'attaquant.
|
||||
- **`sector_identifier_uri`** : Référence un tableau JSON de `redirect_uris`, que le serveur pourrait récupérer, créant une opportunité de SSRF.
|
||||
- **`request_uris`** : Liste des URI de requête autorisés pour le client, qui peuvent être exploités si le serveur récupère ces URIs au début du processus d'autorisation.
|
||||
* **L'enregistrement dynamique des clients** est souvent mappé à `/register` et accepte des détails comme `client_name`, `client_secret`, `redirect_uris`, et des URL pour les logos ou les ensembles de clés JSON Web (JWKs) via des requêtes POST.
|
||||
* Cette fonctionnalité adhère aux spécifications énoncées dans **RFC7591** et **OpenID Connect Registration 1.0**, qui incluent des paramètres potentiellement vulnérables aux SSRF.
|
||||
* Le processus d'enregistrement peut involontairement exposer les serveurs aux SSRF de plusieurs manières :
|
||||
* **`logo_uri`** : Une URL pour le logo de l'application cliente qui pourrait être récupérée par le serveur, déclenchant une SSRF ou menant à une XSS si l'URL est mal gérée.
|
||||
* **`jwks_uri`** : Une URL vers le document JWK du client, qui, si elle est malicieusement conçue, peut amener le serveur à faire des requêtes sortantes vers un serveur contrôlé par l'attaquant.
|
||||
* **`sector_identifier_uri`** : Référence un tableau JSON de `redirect_uris`, que le serveur pourrait récupérer, créant une opportunité de SSRF.
|
||||
* **`request_uris`** : Liste les URIs de requête autorisées pour le client, qui peuvent être exploitées si le serveur récupère ces URIs au début du processus d'autorisation.
|
||||
|
||||
**Stratégie d'exploitation :**
|
||||
|
||||
- Un SSRF peut être déclenché en enregistrant un nouveau client avec des URLs malveillantes dans des paramètres tels que `logo_uri`, `jwks_uri`, ou `sector_identifier_uri`.
|
||||
- Bien que l'exploitation directe via `request_uris` puisse être atténuée par des contrôles de liste blanche, fournir un `request_uri` préenregistré et contrôlé par l'attaquant peut faciliter un SSRF pendant la phase d'autorisation.
|
||||
* La SSRF peut être déclenchée en enregistrant un nouveau client avec des URL malveillantes dans des paramètres comme `logo_uri`, `jwks_uri`, ou `sector_identifier_uri`.
|
||||
* Bien que l'exploitation directe via `request_uris` puisse être atténuée par des contrôles de liste blanche, fournir une `request_uri` préenregistrée et contrôlée par l'attaquant peut faciliter la SSRF pendant la phase d'autorisation.
|
||||
|
||||
## Conditions de course des fournisseurs OAuth
|
||||
|
||||
Si la plateforme que vous testez est un fournisseur OAuth, [**lisez ceci pour tester d'éventuelles conditions de course**](race-condition.md).
|
||||
Si la plateforme que vous testez est un fournisseur OAuth, [**lisez ceci pour tester les conditions de course possibles**](race-condition.md).
|
||||
|
||||
## Références
|
||||
|
||||
* [**https://medium.com/a-bugz-life/the-wondeful-world-of-oauth-bug-bounty-edition-af3073b354c1**](https://medium.com/a-bugz-life/the-wondeful-world-of-oauth-bug-bounty-edition-af3073b354c1)
|
||||
* [**https://portswigger.net/research/hidden-oauth-attack-vectors**](https://portswigger.net/research/hidden-oauth-attack-vectors)
|
||||
|
||||
|
||||
<figure><img src="https://pentest.eu/RENDER_WebSec_10fps_21sec_9MB_29042024.gif" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
{% embed url="https://websec.nl/" %}
|
||||
|
||||
<details>
|
||||
|
||||
<summary><strong>Apprenez le piratage AWS de zéro à héros avec</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
||||
<summary><strong>Apprenez le hacking AWS de zéro à héros avec</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
||||
|
||||
Autres façons de soutenir HackTricks :
|
||||
Autres moyens de soutenir HackTricks :
|
||||
|
||||
* Si vous souhaitez voir votre **entreprise annoncée dans HackTricks** ou **télécharger HackTricks en PDF**, consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop)!
|
||||
* Obtenez le [**swag officiel PEASS & HackTricks**](https://peass.creator-spring.com)
|
||||
* Découvrez [**The PEASS Family**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* **Rejoignez** 💬 le groupe Discord](https://discord.gg/hRep4RUj7f) ou le [**groupe Telegram**](https://t.me/peass) ou **suivez-nous** sur **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Partagez vos astuces de piratage en soumettant des PR aux** [**dépôts Github HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
|
||||
* Si vous souhaitez voir votre **entreprise annoncée dans HackTricks** ou **télécharger HackTricks en PDF**, consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop) !
|
||||
* Obtenez les [**produits dérivés officiels PEASS & HackTricks**](https://peass.creator-spring.com)
|
||||
* Découvrez [**La famille PEASS**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* **Rejoignez le** 💬 [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe Telegram**](https://t.me/peass) ou **suivez-nous** sur **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
|
||||
* **Partagez vos astuces de hacking en soumettant des PRs aux** [**repos github HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
|
||||
|
||||
</details>
|
||||
|
|
|
|||
Loading…
Reference in a new issue