> What is the purpose of the $_GET (or $HTTP_GET_VARS) 
> predefined variable?  It seems that in the case of "get" variables, 
> malicious variables could still be set in the querystring and 
> even using 
> $_GET['variablename'] wouldn't be able to stop this from happening.  
> That is, from what I understand, the advantage of using "get" 
> variables 
> in the first place.
> So does using $_GET actually confer any additional security?  
> If so, how?

Scenario 1: When register_globals is on, all POST, GET, COOKIE, SERVER and
ENVIRONMENT variables get copied *automatically* to global variables. So, if
someone passes admin=1 on the query string, then effectively these two
assignments are *made by PHP*:

$HTTP_GET_VARS['admin'] = 1;
$admin = 1;

If $admin is a session variable, then the value of $admin gets saved
*automatically* to the session when the page finishes. So, if the programmer
has not been careful, a cracker can set themself up with "admin" privileges.
Read that all again: the programmer has made no assignments, yet there is a
session variable named $admin set to 1. The two key steps are done
automatically by PHP: create a global version of the GET variable, and write
that global version to the session.

Scenario 2: When register_globals is off, only the first assignment above is
made by PHP when the cracker passes admin=1 on the query string. And that's
where the cracker's input sits harmlessly, unless the programmer does
something silly like writing a loop that assigns all variables in
$HTTP_GET_VARS[] to global variables. The session variables sit in
$HTTP_SESSION_VARS[], and the only way to get a value into there is to
assign it. So, the *programmer* would have to *write* this line of code to
get to the same point as in Scenario 1 (admin set to 1 in the session):

$HTTP_SESSION_VARS['admin'] = $HTTP_GET_VARS['admin'];

And no programmer is that silly, right ;)

Crackers can still pass malicious stuff on the the query string. The
security benefits of register_globals off have to do with what happens to
that malicious stuff inside PHP.

If you are careful, you can defend against Scenario 1 with register_globals
on, but you need to understand all the stuff that PHP is doing with the
data, and that is a fairly complicated picture. Your application can still
work even if you don't understand that picture, and that is how unsecure
applications come about. With register_globals off, the data movement
picture is much simpler, and this is more of a "fail-safe" mode: if you
don't understand how the data moves around in PHP, your application simply
breaks ;)



PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Reply via email to