Developers beware; the lethal SQL (injection) stalks this night

bridgwatera | No Comments
| More

CAST Software's press team has been a busy lot this week. Just last night I was working on a story that talks about the company's opinions on sloppy programmer code validation practices and how this can lead to SQL code injections targeted at the database layer of an application.

The software quality analysis company says that if programmers ignore so-called "application component interaction patterns", then this leaves doors open to malicious attacks.

"While SQL injection is not a new exploit, applications continue to be vulnerable to it. It's not because developers and architects don't know about them or don't have the skill to prevent them -- it's because they can't see them, or worse, they may think they've prevented it, but something outside their range of competence conspires against them," says the company in a press statement.

Not surprisingly, CAST has an automated system that can look for patterns in the application -- patterns of component interactions -- that can potentially compromise the application.

But CAST is not the only company vocal on this subject.

Technical director at F5 Networks Owen Cole says that, "SQL injection attacks are amongst the stealthiest hacking attempts. Attackers have learned that the Trojan Horse can be easily recognised by application firewalls and denied entry into the application infrastructure completely."

Consequently, Owen says that we have seen a modified kind of attack born, the Trojan Zebra.

Zebra_face.jpg

"Standard Trojan horses can easily be corralled by matching suspicious text within the query, but zebras conceal the attack characters within a string of text, rather like a single malicious zebra within an otherwise benign herd. This is simply the next step along the evolutionary arms race of hacking, but organisations can counteract such threats by normalising text and examining both URLs and characters within the text without being fooled by lack of spaces within the entry, for example," said Owen.

Looking further afield for still more opinions in this space we find Tony Haverson, a senior developer at a popular online dating site.

"There are easy and proven ways to prevent SQL injection in most modern programming environments and when best practice is followed, it should prevent the attacks by virtue of preventing user input from being treated as any thing other than data. Parameterising SQL queries, for example, rather than constructing text sql queries out of the user input, will completely defeat SQL injection attacks. For example, microsoft's best practices for preventing sql injection are at http://msdn.microsoft.com/en-us/library/ms161953.aspx."

"This suggests that the solution to these vulnerabilities lies in developer education and proper application of defensive programming in validating user input."

"The use of automated tools as a backstop to these practices is very useful. Developers should be writing unit or integration tests to catch these sorts of omissions, but few developers ever have the time or inclination to write enough cover to catch all of this."

"SQL injection attacks are really just a subset of the larger set of security issues raised by improper verification of input, which include cross-site scripting attacks in a web context, where a malicious user will cause the victim site to display content or run JavaScript code of the malicious user's choice," said Haverson.

Leave a comment

Subscribe to blog feed

About this Entry

This page contains a single entry by Adrian Bridgwater published on April 8, 2011 1:59 PM.

Don't say legacy applications, say LONGEVITY applications! was the previous entry in this blog.

Adobe ups the ante, but it never tells us how it does it is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.