Why SQL Injection Still Plagues Us

Tuesday, July 23, 2013

Dan Kuykendall

72462991dba2e16e1588d4af1293ae58

Why SQL Injection Attacks Can't be Stopped

The complexity of application security is often underestimated. While we, as an industry, 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. 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. Let’s look at the problem from each team’s point of view.

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 remediate 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.


Remediating SQL injection vulnerabilities requires 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 remediate SQL injection.

About the Author: Dan Kuykendall is co-CEO and CTO of NT Objectives, a provider of automated, comprehensive and accurate web application security software and services. Dan can be reached at dk@ntobjectives.comor follow Dan at @dan_kuykendall.

Related ReadingWeb Application Scanners Challenged By Modern Web Technologies (SecurityWeek)

Related Reading: Top 10 Security Threats for HTML5 (SecurityWeek)

 

Possibly Related Articles:
12018
Vulnerabilities Webappsec->General
Information Security
SQl Injection Vulnerabilities Attacks Ajax JSON developers Web web applications
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.