My host, who shall remain unnamed, has informed me in conversation that they can not and will not turn off the Register_Globals feature due to the CGI configuration of their Unix server for php.
Is there a way to secure this on my site to avoid the XSS scripting attacks and other problems?
Thanks!
That sounds odd to me. Are you sure that they understood what you were asking and answered you correctly? It’s certainly not impossible that you have a crochety host who’s invested in keeping register_globals on, but the specifics of the response make me wonder.
As I understand it, PHP can be executed as either a service or a binary executable. Newer and more secure permission systems tend to run it only as an executable, I believe (e.g., suexec). So the way they explain it (referring to CGI) makes me wonder if your tech support person didn’t understand what you were asking and thought you wanted register_globals set to on, and they were saying that no it must stay off (which would be a sensible rule, from a security standpoint, and would fit with the rest of their explanation).
But maybe I’m just reaching here and making up dialogue to the movie in my head...
Have you verified that register_globals is set to ON on your account? That’s all that really matter I guess. If it is, you need to deal with it (and if not, you’re all set).
If it is set to ON, I would try the various methods you can find here on the forums (local .htaccess and php.ini files) and see if any of those works for you. I have found that many hosts refuse to change their global settings and some won’t tell you how to reconfigure your local account (since then they’d need to support you on an unknown environment = they’re lazy). But if one of those methods works for you, you don’t need to tell your host that you did it (shhh).
If it doesn’t, then there are some other .htaccess and PHP tricks that approximate the same behavior. Personally I don’t trust them because they don’t seem to completely patch the gaping hole that is register_globals, but they can work in some situations, and they may be better than nothing. In particluar there is some simple PHP code that you can find on php.net that just cycles through all the registered global variables and unsets them all (so you would need to include this at the very beginning of your index.php, I imagine - although you can see that the problem with this method is that a XSS attack could and usually does start with some other file and thus you’d be unprotected).
Another thing that may help to lock down an installation in this circumstance would be to password-protect your manager directory via .htaccess. This would stop all XSS attacks that include files from there, which is probably most of them (since that’s where you can find a lot of major third-party packages like RTEs, etc.). You will have to log in twice to get access to the manager, and you might not be able to use some scripts from the public end properly without re-working them (e.g., a blog interface using your RTE would trigger the password protection).
MODx is about as secure as a complex application can be on an unsecure server (e.g., with register_globals on). So you don’t necessarily have to throw up your hands and give up just because of this. But you might consider another host if this one won’t cooperate with a security issue so basic...
Thanks!
I did verify through the phpinof() that Register_globals is ON. I did specifically ask the guy a few times throughout the conversation if it could be turned off, or if there was anyway to turn it off from my end. He said no.
It is running the php api as CGI.
Specs from them are:
Linux vux41 2.6.15.6-INQUENT #1 Thu Dec 7 20:25:31 EST 2006 i686
Server API CGI
Virtual Directory Support disabled
Configuration File (php.ini) Path /usr/services
I am actually in the process of writing my .htaccess file to enable FURLS, so is there any thing that I can include in it to lock down the globals?
Thanks!
The best way to do it is by adding this to your .htaccess:
php_flag register_globals Off
But if that gives you a 500 Server Error then that means that you can’t include PHP directives in your .htaccess file on your host.
So the next choice is to try setting a local php.ini file with this setting in it:
However I’ve found that local php.in files are trickier than the .htaccess method. Some hosts ignore or don’t allow them at all. And sometimes you need to set ALL of your PHP settings in the local php.ini file (not just those that you want to change), since otherwise you will reset the rest to the PHP defaults (which is probably not what you want, and may mean that you need to put a php.ini file in every directory as well).
More info on using php.in files here:
http://www.php.net/manual/en/ini.php
An explanation and lots of useful discussion on register_globals here:
http://www.php.net/manual/en/security.globals.php
And as a last resort you may try something along the lines of what Susan suggests here:
http://modxcms.com/forums/index.php/topic,9319.msg65015.html#msg65015
But keep in mind that anything short of properly setting register_globals to OFF is not as trustworthy as getting this right from the beginning.
I tried via the .htaccess file, no luck....came back with a 500 error.
Can’t edit or access directly the php.ini file as it’s not in my root due to server configuration.
Not sure what else to do from here.....
I’ll look at Susan’s fix and see if it will work.
Thanks!
Usually when you have a shared hosting setup you can’t touch the global php.ini file, so that’s normal. But a lot of hosts allow you to add your own local php.ini file (which will override the global settings). A lot of people set register_globals off this way, so I would try that before anything else.
I tried setting a php.ini file in the root of the document with the globals off, but I am getting a 500 error. Not sure if I need to copy and rewrite the entire php.ini file in this case or not. Any ideas on that?
I think that if you get a 500 error that either something is wrong with your file (which may be that you need to include all the settings) or you just can’t use local php.ini files on your host. Try downloading the default php.in from php.net and changing the values to what’s correct for your server (which you can see in the server info screen in the manager). If that doesn’t work, then your host wasn’t lying to you about being unable/unwilling to turn register_globals off...
