Comments on: SQL Injection http://sqlinthewild.co.za/index.php/2008/05/07/sql-injection/ A discussion on SQL Server Mon, 14 May 2012 23:51:41 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Gail http://sqlinthewild.co.za/index.php/2008/05/07/sql-injection/comment-page-1/#comment-56 Gail Fri, 30 May 2008 15:04:43 +0000 http://sqlinthewild.co.za/index.php/2008/05/07/sql-injection/#comment-56 Indeed and I do not ever recommend that key word filtering is used as the sole method of preventing injection. As this recent attack showed, there are ways and means around it. Proper use of parametrised queries and procedures and proper security permissions would have stopped even this attack. With parametrised queries, the additional add-on of SQL does not get executed as a separate query, buy gets treated as a string literal. Worst case, you end up with SQL code been stored in the table, but it won't get executed. If the web user has no rights to the base tables, an attack like the recent one would have failed to even retrieve the list of tables (on SQL 2005). It certainly would have failed to execute the update. I'll write another article on injection sometime soon, this time focused on how to prevent it from working. p.s. Nice to see you here Dion. Indeed and I do not ever recommend that key word filtering is used as the sole method of preventing injection. As this recent attack showed, there are ways and means around it.

Proper use of parametrised queries and procedures and proper security permissions would have stopped even this attack.

With parametrised queries, the additional add-on of SQL does not get executed as a separate query, buy gets treated as a string literal. Worst case, you end up with SQL code been stored in the table, but it won’t get executed.

If the web user has no rights to the base tables, an attack like the recent one would have failed to even retrieve the list of tables (on SQL 2005). It certainly would have failed to execute the update.

I’ll write another article on injection sometime soon, this time focused on how to prevent it from working.

p.s. Nice to see you here Dion.

]]> By: Dion http://sqlinthewild.co.za/index.php/2008/05/07/sql-injection/comment-page-1/#comment-55 Dion Fri, 30 May 2008 09:07:40 +0000 http://sqlinthewild.co.za/index.php/2008/05/07/sql-injection/#comment-55 Hi, I don't disagree that many sites are poorly constructed to handle basic SQL injection attacks. However the problem with the latest epidemic was due to the maliciously ingenious use of a cast operator: DECLARE @S VARBINARY(4000);SET @S=CAST(0x440045004300 4C00410052004500200040005400200076006100720063006800610072 00280032003500350029002C0040004300200076006100720063006800 610072002800320035003500290020004400450043004C004100520045... This resolves to SQL syntax, but none of the usual flags are triggerd. Quite sneaky. -D <em>(Editor: Cleaned up the sql syntax to be legible)</em> Hi, I don’t disagree that many sites are poorly constructed to handle basic SQL injection attacks. However the problem with the latest epidemic was due to the maliciously ingenious use of a cast operator:

DECLARE @S VARBINARY(4000);SET @S=CAST(0×440045004300
4C00410052004500200040005400200076006100720063006800610072
00280032003500350029002C0040004300200076006100720063006800
610072002800320035003500290020004400450043004C004100520045…

This resolves to SQL syntax, but none of the usual flags are triggerd. Quite sneaky.

-D

(Editor: Cleaned up the sql syntax to be legible)

]]>