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