SQL Injection, eye of the storm

Originally published by Security Horizon in the Winter 2009 edition of Security Journal.

In 2008 SQL Injection became the leading method of malware distribution, infecting millions of Web pages and foisting browser-based exploits upon unsuspecting visitors. The ramifications to online businesses include data loss, PCI fines, downtime, recovery costs, brand damage, and revenue decline when search engines blacklist them. According to WhiteHat Security, 16 percent of websites are vulnerable to SQL Injection. This is likely under-reported given that the statistics are largely based on top-tier Web properties that employ a website vulnerability management solution to identify the problem. The majority of websites do not and as such may be completely unaware of the extent of the issue. In addition, some recommended security best-practice have ironically benefited malicious hackers. Websense now reports that "60 percent of the top 100 most popular Web sites have either hosted or been involved in malicious activity in the first half of 2008." Let’s examine the forces that have aligned to create the storm that allows SQL Injection to thrive.

Any custom Web application that lacks proper input-validation, fails to use parameterized SQL statements, and/or creates dynamic SQL with user-supplied data potentially leave themselves open to SQL Injection attacks -- unauthorized commands passed to back-end databases. When Rain Forest Puppy first described SQL Injection ten years ago, on Christmas Day 1998, it was a targeted one-off attack capable of exploiting only a single website at a time. Custom Web applications contain custom vulnerabilities and require custom exploits. Successfully extracting data out of an unfamiliar database is different in each instance and greatly aided by error messages revealing snippets of server-side code.

To solve the SQL Injection problem, preferably in the code, first we must identify what is broken. The easiest method to-date has been through remote black-box testing, submitting meta-characters (single quotes and semicolons) into Web applications. If the website returns a recognizable response, such as an ODBC error message, there is a high probability that a weakness exists. Comprehensive security testing, typically aided by black-box vulnerability scanners, performs the same procedure on every application input-point including URL query parameters, POST data, cookies, etc. and repeated with each code update. This software security testing process is also now one of the assessment options mandated by PCI-DSS section 6.6.

In the wake of highly publicized compromises like the 2006 incident at CardSystems, a back-end credit card transaction processor, in which millions of stolen credit card numbers fell into the wrong hands, website owners were strongly encouraged to update their Web application code and suppress error messages to defend against SQL Injection attacks. Many implemented solely the latter since it only required a simple configuration change, hindering the bad guy’s ability to identify SQL Injection vulnerabilities. Since the vulnerabilities couldn’t be found easily, perhaps this contributed to incorrectly training developers that security through obscurity was enough. Widespread attacks were not seen as prevalent enough to justify a serious software security investment. Despite cutting-edge Blind SQL Injection research helping to improve black-box testing, error message suppression contributed to three very important side effects:

1. Black-box vulnerability scanner false-positive and false-negative rate skyrocketed.
2. SQL Injection became significantly harder to identify, but ironically not exploit.
3. Extracting data out of a database became exceptionally more laborious than injecting data in.

In 2007, cyber criminals in China created a new technique capable of generically exploiting SQL Injection vulnerabilities without reliance on error messages. Perpetrators inserted malicious JavaScript IFRAMEs (pointing to malware servers) into back-end databases, as opposed to pulling data out, and used the capability to exploit unpatched Web browsers and plugi-ins in record numbers. "The scale of this global criminal operation has reached such proportions that Sophos discovers one new infected webpage every 4.5 seconds – 24 hours a day, 365 days a year." No longer limited to one-off hacks, SQL Injection quickly became a method of choice to target anything and everything on the Web. According to Websense, “75 percent of Web sites with malicious code are legitimate sites that have been compromised.” Furthermore, attacks have been widely successful without even needing to authenticate. That means any website functionality beyond a login screen represents further attack targets. Worse still, security pros are unable to leverage these techniques to improve SQL Injection vulnerability detection because doing so risks adversely affecting the website.

For example, when vulnerability assessments are conducted on production systems, a cardinal rule must be followed, “Do no harm.” This often requires that testing rates be limited (X number of requests per second), testing windows be respected (usually during off-peak hours), and tests be nondestructive. It should go without saying that we do not want to crash websites or fill databases with undesirable content. Malicious hackers have no such restrictions as they may test however they want, whenever they want, for as long as they want. The other disadvantage for website defenders is that they must be 100% accurate at finding and fixing every issue all the time, while the attacker need only to exploit a single missed issue. This is an unfortunate, but inescapable reality in Web security and why testing frequency and comprehensiveness approach is vital.

Source code review (aka white-box testing) is the other option to locate SQL Injection vulnerabilities and often able to peer deeper into the problem than black-box testing. Of course you must have access to the source code. Before considering this as a scalable solution begin by asking yourself if executive management would allocate enough resources to perform source code reviews on every website every time they change. Thinking globally, let’s consider that there are over 186 million websites. While not all are “important,” if 16% had just a single vulnerability as previously cited, that means a staggering 30 million issues are in circulation. Would it be reasonable to project that finding (not fixing) each unique issue through white-box testing, even assisted by automation, would require $100 in personnel and technology costs? If so, we are talking about at least a $3 billion dollar price tag to simply locate SQL Injection -- to say nothing about other more prevalent issues such as Cross-Site Scripting and Cross-Site Request Forgery that will be left undiscovered.

Secure software education is another valuable long-term strategy that will help prevent another 30 million vulnerabilities being added to the pile over the next 15 years, but will not provide a short-term fix to the problem. Currently, there are roughly 17 million developers worldwide who are not educated on the basic concepts of secure coding that could help them tackle the SQL injection and other issues. Would $500 per developer be an acceptable rate for professional training (commercial 2-day classes typically start at $1,000 on up)? If so, the market must be prepared to make an $8.5 billion investment and then wait for everyone to come up to speed. Obviously the private sector is not going to shoulder such a financial burden alone, not in any economy, let alone in a recession. The fact is education costs must be shared in amongst colleges, enterprises, vendors, developers themselves, or through materials made freely available by organizations such as OWASP and WASC.

The climate for SQL Injection vulnerabilities has all the makings of a perfect storm, one we are already experiencing. The issue is extremely dangerous, incredibly pervasive, difficult to identify, easy to exploit, and expensive to fix. Over the last 15 years organizations have accumulated a lot Web security debt that eclipses our currently estimated spending of ~$300 million, combining outlays for scanning tools, professional services, training, and Web application firewalls. Perhaps we should ask president-elect Obama for a Web security bailout. Not likely. The fact is not every organization will invest adequately to protect themselves, at least not over night. Those who do not will undoubtedly become the low hanging fruit bad guys target first. The smart money says vast numbers of compromises will continue throughout 2009.

For those wishing to do all they can to prevent compromises, the answer is adopting a holistic approach addressing overall Web security, including SQL Injection. While fully articulating the details of each solution is beyond the scope of this article, it is important to highlight several of the most important and why they are a good ideas.

• Security throughout the Software Development Life-Cycle, because an ounce of prevention is worth a pound of cure.
• Education, teach a man to fish.
• Vulnerability Assessment, because you cannot secure what you cannot measure.
• Web Application Firewalls, because software is not and will never be perfect.
• Web Browser security, because one must be able to protect themselves against a hostile website.

This combined strategy will prevent us from having the same conversation about Cross-Site Scripting and Cross-Site Request Forgery in the near future.