SQL Injection Threat On The Rise
I've been following the rise of SQL Injection attacks because I'm busy protecting a vulnerable web application. I'm very critical of the lack of attention this is getting in the developer community. In my opinion, if web developers were really communicating and collaborating with each other there would be a lot of chatter about this problem. I'm sure there are many programmers being kept busy dealing with the aftermath of these attacks but they are probably all implementing their own quirky solutions in isolation without the benefit of community feedback. And it is the lack of community which created the problem. There is no peer pressure to think about security or exchange of ideas on how best to protect a site against SQL Injection attacks (a topic that can generate a lot of debate). And without any discussion about the SQL Injection attack many developers are going to remain ignorant about it. There is however some ridicule about a lame attempt to protect against SQL Injection to be found on The Daily WTF. It is worthwhile to read through the comments.
I've heard that the Redmond Magazine web site got hit by a SQL Injection attack. Although the press enjoys the irony in that, I only bring it up because they identified the source of the attack and mention copycat attacks "...continue to remain vulnerable to copycats introducing new malicious domains within the vulnerable sites."
I received an issue of eWeek today, May 19, 2008 Vol. 25 No. 16 with an article entitled "Botnet installs SQL injection tool". I can't find the article online but here is a link to their security section: http://www.eweek.com/c/s/Security/ The article describes how a botnet is distributing a SQL injection attack tool that searches Google for .asp pages that contain certain terms. You should be very worried if you have a classic ASP web application that is indexed by Google. I remember that the old version of Storefront, Storefront 5.0, a classic ASP e-commerce shopping cart, only protects against SQL Injection attacks by scrubbing input without using parameterised stored procedures. I'm not sure if it would be safe from this.
Yesterday I tried to check out a Microsoft web site with some information on how to protect ASP.NET web sites from SQL Injection attacks but I did not get very far. The HelloSecureWorld web site is designed like a cheesy computer game. To use the Virtual Laboratory you need to install an ActiveX control which managed to kill my browser. I disapprove of the way Microsoft handled this. They played the blame game and treated it like a public relations issue. The only resources they provided are some vague white papers on "best practices" which don't contain any concrete implementation details. This is not how I envision a true developer community would handle this situation. There should be plenty of concerned articles, blog posts, and helpful tools developed to elevate the general level of security on the Internet.
It certainly isn't fun to revisit a crusty old ASP web application to protect it against SQL Injection attacks. I have to write a lot of stored procedures and then test them. Then I have to write the VBScript code to send the parameters to the stored procedures. This is great way to introduce errors into a working web site! I do have one technical tip to share. If you want to return the ID number of the identity field for a recently inserted record, then place the SET @ID = SCOPE_IDENTITY() outside of the BEGIN...END block that contains the INSERT statement. That tripped me up. In a classic ASP web application, you will frequently find that another SELECT query will be made to get the ID number for a recently inserted record. You can eliminate this query by making the INSERT statement return its generated ID number as an output parameter.