PHP Register Globals = ON

[Guest]

I don't know if you guys have noticed, but for a week and half ALTAR1 server suddenly changed from PHP setting Register Globals = OFF (that is recommended from PHP Inventors and Developer Community to insecure ON state. As my firm moved to RP we tested the server and checked RG setting and it was OFF - we was satisfied! But now we have big problems with customers that want they money back because we said RG is OFF by us I hope you see the trouble!

Now, I asked the support why they changed it and the answer was that the OFF state was just temporary (?!??) setting and that they returned to ON again. Not a word explanation why the state ON is good for RP because we all know it is hazardous setting (just do a search about PHP register globals security) ...

Are all users of cPanel hosting sattisfied with RG=ON?
Are all servers in RG=ON state?

[Vasko]

When the cPanel servers were launched the Register_global setting was set to On. It is long story why it was set to Off , the shortest
one is something like " Because one of our administrators, without consulting with anyone decided to turn it off ".

The end line is - when the severs were launched the setting was On, many customers wanted it to be on, and so it was.
Many free scripts require this option be on, as well as many paid software products. When this option was switched off
we had A LOT of problems with a lot of customers due many sites failing to work properly, and many problems with new customers
who did not know how to turn on register globals locally.
Since this hosting service was first introduced with register_globals = on, and since the trouble caused to customers this state will remain.

Whether register_globals should be on or of is controversial question. In case you need it to be off for your sites all you have to do
is to create a php.ini file with this line of code inside it :

register_globals = Off

then place this file inside every directory for which you want this setting to be Off.

This is the only solution we can offer to this problem, and it is entirely our mistake that register globals were turned off


As for security risk - it is not the setting but the PHP code. Register_globals = off has little effect on the server security,
and it does not solve much bigger problem - insecure web-sites. This is my personal opinion from experience, and I won't argue
that is 100% true or correct.

[Guest]

Hi Vasko!

Thank you very much for taking time to answer me so detailed. My problem is that when we came to site - RG was OFF, as we like it.

The fact that many programs and scripts still use RG=ON is a lack of those programmers knowledge or willingness to correct the problems with their code. As you may (not) know - with introduction of PHP 4.2.0 the default setting is RG=OFF, and it is also an official recommendation of The PHP Group. To go further, upcoming new PHP 6 will be completely without RG support, so there will be no more RG=ON - Alelluyah!!!

As you said, RG=ON it's no risk to server, but to individual account owner, but hacked account is something I do not want to see on my users site! Our customers use various open-source CMS'es with 3PD addons that aren't fully tested so the RG=OFF is very recommeneded to diminish possobilities of SQL injection attacks etc..

As about of suggested solution - the problem with individual php.ini file is that it works only on files in the same directory, no subdirs!! And CMS-es have hundreds of dirs, what is your suggestion??


There is another alternative - adding this code into .htaccess file :

php_flag register_globals 0

but RP server doesn't work with it. Why? And it could be so easy and I wouldn't complain..

[Guest]

There is another alternative - adding this code into .htaccess file :

php_flag register_globals 0

but RP server doesn't work with it. Why? And it could be so easy and I wouldn't complain..

Try putting it in a php.ini file and see what you get?

How do you test if RG is ON or OFF ?

[Vasko]

This is a very nice example of the things we are changing. There won't be any more surprises as far as I can do something about it.
I am aware of the situation with register_globals from quite long, and it was me who insisted to be on because of the many scripts that were using it, and because of the various complains. I do understand that other people will not be okay with this, but a choice had to be made and I made it. I know it can't satisfy all but do you know a way to satisfy everyone in such situation ?

The .htaccess does not work because PHP is being executed through cPanel's CGI Wrapper, it allows a php to be executed
through the user that owns the php file, rather through the apache user - it improves security and it allows monitoring the load caused by a given cPanel account.
This is why the only way to do this is by php.ini file.

When new PHP versions are introduced in cPanel we will act accordingly.

As for comlpaining - this is not a complain :P This is a very good remark
about something that was set in one way and now is set to another and
people who have done that

About the recommendations - they are quite important but in this case we had to choose between recommendation
and a setting that is widely utilized by various scripts.

Basically this is the correct explanation behind the "temporary" solution.
By the way who said that ? PM me and let me know pls. This is something that I missed and I would very much like to know.

[Guest]

Whether register_globals should be on or of is controversial question. In case you need it to be off for your sites all you have to do
is to create a php.ini file with this line of code inside it :

register_globals = Off

then place this file inside every directory for which you want this setting to be Off.

Are you sure it is every directory? I think the main directory should suffice, subfolders are automatically taken care of

[Vasko]

Php.ini did not work recursively last time I tested it - it worked only
for the folder where it was placed without affecting the folders under it. I don't think that this has changed. As far as I know only .htaccess works recursively
(for all folders under it).

[Guest]

As you said - some users complained and needed it ON, but this OFF state lasted 2 months - if the OFF state was problem for them how did their sites work for 2 months? Now, with change to ON we others were basicaly "trough the night" pushed to ON state, without any notification. Vasko, you have to admit this isn't quite OK nor professional, is it?

