The danger of SQL injection last week hit the limelight once again when the British Royal Navy's website was shut down temporarily in response to an attack that had Royal Navy brass wondering whether the hack resulted in unauthorized access to sensitive back-end database files.

Following investigation, the Royal Navy released a statement that "no malicious damage had been done" and that "access to this website did not give the hacker access to any classified information." But the attack was a splashy highlight to the dangers of SQL injections, which, according to the recently released Verizon Business 2010 Payment Card Industry Compliance Report, is the No. 2 most utilized threat action causing payment card breaches, just behind backdoors.

In a report released by Cisco this week, the firm said SQL injections made up 36.86 of all events recorded by Cisco Remote Operations Services. "SQL injection is not caused by a vulnerability per se, but rather is due to the website [or] database administrator's failure to parameterize or properly escape characters and strings in SQL queries," says Mary Landesman, market intelligence manager at Cisco. "This allows attackers to submit a query that is acted upon as if it were an actual command to take some particular action against the database, rather than the expected query to just return the data intended."

According to Jeromie Jackson, president of the San Diego OWASP chapter and a security trainer for developers, SQL injection attacks pose a big danger to back-end databases when combined with other simple attacks.

"One of the things with SQL injection, especially if it is [on an application with] a Microsoft back-end that has built-in stored procedures, is what you can do with a really simple script is end up getting remote shell on the box," Jackson says. "Once you get remote shell, you're pretty much golden."

One of the biggest concepts Jackson tries to hammer home to developers is that they can't ever trust data input. "Much like many of the other OWASP top 10 vulnerabilities, the biggest mitigation technique is really sanitization of user input," he says.

Kevin McDonald of managed service provider Alvaka Networks couldn't agree enough. "So many of the applications that we've seen with SQL injection vulnerabilities is really the result of a poorly written or haphazardly written application," says McDonald, who is executive vice president and director of compliance for the firm. "Coders, in general, are trying to develop for a particular output for a particular result. If they're not careful -- or aware of the problem, even -- they tend to work toward the output result or the action they want, and they don't spend the time and effort to make sure that the process that the database or the application is going through is sanitized enough."

McDonald also believes application developers and DBAs need to do a better job sequestering different databases through improved application account management. Developers should not be granted carte blanche with root access simply to make their lives easier through easy account syncing between databases and applications. It may be convenient, but it also makes it far too easy for hackers to gain unmitigated access to databases should they launch a successful SQL injection attack on a periphery system.

"If you're using a multiapplication or multisystem approach, you should always make sure that each of your user names and passwords are functionally different for each other so that getting permission on the first one is not automatically permission to get into the other one," he says.

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.