Open Redirection Exploitation Tutorial - Part #1

Open redirects let you redirect a user from a trusted domain to an attacker-controlled domain via a URL parameter. They are often dismissed as low severity, but they are useful building blocks for phishing and for chaining with other vulnerabilities.

Finding open redirects

Look for URL parameters that control navigation. Common parameter names:

url, redirect, redir, next, return, rurl, dest, destination,
continue, target, path, forward, to, out, view, ref, go

Example vulnerable URL:

https://trusted-site.com/login?next=https://evil.com

After login, the application redirects to whatever is in the next parameter. If there is no validation, you control where the user ends up.

Chaining through trusted domains

Some targets validate the redirect URL against a whitelist. Chain through known open redirects on trusted domains to build a redirect path that passes validation:

# Google redirect (patched, but the concept applies)
https://www.google.com/url?q=https://evil.com

# YouTube redirect
https://www.youtube.com/redirect?q=https://evil.com

# Chain: target validates that redirect goes to google.com
https://target.com/login?next=https://www.google.com/url?q=https://evil.com

Bypassing validation filters

Applications often implement partial validation. Common bypasses:

Protocol-relative URLs - use // instead of https://:

https://target.com/redir?url=//evil.com

Filters that check for http:// or https:// at the start will miss this.

URL encoding - encode characters to evade string matching:

# Single encoding
https://target.com/redir?url=https%3A%2F%2Fevil.com

# Double encoding
https://target.com/redir?url=https%253A%252F%252Fevil.com

Domain confusion - abuse URL parsing edge cases:

# @ as credential separator
https://target.com/redir?url=https://[email protected]

# Subdomain matching bypass
https://target.com/redir?url=https://trusted-site.com.evil.com

# Backslash (some parsers treat \ as /)
https://target.com/redir?url=https://trusted-site.com\@evil.com

Hash and token bypasses

Some applications generate a hash or token to validate the redirect URL, preventing tampering. If the token is generated client-side (in JavaScript), you can reverse the algorithm and generate valid tokens for arbitrary URLs.

Common weak schemes:

• Base64-encoded URL in the parameter - decode, modify, re-encode
• Reversed base64 - reverse the string, then base64 decode
• HMAC with a key embedded in client-side JavaScript
• Simple CRC or hash with no server-side secret

# Base64 redirect parameter
https://target.com/redir?url=aHR0cHM6Ly9ldmlsLmNvbQ==

# Decoded: https://evil.com
echo "aHR0cHM6Ly9ldmlsLmNvbQ==" | base64 -d

Why it matters

Open redirects on their own are low impact. Their value is in combination: phishing (victim sees trusted domain in the URL bar before redirect), OAuth token theft (redirect_uri manipulation), and bypassing SSRF URL validation. Part 2 will cover these chained attacks.