SQL Injection in the News
As far as I’m concerned we’ll likely always have SQL injection around to haunt us. Even though this attack vector has been well-publicized and well-documented for well over a decade (and then some), failure to account for it continues to pop all the time—even in catastrophic places (i.e., not just e-Commerce sites and the occasional school website). For example, take this story where a UK man hacked literally thousands of sites—including damage caused (in the millions of dollars) to a number of US government websites.
Unfortunately, the article describing the attack was clearly written by someone who doesn’t understand how SQL injection works because the article uses terms like "exploiting vulnerabilities in SQL Databases" and then goes on to describe how the hacker used an automated tool to scour IPs/sites and then "inject powerful SQL commands" which makes it sound like this hacker had 'ninja' skills with hacking.
Related: Protecting Your Organizaton from SQL Injection Attacks
Based on how easy it was to find and capture this 'hacker,' I’m personally willing to bet he was actually nothing more than a script-kiddie—using automated (and freely available) SQL injection tools to find just a handful of the existing SQL injection vulnerabilities (in front-end code—not back-end databases) out there.
And, if we’re frank, for these kinds of vulnerabilities to exist in sites belonging to the Army, US Missile Defense Agency, EPA, NASA and others is, itself, bordering on criminal.
SQL Injection and Bad Information
A big and ongoing problem with SQL injection is that there’s just a ton of bad information out there about how to stop it. Some of the more common mistakes about how to protect against SQL injection are that you can just 'scrub' or try to 'filter out' any 'bad' or 'naughty' (or should I say "powerful") commands—whereas other mis-information is that if you used parameterized statements or stored procedures you’re 'automatically' protected. (By their nature stored procedures and parameterized statements clearly separate command-flow and data—but if you then concatenate command/data within the BODY of your statement/sproc, you’re RIGHT back into being susceptible to SQL Injection—such that these techniques are NOT a necessary/fail-safe protection because developers CAN do dumb things that will make their code re-vulnerable to SQL injection.)
And while I’m going to seem very petty for pointing this out, I bumped into a video on YouTube recently trying to explain SQL injecton. To his credit, the presenter does a great job of a couple of things—including calling out how it’s lame that SQL injection still works as well as calling out how scrubbing is futile. Unfortunately though (and even though his keen British accent makes him sound as if he has all of the answers), his entire presentation turns to utter crap towards the end when he somehow equates prepared statements as:
a) "hack on top of a hack" yet then goes on to
b) CORRECTLY explain that prepared statements create a clear distinction between data and commands (the solitary and ONLY way to defeat SQL injection).
Furthermore, his assertion that "a Microsoft database" is somehow MORE susceptible to SQL injection (than others) is also total and complete rubbish (though I don’t have the accent to do that term justice).
It’s also arguable that viewers of this video MIGHT assume that PHP is more susceptible to SQL injection than other languages. But, to be fair, I think that’s something viewers might INFER more so than something that was said. (Still, it's arguable that someone running non-PHP against an Oracle database might INFER from this presentation that they’re probably fine or at less of a risk than someone using PHP against SQL Server, for example).
And, while I’m really not trying to be petty—and I do GET that this presentation WAS given on the back of a napkin—the reality remains that misinformation like some of the details in this presentation ARE part of why SQL injection remains a problem (especially now that this video has been seen almost 100,000 times).
SQL Injection ISN’T All That Hard to Defeat
Ultimately, SQL injection IS something that is easy to fall prey to—when developers don’t understand how it works.
Happily, all that is needed to protect against this exploit is a bit of core/basic knowledge in the sense that ALL that has to be done to protect against SQL Injection is to make sure that data and commands are ALWAYS and CONSISTENTLY separated. If command-flow and data ARE allowed to merge or intertwine or concatenate at ANY point, then you’re susceptible to SQL injection—no ifs, ands, or buts about it.
For more information, I highly recommend my previous article: SQL Injection – Beyond the Basics.