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/
