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()
|
Список | 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 по дате отправления: