At 14:16 10/05/2002, Ford, Mike [LSS] wrote:
No, but this:
if (isset($password)): // register_globals on
$super_user = $password==$super_password;
endif;
if ($super_user):
// sensitive admin stuff
endif;
is more secure than:
if (isset($_GET['password'])): // register_globals off
$super_user = $_GET['password']==$super_password;
endif;
if ($super_user):
// sensitive admin stuff
endif;
You meant it the other way around, didn't you? :)
Also, by using the $_POST, $_GET arrays, you know exactly where the input is coming from (even if register_globals is also on!). If you have register_globals set to on, and you just look to see if (say) $password has a value, which you're expecting to come from a form field, you can't actually tell whether it's been overridden by some smarty-pants typing in the URL with ?password=super_password on the end. If you check specifically for $_POST['password'], you at least have the assurance that it's come from a form field as you were expecting.
There's a bit of a misperception about the security that register_globals=off buys you. Basically, anything coming from the user cannot be trusted, and that includes post variables in $_POST[] (I could write my own form and send whatever variables I want to your form handler). So, generally, anything in $_GET, $_POST and $_COOKIE (or $_REQUEST, in general) cannot be trusted, and should be treated as 'possibly hostile'. The new $_ENV variable, however, can be trusted, as it cannot be poisoned by the remote user, and also, most of the information in $_SERVER can be trusted, because it's coming from the web server.
What does register_globals buy you? Two simple things:
(a) A clean global scope, which cannot be poisoned by the remote user, as your example illustrated (only backwards).
(b) Reliable $_ENV and $_SERVER arrays, and the knowledge that they cannot be poisoned by get/post/cookie data coming from the user.
Zeev