Compartir a través de

SQL Injection continued

  • Artículo

My previous post on this topic generated so much discussion that I thought I should post about it some more.  Specifically I wanted to write about means of checking your code for possible SQL Injection problems.

The first means of checking, if you are using Visual Studio 2008, is to use the Team System environment.  Specifically, there is a code analysis rule in there that will check for some SQL issues.

Note: This set of rules is not a complete set of possible security rules, nor are the existing rules 100% guaranteed to find all the problems in their area of analysis. No code analysis tool can replace a formal security audit. Nevertheless, we have found inside Microsoft that this can be of great help finding potential security issues.

This is a very useful first pass that you can use to check for some issues.  It will find code that you have that looks like:

 someCommand.CommandText = 
   "SELECT AccountNumber FROM Users " +
   "WHERE Username='" + name + 
   "' AND Password='" + password + "'";

This is based on FxCop which is a tool that you can download for free here.  There is also a blog about this tool that has a lot of useful information, including updates, here.

If you aren't using Visual Studio 2008, which you should use as it is our best development environment yet, there are some other alternatives that you can use to check for SQL Injection vulnerabilities.

I haven't tested any of these, so feel free to comment on them if you have used them or add additional suggestions.

Acunetix WVS

Cenzic Hailstorm

Wapiti

Microsoft® Visual Studio Team System 2008 Database Edition Power Tools – this includes a T-SQL Static Code Analysis feature.

kick it on DotNetKicks.com

Comments

  • Anonymous
    June 02, 2008
    You've been kicked (a good thing) - Trackback from DotNetKicks.com

  • Anonymous
    June 02, 2008
    The comment has been removed

  • Anonymous
    June 02, 2008
    The comment has been removed

  • Anonymous
    June 02, 2008
    Maybe its just me, but I feel inline SQL is incredibly bad design. Especially with the introduction of LiNQ. To me, there is no longer a reason to include inline SQL in any project ever.

  • Anonymous
    June 03, 2008
    The comment has been removed

  • Anonymous
    June 03, 2008
    Shail, Have you checked the tools that I linked to this post?  The 3 towards the bottom don't rely on VS2008 and may help you.

  • Anonymous
    June 03, 2008
    StevenMcD, While I agree that Linq does help a lot, there are still some legacy projects that have this code it is that someone may be update to upgrade to Linq right away.  Hopefully I will have a post about Linq soon to help with this also.

  • Anonymous
    June 04, 2008
    Tom, great to see this, too bad I didn't see it until now!

  • Anonymous
    July 22, 2008
    hi tom im jay and im a comsci student..At this moment im still searching for my thesis.."SQL Injection Analysis: Attacks and Vulnerabilities" i want to ask some opinion from you. you can email me at (me_comsci@yahoo.com)