Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59733
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain cywh.com from 209.85.220.170 cause and error)
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> <CAGa2bXbXdNcfHX_dM2EVVz_2JtS4cc+8pxneSLAd382TuQUg-w@mail.gmail.com>
 <4F8539E0.1090701@sugarcrm.com> <4F859063.1010401@lerdorf.com>
In-Reply-To: <4F859063.1010401@lerdorf.com>
Mime-Version: 1.0 (1.0)
Date: Wed, 11 Apr 2012 08:12:37 -0700
Message-ID: <-3427386339833244777@unknownmsgid>
To: Rasmus Lerdorf <rasmus@lerdorf.com>
Cc: Stas Malyshev <smalyshev@sugarcrm.com>, Yasuo Ohgaki <yohgaki@ohgaki.net>, 
	"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: luke@cywh.com (Luke Scott)

Hey Rasmus,

Here are my thoughts:

On Apr 11, 2012, at 7:09 AM, Rasmus Lerdorf <rasmus@lerdorf.com> wrote:

> On 04/11/2012 12:59 AM, Stas Malyshev wrote:
>>> 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.
>>
>> I don't see how it is "much safer". Exactly the same problem exists. Not
>> only it is not "perfect" countermeasure, it's not countermeasure at all,
>> judging from your description. It's like saying "I have SQL injection
>> protection, but only if word "please" is not part of the SQL injection".
>> It's not a real protection then.
>
> I guess he is saying that it prevents:
>
>   Random bytes
>   <?php kill();?>
>   More random bytes
>
> Where random bytes might be an image file so finfo_file() might identify
> it as a valid image whereas it doesn't prevent:
>
>  <?php kill();?>
>  Random bytes
>
> from being mistakenly included. And I guess a secondary thing it might
> prevent is an include of something like /etc/passwd since there is no
> valid PHP code there and it would error out.

Isn't this determined by the web server, not PHP? The only way this
would happen is if image files were sent to the PHP interpreter or the
image had a .php.

In both cases it's the server admins responsibility to make sure the
web server doesn't send any file from an upload folder to the PHP
interpreter, with a .PHP extension or not. The programmer should also
be mindful of what extensions are being allowed to go in the upload
folder incase the server admin was negligent.

The only benefit is only having to check the start of the file for a
<?php tag. But if both the programmer and server admin are being
negligent this benefit is moot.

> So, those are the pros. The cons are:
>
> 1. Creating a new mode for PHP that essentially breaks most existing PHP
> code if this mode is enabled puts more pressure on people trying to
> write portable code. It would encourage them to never use templating
> mode since non-templating mode is the only safe approach that would work
> regardless of the configuration. Much the same way that all portable
> code uses <?php and no <?

Tom has a "similar" RFC that has two modes:

- Template mode - how it is now
- Code (or pure code) mode - <?php is only allowed at the top and is
optional. ?> is disallowed.

Tom's RFC calls for template mode to remain the default, but allow you
to add a flag to require/include to interpret the script in "pure
mode". Allowing an optional starting <?php (only at top) maintains
backwards compatibility with most classes.

The benefit is not having to write <?php and forbidding ?> in the
middle of a class (which most people already do voluntarily).

> 2. Templating is a defining characteristic of PHP. For many people it is
> the primary reason they even use PHP. Adding a feature that would
> essentially discourage use of a defining feature of PHP is illogical.

True. People are side stepping this though for template engines such
as Twig, PHPTAL, Smarty (ug..), just to name a few.

PHP is being used more as a programming language than a template
engine. People have already naturally gravitated towards keeping their
code separate.

Toms proposal of a code and template mode makes sense. It clearly
separates the two. You could theoretically enhance the template part.
Like I love the idea of PHPTAL - I wrote a similar template engine
that uses attributes to convey logic (data-if, for example). Attribute
syntax preserves the design of a template. Right now I have to parse
this and convert this to a PHP class. Wouldn't it be great if PHP did
this in its template mode? Or easily allowed people to provide
alternate "template engines" that required no pre-parsing in PHP
(other than the usual code to opcode transformation)?

> 3. For the /etc/passwd case, the syntax error might reveal enough data
> about the contents of the file that this doesn't actually provide enough
> of a benefit unless we also heavily redact what we show in a syntax
> error. Of course, the argument here is not to show the error to users,
> but people who write code with include $_GET['filename'] aren't likely
> to follow best practices in the first place.
>
> 4. Only protecting against mid-script injections and not top-of-script
> injections is a somewhat subtle concept when the real problem is the
> vulnerable include $_GET['filename'] hole. If this really is a prevalent
> problem, maybe instead of trying to mitigate the symptoms, why don't we
> try to attack the actual cause of the problem. I would love to hear some
> ideas along those lines that don't fundamentally change the nature of
> PHP for somewhat cloudy benefits.

The problem is people are doing that. The solution is they should stop
doing that. Anyone doing this is asking for trouble. The fix is better
education.

In the end while I do support the idea of not allowing "embed mode"
(as a choice when doing require/include), I cannot support the idea
that it somehow makes things more secure.

Luke