Do Developers Hold The Bag For Latest SQL Injection Exploits?

There are no new vulnerabilities in SQL Server or IIS, wrote Bill Sisk, a communications manager for Microsoft's Security Response Center, in a blog posting Friday. "To protect against SQL injection attacks the developer of the Web site or application must use industry best practices," Sisk wrote.

So is Microsoft passing the buck by blaming developers? Many are pointing out that while SQL injections can be extremely destructive and costly, any database left vulnerable will execute anything it determines is valid SQL, be it SQL Server, Oracle, IBM's DB2 and others.

"To suggest that the database vendor should somehow know and choose which SQL should or should not be executed, outside of security and data quality constraints is way out of bounds," said Wayne Snyder, president of the user group Professional Association for SQL Server (PASS) in an e-mail. "It would be great if all software could do what we intend, instead of what we say."
 
Snyder, who is also a managing consultant at Mariner, a Charlotte, NC consultancy and Microsoft business partner, believes threats like this are universal. "I cannot recall the last time I saw any software which spent any effort at all in denying this kind of attack. Lack of money, lack of time, lack of interest, difficulty in decided what to do -- all contribute to the fact what most apps and programmers do not defend against this."

According to various reports, these attacks occur after a hacker injects malicious JavaScript code into the actual database server, which in turn can insert or create one or more malicious scripts that can wreak havoc on the computer of a user visiting the offending Web site.

While the key to protecting against a SQL injection exploit lies with good architecture and development, the United States Computer Emergency Readiness Team (US-CERT), a division of the Department of Homeland Security, advises end users to disable JavaScript and ActiveX controls and, of course, employing good patch management.

Most will agree that it's not an ideal solution by any stretch. For those already infected, DBAs should restore their DBMS "from a clean backup copy and start reviewing your code to make sure all input is properly sanitized; otherwise, you'll just get hit again," writes Scott Gilberson, in a Wired blog.

Should you not have a clean backup of you database Gilbertson points to a workaround by Giorgio Maone's hackademix.net, which simulates the attack but remotes the infected JavaScript. Maone is a database developer in Palermo, Italy, who founded the company InformAction, where he wrote NoScript, a software extension embedded in the Mozilla Firefox browser that is designed to only run JavaScript on trusted Web sites.

In fact Maone has his own thoughts on whether or not the latest SQL injection exploits are a flaw unique to SQL Server. Among other things, he points out that there is no vulnerability specific to Microsoft, at the end of the day "these infections, are caused by poor coding practices during Web site development."

Will this latest exploit be the one to lead IT organizations to put more emphasis (priority and money) into more secure coding practices? That remains to be seen but unless this creates a cataclysmic casualty that has a sizeable impact or threat to the economy or causes a highly publicized event (well beyond the tech media), I wouldn't bet on it.

"Unfortunately many discussions and project plans do not even have this as an item on the risk assessment," Snyder notes. "The sad truth is that we, as developers, DBAs, and project managers are left holding the bag on this -- because it's our bag!"

What's your opinion? Please drop me a line.

Posted by Jeffrey Schwartz on 04/30/2008