What is Open Redirection? Ways to Exploit, Examples and Impact
Master Open Redirection: Learn technical exploit examples, bypass techniques, and remediation strategies to protect your web applications from phishing.
In the modern landscape of web application security, even seemingly minor vulnerabilities can lead to catastrophic consequences. One such vulnerability is Open Redirection. While often dismissed as a low-severity bug, it serves as a critical building block for sophisticated phishing campaigns, OAuth token theft, and cross-site scripting (XSS) attacks. Understanding how to identify, exploit, and remediate this flaw is essential for any cybersecurity professional or developer.
What is Open Redirection?
Open Redirection, also known as "Unvalidated Redirects and Forwards," occurs when a web application accepts user-controlled input to determine the destination of a redirect without proper validation. In a typical scenario, a website might use a parameter in the URL to send a user back to their original page after logging in or changing language settings.
For example, a URL might look like this:https://example.com/login?redirect_url=/dashboard
If the application does not verify that the redirect_url points to a safe, internal location, an attacker can modify it to point to a malicious external site:https://example.com/login?redirect_url=https://malicious-attacker.com
When the user clicks this link and successfully logs in, the browser automatically redirects them to the attacker's site. Because the initial link started with example.com, the user is more likely to trust the destination, making this a powerful tool for social engineering.
Technical Mechanics: How Redirects Work
To understand the vulnerability, we must look at how browsers handle redirection at the HTTP level. When a server wants to redirect a user, it sends an HTTP response with a 3xx status code (most commonly 301, 302, 303, 307, or 308) and a Location header.
HTTP Response Example
HTTP/1.1 302 Found
Location: https://example.com/dashboard
Content-Length: 0
When the browser receives this response, it immediately issues a new GET request to the URL specified in the Location header. In an Open Redirection scenario, the application logic takes a query parameter and injects it directly into this header.
Vulnerable Code Snippets
Let's look at how this vulnerability manifests in different programming environments.
PHP Vulnerability
In PHP, developers often use the header() function to perform redirects. If the input is not sanitized, it is inherently dangerous.
<?php
$target = $_GET['url'];
header("Location: " . $target);
exit;
?>
Node.js (Express) Vulnerability
In Express, the res.redirect() method is commonly used. Without validation, it is susceptible to the same flaw.
app.get('/redirect', (req, res) => {
const target = req.query.url;
res.redirect(target);
});
Python (Flask) Vulnerability
Flask provides a redirect() helper that can be easily abused if the URL is sourced directly from user input.
@app.route('/goto')
def do_redirect():
target = request.args.get('url')
return redirect(target)
Common Parameters to Look For
When performing infrastructure reconnaissance or bug hunting, keep an eye out for parameters that suggest redirection logic. Common names include:
url/uri/u/pathnext/dest/destinationredirect/redirect_to/redirect_uri/r/returnout/view/forward/fwd/linkcallback/checkout_url/continue
By monitoring your external attack surface with Jsmon, you can identify these parameters across your entire infrastructure and ensure they are properly secured.
Ways to Exploit Open Redirection
While a simple redirect might seem harmless, its utility in a multi-stage attack is significant.
1. Phishing and Social Engineering
This is the most common use case. Attackers use the reputation of a trusted domain to trick users. A victim is much more likely to click on a link that begins with https://trusted-bank.com than a random string of characters. Once the redirect occurs, the attacker presents a pixel-perfect clone of the login page to steal credentials.
2. Bypassing OAuth and SSO
In OAuth 2.0 flows, the redirect_uri parameter is used to send the authorization code back to the client application. If the authorization server is vulnerable to Open Redirection or has a loose validation policy (e.g., allowing subdomains), an attacker can redirect the code to their own server.
Example attack URL:https://oauth-provider.com/auth?client_id=123&redirect_uri=https://trusted-app.com/callback?url=https://attacker.com
If the application redirects the user to the url parameter after the callback, the attacker can capture the sensitive token in their server logs via the Referer header.
3. Chaining with XSS (JavaScript Pseudo-protocols)
If the application allows redirects using the javascript: protocol, the vulnerability escalates to Cross-Site Scripting (XSS).
Payload:https://example.com/redirect?url=javascript:alert(document.domain)
When the browser attempts to "redirect" to this URL, it executes the JavaScript within the context of example.com, allowing the attacker to steal cookies or perform actions on behalf of the user.
4. Bypassing SSRF Filters
Server-Side Request Forgery (SSRF) often involves making a server fetch a remote resource. Many SSRF filters block internal IP ranges (like 127.0.0.1 or 169.254.169.254). However, if the server follows redirects, an attacker can point the server to a URL on its own domain that has an Open Redirect vulnerability, which then points to the internal resource. The filter sees a request to a "safe" internal domain and allows it.
Advanced Bypass Techniques
Developers often attempt to fix Open Redirection using blacklists or simple regex, which are frequently bypassed by skilled researchers.
1. Protocol-Relative URLs
Instead of https://attacker.com, an attacker can use //attacker.com. Many filters only check if the string starts with http, failing to catch this valid URL format that inherits the current protocol.
2. The @ Symbol
Browsers interpret the @ symbol as a separator between user credentials and the hostname.https://example.com@attacker.com
In this case, the browser treats example.com as a username and actually navigates to attacker.com.
3. Backslashes and Slashes
Different browsers and parsers handle backslashes (\) differently.https://example.com/\attacker.com
Some filters see this as a subdirectory of example.com, while Chrome or Firefox might normalize it and redirect to attacker.com.
4. URL Encoding
Double or triple encoding the payload can often slip past poorly implemented Web Application Firewalls (WAFs).
- Single:
%2f%2fattacker.com - Double:
%252f%252fattacker.com
Real-World Impact
The impact of Open Redirection varies based on how it is chained. At a minimum, it results in Brand Damage. If your domain is used to facilitate a phishing campaign that steals thousands of user credentials, your domain's reputation and SEO ranking will plummet as it gets flagged by services like Google Safe Browsing.
In more severe cases, such as OAuth bypasses, it leads to Account Takeover (ATO). The ability to steal authorization tokens allows attackers to access private user data without ever knowing the user's password.
How to Prevent Open Redirection Attacks
Securing redirects requires a proactive approach to input validation and architectural design.
1. Avoid User-Provided Redirects
The best defense is to avoid using user input for redirects entirely. If you need to redirect a user back to a page, use a static mapping or a session-based approach where the destination is stored on the server side.
2. Implement a Strict Allowlist
If you must allow dynamic redirects, use a strict allowlist of approved domains or paths.
const allowed_destinations = ['/home', '/profile', '/settings'];
if (allowed_destinations.includes(user_input)) {
res.redirect(user_input);
}
3. Validate the Hostname
If you allow external redirects, ensure you parse the URL and validate the hostname correctly. Do not use simple string matching like indexOf() or startsWith(), as these are easily bypassed.
from urllib.parse import urlparse
def is_safe_url(target):
ref_url = urlparse(request.host_url)
test_url = urlparse(target)
return test_url.scheme in ('http', 'https') and \
ref_url.netloc == test_url.netloc
4. Use Indirect References
Instead of passing the full URL in the parameter, use an ID.https://example.com/redirect?id=42
The server then looks up ID 42 in a database to find the corresponding internal URL. This completely removes the attacker's ability to manipulate the destination.
Conclusion
Open Redirection is a deceptive vulnerability. While it doesn't directly leak data from a database like SQL Injection, its role as an "enabler" for more dangerous attacks makes it a high priority for security teams. By implementing strict allowlists, avoiding direct user input in the Location header, and using robust URL parsing libraries, developers can effectively neutralize this threat.
For security professionals, identifying these flaws across a sprawling infrastructure is the first step toward remediation. To proactively monitor your organization's external attack surface and catch exposures before attackers do, try Jsmon.
