Re: Resolution for ver_export()/addslashes() encoding based script execution attack?

From: Date: Tue, 25 Feb 2014 05:07:02 +0000
Subject: Re: Resolution for ver_export()/addslashes() encoding based script execution attack?
References: 1 2  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message
Hi Nikita,

On Mon, Feb 24, 2014 at 8:07 PM, Nikita Popov <[email protected]> wrote:

> On Mon, Feb 24, 2014 at 10:41 AM, Yasuo Ohgaki <[email protected]> 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
[email protected]


Thread (20 messages)

« previous php.internals (#72803) next »