Edit report at http://bugs.php.net/bug.php?id=53052&edit=1

 ID:                 53052
 Comment by:         php dot net at site dot lanzz dot org
 Reported by:        php dot net at site dot lanzz dot org
 Summary:            PHP_INI_SYSTEM level of allow_url_fopen prevents
                     disabling it
 Status:             Open
 Type:               Feature/Change Request
 Package:            *Configuration Issues
 Operating System:   Irrelevant
 PHP Version:        5.2.14
 Block user comment: N

 New Comment:

The url wrappers are an unfortunate feature that should have never been


implemented the way it is. Still, there is existing code out there that
relies 

on it, so neither reimplementing it better nor disabling it globally via


allow_url_fopen seem like good options.



Why not rely on the php_admin_flag mechanism for restricting
allow_url_fopen? It 

will make it possible for administrators to disable it globally without
letting 

end-users to re-enable it (for example in a shared hosting context), or
let 

administrators leave it unrestricted and manage it at runtime (for
example in a 

dedicated server).



I find it useful to be able to turn on url fopen in a controlled manner,
like 

so:



ini_set('allow_url_fopen', 1);

$content = file_get_contents('http://remote/resource');

ini_set('allow_url_fopen', 0);



This approach will not be possible if only tightening is allowed, as
this code 

will run correctly only once per script execution. Using php_admin_flag
this 

code either will work as expected (turning allow_url_fopen on and off
and 

accessing the resource), or will not work at all, which will be much
easier to 

catch in development.


Previous Comments:
------------------------------------------------------------------------
[2010-10-14 03:22:14] [email protected]

We could presumably change it to PHP_INI_ALL and allow it only to be
tightened, like open_basedir. It's certainly something to be
considered.



Still, allow_url_fopen is not that dangerous. Sure it could make the
effects of some vulnerabilities worse (like if you pass unvalidated data
to to copy()...), but it's not that easy to use it dangerously.

------------------------------------------------------------------------
[2010-10-13 14:10:39] php dot net at site dot lanzz dot org

Description:
------------
The documentation states that "[allow_url_fopen] can only be set in
php.ini due 

to security reasons". This is a completely wrong approach, as it also
prevents 

security-conscious developers to DISABLE the dangerous allow_url_fopen
option, 

if it is enabled server-wide (for example in a shared hosting setup).



Having a single point of control over allow_url_fopen forces the entire


webserver and all websites and applications to share the same setting,
which in 

some cases would force administrators to enable the option due to poorly
written 

third-party code which might be unfeasible to fix or replace, which
would lower 

security for other code that relies on allow_url_fopen being off, and
it's not 

possible to selectively disable it where it really is not needed.



The added security of restricting allow_url_fopen to php.ini only is 

questionable, as malicious users can use other means to access remote
URLs, 

while legitimate users are left without the option of controlled access
to 

remote URLs.



The best scenario would be a globally disabled allow_url_fopen option
(which 

really should be the default), with the possibility for controlled
enabling of 

the feature only where its needed.

Test script:
---------------
# php.ini

allow_url_fopen = On



# test.php

ini_set('allow_url_fopen', 0);

print(ini_get('allow_url_fopen')? 'enabled', 'disabled');

Expected result:
----------------
disabled

Actual result:
--------------
enabled


------------------------------------------------------------------------



-- 
Edit this bug report at http://bugs.php.net/bug.php?id=53052&edit=1

Reply via email to