SQL Injection Defense Tools
Bryan here. A couple of weeks ago, I posted a blog entry with links to SQL injection defense guidelines. The SDL requires guidance and education for end-users, and tools to verify security settings are highly recommended, as defined in "Stage 5: Implementation Phase: Creating Documentation and Tools for Users that Address Security and Privacy". Today, Microsoft is releasing two new SQL injection defense and detection tools, URLScan 3.0 and Microsoft Source Code Analyzer for SQL Injection (MSCASI). We are also excited to announce the release of HP Scrawlr, a SQL injection detection tool developed by HP Web Security Research Group in conjunction with Microsoft.
Each of these tools works differently and each attacks the SQL injection problem from a different angle, and in combination they complement each other well. MSCASI analyzes classic ASP source code to find potential SQL injection vulnerabilities. It can detect both first- and second-order SQL injection bugs and will point you to the exact line of source code where the error occurs.
However, sometimes you don’t have access to the complete source code of your application; for example, you might use third-party libraries or services in your code. This is where Scrawlr comes in. Scrawlr is a black-box analysis tool that doesn’t require access to source code. You just give Scrawlr the URL of your web application and it crawls and analyzes that application for SQL injection vulnerabilities. One downside is that Scrawlr can’t point you to the exact line of vulnerable code the way that Microsoft Source Code Analyzer for SQL Injection can, but this is why the two tools work so well together. In general, source-code analysis tools and black-box analysis tools often work better in conjunction with each other, but this is definitely a larger topic for another blog post.
Finally, URLScan 3.0 is an update to the existing URLScan IIS request filter tool. URLScan 3.0 blocks HTTP requests that contain suspicious text like SQL keywords. URLScan 3.0 is a good defense-in-depth measure, but it’s important to find and fix vulnerabilities at the source. Never rely solely on URLScan or any type of application firewall as your only defense. (I’ve talked on my blog about some potential dangers of substituting firewalls for secure development practices.)
If you’d like more information, the Security Vulnerability Research and Defense blog has posted a more in-depth analysis of each of these tools. I recommend that you download both of the detection tools and test your applications against them. If either tool reports a vulnerability, I also recommend that you use URLScan 3.0 to block attacks while you fix the problems in the source code.
One last note: none of these tools are required by the SDL yet – they just came out today! – but we will definitely be exploring ways to incorporate them into the SDL in the near future. I’ll keep this blog updated with our results.
