[General] PHP register_globals

We have received a few complaints throughout the past few days concerning the disabling of register_globals on all of our servers. What needs to be understood is that there are very few, if any, webhosting companies that are still allowing register_globals to be on by default.

For a quick overview of what register_globals is, imagine that you have a form constructed like:

<form name=”formname” action=”file.php” method=”post”>
Color: <input type=”text” name=”color”>
<input type=”submit”>
</form>

Now with register_globals enabled, you can access the data that submitted by this form in the file.php file by using variable names like:

echo $color;

Note how the name of the color text box is named color. Notice how in the PHP file you just reference that as $color. This is with register_globals enabled.

With register_globals off, you need to reference the variable as:

echo $_POST[‘color’];

Notice how the method part of the form says post. This means that you are POSTing data. So in order to access the information in the color text box, you have to use the $_POST array identifier.

Now that you understand what register_globals is, its easy to see how having register_globals on can open you up for various exploits. The manual page for register_globals offers some good details regarding this. I look through all kinds of security vulnerabilities that are disclosed every day. Practically all of those vulnerabilities come about because variables in a PHP script are not sanitized and because PHP does not require variable initialization. This opens up a script a cross-site scripting vulnerability, where a malicious user will inject PHP code from a remote source into your script and use your script for malicious intent. All of this becomes much less of an issue if register_globals are turned off.

It is also worth mentioning that register_globals is an option that the PHP developers are deprecating (to deprecate something means that it is being removed or taken away). You can see this from the minutes in a recent PHP language developers meeting.

What does this mean to you as an end-user? This means that if you have a script that requires register_globals in order to work, then the script needs to be fixed. This may mean that you as an end-user needs to fix the script if you wrote the script, you may need to contact the developers of the script if you purchased or downloaded a script, or you may just need to upgrade the script to a later version. Yes, register_globals can be enabled on a server, but this is not a fix, this is just applying a patch to a water pipe that is ready to burst.

You may hear that if a script properly sanitizes its variables then its just as safe with register_globals being on as it is being off. This is actually true, but there are very, very few PHP scripts that properly sanitize their variables and do variable initialization for all variables. The entire webhosting community is moving towards having register_globals disabled and even the PHP developers are deprecating register_globals. This means that it is really more of a waste to sanitize and initialize variables in a PHP script when that time and effort can be applied to restructuring the script to work with register_globals off.

This is why we have disabled register_globals on our servers and to be honest, this is something that we should have done a couple of years ago. It basically comes down to how secure do you want your webhosting company to be? If you want us to be lax in our security efforts, then this means that spammers and phishing attacks will be rampant on the servers, causing blacklisted servers and server lockdowns from upstream providers. I don’t think this is what anybody wants. This is why you have to trust our security efforts and realize that we are doing this for the betterment of all of our clients.

The one exception that I know of concerning register_globals is osCommerce. I am not a big fan of osCommerce because I think they have abandoned their project. Like I said, issues with register_globals have been know for several years now. All of the other popular scripts have rewritten their code so that register_globals is not required. Some scripts won’t even install if they detect register_globals as being on, because this justifies a lax security model by the server administrator and if register_globals is left on, there may be other security details that a server administrator has overlooked. osCommerce continues to lag behind the field and continues to require register_globals to be enabled. We will enable register_globals on accounts that are using osCommerce, but I would ask that you either consider moving to a different shopping cart application. This lack of attention by the osCommerce developers really leaves me worrying, what if a major issue with osCommerce comes about? What if a vulnerability in osCommerce allows a malicious user to steal credit card information or other confidential information from a potential buyer? Will osCommerce take 5 years to patch that security hole? Because osCommerce seems to not care about its client base, the client base should really rethink their participation in the osCommerce package.

Hopefully this will provide some insight into the register_globals issue.

Scott Mutter
Director of Administration