> -----Mensagem original-----
> De: info-ingres-admin@cariboulake.com 
> [mailto:info-ingres-admin@cariboulake.com] Em nome de Emiliano
> Enviada em: Monday, June 12, 2006 10:06 AM
> Para: info-ingres@cariboulake.com
> Assunto: Re: [Info-ingres] RES: [Info-ingres] SQL Injection attacks
> 
> On 2006-06-12, Leandro Pinto Fava <leandro@unisc.br> wrote:
> > Three years ago we had a case of SQL Injection against our web
portal of
> > students's info. This portal was made using ICE and reports in 1999
> > (with very bad security control). Now we have this portal made in
PHP
> > and the possibility of SQL injection is nearly null (I think :-().
We
> > had another web application (ASP) that suffered a successful SQL
> > injetcion too. The problems were corrected as well.
> 
> And (to hook into the delightful discussion I'm having with Roy), I'll
> bet you dimes to dollars that both were using query assembly.

The ASP app was, but the ICE app was not directly. Report Writer
internally should work with query assembly when passing parameters to
run a report.

> 
> The PHP function addslashes ought to protect you if you use it
> consistently. PHP ADODb has parameter binds, which are better.

Yes.

> 
> > In our case the problems were in the application layer.
> 
> HTML injection?

No, when I said application layer, I wanted to say the problem was not
in database server.

Leandro.

Leandro Pinto Fava wrote:

>>> In our case the problems were in the application layer.
>> HTML injection?
> 
> No, when I said application layer, I wanted to say the problem was not
> in database server.

SQL injection attacks are *always* in the application layer. The 
database server is never culpable; SQL injection attacks are the 
situations where the DB server does as it's told correctly, but is 
presented with a query which is not as intended by the app programmers. 
It's a logical failure, not a technical failure.

Emile

On Mon, 12 Jun 2006 17:48:32 -0400, Emiliano <Emiliano@Iris-Advies.nl>  
wrote:
> ... SQL injection attacks are *always* in the application layer. ...

In general, yes. Though dbms design can make it harder for the application  
code. These recent lwn.net articles are quite good:

http://lwn.net/Articles/177037/
http://lwn.net/Articles/185813/

-- 
Michael Touloumtzis
Ingres Corporation

This is a multi-part message in MIME format.
--------------080707010907090201030407
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Emiliano wrote:
> Leandro Pinto Fava wrote:
>
>>>> In our case the problems were in the application layer.
>>> HTML injection?
>>
>> No, when I said application layer, I wanted to say the problem was not
>> in database server.
>
> SQL injection attacks are *always* in the application layer. The 
> database server is never culpable; SQL injection attacks are the 
> situations where the DB server does as it's told correctly, but is 
> presented with a query which is not as intended by the app 
> programmers. It's a logical failure, not a technical failure.
>
> Emile
Emile,

I'd almost agree if it weren't for stored procedures.  I'm not sure if
I could manage a SQL injection attack with Ingres' limited stored procedure
language, but Oracle certainly has experienced a number of attack vectors
vi PL/SQL packages.

Whether or not that is considered "the database" is another matter.

Cheers,

Mike Leo



--------------080707010907090201030407
Content-Type: text/x-vcard; charset=utf-8;
 name="mleo.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="mleo.vcf"

begin:vcard
fn:Michael Leo
n:Leo;Michael
org:Caribou Lake LLC
adr:Suite 100;;8401 Golden Valley Drive;Minneapolis;MN;55427;United States
email;internet:mleo@cariboulake.com
x-mozilla-html:FALSE
url:http://www.cariboulake.com
version:2.1
end:vcard


--------------080707010907090201030407--

On 2006-06-13, Michael Leo <mleo@cariboulake.com> wrote:

> I'd almost agree if it weren't for stored procedures.  I'm not sure if
> I could manage a SQL injection attack with Ingres' limited stored procedure
> language, but Oracle certainly has experienced a number of attack vectors
> vi PL/SQL packages.

Via *Oracle provided* PL/SQL packages?! For real?!

OK, the thought that a DBMS vendor would deliver SPs that are
vulnerable to SQL injection never really occurred to me. You got me
there.

> Whether or not that is considered "the database" is another matter.

I agree that could be a confusing debate. I originally meant that the
DB engine can't be culpable. SPs that are a part of the standard DBMS
delivery and part of it's documented API, those could certainly be made
vulnerable, although I'd assume a DBMS vendor would know better!

If the SPs are your own, I'd consider them part of the application layer.

-- 
Emiliano

On 2006-06-12, Michael Touloumtzis <miket262@hotmail.com> wrote:
> On Mon, 12 Jun 2006 17:48:32 -0400, Emiliano <Emiliano@Iris-Advies.nl>  
> wrote:
>> ... SQL injection attacks are *always* in the application layer. ...
>
> In general, yes. Though dbms design can make it harder for the application  
> code.

I agree that hand-holding people that are apt to do these kind of
things is a good thing; if the database engine can enforce that
hand-holding to some extent that's very nice. But I see this as I
would the firewall on your network: of course you'd want to have one,
but you don't want to rely on it for your security policy. It's your
*last* line of defence, not your first.

I'll admit I'm not a database expert by any siginifant means. But all
the samples of QI that I've seen so far would have been entirely
avoidable.

> These recent lwn.net articles are quite good:
>
> http://lwn.net/Articles/177037/
> http://lwn.net/Articles/185813/

Yes, they're both interesting, but AFAIS they underscore my point:
query assembly bad, bound parameters good, and the problem (query
assembly) lies in the application layer. The 2nd article even says
so explicitly:
   "Both of these problems could have been avoided by using prepared
   statements with placeholders (i.e. 'SELECT * FROM tbl WHERE
   id=?')."

-- 
Emiliano

This is a multi-part message in MIME format.
--------------070806040204000009010800
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Emiliano wrote:
> On 2006-06-13, Michael Leo <mleo@cariboulake.com> wrote:
>
>   
>> I'd almost agree if it weren't for stored procedures.  I'm not sure if
>> I could manage a SQL injection attack with Ingres' limited stored procedure
>> language, but Oracle certainly has experienced a number of attack vectors
>> vi PL/SQL packages.
>>     
>
> Via *Oracle provided* PL/SQL packages?! For real?!
>
> OK, the thought that a DBMS vendor would deliver SPs that are
> vulnerable to SQL injection never really occurred to me. You got me
> there.
>   
http://www.ngssoftware.com/advisories/oracle23122004H.txt

Fun stuff,

Mike Leo

--------------070806040204000009010800
Content-Type: text/x-vcard; charset=utf-8;
 name="mleo.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="mleo.vcf"

begin:vcard
fn:Michael Leo
n:Leo;Michael
org:Caribou Lake LLC
adr:Suite 100;;8401 Golden Valley Drive;Minneapolis;MN;55427;United States
email;internet:mleo@cariboulake.com
x-mozilla-html:FALSE
url:http://www.cariboulake.com
version:2.1
end:vcard


--------------070806040204000009010800--