[SOLVED] GoDaddy: register_globals set to ON in your php.ini configuration file

Ryan, I think that it would be good practice for users to check phpinfo() and determine if PHP server is suExec/CGI or Apache API and then make the corrections necessary when presented with the Configuration Warning about register globals.

It is becoming more and more common for hosts to use suExec on shared servers to help deal with XSS. That being said, I can’t figure out why they would use suExec and then turn register_globals ON.

Maybe there ought to be a check in the installer and the files can be created automatically instead of having users have to monkey around so much. You can check the register globals status easily using:



Cheers,

Jay

Jay could you prepare a patch to the config check so we could commit it for one of the next releases?

<scratches head>
I’d like to think so but I am not sure. I will have to look at this. I have never done a patch for anything but a pair of pants. I am still with training wheels on in PHP but I’ll give it a whirl.

I am not sure what all files I would need to update.

I’ll take a look at the installer and see.

Jay

Quote from: rthrash at Jan 10, 2008, 08:43 AM

So can we confirm that on GoDaddy shared servers setting register_globals Off via .htaccess works, or is it only on their semi-dedicated (virtual) servers and above that it works?

The only GoDaddy server that I use (also a shared server) throws a 500 error if it’s done this way. I used a php.ini file instead which worked fine. So I think it’s possible that they have a mix of setups actually, but one of these two methods should work.

Quote from: smashingred at Sep 10, 2007, 03:34 PM

If you look in the root folder where MODx is installed you should have a either an .htaccess file an ht.access file or both. If you changed the default MODx ht.access file to enable Friendly urls there should be a line in there that says:

#php_flag register_globals Off

It should be at or around line 73.

If you remove the "#" and rename the file to .htaccess this should do the trick. UNLESS you are on a server that runs php as a CGI application or in what is calles suExec and in which case this won’t work and you will have to disable register_globals in a php.ini file but try the .htaccess first and get back to the forum.

All the best,

Jay

So, I tried this on my server, and it fixed the error message. Thanks, Jay! My question now is: does this fix the security hole? Or does this just turn off the message? I don’t want to leave myself open to hacks...

Thanks,
Heather

You are good to go. Register_globals is now off. The line you uncommented by removing the hash symbol is a php directive that tells the server to turn off register_globals. Now people accessing your website will not be able to use this to exploit your forms.

All the best,

Jay

I’m kinda stumped on this. I tried the .htaccess file method and I got a 500 error. I then tried adding the php.ini file to the root as well as /assets and /manager and I’m still getting the error..

I know I’m not the only one with this problem.

Wait, sorry! I just read that it takes an hour for the php.ini files to take effect with Godaddy shared servers! I hate to post something without searching for the answer 1st.. Sorry again!

Here’s a topic post I found useful for anyone who is on a shared Godaddy server...

http://modxcms.com/forums/index.php/topic,23997.0.html

-Josh

Hi,

Just a note. There are many hoss that use suPHP to parse php pages as CGI instead of an Apache module.

If this is the case, you should never put php flags in your htaccess file, such as "php_value register_globals 0"

The correct way to do this with servers using suPHP is to add this code in your php.ini file:

register_globals = Off

And then add the following code to your htaccess file: suPHP_ConfigPath /home/username/public_html/ where username is your account /c-panel or plesk uesrname.

This will cause the php.ini file to affect all subfolders, unless a php.ini file is in a subfolder, at which point the php.ini in the subfolder takes precedence, so there is no need to have php.ini files in your sub directories.

Also, under suPHP, all directories should have a permission of 755 and files should be set to 644. If there is any deviation, you will receive a 500 error page.

I hope this was helpful to those on a server using suphp.

Hi,

That’s odd. The change should be instant. I wonder if this is just with godaddy? I’ve never heard of the changes not taking affect right away.