From: | Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp> |
---|---|
To: | fw(at)deneb(dot)enyo(dot)de |
Cc: | ishii(at)sraoss(dot)co(dot)jp, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: possible design bug with PQescapeString() |
Date: | 2006-02-19 10:25:04 |
Message-ID: | 20060219.192504.102582070.t-ishii@sraoss.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> * 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
From | Date | Subject | |
---|---|---|---|
Next Message | Florian Weimer | 2006-02-19 10:33:41 | Re: possible design bug with PQescapeString() |
Previous Message | Florian Weimer | 2006-02-19 10:08:01 | Re: possible design bug with PQescapeString() |