Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72834
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.54 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <530DDEC6.9010901@lsces.co.uk>
References: <CAGa2bXYO=Q3pmYKYOt0qudFtzimrXitJoLcB4KZ80MYJ-nJo0A@mail.gmail.com>
 <CAF+90c9umjqfiW3780hPjk_LpbyV=fT2t=bXZxWhiSDN-yuiuA@mail.gmail.com>
 <CAGa2bXZcs-zq7afbY9dqvOcnQ0q1MAC0muO3VNSfxzMnL4_hCg@mail.gmail.com>
 <530C3C7B.8080907@sugarcrm.com> <CAGa2bXYyxrLXxT812=s_s7zB+En1mfAJy9du90+Yt7OPZYjdvA@mail.gmail.com>
 <530C77F8.2060809@sugarcrm.com> <1393328380.5233.45.camel@guybrush>
 <CAGa2bXbNKxNN-j1LoisnvGsUbxk-6ZqNG87zF3BUg1LEHUYcgw@mail.gmail.com>
 <530DADC7.2070302@lsces.co.uk> <CAGa2bXYFBocCPYXZxznWj8-y+O8ME9vHKC4BcG=UQqC6rocRjg@mail.gmail.com>
 <530DDEC6.9010901@lsces.co.uk>
Date: Thu, 27 Feb 2014 07:28:23 +0900
Message-ID: <CAGa2bXYBqNX8e+sSpoF-AoJCpKY0paQaxMSi0N5rxHOiz1VpQg@mail.gmail.com>
To: Lester Caine <lester@lsces.co.uk>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c23e2e6a296404f356bb5c
Subject: Re: [PHP-DEV] Resolution for ver_export()/addslashes() encoding based
 script execution attack?
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a11c23e2e6a296404f356bb5c
Content-Type: text/plain; charset=UTF-8

Hi Lester,

On Wed, Feb 26, 2014 at 9:32 PM, Lester Caine <lester@lsces.co.uk> wrote:

> Yasuo Ohgaki wrote:
>
>>         As you know, all databases' escaping functions have encoding
>> parameter.
>>         PostgreSQL uses encoding parameter stored in db connection
>> structure. This
>>         is the reason why pg_escape_string() has optional database base
>> connection
>>         parameter for escaping.
>>
>>
>>     On the whole any database access I'm doing with Firebird is done using
>>     parameters which are handled in the database connection rather than
>> having
>>     to worry about many of these sorts of 'protections'. The result for
>> me is
>>     that I don't have to worry about many of the problems the more lax
>> handling
>>     of data in MySQL can create. But the more important thing here is
>> that I've
>>     not used a 'locale' other than UTF8 for websites for many years and
>> so the
>>     whole underlying structure needs fixing rather than trying to patch
>> small
>>     areas that are better handled by doing the job correctly in the first
>> place!
>>
>>
>> We cannot force users to use Unicode for database/file/etc ;)
>> I'm not proposing use of locale, but new escape API that support multibyte
>> encoding.
>>
>
> My point Yasuo is that I think the reason this has been rejected is simply
> because there needs to be a more comprehensive review of how 'multi_byte'
> characters are handled? There needs to be at least some agreement moving
> forward if PHP should be made fully UTF-8 complaint or the alternative
> 'ASCII only' for code, so that perhaps 'mb_' SHOULD be the only way to
> handle multi byte strings? Short term fixes are just exacerbating the real
> problem? Also I don't see how the RFC addressed the problem anyway. While I
> use UTF-8 output exclusively I've not had to resort to mbstring extension
> to do so yet so would not even use the extra functions in normal production.


IMO. PHP core should only support UTF-8 with simple/fast Unicode library.
 Use UTF-8 internally, allow any encoding for I/O. This will makes many
users life easier.

> so that perhaps 'mb_' SHOULD be the only way to handle multi byte strings?

I agree mostly. It would be feasible solution for now. I don't care what
module/feature is going to handle multibyte strings, but we need multiple
encoding support for I/O related functions at least. Escape function is one
of them. Escaped data is escaped to be outputted somewhere. e.g. That's the
reason why we have multiple encoding support for htmlspecialchars(). (We
may force to generate all text with UTF-8, then convert when it is
outputted, but this is BC.)

We cannot force users to use "\n" as line break. Like line break, we cannot
force users to specific encoding for I/O. OSX filename is one of them, too.
We cannot force OSX to use NFC file name. There are things like these.

> Short term fixes are just exacerbating the real problem?

I don't think so. It's just an simple addition to mbstirng. We already have
various mess around multibyte support. e.g. When we need to know multbyte
character length, there is only mb_strlen(). Adding required function for
security weighs. Besides, users who don't use mb_*() do not have to care at
all. Framework developers that support i18n should care, though.

IMHO, both short and long term resolution is good enough. It does not harm
nor affect future PHP development at all. It's a module anyway.

> I don't see how the RFC addressed the problem anyway.

Please research how databases were fixed this issue many years ago. I don't
remember well, but I guess it was around 2005.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a11c23e2e6a296404f356bb5c--