GITBOOK-4370: No subject

pentesting-web/oauth-to-account-takeover.md

@@ -9,7 +9,7 @@ Other ways to support HackTricks:
 * If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
 * Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
 * Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
-* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
+* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
 * **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
 
 </details>
@@ -18,7 +18,6 @@ Other ways to support HackTricks:
 
 {% embed url="https://websec.nl/" %}
 
-
 ## Basic Information <a href="#d4a8" id="d4a8"></a>
 
 OAuth offers various versions, with foundational insights accessible at [OAuth 2.0 documentation](https://oauth.net/2/). This discussion primarily centers on the widely used [OAuth 2.0 authorization code grant type](https://oauth.net/2/grant-types/authorization-code/), providing an **authorization framework that enables an application to access or perform actions on a user's account in another application** (the authorization server).
@@ -27,20 +26,20 @@ Consider a hypothetical website _**https://example.com**_, designed to **showcas
 
 It's essential to grasp the following components within the OAuth 2.0 framework:
 
-- **resource owner**: You, as the **user/entity**, authorize access to your resource, like your social media account posts.
-- **resource server**: The **server managing authenticated requests** after the application has secured an `access token` on behalf of the `resource owner`, e.g., **https://socialmedia.com**.
-- **client application**: The **application seeking authorization** from the `resource owner`, such as **https://example.com**.
-- **authorization server**: The **server that issues `access tokens`** to the `client application` following the successful authentication of the `resource owner` and securing authorization, e.g., **https://socialmedia.com**.
-- **client\_id**: A public, unique identifier for the application.
-- **client\_secret:** A confidential key, known solely to the application and the authorization server, used for generating `access_tokens`.
-- **response\_type**: A value specifying **the type of token requested**, like `code`.
-- **scope**: The **level of access** the `client application` is requesting from the `resource owner`.
-- **redirect\_uri**: The **URL to which the user is redirected after authorization**. This typically must align with the pre-registered redirect URL.
-- **state**: A parameter to **maintain data across the user's redirection to and from the authorization server**. Its uniqueness is critical for serving as a **CSRF protection mechanism**.
-- **grant\_type**: A parameter indicating **the grant type and the type of token to be returned**.
-- **code**: The authorization code from the `authorization server`, used in tandem with `client_id` and `client_secret` by the client application to acquire an `access_token`.
-- **access\_token**: The **token that the client application uses for API requests** on behalf of the `resource owner`.
-- **refresh\_token**: Enables the application to **obtain a new `access_token` without re-prompting the user**.
+* **resource owner**: You, as the **user/entity**, authorize access to your resource, like your social media account posts.
+* **resource server**: The **server managing authenticated requests** after the application has secured an `access token` on behalf of the `resource owner`, e.g., **https://socialmedia.com**.
+* **client application**: The **application seeking authorization** from the `resource owner`, such as **https://example.com**.
+* **authorization server**: The **server that issues `access tokens`** to the `client application` following the successful authentication of the `resource owner` and securing authorization, e.g., **https://socialmedia.com**.
+* **client\_id**: A public, unique identifier for the application.
+* **client\_secret:** A confidential key, known solely to the application and the authorization server, used for generating `access_tokens`.
+* **response\_type**: A value specifying **the type of token requested**, like `code`.
+* **scope**: The **level of access** the `client application` is requesting from the `resource owner`.
+* **redirect\_uri**: The **URL to which the user is redirected after authorization**. This typically must align with the pre-registered redirect URL.
+* **state**: A parameter to **maintain data across the user's redirection to and from the authorization server**. Its uniqueness is critical for serving as a **CSRF protection mechanism**.
+* **grant\_type**: A parameter indicating **the grant type and the type of token to be returned**.
+* **code**: The authorization code from the `authorization server`, used in tandem with `client_id` and `client_secret` by the client application to acquire an `access_token`.
+* **access\_token**: The **token that the client application uses for API requests** on behalf of the `resource owner`.
+* **refresh\_token**: Enables the application to **obtain a new `access_token` without re-prompting the user**.
 
 ### Flow
 
@@ -59,7 +58,6 @@ https://socialmedia.com/auth
 ```
 
 3. You are then presented with a consent page.
-
 4. Following your approval, Social Media sends a response to the `redirect_uri` with the `code` and `state` parameters:
 
 ```
@@ -76,7 +74,7 @@ Host: socialmedia.com
 
 6. Finally, the process concludes as https://example.com employs your `access_token` to make an API call to Social Media to access
 
-## Vulnerabilities <a href="#323a" id="323a"></a>
+## Vulnerabilities <a href="#id-323a" id="id-323a"></a>
 
 ### Open redirect\_uri <a href="#cc36" id="cc36"></a>
 
@@ -98,7 +96,7 @@ https://app.victim.com/login?redirectUrl=https://app.victim.com/dashboard</scrip
 
 ### CSRF - Improper handling of state parameter <a href="#bda5" id="bda5"></a>
 
-In OAuth implementations, the misuse or omission of the **`state` parameter** can significantly increase the risk of **Cross-Site Request Forgery (CSRF)** attacks. This vulnerability arises when the `state` parameter is either **not used, used as a static value, or not properly validated**, allowing attackers to bypass CSRF protections. 
+In OAuth implementations, the misuse or omission of the **`state` parameter** can significantly increase the risk of **Cross-Site Request Forgery (CSRF)** attacks. This vulnerability arises when the `state` parameter is either **not used, used as a static value, or not properly validated**, allowing attackers to bypass CSRF protections.
 
 Attackers can exploit this by intercepting the authorization process to link their account with a victim's account, leading to potential **account takeovers**. This is especially critical in applications where OAuth is used for **authentication purposes**.
 
@@ -109,10 +107,8 @@ Proper handling and validation of the **`state` parameter** are crucial for safe
 ### Pre Account Takeover <a href="#ebe4" id="ebe4"></a>
 
 1. **Without Email Verification on Account Creation**: Attackers can preemptively create an account using the victim's email. If the victim later uses a third-party service for login, the application might inadvertently link this third-party account to the attacker's pre-created account, leading to unauthorized access.
-
 2. **Exploiting Lax OAuth Email Verification**: Attackers may exploit OAuth services that don't verify emails by registering with their service and then changing the account email to the victim's. This method similarly risks unauthorized account access, akin to the first scenario but through a different attack vector.
 
-
 ### Disclosure of Secrets <a href="#e177" id="e177"></a>
 
 Identifying and protecting secret OAuth parameters is crucial. While the **`client_id`** can be safely disclosed, revealing the **`client_secret`** poses significant risks. If the `client_secret` is compromised, attackers can exploit the identity and trust of the application to **steal user `access_tokens`** and private information.
@@ -152,7 +148,7 @@ If you can get the **authorization code and use it with a different client then
 
 ### Happy Paths, XSS, Iframes & Post Messages to leak code & state values
 
-**[Check this 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)**
+[**Check this 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)
 
 ### AWS Cognito <a href="#bda5" id="bda5"></a>
 
@@ -195,26 +191,39 @@ According to [**this writeup**](https://medium.com/@metnew/why-electron-apps-can
 
 To bypass this prompt, it was possible to open a tab to initiate the **Oauth flow** that would set this RU cookie using the **returnUrl**, close the tab before the prompt is shown, and open a new tab without that value. Then, the **prompt won't inform about the attackers host**, but the cookie would be set to it, so the **token will be sent to the attackers host** in the redirection.
 
+### Prompt Interaction Bypass <a href="#bda5" id="bda5"></a>
+
+As explained in [**this video**](https://www.youtube.com/watch?v=n9x7\_J\_a\_7Q), some OAuth implementations allows to indicate the **`prompt`** GET parameter as None (**`&prompt=none`**) to **prevent users being asked to confirm** the given access in a prompt in the web if they are already logged in the platform.
+
+### response\_mode
+
+As [**explained in this video**](https://www.youtube.com/watch?v=n9x7\_J\_a\_7Q), it might be possible to indicate the parameter **`response_mode`** to indicate where do you want the code to be provided in the final URL:
+
+* `response_mode=query` -> The code is provided inside a GET parameter: `?code=2397rf3gu93f`
+* `response_mode=fragment` -> The code is provided inside the URL fragment parameter `#code=2397rf3gu93f`
+* `response_mode=form_post` -> The code is provided inside a POST form with an input called `code` and the value
+* `response_mode=web_message` -> The code is send in a post message: `window.opener.postMessage({"code": "asdasdasd...`
+
 ### SSRFs parameters <a href="#bda5" id="bda5"></a>
 
-**[Check this research](https://portswigger.net/research/hidden-oauth-attack-vectors) For further details of this technique.**
+[**Check this research**](https://portswigger.net/research/hidden-oauth-attack-vectors) **For further details of this technique.**
 
 Dynamic Client Registration in OAuth serves as a less obvious but critical vector for security vulnerabilities, specifically for **Server-Side Request Forgery (SSRF)** attacks. This endpoint allows OAuth servers to receive details about client applications, including sensitive URLs that could be exploited.
 
 **Key Points:**
 
-- **Dynamic Client Registration** is often mapped to `/register` and accepts details like `client_name`, `client_secret`, `redirect_uris`, and URLs for logos or JSON Web Key Sets (JWKs) via POST requests.
-- This feature adheres to specifications laid out in **RFC7591** and **OpenID Connect Registration 1.0**, which include parameters potentially vulnerable to SSRF.
-- The registration process can inadvertently expose servers to SSRF in several ways:
-  - **`logo_uri`**: A URL for the client application's logo that might be fetched by the server, triggering SSRF or leading to XSS if the URL is mishandled.
-  - **`jwks_uri`**: A URL to the client's JWK document, which if maliciously crafted, can cause the server to make outbound requests to an attacker-controlled server.
-  - **`sector_identifier_uri`**: References a JSON array of `redirect_uris`, which the server might fetch, creating an SSRF opportunity.
-  - **`request_uris`**: Lists allowed request URIs for the client, which can be exploited if the server fetches these URIs at the start of the authorization process.
+* **Dynamic Client Registration** is often mapped to `/register` and accepts details like `client_name`, `client_secret`, `redirect_uris`, and URLs for logos or JSON Web Key Sets (JWKs) via POST requests.
+* This feature adheres to specifications laid out in **RFC7591** and **OpenID Connect Registration 1.0**, which include parameters potentially vulnerable to SSRF.
+* The registration process can inadvertently expose servers to SSRF in several ways:
+  * **`logo_uri`**: A URL for the client application's logo that might be fetched by the server, triggering SSRF or leading to XSS if the URL is mishandled.
+  * **`jwks_uri`**: A URL to the client's JWK document, which if maliciously crafted, can cause the server to make outbound requests to an attacker-controlled server.
+  * **`sector_identifier_uri`**: References a JSON array of `redirect_uris`, which the server might fetch, creating an SSRF opportunity.
+  * **`request_uris`**: Lists allowed request URIs for the client, which can be exploited if the server fetches these URIs at the start of the authorization process.
 
 **Exploitation Strategy:**
 
-- SSRF can be triggered by registering a new client with malicious URLs in parameters like `logo_uri`, `jwks_uri`, or `sector_identifier_uri`.
-- While direct exploitation via `request_uris` may be mitigated by whitelist controls, supplying a pre-registered, attacker-controlled `request_uri` can facilitate SSRF during the authorization phase.
+* SSRF can be triggered by registering a new client with malicious URLs in parameters like `logo_uri`, `jwks_uri`, or `sector_identifier_uri`.
+* While direct exploitation via `request_uris` may be mitigated by whitelist controls, supplying a pre-registered, attacker-controlled `request_uri` can facilitate SSRF during the authorization phase.
 
 ## OAuth providers Race Conditions
 
@@ -225,7 +234,6 @@ If the platform you are testing is an OAuth provider [**read this to test for po
 * [**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/" %}
@@ -239,7 +247,7 @@ Other ways to support HackTricks:
 * If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
 * Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
 * Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
-* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
+* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
 * **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
 
 </details>