|Hosting providers - Isn't it time?|
|Written by Brad Baker|
|Sunday, 17 August 2008 04:57|
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.