Bugtraq: RE: Paper: SQL Injection Attacks by Example

[Michael Silk <michaelsilk () gmail com>]

 Michael,

 But that doesn't really matter - you'd attempt to execute your
malicious code at the level where the procedure is executed, not
inside of it.

 I.e. the code could be:
 sql = " exec spSuperSecure " + one + ", " + two;

 We aren't really interested in "spSuperSecure" and it's typed
parameters, you just append your new malicious query on the end of it.

 Although it does depend a bit on the type of  sql injection you are
trying to perform ... you can't add on a " or 1 = 1" on a
password-matching procedure.

-- Michael

> -----Original Message-----
> From: Scovetta, Michael V [mailto:Michael.Scovetta () ca com] 
> Sent: Thursday, 6 January 2005 7:11 AM
> To: David Litchfield; Steve Friedl; bugtraq () securityfocus com
> Subject: RE: Paper: SQL Injection Attacks by Example
>
> David,
>
> Actually, to nitpick your comment a bit, stored procedures 
> usually have typed input variables:
>
>       create procedure foo ( a int, b varchar(20) ) as ...
>
> At least in MSSQL, you'd have to do something bad like use 
> sp_executesql or some other function that will re-form a 
> complete sql query and pass that to the interpreter. As long 
> as you do more sensible stuff like:
>
>       insert into table (name, age) values (@b, @a)
>
> you should be fine.
>
> Michael Scovetta
> Computer Associates
> Senior Application Developer
>
> -----Original Message-----
> From: David Litchfield [mailto:davidl () ngssoftware com]
> Sent: Wednesday, January 05, 2005 2:20 PM
> To: 'Steve Friedl'; bugtraq () securityfocus com
> Subject: RE: Paper: SQL Injection Attacks by Example
>
> Hi Steve,
> Nice paper. However, one small nitpick - under "Mitigations" 
> you list using stored procedures if the database supports 
> them. I've seen other people suggest this as a defensive 
> strategy as well.
>
> Using stored procedures will *not* protect you from SQL 
> injection attacks.
> Firstly, they can be injected into just as easily as a select 
> statement.
> Secondly, the procedure itself can be vulnerable to SQL 
> injection. I have seen for example, procs that use double 
> quotes internally and single quotes on input.
>
> That said, stored procedures are generally faster so it's 
> better to use them for performance reasons, anyway.
>
> Cheers,
> David Litchfield