Re: Re: [RFC] No PHP tags

From: Date: Thu, 13 Feb 2014 15:07:41 +0000
Subject: Re: Re: [RFC] No PHP tags
References: 1 2 3 4  Groups: php.internals 
Request: Send a blank email to internals+get-72556@lists.php.net to get a copy of this message
On 02/12/2014 05:30 PM, Yasuo Ohgaki wrote: > I think you have enough skill to prevent script inclusion attacks. However, > all PHP users are not. Take a look at vulnerability reports, you'll find > number of LFI that could be prevented by this RFC. > > http://packetstormsecurity.com/search/?q=LFI > > These are only reported LFI vulnerabilities and there are countless > vulnerable scripts in the wild. > > I don't see any reason to keep doors open for attackers. We are better to > close as many doors as possible, especially for fatal disaster(script > execution). > > Thank you for the comment! > > Regards, > > P.S. I was added script()/script_once() to the original RFC. However, it > may be easier for users to have template()/template_once() that parses file > as embedded PHP script mode always and keep include()/require() for script > inclusion. This way, users do not have to rewrite include()/require() to > script(). Anyone has any comments? I just went through about 20 LFIs at http://packetstormsecurity.com/search/?q=LFI and in every single case an appropriately set open_basedir would have prevented the LFI. That seems pretty definitive to me. The feature to prevent LFI is already there. We do not need another one. Especially one that introduces a confusing distinction between scripts and templates which really has nothing to do with the underlying problem. So the real problem is two-fold. People are making these mistakes in the first place, and second, they are not coding defensively and setting open_basedir. You are still asking people to actively make a defensive coding change with this RFC, but the people who make these mistakes and don't code defensively aren't suddenly going to change so they would not benefit. -Rasmus

« previous php.internals (#72556) next »