Re: RFC: Security documentation - Mailing list pgsql-hackers

From Tom Lane
Subject Re: RFC: Security documentation
Date
Msg-id 4070.1076265211@sss.pgh.pa.us
Whole thread Raw
In response to Re: RFC: Security documentation  ("Nigel J. Andrews" <nandrews@investsystems.co.uk>)
Responses Re: RFC: Security documentation
List pgsql-hackers
"Nigel J. Andrews" <nandrews@investsystems.co.uk> writes:
> On Sat, 7 Feb 2004, Alex J. Avriette wrote:
>> ... or somebody may be passing in the
>> de rigeur '; select * from sensitive_table; ...' attempts (this is very
>> common, as you know, in CGI applications).

> Actually I can and it involves changing the backend to not permit multiple
> statements in one request. I can't imagine how that could sensibly be
> implemented, if at all, though.

Actually, the extended-query message in the new FE/BE protocol works
exactly that way.  This was done for protocol-simplicity reasons not for
security, but you could use it for that.  The new protocol's ability to
separate parameter values from SQL command is also useful for ensuring
security.

> At some stage your interface code has to accept responsibility for preventing
> dangerous input from reaching libpq.

However, I quite agree with that statement.  The app programmer has to
take responsibility for properly segregating or quoting data strings.
We can (and do) provide tools to make this easier, but it's still the
programmer's responsibility to use the tools correctly.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Thomas Hallgren"
Date:
Subject: Re: session persistent data for plperl
Next
From: Tom Lane
Date:
Subject: Re: Kerberos as source of user name? (Re: [BUGS] segfault in psql on x86_64)