Unvalidated redirects and forwards

What are unvalidated redirects and forwards?

An unvalidated redirect or forward vulnerability allows malicious hackers to influence where your website, web application, or API redirects an end user. Unvalidated redirects and forwards are most commonly used in phishing attempts but may lead to other attacks as well. The most dangerous type of unvalidated redirects and forwards are open redirects.

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 build redirect URLs from user input

What are redirects and forwards?

Websites and web applications can alter the URL that a client accesses, and two different names are used for this behavior:

• A forward is the term used when a website or application changes the URL to another internal URL (within the same web application).
• A redirect is the term used when the destination URL is external to the application, even if it remains within the same web server or domain.

There are several ways for web applications to make such changes on the back end, including:

• Sending a specific HTTP response code (e.g. 301 Moved Permanently or 307 Temporary Redirect) and an HTTP header to the client (the Location header)
• Specifying a META tag in the HTML code (e.g. <meta http-equiv="Refresh" content="0; URL=https://example.com/" />)
• Using JavaScript (window.location)

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

What are unvalidated redirects and forwards?

A dynamic redirect or forward is considered unvalidated if the application does not perform any validation on user-supplied values used in the target URL. This can mean either taking the entire URL from user input or using the input data as a partial building block for the destination URL. An unvalidated redirect that simply redirects to the string provided via user input is called an open redirect.

For example, if your domain is example.com and your site has an unvalidated redirect vulnerability, an attacker may create a URL with the following url parameter value:

http://www.example.com/redirect.php?url=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 have a trustworthy appearance and encourage the user to click on the link and fall for the phishing scam.

Example of an unvalidated forward

The following is simple PHP code for an unvalidated forward that could be exploited to perform a malicious redirect:

$subpage = $_GET['subpage'];
header("Location: https://www.example.com/" . $subpage);

The developer assumes that the $subpage parameter will contain a valid subpage name, such as videos, and the web application will send the following header to the user:

Location: https://www.example.com/videos

However, an attacker may manipulate the parameter value and perform CRLF injection by providing the following payload to construct the target URL:

?subpage=videos%0d%0aLocation:%20https://shadow.vulnweb.com

As a result, the browser will receive two Location headers:

Location: https://www.example.com/videos
Location: https://shadow.vulnweb.com

Faced with two headers to choose from, some browsers (for example, Mozilla Firefox) will use the second header, allowing for a successful attack.

You can find more examples of unvalidated redirects and forwards in the OWASP unvalidated redirects and forwards cheat sheet.

Potential consequences of unvalidated redirects and forwards

Unvalidated redirects and forwards allow malicious hackers to exploit other attack vectors, for example:

• Phishing: The most straightforward use for an unvalidated redirect or forward is to take the victim away from the original webpage and navigate to a cloned malicious site to steal user credentials.
• Malware: An attacker may lead a user to a malicious URL where the user is tricked into downloading malicious software.
• Cross-site scripting (XSS): If the redirect allows the data: or javascript: protocols and the client supports them in redirects, attackers could conduct an XSS attack.
• Server-side request forgery (SSRF): Unvalidated redirects and forwards may be used to evade SSRF filters.
• Content Security Policy bypassing: If a domain whitelisted by your CSP directives has an unvalidated redirect or forward, it may be used to bypass CSP.
• CRLF injection: If the redirection parameter allows line breaks, attackers may include them in payloads to perform response header splitting.

How to detect unvalidated redirects and forwards?

The best way to detect unvalidated redirects and forwards 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 has unvalidated redirects and forwards, 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 unvalidated redirects and forwards (zero-days) in known applications, you must be able to successfully exploit the unvalidated redirects and forwards to be certain that they exist. 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 unvalidated redirects and forwards?

The best method to guard against unvalidated redirects and forwards is to avoid using any redirections in your web applications. If this is not possible, you have the following options:

• Use a list of fixed destination pages. The complete page URLs should be stored in a database and never used directly. Instead, use URL IDs as request parameters. For example, if you stored http://example.org in the database with the identifier 957, you could then use the following call to redirect to example.org: https://example.com/sendredirect.php?redir_id=957.
• If you cannot use a preset list of redirection targets, you should filter any untrusted inputs, if possible, using a whitelist, not a blacklist. Be sure to also check for partial strings (otherwise, a URL like http://example.com.vulnweb.com could bypass a filter that only matches http://example.com). Moreover, only HTTP and HTTPS protocols should be permitted. But as always with filtering, be aware that attackers could find ways to bypass your filters despite your best efforts.

How to mitigate attacks via unvalidated redirects and forwards?

Configuring your web server or development environments will not prevent developers from employing redirections. This is because there are so many ways to perform a redirect, especially since web development languages like Java, Python, or PHP rarely include dedicated language structures for URL redirection. The only way to mitigate such attacks is on the client side.

End users may try to mitigate the problem by relying on specific browser configurations or plugins. The wikiHow article on blocking page redirects has an extensive list of instructions for turning off automatic redirections in different browsers.

Frequently asked questions

Written by: Tomasz Andrzej Nidecki, reviewed by: Benjamin Daniel Mussler