register_globals = security risk?

[Garfield]

Hi,

If you enable register_globals in PHP you don't have to use $GLOBALS['varname'] to access a variable. Since it is switched off be default and considered to be good style to leave it off, I wonder if it is givig me some security risk to have it enabled.

So is it safe to switch it on?

Thanks in advance!

[carneddau]

It's safe providing you have well written scripts that check user submitted values before using them.

[jatar_k]

There is a chapter in the documentation that talks about Security in PHP [ca.php.net] and they cover Using Register Globals [ca.php.net]

my personal opinion is don't do it

[encyclo]

My shared hosting company has Register Globals set to "on" (using version 4.3.5). From the PHP documentation, I know I can change this to "off" by adding

php_flag register_globals 0

to the root level .htaccess file. As none of my scripts need Register Globals to be on, is it a good idea to disactivate it?

[ergophobe]

Yes. Apart from security problems mentioned, I think it just makes more solid code. For example, let's say your script has

$var = $somevalue;

You don't think about it and you build a form with

<input type="hidden" name="var" value="someothervalue">

Now what value does $var have?

In most cases, I think globals make things confusing and can encourage logic errors in the code. If I want one, let me declare it, but I don't want any automagic globals.

[DrDoc]

The matter is actually quite worse than that. Imagine the following on a page using PHP's session handling:

$_SESSION['foo'] = "bar";
$foo = $_SESSION['foo'];
$foo = "blah";
echo $_SESSION['foo'];

What does it print out?

[jatar_k]

also consider this

given that the variable order is Environment, GET, POST, Cookie, Server (EGPCS)

someone passing variables in the url

script.php?foo=badvalue

can corrupt other superglobal arrays.

The key to hacking a script is to understand the data, if someone can get bad values into your code then they can possibly start understanding the structure of the environment and even the structure of your db, among other things. Then from thre exploit different values/variables and learn more etc, etc ....

It is a slippery slope and really depends on what someone is trying to do. They may just be messing around, they may want to wipe your db, who knows but allowing anything passed to your script into the scripts scope always struck me as a very bad idea. You need to then adjust for an infinite number of possible variables floating around in your script. If globals is off you can focus on controlling the values of the known vars.

[ergophobe]

back in the days of dinosaurs (okay, FORTRAN and Pascal, i.e. circa 1980) when I was taking my first programming classes, I was taught three rules:

1. Do not use GOTO statements
2. Avoid globals if at all possible.
3. If it doesn't fit on a page of printout, it needs to be broken down into functions

I've broken #3 more times than I can count (liek yesterday for example) and don't think it makes sense really, but the other two I've happily stuck with since I think it's hard enough to follow my spaghetti logic without adding in features that make it even harder ;-)

[encyclo]

OK, I followed everyone's advice and turned Register Globals off. The only side-effect was that my demo of osCommerce failed completely with a Fatal Error. It appears that it can't do a thing without Register Globals being on. I'll now reconsider using it for an ecom site I'm going to develop...