Why SQL Injection Vulnerabilities Still Exist

The complexity of application security is often underestimated. While the cybersecurity and developer community understand how common vulnerabilities can be prevented, putting those practices into place is often easier said than done. Such is the case for SQL injection, one of the most common application vulnerabilities that hackers are able to successfully exploit. Case and point, between 2005 and 2011, SQL attacks accounted for 83 percent of data breaches.

Unfortunately, eliminating the risk of SQL injection is made complicated by a host of factors —many of which are out of the developer and security teams' control. However, all hope is not lost. It's true that a multitude of factors come into play when writing and testing secure code, but problems can be overcome — with a little insight, organizations can begin to directly address these challenges and better enable developers and security professionals to prevent and address SQL injection.

In order to understand why SQL vulnerabilities still exist, let's take a look at some of some of the challenges that are keeping SQL injection alive.

From the development team's perspective:

• The nature of the beast: SQL is designed to allow people to get any information they want from a database. It is inherently vulnerable; therefore, all developers must understand how to prevent SQL injection.
• A problem of agnosticism: SQL is the common language that works across database platforms. While it allows code to be database server agnostic, it is also the source of the problem. Developers can prevent most vulnerabilities by using parameterized SQL or stored procedures specific to their database server.
• A chain is only as strong as its weakest link: Most web pages have multiple parameters that can be attacked in dozens of ways. There can be tens of thousands of potential vulnerabilities on a single website, and developers must protect ALL of them. A single mistake is all a hacker needs to wreak havoc.
• New developers, old problems: New generations of developers must be taught to create comprehensive validation logic on every single parameter or input on every single page to avoid exposing SQL injection vulnerabilities. Unfortunately, there is a lack of training and mentoring for some of these new developers. 
• Old developers, new technologies: Many developers who are experienced in SQL injection are now developing new kinds of applications like mobile applications, rich Internet applications, etc. These use new formats and technologies like JSON, REST, SOAP, and AJAX. Both experienced and inexperienced developers must understand that application inputs from a mobile interface written in JSON that accesses the backend database can be vulnerable to SQL injection just like any input on an end-user page. This again requires training and process to remind developers to consider SQL injection for every single input.
• Serving many masters: Coordination and prioritization of security vulnerabilities is a problem in many organizations. Security flaws are just one issue that developers have to address, and frankly, they are generally more concerned with building new features and fixing glaring bugs.
• It takes a village: Development and security teams must work together to build policies and practices to avoid security issues like SQL injection. Developers cannot keep up with ever-changing hacker techniques. They need the security team to keep them informed of those that matter most. Security teams can find vulnerabilities, but must work with the development teams to get them fixed.
• Ghost towns: Most organizations are dealing with legacy applications for which all the developers have retired and the source code cannot be located. (Cue the tumbleweeds.) Vulnerabilities still exist in these applications, and they are difficult or impossible to patch.

From the security team’s perspective:

• Insufficient funds: Eliminating all vulnerabilities requires significant investment in both human resources and technology — neither of which organizations have.
• Beware of shortcuts: Because security teams are understaffed and application security technologies are expensive, organizations are forced to take shortcuts; for example, checking just the first few inputs on each web page. Unfortunately, this approach can be fatal. The last input on a page can be just as vulnerable and potentially harmful as the first — and if the organization doesn't find it, a hacker will.
• So many vulns, so little time: Security teams are often dealing with a backlog of hundreds of applications with hundreds of vulnerabilities. They have to find them all, prioritize them, and then develop and execute a plan to remedy them. It's a mountain of work and a race against the clock.
• We're only human: Pen testers are the real experts at finding this stuff, but there are only so many parameters they can test manually. Automation must be employed, but its takes time to compare and pick the best technologies. Many teams continue to use pen testers with rudimentary technology and limited automation. The fact is there are tools now that automate much of the pen testing process. It is critical to leverage these tools so that pen testers are available to test the things that must be tested by hand.

Preventing and remediating SQL injection vulnerabilities require much more than simply understanding how to implement technical fixes. Development and security teams face numerous obstacles that can prevent them from adequately addressing the problem. And the sad fact of the matter is, if not addressed completely, web applications are still vulnerable. However, by understanding these challenges, organizations can begin to address them directly and better enable developers and security professionals to handle SQL injection.