OAuth 2.0 Protocol Penetration Testing

Cited from TryHackMe THM Room OAuth Vulnerabilities

1) OAuth Application Identification

The first indication that an application uses OAuth is often found in the login process. Look for options allowing users to log in using external service providers like Google, Facebook, and GitHub. These options typically redirect users to the service provider's authorization page, which strongly signals that OAuth is in use.

When analyzing the network traffic during the login process, pay attention to HTTP redirects. OAuth implementations will generally redirect the browser to an authorization server's URL. This URL often contains specific query parameters, such as response_type, client_id, redirect_uri, scope, and state. These parameters are indicative of an OAuth flow in progress. For example, a URL might look like this:

https://dev.coffee.thm/authorize?response_type=code&client_id=AppClientID&redirect_uri=https://dev.coffee.thm/callback&scope=profile&state=xyzSecure123

Once you have confirmed that OAuth is being used, the next step is to identify the specific framework or library the application employs. This can provide insights into potential vulnerabilities and the appropriate security assessments. Here are some strategies to identify the OAuth framework:

1) HTTP Headers and Responses

• Inspect HTTP headers and response bodies for unique identifiers or comments referencing specific OAuth libraries or frameworks.

2) Source Code Analysis

• If you can access the application's source code, search for specific keywords and import statements that can reveal the framework in use. For instance, libraries like django-oauth-toolkit, oauthlib, spring-security-oauth, or passport in Node.js, each have unique characteristics and naming conventions.

3) Authorization and Token Endpoints

• Analyze the endpoints used to obtain authorization codes and access tokens. Different OAuth implementations might have unique endpoint patterns or structures. For example, the Django OAuth Toolkit typically follows the pattern /oauth/authorize/ and /oauth/token/, while other frameworks might use different paths.

4) Error Messages

• Custom error messages and debug output can inadvertently reveal the underlying technology stack. Detailed error messages might include references to specific OAuth libraries or frameworks.

2) Stealing OAuth Token

The attacker has compromised a domain that is part of the OAuth flow, more specifically, the redirect_uri domain that the OAuth flow points to.

Attacker sends a link via social engineering to the victim, and while the victim enters his credentials, the attacker hijacks his OAuth token because the domain that the token passes through in the OAuth flow goes to the attacker controlled domain that can host any content the attacker wants inside the compromised domain.

The HTML files in this example are in the scripts folder in this repository.

After the attacker intercepts the authorization code with this technique, he can go to the callback URL endpoint of the OAuth application, and insert the intercepted authorization code to finally steal the access token of the victim.

3) Cross-Site Request Forgery (CSRF)

Requirements: Missing the state parameter in the OAuth URL. If the state parameter is present, the CSRF attack is not possible.

To prepare the payload, the attacker must get his authorization code. This can be done by intercepting the authorization process using a tool like Burp Suite or any other network interception tool.

Example URL intercepted with Burp:

http://coffee.thm:8000/o/authorize/?response_type=code&client_id=kwoy5pKgHOn0bJPNYuPdUL2du8aboMX1n9h9C0PN&redirect_uri=http://coffee.thm:8000/oauthdemo/callbackforcsrf/

Attacker enters his credentials after he visits the above link to get his authorization code to conduct the attack.

The above authorization code would enable anyone to get an access token against it. The URL parameter in the response is the actual payload that we need to send to the victim. Copy the Payload value, which we will use while launching the attack.

Once the attacker has obtained the authorization code, he can prepare the CSRF payload.

Attacker then, sends an email to the victim via social engineering.

After receiving the email, if the victim clicks on the link or executes it in his browser (where xxx is the attacker's authorization code), the attacker's CoffeeShopApp OAuth account will be linked to the victim's account. This effectively transfers all the contacts from the victim's account to the attacker's.

Victim logs into the client app with his credentials.

Victim executes the attacker exploit sent by him by with his browser.

As discussed above, the exact link sent to the victim is the URL parameter received during the Preparing the Payload process. Once executed, the code will make a call to get the access token and send contacts/messages to the attacker's account.

4) Implicit Grant Flow

In the implicit grant flow, tokens are directly returned to the client via the browser without requiring an intermediary authorization code. This flow is primarily used by single-page applications and is designed for public clients who cannot securely store client secrets. However, this flow has inherent vulnerabilities:

1) Exposing Access Token in URL

• The application redirects the user to the OAuth authorization endpoint, which returns the access token in the URL fragment. Any script running on the page can easily access this fragment.

2) Inadequate Validation of Redirect URIs

• The OAuth server does not adequately validate the redirect URIs, allowing potential attackers to manipulate the redirection endpoint.

3) No HTTPS Implementation

• The application does not enforce HTTPS, which can lead to token interception through man-in-the-middle attacks.

4) Improper Handling of Access Tokens

• The application stores the access token insecurely, possibly in localStorage or sessionStorage, making it vulnerable to XSS attacks.

Use "access_token_xss" payload to steal the access token with this vulnerability

TIP: Since OAuth 2.1, Implicit Grant Flow has been completely deprecated from this version.

5) Insufficient Token Expiry

Access tokens with long or infinite lifetimes pose a significant security risk. If an attacker obtains such a token, they can access protected resources indefinitely. Implementing short-lived access and refresh tokens helps mitigate this risk by limiting the window of opportunity for attackers.

6) Replay Attacks

Replay attacks involve capturing valid tokens and reusing them to gain unauthorized access. Attackers can exploit tokens multiple times without mechanisms to detect and prevent token reuse. Implementing nonce values and timestamp checks can help mitigate replay attacks by ensuring each token is used only once.

7) Insecure Storage of Tokens

Storing access tokens and refresh tokens insecurely (e.g., in local storage or unencrypted files) can lead to token theft and unauthorized access. Using secure storage mechanisms, such as secure cookies or encrypted databases, can protect tokens from being accessed by malicious actors.