SQL injections top plenty of lists as the most prevalent means of attacking front-end Web applications and back-end databases to compromise data.
According to recent published reports, analysis of the Web Hacking Incidents Database (WHID) shows SQL injections as the top attack vector, making up 19 percent of all security breaches examined by WHID. Similarly, in the "Breach Report for 2010" (PDF) released by 7Safe earlier this month, a whopping 60 percent of all breach incidents examined involved SQL injections.
"One of the reasons we're seeing such an increase in SQL injections is actually sort of what we've dubbed the 'industrialization' of hacking," says Brian Contos, chief security strategist for Imperva. "It's this notion of smart SQL injections leveraging things like Google searches, automation through bots, and various other technologies to carry out sophisticated, automated attacks."
SQL injection attacks are generally carried out by typing malformed SQL commands into front-end Web application input boxes that are tied to database accounts in order to trick the database into offering more access to information than the developer intended.
Part of the reason for such a huge rise in SQL injection during the past year to 18 months is the fact that criminals are increasingly using automated SQL injection attacks powered by botnets to hit vulnerable systems, Contos says. They use the attacks to both steal information from databases and to inject malicious code into these databases as a means to perpetrate further attacks.
"It doesn't really matter who you are or how big your company is or how sensitive the data may or may not be within the database," he says. "It really is a function of the fact that you just happen to be online, and if you have these vulnerabilities, [the bots] will find you."
Because SQL injection attacks have become so prevalent and often come via automated attacks, Imperva's Contos suggests organizations add another layer of protection between the database and the application accessing it during authentication. By utilizing CAPTCHA technology and requiring users to enter a random series of letters displayed in an image into a text box, organizations can go a long way toward thwarting automated attacks.
Then, of course, a lot of SQL injection prevention on the database side comes down to the basics, Contos says.
First, he recommends DBAs and developers not allow such robust error messages to be displayed when a user enters something weird into an input box. "If I'm an attacker, I'm probably not going to be able to get into the database on the first shot, but what I am going to do is some recon," he explains. "If I can get that database to respond with an error message and tell me all sorts of good stuff, like, 'Hey, I'm Oracle 9i, I'm this, I'm that,' that helps attackers carry out future attacks."
Organizations should also avoid leaving detailed comments and old copies of the database on the same system. While comments might help considerably during development troubleshoots, if left on production systems, they can only help aid attackers.
Finally, and perhaps most important, when it comes to SQL injection attack prevention, be sure to do input and output validation. "Have filters so you're validating exactly what's coming in, and then you can do output validation, too, out up and through the Web application," he says. "If you're expecting an integer, only allow integers."
Have a comment on this story? Please click "Discuss" below. If you'd like to contact Dark Reading's editors directly, send us a message.