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

I saw where the PHP website is reporting that the PHP 4 release tree will go end of life on December 31, 2007. This has been expected, although this is the first I am aware of any official timetable. I suspect that this has a lot to do with the recent GoPHP5 movement which is a project whose aim is to get everybody, every server, and every script switching to PHP5 by February 5th 2008.

This goes along with our unofficial timetable. Over the past year or so we have been eying the end of 2007 as a timetable for getting all of our servers ready to support PHP5. A lot of our servers already support PHP5 although by default all of our servers use PHP4. I am not sure what kind of bearing this announcement will have on our plans. We may make a move to set PHP5 as the default setting around the first of 2008. This has not yet been decided. At any rate, our plans are that by the end of the year, all of our servers should be supporting PHP5.

I would highly recommend that all users check with the developers or vendors of any scripts that they are using and make sure that those scripts are compatible with PHP5. If PHP4 is going end of life, then developers and vendors need to be making sure that their scripts are compatible with PHP5 and making the appropriate changes. This is something that is beyond our control. If PHP4 is no longer going to be supported by the PHP developers then we are going to have to make the switch to PHP5 eventually. It is up to the individual script developers to make sure that there are no issues with PHP5.

Scott

This is the AMS Webhosting Announcement Blog. I have created this blog as a medium to communicate with our client’s and give them a general feel of what is going on behind the scenes regarding the happenings here at AMS Webhosting. Announcements will still be sent for priority updates to the e-mail address we have on file for your account. This blog is just meant to document lesser and smaller happenings that are happening at AMS Webhosting.

We also have a comments form, which you can see listed on the left frame of this page. Comments for specific blog posts has been disabled, but we do have a comment form where users can send comments to us or feedback to us concerning some of the topics that may be discussed on the blog. We view the comments form as an informal way to contact us. If an announcement is made on the blog and this concerns you or you have some feedback to offer, use the comments form to let us know about it. We want to connect with our users and the only way we can know what you like and what you don’t like about our services is if you tell us. The comments form is not meant to be used as a technical support request form as it is not checked as often as our support system is. Please refrain from using the comments form as a support request form.

We also encourage you to subscribe to the blog as an RSS feed. We have written instructions for doing this with the Mozilla Thunderbird client. This way you can stay on-top of any new posts that are made to the blog. A lot of times we make minor changes to a server and do not feel it is necessary to send out an e-mail announcement to the affected clients. This may be a bad decision on our part, but part of our reasoning is that if you flood someone with announcements about minor updates, then they won’t pay attention when a major update is being made. Hopefully this announcement blog will help in regards to this. By using the RSS feed you can manage the announcements almost as if you were on an announcement mailing list.

I am not entirely sure what type of content will be posted to the blog. Right now I envision the blog being used to post general announcements and perhaps security or script updates that might apply to a large group of our clients. I’m not sure how many posts will be made to the blog or how often it will be updated. This is something new for us and so we are going to be learning as we go. Our main hope is that the blog allows us to keep our clients more up-to-date of what is happening to our servers and encourage comments and feedback concerning those happenings.

In the immediate future, I would like to post information concerning new cPanel upgrades that are forth coming, posting information about the upgrade, perhaps some screenshots, and asking for feedback concerning the upgrade, all while we begin our internal test of the new version of cPanel. Some of this information could be important to our user base, but I’m not sure if it falls under the category of warranting an e-mail message to all of our clients. We may also ask questions concerning how our client base feels about certain options and ask for some level of informal feedback. This is how I envision the blog working.

We hope that you find this blog useful. Check back often for updates. Please feel free to leave us any comments or feedback concerning the job we are doing here at AMS Webhosting.

Thank You
Scott Mutter
Director of Administration