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 internals+get-72803@lists.php.net to get a copy of this message
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

« previous php.internals (#72803) next »