In-brief: Open redirects and forwards may be at the bottom of OWASP’s Top 10 list of web application security vulnerabilities, but they are still a potent and widespread problem, says Akamai’s Or Katz, who offers some suggestions for fixing it.
Open redirection is the last item on the OWASP Top 10, and it is considered a Web application functionality that can be used by attackers to redirect users from trusted domains to untrusted domains. But it is a potent problem, as Akamai’s Threat Research Team discovered in their research on an unusual malicious SEO attack campaign that abused Web applications’ open redirect functionality.
In the attack campaign discovered and analyzed by Akamai’s Threat Research Team, the attackers abused the redirected Web application’s reputation in order to promote search engines ranking for thousands of targeted Web applications. And, more recently Akamai Threat Research Team detected similar volumetric activity while analyzing questionable activity over Akamai’s Cloud Security Intelligence (CSI) network. We suspect it is being controlled by the same attackers from a year ago.
This time, instead of analyzing the campaign’s attacking sources and traffic we decided to focus our research on the redirecting Web applications. Here are the highlights of our findings:
How many redirecting Web applications?
We verified 553 Web applications that have a working open redirect functionality, among those Web applications we identified those associated with fortune 100 companies, government agencies, non-profit organizations and even a bank. Analyzing redirecting pages out of 553 Web applications, 270 are vulnerable to reflected Cross Site Scripting (XSS).
Why do SEO attack campaigns abuse open redirect functionality?
We believe that the answer for that can be found in the “notify and confirm” redirection mechanism that is considered the recommended way for mitigating open redirects exploitation. The users destination input is being reflected into the server’s response as a “notify and confirm” link. This link, when being used without the relevant HTML attribute, is what makes the SEO attack campaign successful. In other words, the recommended mitigation created a new problem.
Analyzing Redirecting Web Applications
Analysis of the recent attack campaign data with information that was collected from hackers Web forums, revealed a list of more than 4000 Web pages suspected to include open redirect functionality. Checking those links shows that while many of them are targeting Web pages that are no longer active, 553 Web pages contain a working redirect functionality (without white-list limitation on the destination).
Those active Web pages use the “notify and confirm” mechanism, meaning the requested destination is being reflected to a Web application response as an HTML referring link (i.e HTML href object). The “notify and confirm” mechanism makes sure that users won’t be redirected without clicking the new destination link.
The redirecting Web applications are from all over the world, representing industry segments such as: non-profits organizations, banking, government, educational organizations and e-commerce.
Analyzing Redirecting Pages
Since the “notify and confirm” mechanism reflects users’ input into the Web application response, we decided to check whether those redirecting pages are vulnerable to reflected Cross Site Scripting (XSS). The results show that 270 – or 48 percent – of the redirecting pages are vulnerable to reflected Cross Site Scripting.
Out of the 553 redirecting Web applications, 62 are safe from SEO attack. These 62 pages contain an HTML setting that will instruct search engines not to follow the link. However, out of that population of 62 redirecting Web applications with the proper HTML setting, 15 are still vulnerable to XSS. In other words, only 8 percent (47 Web applications) of the redirecting Web applications should be truly considered as safe.
Best Practices for Redirects
Earlier this year, our own Ezra Caltum, a senior security researcher at Akamai, presented in AppSec Europe in Amsterdam research done by Akamai’s Threat Research Team. (There’s more on his research on Akamai’s blog.) In his presentation, Ezra referred to a OWASP un-validated redirects and forwards “cheat sheet.” This cheat sheet recommended sanitizing open redirects by forcing users to first go pass by a page that notifies users that they are going off of your site. Users would then have to click a link to confirm their decision to be forwarded to a different site.
In fact, we now realize the same “notify and confirm” mechanism that was supposed to protect users from being exploited may be an element in the SEO attacks we have observed. Simply: the “notify and confirm” mechanism enables attackers to create a chain of HTML referring links to the promoted (malicious) Web applications. This chain runs through the redirecting pages.
Why? We know that search engines such as Google are working hard to keep the abused redirecting pages out of their index. But Google is only using the “nofollow” attribute on redirecting pages to instruct search engines not to follow such a reflected HTML links. To mitigate SEO attacks that abuse open redirect functionality, additional steps are needed.
We recommend the following actions:
- If possible, develop a whitelist of the target domains that are trusted destinations
- Set the robots.txt page to disallow search engines from accessing the redirecting pages
- Add an HTML “meta” tag to the redirecting pages or “rel” attribute to links with the value “nofollow.” That will prevent search engines from following links from that page
While “Un-Validated Redirects and Forwards” is the last item on the OWASP Top 10, we don’t consider it the least risky or exploitable vulnerability in the wild, as this report indicates.
Many Web applications consider redirecting functionality essential. Today, “notify and confirm” is the most common method for mitigating security issues with redirects.
The problem with “notify and confirm,” of course, is that it gives users the power to decide whether to follow suggested redirection. As we know, users (being human) make mistakes.
Server side mitigations, such as white-listing, are not as commonly used in the wild since they may break and limit the openness of redirecting feature. Even when a necessary application feature, open redirect functionality has the tendency to be vulnerable to XSS and therefore introduce a greater indirect risk to Web applications security.
Our research suggests that open redirects and the associated cross site scripting vulnerability is not just a problem for small and little used Web applications on the Internet. Rather, even large and highly trafficked and respected Web applications rely on insecure redirects.
We recommend updating open redirect best practices in a way that will also reflect protection for SEO attacks and, at the same time, put more attention to casually related vulnerabilities such as XSS.