Bruce Momjian wrote:
> Your patch has been added to the PostgreSQL unapplied patches list at:
> I will try to apply it within the next 48 hours.
> > It has come to our attention that many applications which use libpq
> > are vulnerable to code insertion attacks in strings and identifiers
> > passed to these applications. We have collected some evidence which
> > suggests that this is related to the fact that libpq does not provide
> > a function to escape strings and identifiers properly. (Both the
> > Oracle and MySQL client libraries include such a function, and the
> > vast majority of applications we examined are not vulnerable to code
> > insertion attacks because they use this function.)
I think the real difference is what I complained in another mail to this
in postgresql you can't do PREPARE / EXECUTE which could _automatically_
where string escaping is needed or just eliminate the need for escaping.
In postgreSQL you have to construct all queries yourself by inserting
parameters inside your query strings in right places and escaping them
needed. That is unless you use an interface like ODBC/JDBS that fakes
PREPARE/EXECUTE on the client side and thus does the auto-escaping for
I think that this should be added to TODO
* make portable BINARY representation for frontend-backend protocol by
typsend/typreceive functions for binary and typinput typoutput for
(as currently typinput==typreceive and typoutput==typsend is suspect
usage to be inconsistent).
* make SQL changes to allow PREPARE/EXECUTE in main session, not only in
* make changes to client libraries to support marshalling arguments to
using BINARY wire protocol or correctly escaped ASCII. The binary
would be very helpful for BYTEA and other big binary types.
> > We therefore suggest that a string escaping function is included in a
> > future version of PostgreSQL and libpq. A sample implementation is
> > provided below, along with documentation.
While you are at it you could also supply a standard query delimiter
as this is also a thing that seems to vary from db to db.
In response to
pgsql-hackers by date
|Next:||From: Peter Eisentraut||Date: 2001-08-31 08:51:09|
|Subject: Re: Multiple semicolon separated statements and autocommit|
|Previous:||From: Tatsuo Ishii||Date: 2001-08-31 02:06:00|
|Subject: Re: Majordomo being upgraded ...|