Re: Escaping strings for inclusion into SQL queries

> Patch applied. Thanks.
>
> > Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> >
> > > Patch removed at the request of the author. Author will resubmit.
> >
> > I've attached the fixed version of the patch below. After the
> > discussion on pgsql-hackers (especially the frightening memory dump in
> > <12273(dot)999562219(at)sss(dot)pgh(dot)pa(dot)us>), we decided that it is best not to
> > use identifiers from an untrusted source at all. Therefore, all
> > claims of the suitability of PQescapeString() for identifiers have
> > been removed.

I found a problem with PQescapeString (I think). Since it escapes
null bytes to be literally '\0', the following can happen:
1. User inputs string value as "<null byte>##" where ## are digits in the
range of 0 to 7.
2. PQescapeString converts this to "\0##"
3. Escaped string is used in a context that causes "\0##" to be evaluated as
an octal escape sequence.

For example, if the user enters a null byte followed by "47", and escapes
it, it becomes "\071" which gets translated into a single digit "9" by the
general parser. Along the same lines, if there is a null byte in a string,
and it is not followed by digits, the resulting "\0" gets converted back
into a null byte by the parser and the string gets truncated.

If the goal is to "safely" encode null bytes, and preserve the rest of the
string as it was entered, I think the null bytes should be escaped as \\000
(note that if you simply use \000 the same string truncation problem
occurs).

-- Joe