PHP and register_globals...

[chsh]

This is to continue a potentially useful discussion in a relevant forum:

Originally posted here by slarty
A secure well-written PHP app can easily contain a vulnerability when register_globals is enabled, but be secure otherwise.

This is why my apps always check for register_globals and produce an error message if it's on.

If an app is vulnerable when register_globals is enabled, it isn't secure or well-written IMO. Please cite examples of "secure well-written PHP app"(s) that are vulnerable only when register_globals is switched on.

To my knowledge, the only time register_globals can affect anything is when scripts don't do their own proper variable initialization, in which case they are far from secure or well written.

[slarty]

Ok, say you have a variable, $authorised, which you haven't initialised. Now you have some security check code:

if ($_POST['username'] == 'admin' && $_POST['password'] == 'secret') {
 // Auth ok
 $authorised = true;
}
// Later on in your code...


if ($authorised) {
 // Do something highly important...
}

Now, without register_globals, this seems fine. Although the uninitialised variable will generated a warning, it won't actually cause a security problem.

If register_globals is on, however, the user only needs to supply "&authorised=1" on the query string, and they can bypass the authentication and be allowed to do something very important.

There are other cases too - basically register_globals allows people to set any variable to any value - this is dangerous.

Also if you actually *rely* on this behaviour, it's dangerous too, because something which is supposed to be a post variable could be changed into a querystring variable without your code noticing - which might make stuff hackable, for example by using the old favourite image tag vulnerability:

<img src="/admin/superimportantpage.php?action=nuketheworld&confirmed=1" />

As soon as someone whose browser contains the auth cookie for superimportantpage.php to work hits the page containing the image (which need not even be on the same site, or could be for example, an inline image in a forum such as this one), the world will be nuked.

Slarty

[chsh]

Again though, that's leaving uninitialised variables lying around, which creates problems potentially beyond just your example above.

[ss2chef]

While I agree that turning global variables off is wise, if someone finds some garbage software they can't live without and it requires global variables on, they should turn them on per site via .htaccess files unstead of editing the php.ini for everyone...IMO

[slarty]

register_globals does not turn global variables off, it just stops the contents of the query string, post payload, cookies etc from being copied into them.

I agree that uninitialised variables are bad.

I always turn register_globals on when I need them (i.e. for running legacy third party applications) on a per-directory basis in my Apache config and leave them off by default.

I write my own apps such that they will give an error if accidentally run with register_globals on.

Slarty

[Sick Dwarf]

I don't see why any application should require register_globals to be on. We have $_GET for things like that. Coding applications using register_globals seriously deteriates the code-readability, especially for third-party developers.

Although I always disable register_globals, I also properly initialize my variables. If you code with full error reporting (notices, etc) this is very easy to achieve as PHP will warn you about those uninitialized variables. Doing this enables you to run your code on servers with register_globals on or off, while either not properly initializing your variables, or requiring register_globals to be on, seriously limits your code's compatibility with different servers.

[chsh]

I think we need to make a clear distinction here:
Developers should NOT be writing PHP that will require register_globals to be turned on, and that will be safe if it is.

Sysadmins should try and run all of their PHP apps with register_globals off in case there are PHP apps in use that are vulnerable with it on. If necessary, it should be restricted to specific directories via .htaccess.

It's really too bad register_globals couldn't be set at runtime via ini_set() as that would mean instead of erroring out, apps like Slarty has written could disable it for the duration of the script. I understand why this is likely impractical, but it still doesn't make it less useful.