Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59719
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.161.170 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <4F851FE4.7000706@sugarcrm.com>
References: <CAGa2bXZ6G=Cphjrde3u1Mq3AAw-4yJk3s28vNe+Aybt2nGTumg@mail.gmail.com>
 <CAGa2bXZh4uMeUH_BSCFmfNgxS-SZC0svA9BPcSROjwmbfrtFyQ@mail.gmail.com>
 <CAGa2bXbhi4zdgd9Udo6KsoycDwg_Ke0Xe5h3_-fVDMvn_VfAjQ@mail.gmail.com>
 <A633CF2D7C7BED41B41F1E64F25507B806A5CDD6C2@MAILR001.mail.lan>
 <CAGa2bXZKfQ+HqOucwOnBH7gV84hpdxZb5qNY3t3ThF_zMKSGHw@mail.gmail.com>
 <4F850D06.10701@sugarcrm.com> <CAGa2bXZWrRh8RdMtKK_2_U_XmByC-O6hGRPrJyW5KwvE0CAK-w@mail.gmail.com>
 <4F8515AF.8060706@sugarcrm.com> <CAGa2bXZWudQeRm5h2eENGmgQDPfOqEmijB9-vPAvfKXLCfDiLw@mail.gmail.com>
 <4F851FE4.7000706@sugarcrm.com>
Date: Wed, 11 Apr 2012 15:36:58 +0900
Message-ID: <CAGa2bXbXdNcfHX_dM2EVVz_2JtS4cc+8pxneSLAd382TuQUg-w@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: John Crenshaw <johncrenshaw@priacta.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] Re: Disabling PHP tags by php.ini and CLI options
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

Hi,

2012/4/11 Stas Malyshev <smalyshev@sugarcrm.com>:
> Hi!
>
>> If attacker can inject code at the beginning or make valid syntax
>> at the beginning, they can succeed injection. This is true not
>> only for PHP, but also Ruby/Perl/Python.
>
> This is exactly my point. Since it does not solve the problem that you
> are presenting (I am still not convinced it's our problem, but for the
> same of discussion let's assume for now it is so) - why exactly would we
> want to do it? I'm afraid we'd have another safe_mode scenario on our
> hands here, where we lure users into complacency with false sense of
> security, while not actually providing it.

safe_mode was security measure in first place.
(I liked it as fail safe feature. The name should have been
 fail_safe_mode)

template_mode=on is not a actual security measure, but a
switch for language mode. template_mode=on has side
effect that makes PHP as safe as other scripting languages
or even better!

Therefore, it should not be misunderstood as perfect LFI
countermeasure even if I stressed on security meanings.
I'm stressing security because this actually helps PHP being
much safer than now.

For this respect, template_mode=on is like prepared query.
Prepared query is *NOT* designed as a security measure, but
for better performance. Prepared query is not a perfect
SQL injection countermeasure as it never escape nor
parameterize identifiers/SQL literals. It works well as a
security measure for most cases, though.

There are many features that is used or considered as
security measure that aren't a perfect or designed for it.

We have to be careful about this so that PHP programmers
do not misunderstood LFI prevention is not required anymore,
 if we are going adopt this RFC for next PHP.

PHP could be stronger against LFI compare to scripting languages
as I described in previous mail.

With this RFC, infamous reputation of LFI can be removed from PHP!

I hope most of us will accept this RFC, if it is not all.
Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net