How Open Redirection Threatens Your Web Applications

Open redirection is listed in the OWASP Top 10 for 2013 and 2010 (10th position in both lists) since it is still an active threat in modern web applications. Open redirection occurs when a vulnerable web page is redirected to an untrusted and malicious page that may compromise the user. Open redirection attacks usually come with a phishing attack because the modified vulnerable link is identical to the original site, which increases the likelihood of success for the phishing attack.

While open redirection is not exactly common, my research was able to uncover several open source applications that were vulnerable. In this article, I describe the results of my research, and some recommendations for avoiding open redirection vulnerabilities in your code.

Hide the remainder of this articleVulnerability Found and Fixed in Moodle

Six months ago when I was evaluating the popular open source learning management software Moodle, I discovered an open redirect vulnerability caused by a lack of constraints on the referer parameter. This vulnerability could redirect users to a non-local website and launch a phishing attack. It has been fixed (by adding code to replace the referer with a local URI when the referer value was used as a redirection vector), and the detail has been listed in CVE-2015-3175 and MSA-15-0019.

Here's how the vulnerability could be exploited:

Proof of Concept

GET /moodle/mod/forum/post.php?forum=1 HTTP/1.1
Host: Yourhost
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://www.qualys.com
Connection: keep-alive

By make the request and clicking the "cancel" button in the response page, the user will be redirected to https://www.qualys.com. By taking advantage of this vulnerability, an attacker could launch a phishing attack there very easily.

Research Uncovered More Vulnerable Applications

After submitting this issue and getting it accepted by the Moodle developer team, I decided to commit some time to check whether open redirection is a popular and underlying threat that could damage modern web applications.

I conducted some pen tests against some popular web sites as well as some web applications in a bounty list.

After conducting research off-and-on for several months, the results are bittersweet. The good news is that most web applications are deployed with some input validation to block redirection to a different domain when there are users' input requiring a URL value. However, some web applications do not implement the countermeasure correctly or they do not protect against open redirection at all, which leaves them vulnerable.

Interesting Discoveries

During the survey, I observed several common interesting behaviors of the web applications vulnerable to open redirection.

Login Pages Require the Most Attention

Login Pages are the most likely places where the open redirection can be found. Current modern web applications track users' original request before authentication and redirect the users to the page after authentication. Here is how a common web application behaves: an unauthenticated user makes a request to http://example.com/myprofile. The website will redirect the user to the login page and remember the original request by adding a parameter under the login page http://example.com/login?toURL=http://example.com/myprofile . After the user logs in, she/he will be redirected to http://example.com/myprofile. Since this kind of behavior requires a redirection, it becomes the most vulnerable part of the web application regarding to open redirection attack.

Some Applications Have No Protection

I found two web applications vulnerable to open redirection attacks at the login page because they do not implement any countermeasures. An attacker could send the victim a link like http://example.com/login?toURL=http://evil.com/login. Since the vulnerable link is identical to the original site, the user will think it as a trusted link and enter valid credentials and then she/he will be redirected to the http://evil.com/login and it could ask for the credentials again by claiming they're not valid; which leads to a simple and efficient phishing attack.

Countermeasures Are Not Working Properly

Some web applications implement countermeasures which are not robust enough to eliminate the open redirection vulnerability. One web application in the survey was vulnerable to open redirection after a weak countermeasure is deployed in the application.

The vulnerable page is at http://example.com/view_topic?view=/topic1.html. The web application implemented input validation on the parameter view. If the value of the parameter view starts with http or https, an error will be flagged to indicate page not found. For example, an error was flagged when a request was made to http://example.com/view_topic?view=http://www.qualys.com because the value starts with http. However, if the request http://example.com/view_topic?view=//www.qualys.com is made, you will be redirected to http://www.qualys.com without any error message.

Attacks via the Referer Header

As described in the previous section, the injection point for the open redirection in Moodle was the referer header. A lot of countermeasures do not implement any restriction or validation for this injection point. It's recommended to do what Moodle did -- prevent redirection to non-local websites.

Conclusion

To mitigate an open redirection vulnerability, the best strategy is to eliminate the potential risks before the implementation phase. Qualys Web Application Scanning (WAS) coupled with a program for secure software development practices enables developers to test for this vulnerability at various phases in the development process.

According to my survey, most web applications do not allow cross-domain redirections intentionally. If that is the case, developers should implement robust input validation strategies, which will decline or rewrite all the redirection requests to different domains. If you want to make redirection under several domains, it is a good practice to add the domains in the whitelist and only allow redirection to the links originating from these whitelists. If you have to make redirection to some third party websites, it is important to clearly remind the users that they are being redirected to a third party website.