Kirk, Okay, I now understand why the $_GET and $HTTP_GET_VARS variables are useful. I had made the mistaken assumption that if I leave "register_globals" on, but write code that works with "register_globals" off, my code would somehow be safer simply for having been written this way. But this is not the case -- all of the stand-alone variables are still being made GLOBAL, including any variables passed over the querystring by a cracker.
In order to take advantage of the added security of PHP4.1.0, one needs to go the whole mile and turn register_globals to OFF, so that any querystring-sent variables *stay* in the $HTTP_GET_VARS/$_GET array, rather than get globalized. And the only variables in those arrays that will become global will be the ones which the PHP programmer has explicitly pulled from that array for that purpose. Originally I couldn't see why you would want to use $_GET['variablename'] when writing the code for your page, since this array will include any variables that have been passed on the querystring, possibly with malicious intent. But now I see that the advantage of $_GET is not so much for when you need to pull a variable, but rather to make sure that querystring-passed variables *stay* in the $_GET array. In other words, it's a wall rather than a door. Alright, thanks very much for the explanations. I'm glad I came into learning PHP now so that I (hopefully) get into the habit of writing my variables using predefined vars. Erik On Wednesday, January 16, 2002, at 11:38 AM, Johnson, Kirk wrote: >> 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] > -- 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]
