Re: RFC: Security documentation

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Nigel J(dot) Andrews" <nandrews(at)investsystems(dot)co(dot)uk>
Cc: "Alex J(dot) Avriette" <alex(at)posixnap(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: RFC: Security documentation
Date: 2004-02-08 18:33:31
Message-ID: 4070.1076265211@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Nigel J. Andrews" <nandrews(at)investsystems(dot)co(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2004-02-08 18:54:26 Re: Kerberos as source of user name? (Re: [BUGS] segfault in psql on x86_64)
Previous Message Andrew Dunstan 2004-02-08 18:04:54 Re: session persistent data for plperl