Years ago XKCD introduced readers to Bobby Tables whose full name is Robert’); DROP TABLE Students; See what they did there? A classic SQLInjection that in the cartoon leads to the loss of an entire year of school records. And earns the school admin the admonishment from Bobby’s Mom: “I hope you’ve learned to sanitize your database inputs.”

But that was the past. SQLi is old news. Developers know all about it and aren’t introducing injections vulnerabilities into their applications – or if they are the app sec teams are catching them and getting development to remediate the issues before launch. We’re over SQLi and have moved on to other, newer attacks. Right?

Not so fast. As attractive as a 0-Day (zero-day exploit) may be, the reality is that attackers will take whatever path they can to an exploit. And the simpler the path the better. As long as there are SQLi vulns in web applications, attackers will exploit them.

If you doubt that, here are a few supporting points. In the most recent IBM X-Force report, researchers found that based “on the incidents we have covered, SQL injection (SQLi) remains the most common breach paradigm.” And in the 2013 refresh of the OWASP Top 10, injection vulnerabilities (including SQLi) retain their place in the number one spot.

So if we know how to code around injection vulnerabilities, why aren’t we doing it? Perhaps part of the issue is the perception that this is an “older” attack and an expectation that developers have been trained on ways to avoid SQLi.

The research above points to this being an oldie but a goodie of an attack.

Educating Management

Ensure that executives and business application owners understand that, though SQLi has been around for a long time, it is still actively being exploited. Consequences of exploit can be extremely damaging to the business and can include:

Exposure of data
Destruction/loss of data, including loss of entire data tables
Data tampering
Identity spoofing

Those bullets might seem a bit dry for management, so look at the kind of data being accessed by the web app and explain the risks in meaningful terms for the business. For example: “an injection vulnerability on this application could lead a HIPAA violation because all of our EHR (electronic health records) could be exposed.” Or “a vulnerability in our customer portal could mean someone gets free energy for the entire year.”

Got management’s attention? Good, now use that to explain why resources are needed to help train developers how to prevent SQLi and to ensure applications are security tested before launch and after they’re in production.

Educating Developers

There are many great resources on how to help educate developers on SQLi prevention. The key prevention techniques are:

Sanitize input – Don’t trust user data. The web application must filter all input before passing it to the database. For example, if a name contains a non-alphabetic character, don’t pass it.
Use parameterization – This might include use of parameterized stored procedures in the database and SQL queries.
Employ least privilege – Does your web application require full administrator rights to the database? Probably not, yet a lot of web apps have it. Lock down rights for the web application account with the least privileges possible.

When you get ready to train developers, you’ll need more guidance than the list above. These resources are an excellent place to start:

Test for SQLi

Security testing for applications needs to be built into the SDLC (software development lifecycle) and should be done before the application is launched and after it is in production.

There are many automated tools that can help look for SQLi vulnerabilities (including IBM Security AppScan) but no matter what tool is used, it’s critical that testers understand what SQL injection is, how to test for it, and how to validate that it is an exposure. Kevin Beaver has a good overview in Hacking for Dummies. The SQL specific parts are also available at the dummies.com site. And OWASP has an excellent guide for testing SQL injection in the OWASP Testing Guide v4.

Testing before the application is launched will reduce risk to the business, but even fully vetted and tested applications should be tested again in production to ensure that vulnerabilities haven’t been introduced. If vulnerabilities are found, work with the development team to have them remediated as quickly as possible. This is where the step of educating developers will help speed up the process. And since you’ve also already educated management, there should be support and resources to get that remediation work prioritized.

Last Mile Protection

Despite all of your hard work, there still may be applications in your production environment with SQLi and no resources to remediate them. A final act of protection can come in the form of a WAF (web application firewall), IPS, NGFW or other application-aware perimeter protection tool. When preventing or fixing a SQLi just isn’t possible, a well-constructed rule on the WAF could save the day and the data.

SQLi may be old news, but hackers don’t care if it’s old, they just care if it works. Hopefully the advice above has given you a place to start with your SQLi prevention activities.

Other Application Security Questions Answered

What is the importance of software security in supply chain management?

Who Should be Responsible for Application Security Testing?

Can “generated code” be tested?

How do we secure application vulnerabilities and code development, particularly for mobile and social applications that are built by business units or reside on the cloud?

As a CISO, how can I control my organization’s testing methodologies, change management and deployment processes, without compromising on quality and project timelines?
How Can I Secure Apps in the Cloud?

Will the legal landscape change if software vendors can be sued without damages or loss being proven?
The Legal Landscape: Can vendors be sued without damages? What the heck is PII?

What is PII – How much can the definition expand?
Mobile Apps: Which are More Secure Android or iOS?

Does IoT (Internet of Things) “change everything” for Application Security?

What is the difference between PCI DSS and PA DSS?

How can we foster cooperation to help our Development and Security Teams work together?

How do I know my Cloud Service Provider (CSP) Applications are secure?