As a Joomla! developer I often find myself providing support to users of my software. Sometimes, despite my best intentions, I hit a stone wall: a server setting is amiss. In this case I explain to my users what the problem is and ask them to contact their host to rectify it. One of the most irritating situations I’ve found myself dealing with is when a host replies “we can’t do this for security reasons”. I would generally accept that, if only the host actually knew what they’re talking about. And, yes, I am specifically talking about the fopen URL wrappers and the fact that they are stupidly disabled on many hosts.

As a Joomla! developer I often find myself providing support to users of my software. Sometimes, despite my best intentions, I hit a stone wall: a server setting is amiss. In this case I explain to my users what the problem is and ask them to contact their host to rectify it. One of the most irritating situations I’ve found myself dealing with is when a host replies “we can’t do this for security reasons”. I would generally accept that, if only the host actually knew what they’re talking about. And, yes, I am specifically talking about the fopen URL wrappers and the fact that they are stupidly disabled on many hosts.

Before we go into any further detail, perhaps we should discuss what are the fopen URL wrappers and why they are needed. The easiest way to retrieve information from another server in a PHP application like Joomla! and its components is using fopen or file_get_contents with a URL instead of a filename. This is the method used by Joomla!’s language installer, the extensions installer’s “install from URL” feature, the extensions updater and, of course, Joomla! update itself. As you understand, if this PHP feature is disabled you miss a great deal out on convenience. In extreme cases it may actually undermine your site’s security because extensions updates suddenly become a huge hassle.

If this PHP feature is so useful -and used in pretty much any and every major PHP-based application- why would anyone be so foolish as to disable it? Well, in order to understand that we have to consider a common hacking method of many years ago. Back then there were certain PHP applications which allowed you to pass the name of a file directly in the URL. They would then load that file and execute it. Due to insufficient checks a malicious user could also use a URL instead of a file name. Pointing to a file of his choosing with malicious content would allow him to hijack websites. This kind of attack was made possible by URL fopen wrappers, as they made PHP oblivious to the fine difference between a secure, local file and a very likely harmful, remotely hosted file. That’s why hosts started disabling that feature on grounds of perfectly valid security concerns, setting the allow_url_fopen parameter to 0 in their php.ini files.

You must be thinking that PHP developers must be suicidal for continuing to rely on such a dangerous, outrageous feature. You probably think that hosts are right for disabling that feature and I’m crazy for writing this article. Well, if I was writing this article six years ago I would agree with you.

So, what has changed six years ago? PHP 5.2.0 was released on November 2nd, 2006. One of the major security features introduced in this release was the introduction of a new configuration parameter in php.ini called allow_url_include. Setting this parameter to 0 allows PHP to forbid the inclusion and execution of code hosted on remote servers, i.e. neutralize the attack vector which hackers have been previously exploiting. In fact, it’s absolutely secure to set that parameter to 0 and leave allow_url_fopen enabled, allowing PHP code to easily download non-code information -such as update information- from remote sites.

By now you’ve probably understood the point of this article and its title. Hosts, quite stupidly, a flicking the wrong switch. Instead of disabling allow_url_include, neutralizing the attack vector, they disable allow_url_fopen killing useful features in the PHP applications used by their clients. Of course, some hosts argue that they don’t want to allow to download and run arbitrary from the web on their servers. Sadly, these hosts are being complete morons because they are saying that they don’t want to be in the business they are in! the very definition of being a web host is that you will be allowing your users to download code from wherever, install it on your server -the one you are essentially leasing to them- and run it.

So, here is my plea to web hosts. Please, talk to your systems engineer. If you don’t have one or the one you have cannot understand this basic stuff, please do hire someone who can actually do his job properly. And my plea to users, the heart and soul of the Joomla! community. If you bump into a host who’s giving you unsubstantiated excuses for disabling features in PHP, please vote with your wallet. You have the power to change the hosting landscape in a positive way.

Published by Nicholas Dionysopoulos

PHP developer, author of Akeeba Backup and Admin Tools. Father, husband, cat herder and geek. Proudly uses all major Operating Systems on desktop and mobile.

One reply on “Flicking the wrong switch”

  1. I applaud you’re post, thank you for outlining the problem, the reason some don’t fix it, and the solutions. Kudos sir

Comments are closed.