View Full Version : Register_globals question
vinyl-junkie
11-16-2005, 04:24 AM
I was forced to switch web hosts a month or so ago because the one I was with was going out of business. The new host had register_globals on, and I found out I couldn't change that via .htaccess. I asked my new host if they would turn it off for me, and here is their response (below). I understand that their first priority is server security, but I want to know if what they're doing is "good enough" security for my site. Your opinions are most appreciated.
After researching this more in depth and looking a little deeper into our PHP environment (php_suexec) and analyzing the needs of all of our customers, it's not very feasible to turn register_globals off for the entire server.
The php_suexec module for Apache (which causes PHP to run as a CGI for each individual user) provides a much safer environment for individual users as it protects individual users from each others scripts. The only "drawback" of this method is that it disables the option to override PHP settings, such as register_globals, on a site-by-site basis using .htaccess. The only way to toggle register_globals on/off in this setup is my placing a simple php.ini file in EACH DIRECTORY where you have PHP files stored. Unfortunately, changes to settings made in php.ini files will not be inherited by sub-directories the way that .htaccess files do. We understand the inconvenience this presents, but we feel the extra security gained from running php_suexec outweigh this mild annoyance.
The php.ini file should consist of this one-liner:
register_globals = Off
We recommend creating a single php.ini file in your public_html folder and then creating a symbolic-link back to that file in each directory that it is necessary for. If you'd for us to take care of this for you, we'll be more than glad to - just let us know.
SteelValor
11-16-2005, 04:46 PM
I would find a new host. Forcing users to go throught all that to turn r_g off is crazy. Every directory?! lmao
hyperbole
11-16-2005, 05:15 PM
I infer from the reference in their response to 'symbolic links' that your new provider is running the server on Linux. If that is the case, following their suggestion to create a php.ini file in your root and make symbolic links from each directory to the file is perfectly reasonable. It can be done in two steps.
I also note that they offered to do it for you so it really isn't that much work for you at all.
.
vinyl-junkie
11-17-2005, 05:44 AM
Update on the situation: My web host now says they are considering other options besides what I mentioned in my first post. I am not a server guru by any stretch of the imagination, but I don't see why their server is setup in such a way that register_globals can't be turned off for just me. :confused:
schleppel
11-17-2005, 07:06 PM
If you are using APache, you could try using "php_value" (http://uk2.php.net/php_value) in a .htaccess file in your root directory. Something like php_value register_globals 0 i think. It might not work though (if you get 500 errors, take it out).
EDIT: After reading a little, it says set boolean values with php_flag, like so php_flag register_globals off
bcarl314
11-17-2005, 08:14 PM
According to the php.net site (http://us2.php.net/manual/en/ini.php#ini.list), register_globals can be set anywhere, meaning that even if they stopped the .htaccess functionality, you should be able to set it on scripts using ini_set
I.e
<?php
ini_set("register_globals","off");
?>
at the top of your script. If you're like me and create all your scripts with a "globals.php" or other file that you include all necessary constants, etc, you just need to add that once.
vinyl-junkie
11-18-2005, 04:16 AM
schleppel -
I can't set any sort of php_flag without getting a 500 error. Already ran into that when I first moved my site to this host.
bcarl314 -
I just ran a little test program with your suggestion, and register_globals was still on.
My host has given me some instructions on for a workaround instead of using .htaccess. I will post those instructions once I've verified that they work. (And in case anyone is wondering, yes, they're willing to do this for me; I asked them how to do it so I could manage it myself.)
felgall
11-18-2005, 08:53 PM
Anywhere with register globals on has the potential for major security issues. I would be looking for a different host.
vinyl-junkie
11-19-2005, 07:23 AM
Anywhere with register globals on has the potential for major security issues. I would be looking for a different host.
Permit me to ask a question out of total ignorance. Does it matter from a security standpoint if register_globals is on for the majority of sites on the server but off for my site?
felgall
11-19-2005, 09:10 PM
Depending on the other settings on the server, having register globals on may be all that someone needs to gain access to the server at a low enough level to impact on everything running on that server.
Sensible hosts only allow register globals to be turned on for a domain when about a dozen other settings are turned off in order to limit the effect of its being turned on to that domain only. If the host has register globals on by default then chances are they have these other settings on by default as well.
vinyl-junkie
11-19-2005, 09:37 PM
Is there a way of evaluating which of those other settings are important enough to expect them to be on or off?
BTW, the reason I'm asking all of these I guess rather dumb questions is that I have had three different hosts for my site, and all three of them had register globals on by default. What I'm really wondering is, how common is it for things to be that way?
SteelValor
11-21-2005, 09:35 PM
; You should do your best to write your scripts so that they do not require
; register_globals to be on; Using form variables as globals can easily lead
; to possible security problems, if the code is not very well thought of.
register_globals = Off
Plain and simple is most people are slackers
http://us2.php.net/register_globals and even more clueless on the exploits people can use against their applications http://secunia.com/search/?search=register_globals
My host is pretty paranoid, almost to paranoid at times, but they're pretty good and support all the major languages. They're also very afforadable too. http://www.uplinkearth.com
vinyl-junkie
11-22-2005, 03:15 AM
; You should do your best to write your scripts so that they do not require register_globals to be on;
You're preaching to the choir. ;) Actually, it isn't my own scripts that I have to worry about. It's the free ones I get on the internet that can be problematic with security in general.
vinyl-junkie
11-23-2005, 06:04 AM
My host has given me some instructions on for a workaround instead of using .htaccess. I will post those instructions once I've verified that they work. (And in case anyone is wondering, yes, they're willing to do this for me; I asked them how to do it so I could manage it myself.)
Sorry it took so long to be able to verify that what they were giving me would work, but here goes:
Make (or add to) a file called php.ini with the following in it:
register_globals off
Place that file in your root directory. Then for each sub-directory for which you also want to turn off register globals, you can do it one of two ways:
(1) Put this same php.ini file in each of those sub-directories
or
(2) Create symbolic links back to the root directory for each of your sub-directories via the command line. For example, let's say your root directory is:
/home/username/public_html
and you want to create a symbolic link back to it from a sub-directory called:
myscripts
Here are the command lines you'll enter:
cd ~/public_html/myscripts
ln -s /home/username/public_html/php.ini
Repeat those two commands for each sub-directory you want to turn off register_globals for.
The advantage is using method 2 is that if for some reason you wanted to turn register_globals back on for your whole site, you'd have just the one php.ini file in the root directory to change. Method 1 would force you to change that file in the root directory, as well as every sub-directory it was in.
Anyway, that's how you do it.
vBulletin® v3.8.2, Copyright ©2000-2012, Jelsoft Enterprises Ltd.