I contacted my web host (1and1) and they advised that they would not turn off register globals within their shared hosting and that I should edit php.ini or .htaccess to turn it off myself.

I tried creating a .htaccess with the line php_flag register_globals 0 but just got server 500 error.

I google'd and discovered several postings that said that it wasn't possible to turn off register globals via php.ini.

Can someone in the know please advise

thanks

Should be



But will not work on all servers and you can not get access to you php.ini file if you are on a shared hosting however there is a ini.php file as part of Cubecart...

For one of my webhosts, editing .htaccess with php_flag register_globals off seems to work for the local value not the master value - whatever that means... is this ok? Am I secure now?

For my other webhost, editing the .htaccess gets me error 500, but changing the php.ini file to register_globals = 0 seems to work BUT work only on the directory within which it is contained, so the cube cart admin still shows register globals = on!!! Please advise.

I was a bit confused by your statement that you can not get access to your php.ini file if you are on a shared hosting - my hosting is shared and all I did was upload a php.ini file I created.

Lastly if there is a ini.php file as part of Cubecart why don't Devellion just make a change in that?

because it is the individual users choice on disableing register_globals but is HIGHLY recomended...

I am on a shared server.

where do I put my own php.ini to override the system's php.ini?

im sorry i had forgoten about the ability to upload individual php.ini file...

@gingfelder i personaly found that i had to place the php.ini file in Every folder that i want to change the settings in for this to have an effect but again this may be diffent for diffrent servers...

The local value means within the directory where you uploaded the .htaccess file (and all subdirectories). The global value is for the entire server (all users - not just your account). If your local value is OFF you are fine (you can't change the global value anyway on a shared host).

Your second host seems to not allow php directives in .htaccess files, so it sounds as if you're doing the right thing by using a php.ini file instead. I'm not very familiar with the syntax of php.ini files, so perhaps someone who knows more about them can post some guidance on this. For example, I think that if your server runs PHP Suexec you can add a "suPHP_ConfigPath" directive to your .htaccess file that will allow you to have one php.ini file that works for all your subdirectories (instead of needing one per directory).

You cannot get access to the GLOBAL php.ini file if you are on shared hosting; you may or may not be able to set your own local php.ini files (depending upon your host).

The ini.inc.php file is loaded by all CubeCart scripts and could un-register all globals as well (you actually can't set the register_globals value at this stage with ini_set - they're already registered by the time it reads your script - but you could un-register them after the fact). But this would not affect the environment, since you would need to load this script in order for it to take effect (unlike php.ini files, which are automatically loaded whenever any PHP script runs). So a hacker could look for ways to run scripts without loading that file, and register_globals would still be on...

Am using php.ini (just containing 'register_globals = Off') to switch off register_globals for my shared host with 1&1; this must be placed in every folder I wish to control. Apart from the 'includes' folder can someone please let me know which other critical folders need protecting in this way ..... or do they all need protecting.

Many thanks

Paviland (and anyone else using 1and 1 hosting). I don't think it is acceptable for 1and1 to say that the only solution to turning off register_globals on their hosting is to put a php.ini in every folder (other methods such as .htaccess result in error500s). Do you?

1and1 are leaving their shared hosting customers open to hacks because even if you made sure a php.ini is placed in every one of your directories, you can be sure that someone else on your shared hosting wont and so you'll still be vulnerable.

I would urge everyone to write to 1and1 expressing your dissatisaction and request that 1and1 review their decision to leave register_globals on or that they either make it easier for their customers to switch it off.

It may have more to do with 1 & 1 running php as cgi instead of php as an apache module than them being obstinate or unwilling to change otherwise.

I agree with theorbo in the fact that 1&1 do indeed run php as a CGI and this only allows the use of php.ini files...

But however they do have access to turn Register globals off as a whole even with it running as a CGI as that is still a PHP function...

What you will find is that hosts will VERY slowly start changing to register_globals off over time but at the present time there are TOO many major scripts that require register_globals to be on to work...

osCommerse is one of such scripts even though there is such a mod availavble to allow it to run with register_globals off out of the box it requires them to be set to on, and so hosting companies leave them on...

Come on it's not difficult. 1and1 could change the way they are running php. Like any business they will listen if enough of their customers press them or risk losing them.

As to not doing anything just because some apps require reg_glo=on, I don't accept that this for the simple reason that if it was something that they wanted to change they would simply give due notice to existing clients and do it. For instance when they decide to migrate from php4 to php5, or asp.net 1 to 2 etc they won't loose too much sleep over the minority of clients who will experience upward compatibility problems with selected apps.

At the end of the day us 1and1 customers can simply vote with our feet and go elsewhere but as someone who is by and large happy with their product/service I would prefer that they have the chance to keep my business by changing the way they run php. Hence the urge for others to lobby them to change.

Many thanks all for your thoughts on this. Seems to me that there is no simple solution. I too am happy with 1&1 but this is one aspect that now makes me feel very uncomfortable, especially as those of us with 1&1 are at risk. I agree with Bikeman's approach but also appreciate their current unwillingness to do so. I will contact them again over this matter explaining the problems that some folks running CubeCart have had this Christmas; maybe this wil go part way to encourage them to put into place plans to phase out reg_glo=on that much sooner.

Whoopee, I now have a solution for us 1and1 cubecart users.

1and1 hosting uses multiple levels of php. With php5, register_globals is by default OFF.

To switch from php4 to php 5 you can
i) change all .php files to suffix .php5 which is worse than placing a php.ini in every folder

