Re: possible design bug with PQescapeString()

> >> Uh-oh, this is my fault. PQescapeString should escape all characters
> >> greater than 126. Unfortunately, there is nothing we can do about
> >> this in the current function because tha twould need four times the
> >> lenggth of the input string (plus one). Drat.
> >
> > Please don't do that. That would break all applications those use
> > the mutibyte encodings including UTF-8.
>
> Why? Doesn't the server perform unquoting *before* multi-byte
> processing? -- Ah, it doesn't. Perhaps this is the part which should
> be fixed?

No no. Probably you misunderstand why we need quoting. If special
characters such as "'" or "\" appears, it should be quoted. But you
should not if it's a part of multibyte characters.

> >> (I don't think you should have to consider the encoding in the client;
> >> strange things may happen if there is an interpretation conflict
> >> between the client and the backend.)
> >
> > No. For the sake PQmblen() is provided. What I (and I guess Tom too)
> > am thinking is like this:
> >
> > attacker's input:
> >
> > (0x95+0x27);DELETE FROM members;--
> >
> > new-PQescapeString() treats this:
> >
> > 0x95+0x27;DELETE FROM members;--
>
> But this still needs knowledge of SJIS at the client side (and both
> client and backend must have the same notion of SJIS).

No problem. We have the client encoding in PGConn. That's why Tom suggests
PQescapeString() should have the PGCConn argument.
--
Tatsuo Ishii
SRA OSS, Inc. Japan