Re: possible design bug with PQescapeString()

> > Tatsuo Ishii <ishii@sraoss.co.jp> writes:
> > > I suggest that PQescapeString() should have a parameter to specify the
> > > encoding of "to".
> > 
> > You mean the encoding of "from", no?
> 
> Oops, "from", yes.
> 
> > But actually I'd argue that
> > letting the client programmer supply the encoding is still a pretty
> > dangerous practice.  Your example demonstrates that if the encoding
> > PQescapeString is told is different from the encoding the backend parser
> > thinks is in use, problems result.  Perhaps we should pass the PGconn
> > to new-PQescapeString and let it dig the client encoding out of that.
> 
> Sound good to pass PGconn to new-PQescapeString. Here is the proposed
> calling sequence for the new function:
> 
> size_t PQescapeStringWithConn (const PGconn *conn, char *to, const char *from, size_t length)
> 
> If this is ok, I will implement for 8.2.

In further investigation, Akio Ishida found this kind of attack is
possible even with EUC_JP/UTF-8. So it seems the problem is not only
with SJIS, BIG5 and GBK. I think we need to add PQescapeStringWithConn
or whatever as soon as possible.
--
Tatsuo Ishii
SRA OSS, Inc. Japan

> > You could still get burnt if the client encoding changes between the
> > invocation of new-PQescapeString and the sending of the constructed
> > command, but that's a fairly unlikely case.
> > 
> > The bottom line to this though is that these encodings are just plain
> > dangerous.  I'm more than half tempted to suggest that the only secure
> > answer is to drop support for these encodings.  Consider for example
> > an application that isn't using PQescapeString but has its own
> > double-backslashes-and-quotes logic embedded.  You can break it if you
> > can manage to get the backend to think that the client encoding is SJIS
> > or similar.  That's a hazard we're basically not ever going to be able
> > to prevent.
> 
> Dropping support for SJIS and so on will not be practical at all since
> these encodings has been widely used and I don't see these encodings
> are deprecated in the near future. I think dropping the support will
> simply prevent people from using PostgreSQL. Especially in Windows
> world, these encodings are pretty common.
> 
> I know that these encodings are broken in their design and actually I
> hate them:-) But this is real world and we have to live with them...
> --
> Tatsuo Ishii
> SRA OSS, Inc. Japan
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
>