or ii) add the line, AddType x-mapp-php5 .php, to a .htaccess in your root directory. The good news is it applies to all sub-directories

This seems to avoid server 500 errors, unlike a .htaccess with the line, php_flag register_globals off
Such a shame that 1and1 tech support couldn't have told me of this!

Cubecart seems to work fine on php5. I hope someone here will advise if there is a problem with php5 and CC.

Bah! I just knew there'd be a problem.

I also have a cc2 store which requires PHP4 and register_globals ON.

As CC2 needs reg_glo ON isn't it also vulnerable to the recent hacks?

I contacted my host (OneWorldHosting) to ask them why they set register_globals to on also. We have about a dozen accounts with them and they are generally excellent so they got back to me right away. They didn't really explain why they have it on by default but they did give me instructions for switching it off via htaccess.

I think it's good for all of us to ask our hosts who have register_globals on why so that they will begin to realize that many of their customers would support them if they were to make this switch.

One thing that those of you who are using a php.ini file should definitely look into before assuming that you have resolved the situation is the proper syntax for these files on your server. I'm pretty sure that these files should set EVERY php setting (NOT just the ones you want to change) or you will end up with the hard-coded default settings instead of the right ones for your host. This may result in other security issues (although perhaps not as bad as leaving register_globals on) as well as cause problems with other scripts (for example for uploading images, etc.). You should also be able to set a path to your local php.ini file somehow (either using htaccess or in the php.in file itself), which would mean that you would only need one file per account. Definitely ask your host to help you with this and encourage them to add instructions for doing this to their public FAQ or KB so that others can find out how to do it properly as well.

I have now received a reply from 1and1 confirming that if other users of their shared package have Register_Globals On, this will not affect those users who choose to use php.ini to turn Register_Globals Off. Each account works independently of all other accounts and this does not have any effect on the other packages that are hosted on their server.

Except of course if an account on the same machine as your account is hacked (due to register_globals being on) and the attacker uses it to send massive amounts of spam or something else that would dramatically affect the performance of the whole machine...

This is not a hypothetical, btw, since this is exactly what happend to some folks recently.

Maybe the next question for them (and other hosts with the same policy) is why they don't set it off by default and let users turn it on if there's a good reason. As hosts switch to PHP 5 this seems to be changing. A friend of mine just had to fix an older version of a webmail program (SquirrelMail) that no longer worked after upgrading to PHP 5 because register_globals was set to off.