Hi Jan, On Thu, Feb 26, 2015 at 8:30 AM, Jan Ehrhardt <php...@ehrhardt.nl> wrote:
> Jordi Boggiano in php.internals (Wed, 25 Feb 2015 23:09:40 +0000): > >On 25/02/2015 22:46, Stanislav Malyshev wrote: > >> 2. I think this RFC provides false sense of security for people that > >> create vulnerable code and lets them think it's OK to have variable > >> includes without adequate safety, since they are "protected" by these > >> changes. > > > >People that are clueless already do not validate anything and are *NOT* > >protected by this RFC. People that know what they are doing probably do > >not need this patch. So the way I see it it's a win for random crappy > >code out there, and a noop at worst for the others. > > > >> 3. I think it causes significant BC break which might be warranted in > >> case it provides major improvement in security, but IMO in the light of > >> the above it does not provide even minor one. > > > >A way to mitigate this might be to change the default to include a few > >more common extensions like phtml, inc, or whatever. As those are all > >commonly associated with PHP and offer no good reason to be allowed in > >user uploads, I guess it's safe. > > Better yet: allow all by default. Then there is no BC break and nothing > changes for clueless people. People with clue can make their own choice > to use or not to use. > Providing "secure default" is our responsibility, especially for fatal security breach. IMHO. We've done that for allow_url_include, for example. I hoped allow_url_include and NULL byte prevention could eliminate script inclusions, but it didn't. This RFC is more powerful than allow_url_include/NULL byte protection. In fact, it makes PHP programs as safe as other languages with respect to script inclusions when consistent configuration is used. The feature can be disabled by users easily. The feature warns users possible security breaches. I don't see reasons disabling the feature by default. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
