Unvalidated redirects and forwards cannot harm your website or web application but they can harm your reputation by helping attackers lure users to malware sites. If you allow unvalidated redirects and forwards, your website or web application will most probably be used in phishing scams. Therefore, it is very important that you use redirects and forwards responsibly.
While unvalidated redirects and forwards did not make the OWASP Top 10 list in 2017, they were present on the list in 2013 (A10 Unvalidated Redirects and Forwards).
What Are Redirects and Forwards
A redirect is a situation when your website or web application causes the user’s browser to open another URL (external). A forward is a situation when instead of an external URL, your website or web application causes the browser to go to different parts of the site. Redirects and forwards are technically identical, the only difference is the type of destination: external URLs vs. internal pages.
From the technical point of view, the most common way to create redirects and forwards is for the web server to send a 3xx status code to the client (for example, 302 Found). This is done using back-end technologies, either in server-side programs or web server configuration. However, you can also create redirects and forwards directly in HTML using META tags (meta http-equiv="Refresh") or using client-side JavaScript.
What Are Unvalidated Redirects and Forwards
An unvalidated redirect or forward happens if your application uses a URL or a page name that is supplied directly from untrusted input. This makes it possible for an attacker to redirect the browser to a malicious site and use your domain name to gain the victim’s trust. For example, if your domain is example.com, the attacker may create the following URL:
http://www.example.com/redirect.php?url=http://evil.com
The attacker may then send this URL as part of a phishing attempt hoping that example.com at the beginning will have a trustworthy appearance, gain user’s trust, and make them fall for the phishing scam.
Note that exactly the same may happen if the intent of your application is to forward users to different pages within your site. If the user input parameters are unvalidated, a forwarding mechanism may be used to create a redirect.
An Example of an Unvalidated Redirect
If for some reason your application needs to redirect the user to another URL, some developers might use the following simple construct (example in PHP):
$new_url = $_GET['url'];
header("Location: " . $new_url);
This is an unvalidated redirect (in this case, a completely open redirect) because the attacker may supply a malicious URL in the url parameter of the GET request and this target URL will be used in the Location: header.
Consequences of Unvalidated Redirects and Forwards
In addition to phishing scams, unvalidated redirects and forwards may facilitate other types of attacks:
- Cross-site Scripting (XSS): If the redirect can use data: or javascript: protocols and the user’s browser supports such protocols in redirects, an XSS vulnerability may be introduced.
- Content-Security-Policy bypassing: If CSP is used to protect against XSS and a whitelisted domain has an open redirect issue, it may be used to bypass CSP.
- Server-Side Request Forgery (SSRF): Open redirects may be used to evade SSRF filters.
- CRLF Injection: If the destination parameter includes line breaks, a CRLF Injection attack may be possible (response header splitting).
How To Prevent Unvalidated Redirects and Forwards
The best solution to maintain web application security is not to use any redirects or forwards. However, if the website or web application cannot function properly without redirects or forwards, there is a number of ways for safe use.
- If you have a limited list of destination pages to redirect or forward to, store full URLs in the database, give them identifiers, and use the identifiers as request parameters, redirecting to the actual URL represented by an identifier. With such an approach, attackers will not be able to redirect or forward to unauthorized pages.
- If you cannot use a list of destination pages and/or URLs, filter untrusted URL input, preferably on the basis of a whitelist, not a blacklist. Be careful when checking for partial strings, for example, note that http://example.com.evil.com is a valid URL. Also, allow only HTTP and HTTPS protocols. Note that this solution is risky because errors in filtering may make certain attack vectors possible.
Get the latest content on web security
in your inbox each week.
THE AUTHOR
Principal Cybersecurity Writer
