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