Php.ini did not work recursively last time I tested it - it worked only
for the folder where it was placed without affecting the folders under it. I don't think that this has changed. As far as I know only .htaccess works recursively
(for all folders under it).

OK, choices have to be made, the coice was using less secure one. I am sure that users that have currently scripts that need ON state could very easy find upgrades or fixed solutions for the OFF state. Are they avare if ON insecurity (sure, it depends mainly on quality of PHP coder..)?

So, what is left to us that wanna have secure, OFF state?

• php.ini is not working recursively and I have hundreds of folders to take care of
• .htaccess method doesn't work at all
• ??

Can you consider possibility to have one server with OFF and other with ON and then regroup us users accordingly? I am sure this couldn't be the problem, and there are surely other users that would like to have it OFF (I hope they will wake up and say it). ... This is the way you asked about, when everyone would be satisfied.

Vasko, look at votes, and many users didn't saw one day old topic, or will even never see it or know that settings quietly changed from OFF to ON, maybe they don't know what this means... IMHO you could at least send some notification about such important changes. I'm sure you see my point and are willing to find compromise for all of us.

[Guest]

Basically this is the correct explanation behind the "temporary" solution.
By the way who said that ? PM me and let me know pls. This is something that I missed and I would very much like to know.

take a peek on my tickets

[Vasko]

Well if no one decided to make changes for fun that problem would not have occurred at all
Actually those changes were not for the fun but exactly because of the reasons you posted, but I already explained
why it should not have been done in that way. This is a mistake which I will make sure not to happen ever again.

About your suggestion for a server with register_globals set to Off - I was thinking to write you about this yesterday but
I did not because I can't take the obligation for this in the spirit that I don't know when a new server will be
available and if the CEOs will agree with this.In general the policy is to have all servers with the same settings.
I can promise to ask but I can't promise I will contact you immediately after - a lot of things are in my head right now and I'm starting
to loose track of them all (that's where a PDA would perfectly fit in ) My advise is to ask - send us an e-mail in 10 days from now
asking about this or just copy/paste the URL of this forum thread.

[Guest]

OK, I'll do that and I hope you will manage someting. Maybe the new server isn't needed, just short mail to all of the cPanel users what the setting they need/want and you'll already have good list how to regroup us on the existing servers..

And, for future, I hope you will send us mail with info that something important is gonna change, and ask us if the change is acceptable to us. At last we are the customers here so we have to know and get you feedback if this is OK to us or not ...

[Guest]

The scary thing is Bernard a lot of people don't know enough about the scripts they run in order to have register_gobals on or off.

I agree that they should be turned off because of a great security risk it causes not only to the accounts that are hosted but to the server itself!

Think about it, let’s say I have a string variable $foo that stores its value in to a database using the following command:
INSERT INTO `database` VALUES($num, $foo);
- someone could write

http://www.site.com/run.php?foo=); DELETE FROM `database` WHERE (1

and delete everything in your wonderful database! How awful would that be?

This is why PHP recommends, and 99 out of 100 shared hosting companies do, turn Register_Globals off.

Vasko - as a full time technician I understand and appreciate your decision to act on this issue and do what you think best is for the servers. And I understand the reluctance to change anything again at this point. But please bear in mind that this is a security risk and disabled for a very important reason.

Most PHP programs that require Reg_Globals to be turned on are not well-managed programs, old legacy programs, or were written for a PHP that was less than version 4.1 and never upgraded to take in to account the Superglobals $_POST, $_GET, $_SESSION, $_COOKIE, etc.

Just my 2 cents on the issue...

[Guest]

The scary thing is Bernard a lot of people don't know enough about the scripts they run in order to have register_gobals on or off.
I agree that they should be turned off because of a great security risk it causes not only to the accounts that are hosted but to the server itself!
Vasko - as a full time technician I understand and appreciate your decision to act on this issue and do what you think best is for the servers. And I understand the reluctance to change anything again at this point. But please bear in mind that this is a security risk and disabled for a very important reason.

Most PHP programs that require Reg_Globals to be turned on are not well-managed programs, old legacy programs, or were written for a PHP that was less than version 4.1 and never upgraded to take in to account the Superglobals $_POST, $_GET, $_SESSION, $_COOKIE, etc.

Just my 2 cents on the issue...

Devilboy,

thanks for support for this my initiative. I'm pointing at this same things from the first post - scripts that require it ON are OLD and/or not well written - the variables should be called with superglobals.

Also, there was no answer at my question - how come that those people with this "bad scripts" had no problems running for 3 months...

[Guest]

The only thing I can think of is that no one signed up yet during those three months that needed RegisterGlobals on. When they signed up, they asked if they could be turned on and RP concluded that it was worth the effort to meet their need.

Personally, because of the security risks involved, I think they should remain off and those that need them on can use the php.ini file to manually turn them on.

[Guest]

Personally, because of the security risks involved, I think they should remain off and those that need them on can use the php.ini file to manually turn them on.

That's my opinion too. Why shouldn't those who want it ON simply put php.ini files where and when they need it, and not us who know what we need and what we are doing...