Well, I’ll grant that a discussion about allow_url_fopen could evolve into something of a “Holy War”, with some of the PHP community maintaining that it is needlessly risky to use when “safer” alternatives exist and others maintaining that it should not be considered risky “in and of itself” if it is used properly.
There is a lot of information about this in various places on the web. A few examples are below:
There is also an example of a potential exploit on our own DreamHost wiki page on the subject: http://wiki.dreamhost.com/Allow_url_fopen#Example_exploitation
This begs the obvious question: “If allow_url_fopen is so potentially dangerous, why does DreamHost even allow us to implement a work-around to enable it on a shared server?”
While I can’t answer for DreamHost, my sense of it is that DreamHost wants to facilitate us in every reasonable way, and it is possible to use allow_url_fopen safely if a programmer is sufficiently sophisticated, conscious of the hazards involved, and not just too lazy to “do it right”.
By making it “less than trivial” to enable allow_url_fopen on DreamHost shared servers, they have introduced something of a “barrier to entry” that might result in only those who “know what they are doing” re-enabling the functions.
Frankly, I worry that the wiki’s instructions go too far in removing that barrier and that the result might be that users who do not “know what they are doing” might enable the functions for use with insufficienty robust, or hardened, code resulting in exploited/compromised servers.
I do not want it enabled on a server that I share with others so badly that I almost wish there were not the “workarounds” out there that allow “almost anyone” to enable it. I say “almost wish” because I really do like the fact that we can tweak our environments as necessary - I just worry that someone who shares my server will do something stupid with their configuration and I’ll also suffer as a result.
The problem is that, for most who are asking about such things here, they do not understand the problem and/or do not have the expertise (or interest) to inspect/modify any code they might be running to make sure it is properly hardened- they just want to “run it”. I think that is a pretty safe assessment because a programmer would not be asking the question in the first place - the error message clearly indicates the problem, and the wiki (or general knowledge of PHP) is all that is needed to apply the “fix”.
There is so much code out there, of varying degrees of quality, it is not really reasonable to assume a DreamHost user on a shared server can or will ensure they are only running appropriately hardened code.
I’m suspicious of any code that requires the use of those functions today because:
cURL has been around a long time and is not that hard to use, and is a much better solution
The continued use of allow_url_fopen ,when writing scripts you expect will be run be others in different hosting environments than your own, could be due to either laziness, or ignorance, considering that many other hosts also disable it.
If “laziness” is the reason, it is unlikely that the programmer has gone to the extra trouble of filtering the input sufficiently.
If ignorance of common exploits and the state of common PHP hosting environments is the reason, it is likely the programmer has not kept up with the “standard of coding” required to provide “safe” applications for today’s web.
To me the “bottom line” is that DreamHost has done the “right thing” with this, and that it shouldn’t be changed except by those who are capable of identifying such risks in others’ code, skilled in employing hardening techniques to mitigate those risks, and industrious enough to do both.