Message-ID: <C6AF3ECACA6E9A46A2CB2FABCDCB35C424AEEB@swilnts810.wil.fusa.com>
Date: Mon Apr 25 14:16:37 2005
From: Glenn.Everhart at chase.com (Glenn.Everhart@...se.com)
Subject: FW: Introducing a new generic approach
	todetecting SQL injection

While the example would pass the proposed test evaluation in the sense it
would still give an invalid statement, there may be some related type
tests that check things like the count of results from an inserted
result which would reveal some of those attacks.

The scheme I proposed was not guaranteed to cover all attacks, just some
classes of them; I'd be amazed if there weren't a number more classes that
don't work, but again perhaps there are other related defensive techniques.
They don't replace everything else that is known, are just another set
of tests that can be used.

I could wish for extensions to the SQL parser (controlled out of band since
Paul pointed out that in band controls would be trivial to bypass...doh) that
would allow a caller to get information generally about the results that
would be obtained or about parsing features used. Such things might be a whole
lot easier to gather and use, and more precise than shoving entire statements at
the parser and watching for errors. This is one of those cases where we only
have a hammer and maybe a couple other tools, so have to do some creative abuse
of the materials to get what we want. Doesn't mean we can't also shop for a
fuller toolbox. (In my old spreadsheet AnalyRim, I found that it was often handy
to return extra information from functions, and used a bunch of global accumulators
to do so. The functions I did this in grew hardly at all, since only a few instructions
were added to save internal results that were already being generated, but I was enabled
to write some applications in far less code. The info needed is likely already generated
inside the DBMS and might be returnable in some similarly cheap way if authors
of the DBMS code feel like doing it.

Glenn Everhart

-----Original Message-----
From: full-disclosure-bounces@...ts.grok.org.uk
[mailto:full-disclosure-bounces@...ts.grok.org.uk]On Behalf Of Mohit
Muthanna
Sent: Saturday, April 23, 2005 8:20 AM
To: Paul J. Morris
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: [Full-disclosure] FW: Introducing a new generic approach
todetecting SQL injection


>      What is intriguing me about it is that it is a different way of
> approaching the problem of untrusted user input, one that uses the
> strengths of the dbms itself rather than relying on code written on a
> layer above the dbms to send safe data to the dbms.  

True... it is novel. My guess is that it opens up a really big can of worms.

>    Because we are not talking about an attacker on a psql console, we
> are talking about an attacker passing characters through an interface
> layer that might be using different rules than the PostgreSQL
> parser. If I can encode' as a multibyte character in a way that the
> layer which is doing the escaping does not recognize it as a '
> character, but the PostgreSQL parser does, then I can bypass your

I wasn't talking about the console either. But I see your point about
weaknesses in the validation mechanisms of other interface layers
adding an element of uncertainty. I'd like to add that in this case,
prepared statements (or very restrictive regular expressions) would be
invaluable.


> attacks in the same way that it does.  One form of attack I see that it
> won't recognise is a valid clause that extends the scope of the result
> set without invoking the name of a entity in the database: "' and 1=1
> and 1='"

Yes. This is just one worm from the can. :-)

>      I have learned to worry when some piece of security seems easy....
>  :)

With good reason.

Mohit.

-- 
Mohit Muthanna [mohit (at) muthanna (uhuh) com]
"There are 10 types of people. Those who understand binary, and those
who don't."
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/


**********************************************************************
This transmission may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you
**********************************************************************

Powered by blists - more mailing lists