> 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 ;) HTH Kirk -- 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]
