Open Redirect Expert Attack Playbook

Problem It Addresses

An open redirect is not just an unexpected URL jump; it lets a trusted domain become an unauthorized launchpad. In real web applications, parameters like redirect, url, next, and return_to may accept attacker-controlled destinations. If validation is weak, an attacker can send https://bank.com/redirect?url=https://evil.com, where the visible domain looks legitimate while the destination is a phishing clone. The issue becomes more serious when the redirect chains with OAuth redirect_uri, CSRF Referer checks, server-side URL preview, window.opener, or redirect-following clients. This skill frames open redirect as a practical manual testing playbook: from locating sinks, to bypassing validators, to understanding exploit chains and parser differentials.

How It Works

• Find sinks: inspect server-side Location and 302 behavior, URL concatenation, and client-side assignments such as location.href, window.location, and location.replace.
• Bypass validators: cover patterns such as //evil.com, \/\/evil.com, https://trusted.com@evil.com, /\evil.com, endswith checks, and subdomain takeover.
• Chain exploits: explain how open redirect can amplify phishing, bypass Referer validation, leak OAuth implicit-flow tokens in fragments or authorization codes in query strings, and trigger SSRF when a server follows redirects.
• Use parser differentials: compare what a validator sees versus what a browser ultimately navigates to, including protocol-relative URLs, backslashes, userinfo sections, double encoding, and CRLF confusion.
• Check tabnabbing: look for target="_blank" links without rel="noopener", where a new tab can use window.opener to redirect the original page.

Scope and Caveats

This material is oriented toward authorized security testing and vulnerability analysis. It is useful for reviewing redirect logic, redirect_uri allowlists, OAuth callbacks, link unfurlers, URL preview services, and user-generated links. It is not a generic WAF rule list, nor does it replace validation against real application behavior. Actual exploitability depends on whether the target preserves query parameters or fragments, allows cross-protocol redirects, renders user-controlled links, and how its HTTP client decodes or follows redirect responses.