bugtraq - RE: Paper: SQL Injection Attacks by Example

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <b841ffed05010513441acef7e7@mail.gmail.com>
Date: Thu, 6 Jan 2005 08:44:06 +1100
From: Michael Silk <michaelsilk@...il.com>
To: Michael.Scovetta@...com, davidl@...software.com,
	steve@...xwiz.net, bugtraq@...urityfocus.com
Subject: 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@...com] 
> Sent: Thursday, 6 January 2005 7:11 AM
> To: David Litchfield; Steve Friedl; bugtraq@...urityfocus.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@...software.com]
> Sent: Wednesday, January 05, 2005 2:20 PM
> To: 'Steve Friedl'; bugtraq@...urityfocus.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