eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Last September, Errata Security CEO Robert Graham told us in an interview that SQL Injection was a great risk for Web sites based on many open-source tools and on older, pre-.Net Microsoft technologies. Boy, was that ever a prescient interview.
Several months later, as Wired put it, a massive attack hit half a million Windows data-driven Web sites. In fact, it was the data in these sites that got compromised, and they were set by the attack to serve malware and links to malware on top of their actual data. As the Wired blog puts it, the attack was not exactly Microsoft’s fault and didn’t reflect an actual vulnerability. And subsequent waves of the SQL injection attacks targeted non-Windows servers.
The best way to put it comes from the Graham interview, months before:
“The pre-.Net Microsoft tools in particular were very vulnerable to attack and at the same time very easy to use. You had a lot of people building Web sites with them who really had no clue how to defend themselves from attackers. Since then Microsoft has rearchitected its products and the current generation of .Net tools makes it much more difficult to expose yourself to SQL injection unless you do something really strange.“
In other words, the old Microsoft tools made it easy to program insecure code. Back in 1998 and 1999 I wrote a bunch of ASP sites which, if any were still alive (thank goodness they’re not) would be easily vulnerable. I wrote them the obvious way, by reading input from users of Web forms and constructing SQL commands in VBScript. It’s just not a good idea anymore to do it this way, at least not without checking the input.
On June 24, Microsoft released an obviously coordinated group of tools and documents to address the wave of servers compromised through SQL injection that occurred many weeks ago. Better late than never.
A security advisory entitled “Rise in SQL Injection Attacks Exploiting Unverified User Data Input” starts out by defining the problem (SQL injection attacks are being made against ASP sites that don’t sanitize inputs) and has lots of good links in it, including to tools about which I will go into some detail below. And then there are links to developer articles about SQL injection and how to avoid it:
- SQL Server Injection Protection
- Preventing SQL Injections in ASP
- How To: Protect from SQL Injection in ASP.NET
- Coding Techniques for protecting against SQL Injection in ASP.NET
- Filtering SQL Injection from Classic ASP
- Security Vulnerability Research & Defense Blog on SQL Injection Attack
Tools to Fight SQL Injection
The Microsoft Source Code Analyzer for SQL Injection tool is a static code analysis tool, built on the .NET Framework version 3.0, which analyzes your ASP code for SQL injection vulnerabilities, both first order and second order vulnerabilities.
First order is the type my own sites would be vulnerable to: using user input directly to construct SQL statements. Second order is where those statements are constructed based on data from the database. See Preventing SQL Injections in ASP for more on this distinction. As a programming matter, by the way, the general solution to SQL injection is called parameterized queries, a topic also covered in this article.
A second tool is UrlScan version 3.0 Beta, the latest in a long line of UrlScan versions that have prevented many a common attack. UrlScan is a runtime filtering tool that looks at HTTP requests sent through IIS. It scans for malicious ones and can be set to block whatever you want to block. This can be handy when you read about specific attack patterns being committed.
SQL injections are often performed through HTTP GET commands, in which case UrlScan should be able to detect them (for instance by setting a rule to drop any request that contains the string “INSERT INTO “). Microsoft has a page with UrlScan rules for common security scenarios, including SQL injection, which can help.
Finally, there is a third-party tool, Scrawlr from HP. This tool crawls Web sites, analyzing parameters of pages for SQL injection vulnerabilities. Unlike the Microsoft Source Code Analyzer for SQL Injection tool, it doesn’t require source code. Even if you have source code, this provides a different perspective and a useful comparison.
Preventing successful SQL injection attacks has to begin with proper programming techniques, and there’s only so much Microsoft can do about that. They have provided the programming systems you need to do the job right. Scrawlr and UrlScan are good tools to have and are worth running, at least for a while, but if they are your main defense you can’t feel good about it.
SQL injection is a great example of how security is everyone’s job. Ten years ago very few people appreciated that this level of programming could be the target of a massive attack, but systems are so complex these days that every level is suspect. Don’t take anything for granted.
Security Center Editor Larry Seltzer has worked in and written about the computer industry since 1983.
For insights on security coverage around the Web, take a look at eWEEK.com Security Center Editor Larry Seltzer’s blog Cheap Hack