Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:16979
Return-Path: <gareth@fission.org.uk>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 51118 invoked by uid 1010); 29 Jun 2005 01:53:50 -0000
Delivered-To: ezmlm-scan-internals@lists.php.net
Delivered-To: ezmlm-internals@lists.php.net
Received: (qmail 51102 invoked from network); 29 Jun 2005 01:53:50 -0000
Received: from unknown (HELO pb1.pair.com) (127.0.0.1)
  by localhost with SMTP; 29 Jun 2005 01:53:50 -0000
X-Host-Fingerprint: 81.103.221.47 mta07-winn.ispmail.ntl.com Solaris 8 (1)
Received: from ([81.103.221.47:48426] helo=mta07-winn.ispmail.ntl.com)
	by pb1.pair.com (ecelerity 1.2 r(5656M)) with SMTP
	id 94/AF-00424-D2FF1C24 for <internals@lists.php.net>; Tue, 28 Jun 2005 21:53:49 -0400
Received: from aamta10-winn.ispmail.ntl.com ([81.103.221.35])
	by mta07-winn.ispmail.ntl.com with ESMTP
	id <20050629015345.QSGI481.mta07-winn.ispmail.ntl.com@aamta10-winn.ispmail.ntl.com>;
	Wed, 29 Jun 2005 02:53:45 +0100
Received: from [192.168.0.27] (really [81.106.213.130])
	by aamta10-winn.ispmail.ntl.com with ESMTP
	id <20050629015345.VKZD23101.aamta10-winn.ispmail.ntl.com@[192.168.0.27]>;
	Wed, 29 Jun 2005 02:53:45 +0100
Message-ID: <42C1FF2A.4000006@fission.org.uk>
Date: Wed, 29 Jun 2005 02:53:46 +0100
User-Agent: Debian Thunderbird 1.0.2 (X11/20050331)
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>	<42C0CF76.6090203@lerdorf.com>	<42C0F4DA.4000605@php.net>	<17089.18702.450236.614561@desk.crynwr.com>	<1119998580.13690.109.camel@localhost> <17089.63833.772427.529013@desk.crynwr.com>
In-Reply-To: <17089.63833.772427.529013@desk.crynwr.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] allow_url_fopen should be INI_ALL
From: gareth@fission.org.uk (Gareth Ardron)

Russell Nelson wrote:

>Graphical user interface designers understand the idea of an
>'affordance'.  An affordance is something whose operation is obvious
>simply by looking at it.  An uparrow button moves something upwards.
>'include' is an affordance.  It obviously includes a local file.
>  
>
To me, it's obvious that include includes a file - I see no obvious 
determination that that file is either local or remote in the "include" 
statement.

Also, I think it's silly to make include into two functions as you 
suggest given that the ability to include a remote file depends on the 
fopen wrapper being enabled. If we were to follow this line of logic, we 
would have two functions for every current one function which can use 
the fopen wrappers.
I think the documentation quite clearly states that /all/ functions that 
deal with files may deal with remote files if the fopen wrappers are 
enabled and that it's safest to make sure these wrappers are disabled in 
the php.ini/config file.

I'm not speaking as somebody who's never seen the misuse of include() 
either - I had a server remotly exploited several months back after I 
"did a favour for a mate" and let him run some of his dodgy code on the 
machine. However, as I mention above, every single function that can use 
fopen wrappers can be exploited in this way. Now, if include is at the 
top of the currently-exploited-in-this-manner list of these functions, 
maybe the documentation needs to start using <blink>* tags to highlight 
things a bit more - this is an entirely seperate issue to the function 
being broken.
Sadly, the (ab)use of this function and others using fopen are things 
I'm seeing are in-line with how I saw people abusing crap perl scripts 
5-10 years back when that started to become really popular for web 
scripting. It's unfortunate, but there's a lot of muppets out there who 
think they can code - it shouldn't be anybodies job to shield them from 
the headaches they'll be unleashing upon themselves when that removes 
functionality or changes existing functionality for those of us who know 
how to use these functions appropriatly - after all, about the first 
thing you read in any book about any web scripting is you /do not/ 
accept unvalidated user input.

* -- sorry, joke :-)