On the December 2012, an Egyptian hacker who calls himself ViruS_HimA claimed to have breached Yahoo!’s security systems and acquire full access to certain Yahoo! databases, leading to full access on the server for that domain. The attack method was analyzed and recognized to be a variant of the SQL injection attack and the specific victim Yahoo! web application was identified as a third party astrology application branded as a Yahoo! application.
Figure 1 The hacker’s hack evidence screenshot
This attack underscores the security problem posed by third party code. In this case, the vulnerable application was probably not coded by Yahoo! team, and not even hosted on Yahoo’s server farm, leaving Yahoo! with the full responsibility for securing the application on one hand, and a very limited capability to actually control the code, on the other hand.
This is not the first time Yahoo! has been struggling with security issues on third-party code. Last July, Yahoo! Voices was breached and 400K users’ credentials were exposed. According to the hackers, the breach was enabled by a SQL injection vulnerability (Union based SQLi). Yahoo! Voices is an online publishing application that was developed by Associated Content and later acquired by Yahoo!.
The problem of third-party code is not limited to Yahoo!, of course. Almost every web application includes some components that were not developed by the application programmers.
Protecting third party code and applications
The Payment card industry Data Security Standard (PCI DSS) Requirement 6.6 provides two options for web applications protection. The first is to conduct a vulnerability assessment and incorporate the assessments into the software development life cycle (SDLC). The other is to deploy a Web Application Firewall (WAF) if front of the web application.
Naturally, where all the options are available, the best protection is achieved by combining all of them together. However, with third party code, the ability to incorporate the assessments into the software development life cycle (SDLC), or simply put fixing the code, is virtually nonexistent.
Some of the issues can be discovered and fixed beforehand with an appropriate security due diligence. Therefore, from a business standpoint, executives should always assume third party code—coming from partners, vendors, mergers and acquisitions—is vulnerable, and take relevant precautions: Putting in place legal requirements in a contract for what you will and will not accept from a security perspective, incorporate security due diligence for any merger or acquisition activity and require a report specifying security issues and measures taken to address them.
However, when these precautionary measures fail to prevent a security vulnerability, the only practical way to protect third party code is by putting it behind a WAF. In this case of the hacked third party astrology application, Yahoo! could have directed user traffic to Astroyogi.com with a WAF, deployed on Yahoo!’s environment or on the cloud as a reverse proxy and shield the application. That way, the application would have been protected from the hacking and Yahoo! would have spared the bad PR and the possible abuse of its users’ privacy.
The Key Lessons
Whether you are outsourcing development, services or maintenance, the bottom line is that if you are allowing others to create code and run services that your customers will perceive as coming from you—meaning that you are responsible for any functional problems or security breaches. Guaranteeing that your programs and data will remain secure once you’ve allowed outside applications to run on your servers or integrated them into your Web presence is not an easy task. But there are practices you can adopt that will ensure—as much as possible—that you maintain control over the security of your company and customer information. When it comes to third-party code, protecting applications with a Web Application Firewall is essential.