/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/