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.
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.
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:
- OWASP – Guide to SQL Injection
- Microsoft – SQL Injection
- US-CERT SQL Injection
- NIST 800-44 – Guidelines on Securing Public Web Servers
- FFIEC – Controls to Protect Against Malicious Code
- CodeProject – SQL Injection Attacks and How to Prevent Them
- Microsoft – How to Protect from SQL injection in ASP.NET
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.
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?
Submit your questions via Twitter using #ThinkAppSec