Thomas Mueller wrote:
> Disabling literals is still the only way to actually protect from SQL
> injection. Except Meredith's libdejector, which is even a bit better
> as far as I see, but requires more work from the developer. I don't
> count Microsoft LINQ (or Java Quaere) currently because that would
> require a complete re-write of the application.
>
>
>

I honestly don't think there's any chance of this happening, for the
many good reasons previously covered in this debate.

cheers

andrew

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

"Thomas Mueller" <thomas.tom.mueller@gmail.com> writes:
>> 1. Inexpensive to implement

> Disabling literals wouldn't be much harder to implement I believe, but
> I don't know the PostgreSQL internals.

You're ignoring the client-side costs of repairing broken applications.

(If it only broke applications that were in fact insecure, that would be
one thing, but having to change code that there is nothing wrong with
is not something that people will accept easily.)

> Disabling literals is still the only way to actually protect from SQL
> injection.

If it were actually a complete defense then maybe the costs would be
justifiable; but it isn't, as per previous discussion.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Thu, May 01, 2008 at 06:33:07PM +0200, PFC wrote:

> But it's true that preventing multi-statements adds a layer of
> idiot-proofness... a rather thin layer...

As I already said in a previous remark in this thread, I don't really
like partial security solutions.

What the "no multi-statement SQL" switch adds is a complete protection
against _one class_ of injection attacks. What is nice about it is
that it completely eliminates that class of attacks, so they are no
longer something one needs to worry about.

They do not, of course, prevent every kind of injection attack. I
think the thread has already had ample evidence that such complete
prevention is either impractical to implement, too costly to existing
applications, too limiting, not actually effective (i.e. not really
complete prevention), or some combination of the above.

That's not an argument that the simple change that is effective for
only one class of attacks is a bad idea. Making the battlefield
smaller is one thing one can do to decrease one's exposure to attack.

A
--
Andrew Sullivan
ajs@commandprompt.com
+1 503 667 4564 x104
http://www.commandprompt.com/

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

* Thomas Mueller:

> What do you think about it? Do you think it makes sense to implement
> this security feature in PostgreSQL as well?

Can't this be implemented in the client library, or a wrapper around it?
A simple approximation would be to raise an error when you encounter a
query string that isn't contained in some special configuration file.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

fw@deneb.enyo.de (Florian Weimer) writes:
> * Thomas Mueller:
>
>> What do you think about it? Do you think it makes sense to implement
>> this security feature in PostgreSQL as well?
>
> Can't this be implemented in the client library, or a wrapper around it?
> A simple approximation would be to raise an error when you encounter a
> query string that isn't contained in some special configuration file.

This could be implemented in a client library, but that means that
you're still entirely as vulnerable; any client that chooses not to
use that library won't be protected.

It would be a mighty attractive thing to have something at the server
level to protect against the problem.
--
let name="cbbrowne" and tld="linuxfinances.info" in String.concat "@" [name;tld];;
http://linuxdatabases.info/info/lsf.html
If you add a couple of i's to Microsoft's stock ticker symbol, you get
'misfit'. This is, of course, not a coincidence.

Chris Browne wrote:
> fw@deneb.enyo.de (Florian Weimer) writes:
>
>> * Thomas Mueller:
>>
>>
>>> What do you think about it? Do you think it makes sense to implement
>>> this security feature in PostgreSQL as well?
>>>
>> Can't this be implemented in the client library, or a wrapper around it?
>> A simple approximation would be to raise an error when you encounter a
>> query string that isn't contained in some special configuration file.
>>
>
> This could be implemented in a client library, but that means that
> you're still entirely as vulnerable; any client that chooses not to
> use that library won't be protected.
>
> It would be a mighty attractive thing to have something at the server
> level to protect against the problem.
>

If by "the problem" you mean SQL injection attacks in general, I
strongly suspect you are chasing a mirage.

Someone mentioned upthread that the best way to secure the database was
to require that all access be via stored procedures. You can actually go
quite a logn way down that road. I have seen it done quite successfully
in a Fortune 50 company. In effect you are getting out of the game of
catching insecure operations by not allowing your user direct access to
them at all. (This approach also has huge benefits in allowing
optimisation without disturbing client code).

But this requires work by the DBA. I have some ideas about how we could
make it a whole lot easier and more workable, but they probably don't
belong in this thread.

cheers

andrew

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers