[Resolved] Security with register_globals 'on'

[bunner_bob]

I'm building a site for a client who uses a shared host. The shared host has register_globals switched on and won't turn it off (yes, it makes me go #$%! too).

The site is being built with register_globals is off. All database retrievals are via $GET, and submissions are via $POST. On the admin side, passing data from form to form uses $REQUEST because in the case of errors I bounce the user back to the original form, in which case the data comes via $POST (instead of the $GET that was used to fill the form originally). But at the end of the line, all submitted data is regexp-error checked and then $POST-ed to the database.

Since I'm requiring $_POST, is my system any less secure than if I had register_globals off? Or can I breathe easily?

• Bob

[swr]

Originally posted by bunner bob
Since I'm requiring $_POST, is my system any less secure than if I had register_globals off?

Yes. Look at the example in the [man]register_globals[/man] manual page example and you'll see why.

If the web server is Apache, you can use .htaccess to turn register_globals off on a per-directory basis:

php_value register_globals 0

[Gary_King]

It doesn't matter if you use $REQUEST, $POST, etc. if you have register_globals turned on anyways (although $_REQUEST, etc. are always the best way to go.)

[bunner_bob]

SWR - huh - didn't know you could do that, but I'm relieved you can. I will do so.

However, if (for database input) I require $_POST variables, I don't see how that leaves me vulnerable. On my admin pages, login is via POSTing of userid & password, and registers the username into a session variable. So there's no way to do anything via GET - at least that I can find.

Am I wrong?

Gary - I realize that. I just figured I'd code to the tighter standard (globals off), since it'll always fall back to working with globals on. Makes the code more portable. If my client ever gets their own server we'll certainly set it up with globals off and the code will already be set up for it.

• Bob

[Gary_King]

Okay I'm not too sure on what you're saying, but here's what I have to say:

If you have register_globals set to ON and you use $POST[something] then I think (not sure) that if someone does index.php?something=1 then $POST[something] will also register.

[bunner_bob]

Huh - now I thought it was, that if you have register globals on, and you have code that says:

if ($var) {
// do something
}

and you sent a value for $var via any method (GET, POST, whatever), PHP will essentially translate $POST['var'] into $var, and $GET['var'] into $var. In other words, it does away with the requirement to write your code like this:

if ($_POST['var']) {
// do something
}

But I can't imagine it would translate backwards - turning $var into $POST['var'] - or in this case, turning $GET['var'] into $POST['var']. If the code requires a variable be in the $POST array (like the second example above), I'm pretty sure it still has to be sent that way.

It's my understanding that register_globals 'on' enables you to write code without specifying "POST" or "GET" - effectively automatically translating both those "arrays" into regular old variables. But I don't believe register_globals actually generates "POST" or "GET" variables from other things.

Of course I could be completely wrong - I'm just saying what would make sense, given the reasoning behind register_globals. I haven't been able to determine the truth or falsehood of this from the manual.

• Bob

[Gary_King]

The way I said is correct, because if you had code that was like $_POST[var] then that could never be TRUE on a server with register_globals ON, how would it? (If we went with what you said) 😉

[bunner_bob]

I'm sorry - could be I haven't been awake long enough but I didn't understand what you wrote.

• Bob

[swr]

Originally posted by bunner bob
However, if (for database input) I require $_POST variables, I don't see how that leaves me vulnerable. On my admin pages, login is via POSTing of userid & password, and registers the username into a session variable. So there's no way to do anything via GET - at least that I can find.

The problem is not that they can do anything via $GET or $POST, the problem is that they can do things via other variables in your program that shouldn't come from the user, but due to register_globals, might.

The first example on the [man]register_globals[/man] manual page shows this. The code is not attempting to get any data from the user, but due to register_globals, gets it even though it doesn't want it. Even if the code uses $_POST in the parts where it wants user input, the user can still set $authorized so long as register_globals is enabled.

[bunner_bob]

Ahh - I get it! So they can affect variables that weren't even meant to be affected by POST or GET. Wow. Skeery!

I'll get on that .htaccess business right away!

• Bob

[devinemke]

you may also be able to maintain your own custom php.ini file with register globals OFF. copy the main php.ini, edit it, then save it your main web directory (htdocs on apache).

[Gary_King]

Personally I think the .htaccess way is the best, because you just place in your root and then all subdirs have register_globals off. Also this method works with a large majority of hosts 🙂