Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71196
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.50 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CAF+90c-ZgsCczU71TJap1yeaNhKgQeoUR5oLKwwHHaoOD8z_ig@mail.gmail.com>
References: <CAGa2bXauxj6Sca8qYk2cxQ=TeG4bjWgcv-Aqy3cJe35ap72Yfw@mail.gmail.com>
 <CAF+90c-ZgsCczU71TJap1yeaNhKgQeoUR5oLKwwHHaoOD8z_ig@mail.gmail.com>
Date: Fri, 17 Jan 2014 07:34:06 +0900
Message-ID: <CAGa2bXb6jLX8HMN-rL7t5j5R_0SaeRkd5r4_MrmQFfsJxxaSxQ@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e01493f6460deda04f01e08f1
Subject: Re: [PHP-DEV] [RFC] Multibyte char handling
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--089e01493f6460deda04f01e08f1
Content-Type: text/plain; charset=UTF-8

Hi Nikita,

On Thu, Jan 16, 2014 at 9:18 PM, Nikita Popov <nikita.ppv@gmail.com> wrote:

> On Thu, Jan 16, 2014 at 12:50 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
>
>> Hi all,
>>
>> addslashes() could be vulnerable via char encoding based attacks.
>> It is needed to decide what counter measure we adopt.
>> This is RFC for this issue.
>>
>> https://wiki.php.net/multibyte_char_handling
>>
>> Please comment.
>> Thank you.
>>
>
> Please do *not* add encoding parameters to our existing string functions -
> we have an mb extension and mb functionality should go there. Don't mix the
> things, it will only lead to a lot of confusion. Right now it's obvious
> which functions handle encoding how, no need to break that.
>

This discussion circulate discussion.

At first, I proposed locale based solution using php_mblen().
This approach does not require additional encoding parameter
since encoding is specified by locale.

However, some people don't like the solution (in security ML)
because it is  locale based solution. It may have unwanted side
effects. Locale is unreliable and most user just don't care about it.

Therefore, I proposed this approach that introduce encoding
parameter just like htmlspecialchars()/htmlentities().

Encoding parameter (or some way to specify encoding) for security
related string function is mandatory. We should provide some way
to specify encoding.

Do you like locale based approach for now?

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--089e01493f6460deda04f01e08f1--