Hosting providers - Isn't it time?

Written by Brad Baker

Time for what? PLEASE read this: http://au2.php.net/register_globals - read the part in RED.

I've finished yet another posting spree trying to help users with security and performance issues and I am still SHOCKED at how many hosts still have register_globals ON serverwide. Come on hosting providers, isn't it time you you kept up? Isn't it time you closed this security hole that only you as a host can close, and help prevent cross server file compromises?

What about running suphp (or an equivalent)? Why are so many hosts STILL not running a 'more secure' environment for their users?

I am sure all hosts understand (they should!!) what I am talking about, but for the users, who I suggest take this and pressure your hosts, let me try to explain these two things in laymans terms:

1. With register_globals ON serverwide even if you as a user disable them (via a php.ini or .htaccess directive) under certain circumstances your site can still be compromised if another user account on the server is compromised or is used maliciously. It's that simple, and it happens day in and day out, people posting on the Joomla Forum making it apparent that this was the reason their site was compromised.

* Disclaimer: It's true, your host may have a method of working around this huge security hole, but even still, I ask "WHY?" register_globals has been off since php 4.2 by default, and we are well into the php5 world now.

2. suphp (or equlivalent). Running Apache/php via this method means permission problems for you users are a thing of the past (almost). Under this environment when php writes a file (ie installing a template for example) the files are owned by your user account. Files that are 644 are writable by your user (ftp), and yet other users on the same shared server cannot write to them. Again, why would you not want this simple extra layer of security, as well as making it so much easier for your users to mange their Joomla (and any other php script) website?

* Disclaimer: Again, there are circumstances when suphp is not efficient (dedicated server possibly, and extremely high load possibly), however at the least, check with your provider and ask them what methods they use and why.

.. anyway.. that's if for now. PLEASE, do your users, and by extension yourself a favor and consider my comments.

Oh, and I guess it goes without saying, since php4 is now EOL all hosts should be running php5 now.

35 Votes

23 Comments

Feed

Krisstoffer makes this comment

2008-08-17 22:20:27

Somewhat annoying that hosts are not keeping up with this kind of thing, overall they as stated save themselves endless hours by closing simple little things like this.

but! if your host doesn't offer PHP 5 as at the very least an option then id be thinking about switching!
amy.stephen makes this comment

2008-08-18 01:41:27

To add to Brad's plea to turn register_globals OFF, read Chris Shiflett's 2004 article on the importance of input filtering and turning register_globals OFF. Shiflett is a recognized expert in PHP Security http://shiflett.org/articles/input-filtering * Joomla! End Users - when you install Joomla!, those red lights on the first panel are there to warn you. If your host has register_globals on, your Installation Panel will warn you. Don't ignore those warnings. If your hoster won't respond to your demands for increased security, take note and move on. There are MANY other options.
Dan Knauss makes this comment

2008-08-18 20:42:50

Very good tips. I have some quality shared hosting at NEXCESS.net (great VPS package also) and while working through Joomla security and file permissions with their support (the best I have ever seen) they ended up deciding method #2 (above) was the best way to go.
gnuffmaster makes this comment

2008-08-19 10:36:11

I agree with you, and also can't understand this. But the reason why hosting provider don't want to change this in the near future is simple... they don't want the higher support. If they don't have PHP4 many people don't understand why tons of their 10 year old downloaded scripts won't work anymore. This is also the same reason why some Joomla! Extension developer code for PHP4.
I would prefer if Joomla only runs on PHP5 systems (like many other frameworks do it). Sure it will not run on a lot of systems, but many hoster also offer PHP5 so the user have to look for another hoster then.
Dan Knauss makes this comment

2008-08-19 22:39:43

Of note--"Permissions Under phpSuExec"--and much more:
http://www.joomlatutorials.com/faq/view/joomla_security_tips/permissions_under_phpsuexec/60.html
Jon makes this comment

2008-08-20 15:15:33

What it all boils down to is, avoid the hosts that don't care and find a host dedicated to Joomla. After using several hosts that had the issues described in the article, I now have a package that allows me, the user, to modify the server settings for my package such as register globals, and more.
rootlock makes this comment

2008-08-22 18:16:34

JoomByte is hosting a new community site that I am finishing up. They seem to be on par with what you all have been saying.
Eric Caldwell makes this comment

2008-08-26 18:40:59

I take it a few steps further than mentioned above by running suhosin to harden PHP4&5, I disable these PHP functions (show_source, system, shell_exec, passthru, popen, proc_open, allow_url_fopen) server wide (and a few others) and I run mod_security with some really tight rules.

Even with this strict environment all my Joomla components and modules function normally. I have other controls in place that I don't want to mention here.
Sean makes this comment

2008-08-30 04:55:59

Yes. Please! Turn that crap off. I can't believe that one of the hosting providers I have an account with still has register_globals turned on server wide for shared hosting with the entire fleet of servers. And this isn't a small hosting shop, but one of the most popular hosting providers here in the US with hundreds of thousands of clients.
kRem makes this comment

2008-08-31 21:32:35

Does anybody know if 1 and 1 has done the change? Or, is it really that secure?
Brendon Hatcher makes this comment

