Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72568
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.42 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <52FCDFBD.80901@lerdorf.com>
References: <CAGa2bXYU0+eVgnDCkqpG6AWvLCX9gV3+5nzoeD-RJge8Rtw-dQ@mail.gmail.com>
 <CAGa2bXZCBxJczqX6FKz0T0_iV9LzdeHkw46c17NQsanuCCJ9rA@mail.gmail.com>
 <52FBF8F8.5040107@gmail.com> <CAGa2bXb=2fJisj90HY6ojMKmJeFFGbTwn6J1vZayzxBTLz7fBQ@mail.gmail.com>
 <52FCDFBD.80901@lerdorf.com>
Date: Fri, 14 Feb 2014 07:51:59 +0900
Message-ID: <CAGa2bXb4Ry6rwaXzjfjfLDzyhb_vgehTKTmadeSHScUCYycEqg@mail.gmail.com>
To: Rasmus Lerdorf <rasmus@lerdorf.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7ba9719add1e5604f2518b61
Subject: Re: [PHP-DEV] Re: [RFC] No PHP tags
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--047d7ba9719add1e5604f2518b61
Content-Type: text/plain; charset=UTF-8

Hi Rasmus,

On Fri, Feb 14, 2014 at 12:07 AM, Rasmus Lerdorf <rasmus@lerdorf.com> wrote:

> 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.


I agree.
People who realize importance of security must develop application
defensively. They must validate all inputs strictly when inputs are
supplied. They must use all protection mechanism available.

It's perfectly true that users can write robust web applications with PHP,
but Packet Storm reports show that we are better to have yet another
protection for disasters. People write weak applications/codes. I audit
Rails application also. Rails is not a magic platform that makes web
applications secure. Those people write weak applications with Rails  would
write weak applications with PHP, too. I'm sure many of them would write
LFI vulnerable codes. Yet, their applications do not have fatal disaster
like LFI.

PHP is for the web. Web is extremely dangerous as serious professional
attackers exploit web for money. Introducing yet another effective counter
measure for fatal error is valuable for PHP community because there are
vulnerable applications/codes. I cannot accept the fact that PHP could be
much insecure than others when the same developers write applications...

<?php
ini_set('template_mode', 'OFF'); // All require()/include() are protected
against typical LFI
require($some_module); // script only
require($another_module); // script only

// Need template(embedded) mode. Extra caution here.
template($mytemplate . '.php'); // embedded script.


Users may have LFI with template() still, but attack vector is limited to
template(). It's much easier for users to pay extra attentions to limited
template() rather than all script inclusions. (It's easier to audit, too :)

Perhaps, we may be better to force template() to have ".php" extension (or
2nd required param as extension), so that
template($template);
includes "${template}.php" always. It's much secure thanks to your(Rasmus)
null byte attack protection.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--047d7ba9719add1e5604f2518b61--