January 05, 2012 How to Stop SQL Injection

On the very last day of 2011, SANS published a story about automated SQL injection attacks affecting 1M plus websites. What will be different with SQL injection in 2012? Nothing. Perhaps more, perhaps some new attack tools. But otherwise, it’ll look like quite the same.
Since SQL injection continues to be the major tool for data theft, we will try to devote a blog a month to the topic in an effort to eradicate the world of this problem. Our first entry is a summary of a webinar (registration required) we did late in 2011. Today’s blog uses what we outlined in this webinar with respect to a mitigation checklist (minus the honey-voiced narration).
Here’s what any firm that has data flowing in web applications should do in order to protect themselves from SQL injection:
Step 1: Dork yourself
The first step hackers often take to find vulnerable websites is simply conducting a Google search. In this case, they search for technical snippets unknowingly left inside of web applications that help indicate there’s a vulnerability. Today, hackers have automated the process, using bots to search for vulnerabilities. There are also online tools. Last year, we showed how frequent Google Dork searches were taking place (click to BIGGIFY):
As the chart shows, several thousand searches take place per hour. How does dorking work? You search for something technical to help find a vulnerability, such as, “in url:page.php?id=”. A fuller list can be found here.
How do security teams shield themselves from dorking?

Dork your own website and see what is exposed.
Regularly schedule “clean ups” to remove the nasty bits.

Step 2: Create and deploy a blacklist of hosts that initiated SQL Injection attacks
In our report on SQL injections, we showed that 40% of SQL injection attacks came from just 10 sources (IP addresses). With such numbers, blacklisting makes sense. One of our customers has adopted an interesting blacklisting policy that goes beyond SQL injections: any attack from any IP address is blocked for six years (!). This may not be the right policy for everyone, but something to think about.
Step 3: Use a web application firewall (WAF) to detect/block attacks
Yeah, we’re a WAF vendor. But others have made it clear that a good WAF is an important part of an security strategy.
Here’s an example of how Imperva’s WAF would alert you to the attack:

This screen shot shows the details of the SQL injection itself (click to BIGGIFY):

Step 4: WAF + Vulnerability Scanner
Again, we’re a WAF vendor and I don’t want to sound like we’re promoting product. For this reason, I’ll defer to Gartner:
Security No-Brainer #9: Application Vulnerability Scanners Should Communicate with Application Firewalls
If a web application security testing tool tells me I have a vulnerability in an application, what do I do? “Fix it” is the right answer, but not always so easy if my development organization is backlogged or, worse, I don’t have access to the source code. Another answer is to shield the application from attacks on the vulnerability using an application-level firewall – in this example a web application firewall.
In fact, just yesterday, Gartner came out with a Magic Quadrant for vulnerability scanning (DAST, in their jargon). One of the key criteria for DAST vendors? WAF integration (mentioned 19 times).
Step 5: Stop Automated SQL Injection Attack Tools
Hackers deploy automated SQL attack tools like SQL map and Havij. Identifying their attack patterns and fingerprints to block their activity is essential. To do so you, should identify the different patterns of automated attacks. Patterns might be found in several places such as:

HTTP Headers – Distinct User agent string, lack of “normal” HTTP headers.
Application parameters – Distinct constants used by the tools.

Having a piece of equipment that speaks the application layer language (this is where a WAF comes in) allows enterprises to express that knowledge into security rules.
Step 6: Code review
Code review is ardous and expensive, but it gets the problem is fixed–hopefully for good. With most code bases becoming exceedingly large, code review is far from comprehensive which makes steps 3 and 4 very important.