Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83490
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.44 as permitted sender)
Message-ID: <54EA5162.6060408@gmail.com>
Date: Sun, 22 Feb 2015 14:00:02 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Yasuo Ohgaki <yohgaki@ohgaki.net>, 
 "internals@lists.php.net" <internals@lists.php.net>
References: <CAGa2bXZ_Q4Ytz5HgcmBoKNPzUaCh6vLETkyyd-jVsR9df60RPg@mail.gmail.com>
In-Reply-To: <CAGa2bXZ_Q4Ytz5HgcmBoKNPzUaCh6vLETkyyd-jVsR9df60RPg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] [FINAL DISCUSSION] Script only include/require
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> I think this will be the final discussion before vote.
> This RFC is to make PHP stronger against script inclusion attacks just like
> other languages.
> 
> https://wiki.php.net/rfc/script_only_include

I still think this RFC takes a wrong road for the following reasons:

1. Having any code in your app that allows to run include on
user-controlled files (I'm not talking about filtered cases but user
data controlling the path) is insecure and can not be made secure. It
should just never be done. Trying to find workarounds for this is like
safe_mode - good idea in theory, leads to worse security in practice.

2. Default configuration would break tons of PHP scripts with extensions
other than .php (very frequent case). The BC break potential of this is
very big as it modifies core functionality.

3. Prohibiting phar uploads would also be a bc break, but more
importantly, there still probably are ways to work around this by using
phar files with extension different than .phar and then asking to
include files within that phar file. As long as the eventual path would
end in .php, your code would allow it.

Also, the claim that move_upload_file() is obsolete is not based on
anything as far as I can see. Why is it "obsolete"?

-- 
Stas Malyshev
smalyshev@gmail.com