Re: possible design bug with PQescapeString()

> * Tatsuo Ishii:
>
> > Users can input value for "var" from a web form. The attacker inputs
> > following string:
> >
> > (0x95+0x27);DELETE FROM members;--
> >
> > where 0x95+0x27 is actually a SJIS mutibyte KANJI. Programmer applies
> > PQescapeString() to it and gets:
> >
> > 0x95+0x27+0x27;DELETE FROM members;--
>
> 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.

> (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;--

because the encoding is SJIS. And the result SQL will be:

SELECT * FROM members WHERE member_name = '0x95+0x27;DELETE FROM members;--';

The attacker loses.
--
Tatsuo Ishii
SRA OSS, Inc. Japan