Yeah ... I meant $foo, not $variable ...
Just thinking out loud here (cogs grind, smoke billows): ... suppose you have
register_globals ON (not the way it should be, but suppose) ... then you register some variable, say ... $status, with
session_register('status') ... now $status is global. Since PHP Enemy #1 is set to ON, if an attacker sends a variable 'status=fubar' in a COOKIE, GET, or POST, then how does the script know the difference between the one you set with session_register, and the one that the attacker, via
register_globals, just set for you? (Yes, that's a recap of JAM's post, but humour me ...)
That makes sense ... but if you're checking your variables (as all good PHPers do

) ... how does that change anything? Does register_globals get first dibs at the data, before you get to validate it? A quick look at the manual, leads me to believe that, in fact, this is the case. Ok ... then why do they even give people a choice? I mean, why don't they just remove the
register_global functionality altogether?
(More thinking out loud): Then, because the only way to be sure you're using a clean value consistently with a session, would be to use a variable from a place that only the script has access to, the $_SESSION superglobal was introduced. Of course, you've still got to validate the values, or better ... set them yourself. But because $_SESSION requires a call to
session_start(); before it's available, the attacker can't try to use
register_globals to set a session variable for you with a request like:
http://..../script.php?_SESSION['status']=fubar.
Ok ... I think I've more or less answered my own question ...
Thoughts, anyone?