2008-09-01 15:25:07

@gnuffmaster

I think you are correct.
Hosting companies are NOT in a position to upgrade or troubleshoot systems that no longer work with register_globals off.

Even worse, many php systems are installed by people who cannot understand the technical issues. All they know and care about is that "My host did something and now my site won't work".

The only solution is a business/marketing one - Hosts advertise an "up-to-date, modern, more secure server" with a list of restrictions (e.g. php5 only, register_globals off.

They then change their service levels for the older servers - longer response times, more costly support etc. The argument being that these old sites create lots of security hassles and more work for the host.

Finally, they offer to migrate a copy of a site to the modern server to see if it works. If not, the client understands that they have two choices - the old server or the new.

Regards
Brendon
Nick makes this comment

2008-09-03 14:11:25

Quote:
Oh, and I guess it goes without saying, since php4 is now EOL all hosts should be running php5 now.

XP is EOL so should everyone buy Vista? N0, of cause not! There are loads of scripts and software designed to run on php4 so a good Host should provide a choice of both.
Virtual makes this comment

2008-09-03 14:29:51

I'm a small boutique personalized service hosting provider that specializes in open source applications. I don't have it turned on, but it is required by oscommerce based applications.. creloaded, oscommerce, and freeway. Some of my customers require it to be on for that purpose, but I don't take the shotgun approach to managing my customers like the big guys do.
brad makes this comment

2008-09-03 23:58:27

Nick, XP is not EOL, security patches are still being released.

Virtual, what you should so is disable it serverwide and only enable it on a per user basis. If you are running suphp this would be in a local php.ini file and be far safer than running it serverwide.

I guess your server admin should already know this though.
JohnMc makes this comment

2008-09-04 22:20:25

I gotta agree with everything Brad (and everyone else) is advocating here. If for no other reason that this - my host operates in very much the way Brad suggests (plus other security tweaks), and it has made my whole "journey" with Joomla an absolute pleasure from Day 1. None of the very common problems associated with the "100gig-for-a-buck" hosts ever come my way. I guess you get what you are willing to pay for!
Doug makes this comment

2008-10-01 13:23:43

heads up to non-techie people:

I noticed that my site was down yesterday, returning "500 internal errors" for anything in joomla. Everything looked to be ok, php itself was running, the database looked ok, but no joomla. panic!

I contacted my provider, and after being asked to look twice they came back and said that indeed they had installed suPHP the night before.

since I had my file permissions all over the place, the requirement for 644 was being violated.

so now I get to dance on the table, knowing I have cheated death once more!
Andrew makes this comment

2008-10-05 17:03:30

Hi guys,

I thought i reply to this thread with an note to our service, which we run since joomla began... we offer state of the art joomla-hostings , either for view domains or as reseller... step by at www.joomla-hostings.ch Over 2000 happy joomla designers speaks for it self Our Data Center is directly connected to oversea wires to the States, UK, and Dubai which results in a latency equal to zero worldwide...For sure we support as well with contributions some exceiting opensource projects
Simon makes this comment

2008-11-04 20:16:23

To be really "belt-and-braces" the host should also be using Suhosin (fixes some inherent security vulnerabilities in PHP) and ModSecurity (helps to protect apps like Joomla against common application-level hacks). Combined with suPHP this makes for pretty much the most secure environment you can expect in a shared hosting environment.

I find it amusing to hear a host has enabled suPHP without correcting the file ownerships and permissions to be compatible. Very sloppy!
What Joomla user want makes this comment

2009-01-30 02:40:08

Hi, as we all know the economy really stinks. My wife and I work for a VERY large computer company and with people being laid off everyday we decided to make our own hosting company. Yes, lol we know how to do it, lol.. But I wanted to ask you guys what would you like to see on a Joomla hosting service. I want to offer VPS for $10. a month.. But would really like your input please...

damorosso@hvc.rr.com
Jamoola makes this comment

2009-03-03 21:08:42

LOL, yes try to visit

www.hardwebcafe.net

hope this helps
Sacha van Geffen makes this comment

2009-06-30 11:01:48

As a provider I am committed to offer an easy and secure platform, especially for joomla. I totally agree with you on the register globals and the php4 comments.

I like to emphasize on your disclaimer about suPHP, in a shared environment suPHP will protect other users from the current user, but it breaks the protection of running a webserver as a less privileged user. Other methods exist to get a more secure setup without using suphp.

Joomla itself breaks more advanced and secure setups by not adhering to the system/apache umask. this discussion.

This in effect is pushing us to use the ftp layer which is a less secure, less preferable workaround in any way. especially because of bug #16510
The ftp layer also does not play nice with nfs mounted dirs:
bug #17022 but a patch is available in the tracker.

I tried to include urls to the bugs but that would mark my comment as spam.
Top ten Hosting providers makes this comment

2009-07-15 08:10:24

This list is used by new online business start-ups, help them by voting here to make sure these recommendations reflect your experiences.
webempresa makes this comment

2009-07-29 08:30:31

What do you think about suhosin & joomla?

Regards
Lucas

Latest Posts

Hosting providers - Isn't it time?

23 Comments

Add Comment