How Open Redirection Threatens Your Web Applications
Last updated on: September 6, 2020
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.
Vulnerability 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.
Nice post!
I am confused by the “Poof of Concept” section. How do an attacker make victim’s browser issue a request with a malformed “Referer” header?
Thanks!
Hi Whucjj,
It is hard to make the victim’s browser to make a request with a malformed “Referer” header in a real attack. To exploit this vulnerability. It is not necessary to use encoded Referer Header to exploit this vulnerability, you could use a normal referer header, such as “https://www.qualys.com” in the request header to launch an attack, which is easy to implement!
The intention to use malformed “referer” (ASCII Encoded) in the POC is to show that this vulnerability could also lead to a XSS attack. If you use “javascript:alert(‘xss’)” in the referer header, your request will be rejected; however, if you encode the payload to javascript:alert('xss') in the referer header, the request will go through!
I hope it make some sense for you!
Regards
Daniel
But for an attacker to set the referer it would have to send the victim to the malicious site in the first place: malicious_site -> vulnerable_site -> malicious_site again.
How could this be explored in real life, for an application that copies uses the referer verbatim to redirect?
Hi Tiago,
Sorry for the delayed reply. Here could be a real scenarios
1. The victim is visiting a forum, which is a malicious website
http://evil.example.com/?alert(123)>
2. The malicious page above will redirect to the vulnerable page
http://victim.example.org/vulnerable_xss_page.php
3. The malicious website http://evil.example.com/?alert(123)> will be preserved as the Referer value when the victim is redirected to the vulnerable page. As a consequence, the JavaScript code in the refer value will be executed.
Does it make any sense for you?
Daniel
Hi Daniel
I have the same opinion as Tiago – Your above example has the user already on a malicious/evil site – If the user is on such a site, an attacker does not need my application’s Open Redirect flaw to get me onto the evil site.
I agree that a XSS flaw on my site/applicaiton can be exploited through the referer header, but that’s a different issue and could be fixed by output sanitization (or other means).
But how can an attacker make practical use of an Open Redirect issue through phishing if the referer is being used for the redirect, seeing that a phish email will not be able to set the referer?
I completely agree that the referer header is not the best way to mitigate the issue, but in some scenarios and applications you don’t have anything else to use.
Hoping I’m not missing something obvious.