Re: possible design bug with PQescapeString()

Поиск
Список
Период
Сортировка
От Florian Weimer
Тема Re: possible design bug with PQescapeString()
Дата
Msg-id 87lkw7iqnu.fsf@mid.deneb.enyo.de
обсуждение исходный текст
Ответ на Re: possible design bug with PQescapeString()  (Tatsuo Ishii <ishii@sraoss.co.jp>)
Ответы Re: possible design bug with PQescapeString()  (Tatsuo Ishii <ishii@sraoss.co.jp>)
Список 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).


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tatsuo Ishii
Дата:
Сообщение: Re: possible design bug with PQescapeString()
Следующее
От: Tatsuo Ishii
Дата:
Сообщение: Re: possible design bug with PQescapeString()