Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82484
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.54 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <54DB0575.8020506@gmail.com>
References: <CAGa2bXZsANJz_RvsBvC9yBhac+ukHYUngA=GjLOgcqTTPbpGhg@mail.gmail.com>
 <54DB0575.8020506@gmail.com>
Date: Thu, 12 Feb 2015 02:28:17 +0900
Message-ID: <CAGa2bXY1XQa3JbQG1EK2aXtHN_7QL64WPJQhBWn5=ZCVYrX5Hw@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113c9854971e36050ed3563c
Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Script only includes
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a113c9854971e36050ed3563c
Content-Type: text/plain; charset=UTF-8

Hi Stas,

On Wed, Feb 11, 2015 at 4:32 PM, Stanislav Malyshev <smalyshev@gmail.com>
wrote:

> > Some of you are tired with this topic, but please take a look the RFC
> >
> > [RFC] Script only includes - this is 3rd version.
> > https://wiki.php.net/rfc/script_only_include
> >
> > Please let me know what you like or dislike.
>
> I think there are several issues with this RFC:
>
> 1. It does not protect against all the problems it purports to protect.
> I.e. if you want to protect against local PHP code accessing evil
> uploaded files, local PHP code can also do echo
> file_get_contents('/etc/paswd') and still have a problem (actually, very
> common LFI issue).  Even if the application only allows to require
> random file, it may be possible to inject data via other means - such as
> data stream, URL, temp files, session files, etc. Upload is not the only
> way inputs can be controlled.
>

File disclosure issue is not scope of this RFC.

2. Legitimate files can include <? as byte sequence - in fact, it is
> almost guaranteed big enough binary file would contain it. Restricting
> upload of such files would break uploading functionality on many sites.
>

Good point.
User needs compression/encryption to avoid issues.

I may make move_uploaded_file() more strict.
How about syntax check? If it detected as script and there is no syntax
errors,
then reject. This will never happens binaries.

However, this is not enough. User may upload text with PHP program sample.
So add and options that force to move embedded PHP script?

Another possibility is use of filename extension(s). It's going back to old
approach,
but register script extension and allow execution only for matched
extension.
This may be the way to go.

3. General approach of this RFC is, given site with glaring security
> hole in their code, give them a measure of protection against some of
> the consequences. This looks like safe_mode approach, and that proved
> ineffective in the past.


I'm not trying to be perfect, but I would like to make PHP as secure as
other
languages from script inclusion attacks. It's too easy currently...

I hope we have consensus for a resolution.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a113c9854971e36050ed3563c--