Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72803
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.169 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CAF+90c9umjqfiW3780hPjk_LpbyV=fT2t=bXZxWhiSDN-yuiuA@mail.gmail.com>
References: <CAGa2bXYO=Q3pmYKYOt0qudFtzimrXitJoLcB4KZ80MYJ-nJo0A@mail.gmail.com>
 <CAF+90c9umjqfiW3780hPjk_LpbyV=fT2t=bXZxWhiSDN-yuiuA@mail.gmail.com>
Date: Tue, 25 Feb 2014 14:07:02 +0900
Message-ID: <CAGa2bXZcs-zq7afbY9dqvOcnQ0q1MAC0muO3VNSfxzMnL4_hCg@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e013c6ae461833204f3341136
Subject: Re: [PHP-DEV] Resolution for ver_export()/addslashes() encoding based
 script execution attack?
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--089e013c6ae461833204f3341136
Content-Type: text/plain; charset=UTF-8

Hi Nikita,

On Mon, Feb 24, 2014 at 8:07 PM, Nikita Popov <nikita.ppv@gmail.com> wrote:

> On Mon, Feb 24, 2014 at 10:41 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
>
>> Hi all,
>>
>> Since this RFC is declined,
>>
>> https://wiki.php.net/rfc/multibyte_char_handling
>>
>> We need another short term resolution for it at least.
>> Any suggestions?
>>
>
> Quoting from another thread:
>
> > I'd like to start off by saying that I disagree with your premise that
> this is a security vulnerability that needs to be fixed quickly and across
> all supported versions. As far as I can see the issue is somebody using
> addslashes() in an inappropriate context - this is a vulnerability in the
> application, not PHP. This is a lot like saying that we have an RCE
> vulnerability in eval() because someone had the genius idea of putting
> eval($_GET['str']) in his or her code.
>
> There is no vulnerability here as far as PHP is concerned. As such there
> is no need for a short term resolution.
>

This kind of bugs are considered as vulnerability. There are number of
them. Examples are encoding based JavaScript/SQL injections. I'm not sure
what do you mean by "not a  vulnerability".

> using addslashes() in an inappropriate context - this is a vulnerability
in the application, not PHP.

This is incorrect. PHP supports SJIS and others even in engine.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--089e013c6ae461833204f3341136--