Open redirect

What is an open redirect?

An open redirect is a vulnerability that allows your website, web application, or API to be used as a tool to trick others into visiting malicious sites. Similar to reflected cross-site scripting, open redirects are most often used in phishing attempts and other social engineering attacks. If someone receives a link that looks legitimate because it contains your domain name, they are more likely to click that link – and when they do, the open redirect vulnerability in your web application will be used to redirect the victim to a site controlled by a malicious hacker.

Open redirects are a specific type of unvalidated redirects and forwards.

Severity:		severe
Prevalence:		discovered regularly
Scope:		web applications that use redirects
Technical impact:		victims visit malicious websites
Worst-case consequences:		severe reputation loss
Quick fix:		do not redirect to URLs provided by user input

‍

How do redirects work?

Websites and web applications can change the URL accessed by a client:

• When a website or application changes the URL to another internal URL (within the same web application), it is usually called a forward.
• When the destination URL is external to the application (even if it remains within the same web server or domain), it is usually called a redirect or redirection.

There are several ways that web applications can perform such changes from the back-end, including:

• Sending a specific HTTP header to the client (Location)
• Specifying a META tag in the page HTML code (http-equiv="Refresh")
• Using JavaScript (window.location)

Redirects and forwards can be static (hard-coded in the web application) or dynamic (influenced by the client).

What is open redirection?

A dynamic redirect is considered unsafe if the destination URL can be manipulated by the client (for example, constructed from parameters provided by the client). It is considered open if the client can directly provide the target URL and no sanitization is performed. Here are some examples of safe redirects and unsafe/open redirections:

• If the legitimate website redirects the client to a fixed URL, it is a safe redirect (static).
• If the legitimate website safely constructs a dynamic redirect URL based on parameters provided by the user, it is a safe redirect.

• If the legitimate website constructs a dynamic redirect URL based on parameters provided by the user but does not sufficiently validate/filter input, it is an unsafe redirect (because an attacker may manipulate the input).
• If the legitimate website allows the user to directly specify the destination redirect URL and does not validate it (e.g. against a whitelist), it is an unsafe redirect (open redirect).

In general, whenever you use a dynamic redirect (based on data from the client), you should treat the URL inputs as untrusted data. Otherwise, attackers may be able to redirect the browser to a malicious site and use your domain name to fool the victim.

For example, if your domain is example.com, the attacker may create a URL with the following query string for the url parameter:

http://www.example.com/redirect.php?url=http://shadow.vulnweb.com

The attacker may then send this URL as part of a phishing attack to redirect the victim to a malicious website at shadow.vulnweb.com. The attacker would be hoping that example.com at the beginning will make the URL more trustworthy and persuade the user to click on the link and fall for the phishing scam.

Example of an open redirect vulnerability

The following simple PHP code creates an open redirect:

$redirect = $_GET['url'];
header("Location: " . $redirect);

This is an open redirection vulnerability because the attacker may supply a malicious website URL in the url parameter value of the GET request. This target URL will then be sent unsanitized in the Location header, redirecting the client to a malicious web page.

Potential consequences of an open redirect vulnerability

If you have an open redirection vulnerability, it makes many other attacks possible:

• Phishing: The most obvious way to use an open redirect is to steer the victim away from the original site to a cloned site, steal user credentials via a fake login page, and then return to the vulnerable website as if nothing happened.
• Malware: Attackers may redirect users to a malicious page that tricks them into downloading malware.
• Cross-site scripting (XSS): If the redirect allows the use of data: or javascript: protocol schemes and the client supports them in redirects, it allows attackers to perform XSS attacks.
• Server-side request forgery (SSRF): Open redirects may be used to evade SSRF filters.
• Content Security Policy bypassing: If you use CSP to protect against XSS and one of your whitelisted domains has an open redirect, this vulnerability may be used to bypass CSP.
• CRLF injection: If the redirection parameter allows line breaks, the attacker may include such special characters in the payload to perform response header splitting.

How to detect open redirect vulnerabilities?

The best way to detect open redirection vulnerabilities varies depending on whether they are already known or unknown.

• If you only use commercial or open-source web applications and do not develop web applications of your own, it may be enough to identify the exact version of the application you are using. If the identified version is susceptible to open redirection, you can assume that your website is vulnerable. You can identify the version manually or use a suitable security tool, such as a software composition analysis (SCA) solution.
• If you develop your own web apps or want the ability to potentially find previously unknown open redirect vulnerabilities (zero-days) in known applications, you must be able to successfully exploit the open redirect vulnerability to be certain that it exists. This requires either performing manual penetration testing with the help of security researchers or using a security testing tool (scanner) that can use automation to exploit web vulnerabilities. Examples of such tools are Invicti and Acunetix by Invicti. We recommend using this method even for known vulnerabilities.

How to prevent open redirect vulnerabilities?

The safest way to prevent open redirection vulnerabilities is not to use any redirections in your web applications. If this is not possible, you can attempt the following approaches:

• Use a list of fixed destination pages. Store their full URLs in a database and call them by passing identifiers, not the URLs themselves, as request parameters. For example, you could store http://example2.com in the database with the identifier 957 and then use the following call to redirect to example2.com: https://example.com/redirect.php?redir_id=957.
• If you cannot use a fixed list of redirection targets, filter untrusted input (if you can, using a whitelist, not a blacklist). Make sure you also check for partial strings – for example, http://example.com.vulnweb.com is a subdomain of vulnweb.com, but it might bypass a filter that only matches http://example.com. Additionally, disallow all schemes except HTTP and HTTPS. However, be aware that despite your best efforts, it is possible that attackers may find a way around your filters.

How to mitigate open redirect attacks?

There is no way to fully prevent developers from using redirections, whether by configuring the web server or by setting up the development environments. This is due to the variety of methods that can be used to perform redirection, as well as the fact that web development languages such as Java or PHP rarely provide specific language constructs for URL redirection only.

End-users may attempt mitigation by relying on specific browser configurations or extensions. The wikiHow article on blocking page redirects has an extensive list of instructions for turning off automatic redirections in different browsers.