Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81903
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.43 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXarZ4A9+HPXniAvBxEtE9KEJTYHHW8aYHCkBsNN5dRNUw@mail.gmail.com>
References: <CAGa2bXZMxxXBOQ=NdbNtzgrjjvdomV8zOr+Z4zASZU4+JHmqyw@mail.gmail.com>
	<CAGa2bXbf=hzbZ9eH6JVnMM0+6OeTQvAoqBe44g8qxFAAr9u9Kw@mail.gmail.com>
	<CAG1choq8S_EkdS22SFO+443u_LYVB-Z-b2ra6RK8sDhrJKc-VQ@mail.gmail.com>
	<CAGa2bXbJyK=2GCmGDw7PAh0ib=EL9GO7FFGf0X6VyAWqfR8EAA@mail.gmail.com>
	<CADajX4CHHdSpUfLfjhwrtdzmJfg9di4FpfeVEzBG4P7K7B+e0w@mail.gmail.com>
	<CAPwsocGh_-SYiWceEg=5go8G1bUs+CWUBb9uv_2Oh7AZhBxd8A@mail.gmail.com>
	<CAGa2bXY36wVN50sQ=MTYi+X6664+NYqMhsYFVZ9jeFZ1DXBg9Q@mail.gmail.com>
	<CAEZPtU5=vJG6=cguZfcT6RBriu8GT9vfW=Lqva8-XfEnXzZ23Q@mail.gmail.com>
	<CAGa2bXarZ4A9+HPXniAvBxEtE9KEJTYHHW8aYHCkBsNN5dRNUw@mail.gmail.com>
Date: Thu, 5 Feb 2015 18:49:20 +0700
Message-ID: <CAEZPtU4ThQHcH1hsgYaKwd2yOKAGP7obmcDH15qbDVr6CdgzSQ@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: Leigh <leight@gmail.com>, Adam Harvey <aharvey@php.net>, reeze <reeze@php.net>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Re: [RFC][DISCUSSION] script() and script_once()
From: pierre.php@gmail.com (Pierre Joye)

On Thu, Feb 5, 2015 at 5:47 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
> Hi Pierre and all,
>
> On Thu, Feb 5, 2015 at 7:24 PM, Pierre Joye <pierre.php@gmail.com> wrote:
>>
>> >
>> >
>> > I'm proposing *SCRIPT* only inclusion. This can be done by
>> >
>> >  - allowing "<?php" only at to top of script
>> >  - not allowing "?>" anywhere (We may allow at the end possibly)
>> >
>> > Those who do not understand my point.
>> > Please search by "PHP LFI" or "PHP file inclusion" for real life
>> > security issues.
>>
>> I do understand what you try to achieve, from all point of view.
>> However I strongly disagree with this as a security improvement. I see
>> this more as yet another attempt to replace what should be done at the
>> OS level.
>
>
> This is "PHP inclusion" search result.
>
> http://www.exploit-db.com/search/?action=search&filter_page=1&filter_description=PHP&filter_exploit_text=inclusion&filter_author=&filter_platform=0&filter_type=0&filter_lang_id=0&filter_port=&filter_osvdb=&filter_cve=
>
> While I understand your opinion and the methodology is good practice indeed,
> but I
> cannot ignore the fact that PHP is *MUCH* more vulnerable than other
> languages. Other
> languages do not have many security issue like PHP. The reason is simple.
>
> PHP enables embedding mode always for script inclusion.
>
> Solution is simple also.
>
> Provide non embedding mode script inclusion.
>
> PHP is made for web and web is priority target of attackers.
> PHP is better to be safer than now, the same level as other languages at
> least.
>
> I hope there will be a consensus to make PHP safer as other languages.

PHP is just as safe than the other languages. PHP applicatons maybe
less, maybe more. I tend to see the amount of attacks as a proof of
success of a tool instead of a proof of the tool being unsafe (not
worth attacking 0.01% of the market when you can attack 75%).

> Your proposal requires admins to do the job. It's better to have developer
> option.
>
> Do any of you have other preferred option for developers?

We do have one, it is called open_basedir, which I wanted to remove as
well but we agreed that it has its usefulness. One of them being
exactly to avoid the inclusion (and display) of critical information.
It indeed does not prevent one to include and display some text data
containing passwords or the likes when they are in the open_basedir
list but still.

And again, if one app allows unvalidated include/require (as in your
example), it will most likely do fopen and co as well and get data
displayed one way or another. Using yet another construct will again
give a false sense of security, solving a real problem using a bandaid
tape.

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org