Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72556
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lerdorf.com from 209.85.213.43 cause and error)
Message-ID: <52FCDFBD.80901@lerdorf.com>
Date: Thu, 13 Feb 2014 07:07:41 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
CC: "internals@lists.php.net" <internals@lists.php.net>
References: <CAGa2bXYU0+eVgnDCkqpG6AWvLCX9gV3+5nzoeD-RJge8Rtw-dQ@mail.gmail.com> <CAGa2bXZCBxJczqX6FKz0T0_iV9LzdeHkw46c17NQsanuCCJ9rA@mail.gmail.com> <52FBF8F8.5040107@gmail.com> <CAGa2bXb=2fJisj90HY6ojMKmJeFFGbTwn6J1vZayzxBTLz7fBQ@mail.gmail.com>
In-Reply-To: <CAGa2bXb=2fJisj90HY6ojMKmJeFFGbTwn6J1vZayzxBTLz7fBQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: [RFC] No PHP tags
From: rasmus@lerdorf.com (Rasmus Lerdorf)

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