Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:16956
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <42C0F4DA.4000605@php.net>
Date: Tue, 28 Jun 2005 08:57:30 +0200
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
MIME-Version: 1.0
To: Rasmus Lerdorf <rasmus@lerdorf.com>
CC: Russell Nelson <nelson@crynwr.com>, internals@lists.php.net
References: <42BDDC82.6020208@ohgaki.net> <17088.52397.92440.326561@desk.crynwr.com> <42C0CF76.6090203@lerdorf.com>
In-Reply-To: <42C0CF76.6090203@lerdorf.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: sesser@php.net (Stefan Esser)


>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.
>  
>
I agree with Rasmus. Remote URL Includes are dieing out. They are not as 
common as they were some time ago. Most released advisories are SQL 
Injections nowadays and well maybe Russells next mail says: 
mysql_query() considered harmful.

Ohh btw... Many remote url include holes nowadays are only exploitable 
with register_globals=On. And here again you may blame PHP because it 
allows an attacker to change the content of unitialized variables. 
(Which can also be achieved in C programs, by populating the stack with 
values you want through other code paths).

But I blame the programmers for not initializing their variables 
correctly. Not filtering user input...

Ohhh btw Russell, if you really consider include harmful, then simply 
install the Hardening-Patch for PHP and live with it. Several big 
hosters already use it, and it disallows any remote includes, beside 
other include tricks.

Stefan