Over the past several months, a number of SQL injection attacks have been targeted at systems running Microsoft IIS and Microsoft SQL Server, and thousands of those systems were victims because of poor Web site security. Some of the attacks use specialized automation tools that can query Google for vulnerable Active Server Pages (ASP) and subsequently attack the sites on which those pages reside.
In April, Bojan Zdrnja posted a fairly detailed analysis of one such tool in the SANS Handler's Diary blog at isc.sans.org/diary.html?storyid=4294. Then in May, SecureWorks said that it had detected a SQL injection exploit tool that was compounding matters even further. The tool was discovered as it was being pushed out to a big botnet, and, of course, the tool made all the bots capable of launching SQL injection attacks. You can read about the exploit tool at
www.secureworks.com/research/threats/danmecasprox/.
It's probably safe to say that just about all of the successful exploits were a direct result of poor Web application coding practices, as well as a lack of adequate failsafe security defenses. Failure to properly sanitize user-provided input will invariably lead to a security breach. However, using a strong back-end Web application security system can help stop malicious code that makes its way past any sanitation code that's built into your Web applications.
Last week, to help with proper coding practices, Microsoft stepped up to offer some advice. The company released the security advisory, "Rise in SQL Injection Attacks Exploiting Unverified User Data Input" (www.microsoft.com/technet/security/advisory/954462.mspx), which outlines three tools that can be used to find and fix coding problems.
One of the tools, Scrawlr, is relatively new and provided by HP. The tool will crawl a Web site to look for SQL injection attack vectors. In the security advisory, Microsoft also reminds administrators of its long-standing UrlScan tool, which is now available as a version 3.0 beta. Both of these tools scan the publicly exposed side of a Web site. To dig deeper, actual source code can be examined for vulnerabilities by using Microsoft's Source Code Analyzer for SQL Injection tool. However, be aware that the tool can examine only ASP code that's written with VBScript, and it doesn't parse all types of ASP constructs. In other words, the tool has its limitations.
Other scanning tools you might consider using to protect your Web site include Acunetix Web Vulnerability Scanner, Cenzic Hailstorm, N-Stalker Web Application Security Scanner, NT OBJECTives NTOSpider, WhiteHat Sentinel, IBM Rational AppScan, HP WebInspect, Next Generation Security Software NGSSQuirreL, and IPLocks Armour.
You should also strongly consider using a Web application firewall to protect your Web site. There are a wide range of choices available today. Some of the solutions that I'm aware of are AppliCure dotDefender, ArmorLogic Profense, Barracuda Web Site Firewall, Breach Security WebDefend and ModSecurity, eEye Digital Security SecureIIS, F5 BIG-IP Application Security Manager, Imperva SecureSphere, Privacyware ThreatSentry, Protegrity Defiance Threat Management System, Radware AppXcel with Web Application Firewall, and webScurity webApp.secure. All of these products can easily be located using your favorite search engine.
Keep in mind that Web application firewalls should be considered only part of an overall security strategy—even with such a solution in place you still need to do everything you can to ensure that your code and your database servers are as secure as they can be
