|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #53052 PHP_INI_SYSTEM level of allow_url_fopen prevents disabling it
Submitted: 2010-10-13 14:10 UTC Modified: 2010-12-01 15:22 UTC
Avg. Score:4.2 ± 0.8
Reproduced:2 of 3 (66.7%)
Same Version:2 (100.0%)
Same OS:2 (100.0%)
From: php dot net at site dot lanzz dot org Assigned:
Status: Open Package: PHP options/info functions
PHP Version: 5.2.14 OS:
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please — but make sure to vote on the bug!
Your email address:
Solve the problem:
12 + 13 = ?
Subscribe to this entry?

 [2010-10-13 14:10 UTC] php dot net at site dot lanzz dot org
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:

Actual result:


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2010-10-14 03:22 UTC]
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-14 08:22 UTC] php dot net at site dot lanzz dot org
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 

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.
 [2010-12-01 15:21 UTC]
-Package: *Configuration Issues +Package: PHP options/info functions
 [2010-12-01 15:22 UTC]
-Operating System: Irrelevant +Operating System:
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue May 28 22:01:35 2024 UTC