RE: Paper: SQL Injection Attacks by Example
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@xxxxxx]
> Sent: Thursday, 6 January 2005 7:11 AM
> To: David Litchfield; Steve Friedl; bugtraq@xxxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxx]
> Sent: Wednesday, January 05, 2005 2:20 PM
> To: 'Steve Friedl'; bugtraq@xxxxxxxxxxxxxxxxx
> 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