Re: possible design bug with PQescapeString()

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).

In response to

Responses

Browse pgsql-hackers by date

  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()