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
