Open redirect is a type of web application security issue that allows attackers to use your business reputation to make phishing attacks more effective. If you allow open redirects, an attacker can send a phishing email that contains a link with your domain name and the victim will be redirected from your web server to the attacker’s site.
Note that open redirects were included as a vulnerability in the OWASP Top 10 list in 2013 (A10 Unvalidated Redirects and Forwards).
What Is a Redirect
What Is Open Redirection
An open redirect vulnerability exists when the destination of the redirect is provided by the client and it is not filtered or validated. Here are some examples of safe redirects and unsafe redirects:
- If the legitimate website redirects the client to a fixed URL, it is a safe redirect.
- If the legitimate website safely constructs the redirect URL based on parameters provided by the user, it is a safe redirect.
- If the legitimate website constructs the redirect URL based on parameters provided by the user but does not sufficiently validate/filter input, it is an unsafe redirect (the attacker may manipulate the input).
- If the legitimate website allows the user to specify the destination redirect URL, it is an unsafe redirect (open redirect).
In general, developers who use dynamic redirects (based on data from the client) must treat such data as untrusted input. If not, the attacker will 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 the following URL:
The attacker may then send this URL as part of a phishing attempt to redirect the victim to a malicious website attacker.com. The attacker would be hoping that example.com at the beginning will have a trustworthy appearance and make them fall for the phishing scam.
An Example of Open Redirection
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 and this target URL will then be sent as the Location header, redirecting the client to a malicious web page.
Consequences of Open Redirection Vulnerabilities
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 site that looks the same, steal user credentials, and then return to the vulnerable website as if nothing happened.
- 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 the 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 try to perform response header splitting.
How To Prevent Open Redirects
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 table and call them using identifiers as request parameters, not the URLs themselves. For example, store http://example2.com in the database table with the identifier 42 and then use the following call to redirect to example2.com: https://example.com/redirect.php?redir_id=42.
- If you cannot use a fixed list of redirection targets, filter untrusted input (if you can, using a whitelist, not a blacklist). Make sure to check for partial strings, for example, http://example.com.evil.com is a valid URL. Additionally, disallow all protocols except HTTP and HTTPS. Also note, that despite your best efforts it is possible that attackers may find a way around your filters.
Get the latest content on web security
in your inbox each week.
*** This is a Security Bloggers Network syndicated blog from Web Security Blog – Acunetix authored by Tomasz Andrzej Nidecki. Read the original post at: http://feedproxy.google.com/~r/acunetixwebapplicationsecurityblog/~3/Arv5Bfy9PbI/