> * 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
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
