| name | open-redirect-advanced |
| description | Advanced open-redirect testing: multi-parser gaps, allowlist failures, encoding and scheme tricks, and chains into OAuth/OIDC redirect_uri and token theft. Use when basic next/return checks exist but Location still leaves the trusted host, or when post-login/SSO exits need deep bypass work. |
Open Redirect — Advanced Parser And OAuth Chains
Scope And Authorization
- Authorized apps, labs, CTFs, and owned systems only. Redirect only to domains you control (collaborator/OAST). Do not phish real users.
- Prefer non-destructive proofs: one hop to your canary. Capture raw
Location with auto-follow off.
- OAuth chains may expose
code / tokens — use test clients and accounts only. Redact secrets in tickets.
When To Use
- Basic
open-redirect ladder failed (//evil blocked) but residual bypasses are suspected.
- Login, logout, SSO callback, email exit, or deep-link bridge uses a return URL with partial allowlisting.
- Validators use
contains, startsWith, regex, or dual stacks (gateway + app + JS) that disagree on host/scheme.
- OAuth/OIDC
redirect_uri or RP return_to reuses the same weak parser as site redirects.
- Keywords: open redirect bypass, allowlist bypass, parser discrepancy, OAuth redirect chain.
Core Model
User-controlled return → filter layer(s) → Location / window.location
→ browser final authority → phishing / token leak / OAuth code theft
| Gap class | Failure |
|---|
| String allowlist | Substring trusted.com ≠ real host |
| Dual parser | Server accepts; browser leaves site (or reverse) |
| Normalize-late | Decode after validation |
| Relative confuse | Path-looking values become scheme-relative |
| OAuth chain | RP open redirect lands code/token on attacker |
Good proof: Browser-resolved host is attacker-controlled; for OAuth, test code/token hits canary.
Bad proof: HTML reflection without navigation; same-host path-only change claimed as full open redirect.
Workflow
-
Inventory sinks — Query (next, return, returnUrl, redirect, continue, goto, RelayState), nested/base64 return_to, client JS/meta, OAuth redirect_uri / post_logout_redirect_uri. Note 302/303/307 and client-only checks.
-
Classify control — Baseline allowed internal path vs blocked https://canary.example.
| Control | Signal |
|---|
| None | External accepted |
| Blocklist | Only known bad strings rejected |
| Prefix/contains | Trusted substring required |
| Parse-host | Host extracted then compared |
| Key map | Opaque keys → fixed paths (strong) |
-
Advanced payload ladder (adapt canary; after basics fail)
| Class | Examples | Why |
|---|
| Userinfo | https://trusted.com@canary.example/ | Filter sees trusted string |
| Scheme-relative | //canary.example, /\canary.example | Path vs authority |
| Backslash | https://canary.example\.trusted.com | Legacy \ as / |
| Encoding | %2f%2fcanary.example, %252f%252f | Validate raw; sink decodes |
| Dot / eTLD | https://trusted.com.canary.example | Contains vs DNS host |
| Port / scheme | https://trusted.com:443@canary.example, https:canary.example | Parser split |
| Data / JS | javascript:..., data:text/html,... |
Routing
| Need | Skill |
|---|
| First-pass inventory / simple payloads | open-redirect |
| OAuth/OIDC client, state, PKCE | oauth-oidc-misconfiguration |
| CSRF gadget via top-level navigation | csrf-cross-site-request-forgery |
| SID in return URL / no regenerate | session-fixation-management |
| Reset link Host vs redirect token leak | password-reset-poisoning |
| Server-side fetch of target | ssrf-server-side-request-forgery |
| CRLF into Location | crlf-injection |
| Secure allowlist / redirect-key code | code-quality-standards |
Output Checklist
Rules
- Record raw redirects; auto-follow hides bugs. Canary domains only.
- Parser-gap needs dual evidence (filter decision + browser host).
- OAuth impact only with test clients/accounts — no production phishing.
- One solid off-site navigation with context beats an unvalidated payload dump.
- Authorized testing only.
