$npx -y skills add elementalsouls/Claude-BugHunter --skill hunt-oauthHunting skill for oauth vulnerabilities. Built from 19 public bug bounty reports. Use when hunting oauth on any target.
| 1 | ## Crown Jewel Targets |
| 2 | |
| 3 | 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. |
| 4 | |
| 5 | **Highest-value targets:** |
| 6 | - **Consumer identity providers** (Google, Facebook, PayPal, Apple SSO integrations) — any compromise cascades across all relying parties |
| 7 | - **Mobile apps with custom deep link OAuth handlers** — Android/iOS intent handling is notoriously loose |
| 8 | - **Multi-tenant SaaS platforms** (GitLab, Reddit-scale apps) where one OAuth flaw hits millions of accounts |
| 9 | - **Gaming/entertainment platforms** with federated login (Rockstar, Oculus) — often security-immature teams |
| 10 | - **Enterprise SSO connectors** — critical infrastructure, high severity payouts |
| 11 | |
| 12 | **Asset types that pay most:** |
| 13 | - OAuth authorization endpoints (`/oauth/authorize`, `/connect/authorize`) |
| 14 | - Token exchange endpoints (`/oauth/token`) |
| 15 | - Mobile deep link handlers (`push_notification_webview`, custom scheme URIs) |
| 16 | - Social login callback handlers (`/auth/callback`, `/oauth/callback`) |
| 17 | |
| 18 | **Typical payouts:** $500–$20,000+ depending on program; account takeover findings often hit max bounty. |
| 19 | |
| 20 | --- |
| 21 | |
| 22 | ## Attack Surface Signals |
| 23 | |
| 24 | ### URL Patterns to Hunt |
| 25 | ``` |
| 26 | /oauth/authorize |
| 27 | /oauth/token |
| 28 | /connect/authorize |
| 29 | /auth/callback |
| 30 | /oauth/callback |
| 31 | /login?redirect_uri= |
| 32 | /signin?next= |
| 33 | /auth?return_to= |
| 34 | /oauth/redirect |
| 35 | /push_notification_webview |
| 36 | ``` |
| 37 | |
| 38 | ### Response Headers That Signal OAuth |
| 39 | ``` |
| 40 | Location: https://accounts.example.com/oauth/... |
| 41 | Set-Cookie: oauth_state= |
| 42 | WWW-Authenticate: Bearer |
| 43 | Content-Type: application/json (with access_token in body) |
| 44 | ``` |
| 45 | |
| 46 | ### JavaScript Patterns (grep in JS bundles) |
| 47 | ```javascript |
| 48 | redirect_uri |
| 49 | client_id |
| 50 | response_type=code |
| 51 | response_type=token |
| 52 | state= |
| 53 | nonce= |
| 54 | oauth_token |
| 55 | access_token |
| 56 | push_notification_webview |
| 57 | deeplink |
| 58 | intent:// |
| 59 | ``` |
| 60 | |
| 61 | ### Tech Stack Signals |
| 62 | - Android apps with `intent-filter` in `AndroidManifest.xml` handling `http://` or custom scheme URIs |
| 63 | - Apps using Doorkeeper, OmniAuth, Devise (Ruby), Passport.js (Node), Spring Security OAuth |
| 64 | - Social login buttons (Google, Facebook, Apple) = OAuth surface guaranteed |
| 65 | - `.well-known/openid-configuration` present = full OIDC surface available |
| 66 | |
| 67 | --- |
| 68 | |
| 69 | ## Step-by-Step Hunting Methodology |
| 70 | |
| 71 | 1. **Enumerate all OAuth entry points** |
| 72 | - Spider the app for `/oauth`, `/connect`, `/auth`, `/login` paths |
| 73 | - Check `.well-known/openid-configuration` and `.well-known/oauth-authorization-server` |
| 74 | - Decompile mobile APKs: `apktool d app.apk` and grep for `redirect_uri`, `intent://`, deep link schemes |
| 75 | |
| 76 | 2. **Map the full OAuth flow** |
| 77 | - Capture the authorization request: note `client_id`, `redirect_uri`, `state`, `nonce`, `response_type` |
| 78 | - Capture the callback: note where tokens/codes land, what validates state/nonce |
| 79 | |
| 80 | 3. **Test `redirect_uri` validation (highest yield)** |
| 81 | - Try exact host bypass: `redirect_uri=https://legit.com.evil.com` |
| 82 | - Try path traversal: `redirect_uri=https://legit.com/callback/../../../evil` |
| 83 | - Try open redirects on the legitimate domain first, then chain into OAuth |
| 84 | - Try parameter pollution: `redirect_uri=https://legit.com&redirect_uri=https://evil.com` |
| 85 | - Try encoded characters: `%2F`, `%40`, `%23` to confuse parsers |
| 86 | |
| 87 | 4. **Test `state` parameter (CSRF)** |
| 88 | - Remove `state` entirely — does the flow complete? |
| 89 | - Reuse a fixed `state` value across sessions |
| 90 | - Check if `state` is validated server-side or only client-side |
| 91 | |
| 92 | 5. **Test `nonce` parameter (replay/bypass)** |
| 93 | - Capture a nonce from one flow, attempt to replay it in another |
| 94 | - Check if nonce is validated after token exchange |
| 95 | - Test if nonce can be extracted via referrer leak (step 9) |
| 96 | |
| 97 | 6. **Test authentication step completeness** |
| 98 | - For multi-step auth (e.g., email verification + OAuth): can you skip to `/oauth/token` directly? |
| 99 | - Check if partial auth state (unverified email) is accepted by the token endpoint |
| 100 | |
| 101 | 7. **Hunt referrer leakage** |
| 102 | - After OAuth callback with tokens in URL fragment or query, check if any on-page resources (images, scripts, iframes) receive the full `Referer` header |
| 103 | - Look specifically at language switchers, analytics calls, social share buttons triggered post-auth |
| 104 | |
| 105 | 8. **Test mobile deep links** |
| 106 | - For Android: craft malicious intent URIs that redirect the OAuth webview to attacker-controlled URLs |
| 107 | - Check if deep link handlers validate the origin/host before loading |
| 108 | - Test `push_notification_webview` patterns that accept arbitrary URLs |
| 109 | |
| 110 | 9. **Test misconfigured client credentials** |
| 111 | - Check if `client_secret` appears in JS bundles or APK resources |
| 112 | - Test if token endpoint accepts arbitrary `redirect_uri` values when combined with leaked `client_id`/`client |