Cybersecurity

User Tools

Site Tools

Trace:
zseano:open_redirects

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

zseano:open_redirects [2026/05/14 09:58] – add zseano methodology article drewzseano:open_redirects [2026/05/14 10:46] (current) – merge bbc ch7 open redirects techniques drew
Line 64: Line 64:
   * [[tbhm:04_authorization|TBHM Auth & Session]]   * [[tbhm:04_authorization|TBHM Auth & Session]]
   * [[zseano:start|Methodology Index]]   * [[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.
  
zseano/open_redirects.txt · Last modified: by drew
Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki