Register Globals On

How does keeping Register Globals On affect security?

[kunwarbs]

I coded my website with register globals ON setting while I was recently told that keeping Register Globals ON can make server more vulnerable? but how?

Do I really need to redo the coding to survive it in Register Globals OFF environment? I have been running the website since last 4 years and never had any issue with register globals ON.

Please suggest

[eelixduppy]

Having register globals set isn't a security issue by itself, it has all to do with the programmer. If one isn't careful then it can become a problem. For instance, if one doesn't initialize a variable before using it, one could add anything they want to the value of that variable without you even knowing. For instance:

if($auth) {
# do something
}

If $auth wasn't initialize then someone could do something like http://www.example.com/script.php?auth=anything and it would work. Keeping register globals off eliminates this as being a possible issue. It's always best to know where your globals are coming from, too, so if we are expecting POST data we want to use $_POST, GET data we want to use $_GET. If you just use the variable name you won't know where it's coming from.

[PHP_Chimp]

The easy answer is that having register globals ON is more likely to produce security holes in your scripts. As with almost every security question the actual answer is not quite so clear cut.

An example that will hopefully show you the sort of problems that register globals on could cause:

<?php
function allowed_user() {
if($_POST['name'] == 'me' && $_POST['password'] == 'password') {
return true;
}
else {
return false;
}
}
if(allowed_user()) {
$authorized = true;
}
if($authorized) {
include 'lovely/data.php';
echo 'You are authorized...';
}
?>

At first glance it all looks fine, as we are checking that a fictitious form on another page is supplying the correct user name and password. Assuming that the user is allowed to access the page we then set $authorized to true and include the info that they are allowed to see.

The problem comes from $authorized. As with register globals on this could also be set by a cookie, a get or post request. So I log into example.com/members_only/everyones_data.php?authorized=true and I am now in.

If you always initialize all variables then there is less of a problem. If you check every single variable to make sure it is of the correct type before you use it then there is less problem. The down side of register globals is that you need to check every variable, as everything could have been set by the user.
So it is just generally more hassle to write secure code with register globals turned on. As we are all lazy there will be more holes in code that relies on register globals than code that does not.

You say that you have not had any problems in 4 years. Well I hope that continues for you. However it is less likely to continue if you have holes in your security.

<edit>
Beaten by half an hour. Wow I must be a slow typer ;)

[edited by: PHP_Chimp at 6:35 pm (utc) on Sep. 22, 2008]

[grallis]

A few days late, but another way of looking at it that is very similar to the above examples, yet slightly different, is to get in the bad habbit of using the superglobal shortcuts provided by register globals.

Take the above example for instance ... $_POST['name'] can also be referenced by the shortcut syntax $name with register globals on. Someone could easily compromise your database with this kind of oversight.

[dreamcatcher]

Do I really need to redo the coding to survive it in Register Globals OFF environment?

The answer is yes.

PHP6 sees the removal of the register globals directive. So if your system is coded for it to be on its not going to work. Now would be a good time to update your site and also start assuming the register globals directive is off.

dc