Re: possible design bug with PQescapeString()

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


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

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