Re: Re: Using register_globals

From: Date: Wed, 04 Jun 2003 17:44:23 +0000
Subject: Re: Re: Using register_globals
References: 1 2  Groups: php.general 
Request: Send a blank email to php-general+get-150222@lists.php.net to get a copy of this message
I agree that you can write secure scripts with register_globals set to ON. I usually think that alot of rookie PHP programmers (I just started PHP a year ago, myself) read the list, and the way I figure is that it is good to make readers of the list aware of the issues of register globals. Plus, after coding in both states of register globals, I personally like explictly referring to the assoc array $HTTP_xxx_VARS to retrieve the variable. Coders are familiar with "magic numbers" and we should stay away from that, but to me register_globals seems like "magic variables" I look at this variable and I think to myself "Where did this variable come from?" (but that's just me). "Rasmus Lerdorf" <rasmus@lerdorf.com> wrote in message news:Pine.LNX.4.56.0306040936500.5965@thinkpad.lerdorf.com... > On Wed, 4 Jun 2003, Jay Blanchard wrote: > > [snip] > > On Wed, 4 Jun 2003, Jay Blanchard wrote: > > > [snip] > > > Have register globals set to ON is one way of leaving your script open > > > > > to being exploitable. [/snip] > > > > > > Please explain this, how does it make it more exploitable? I think > > > that this is only true if the code is sloppy. > > > > Correct, if you properly initialize your internal variables there is > > nothing insecure about leaving register_globals on. > > [/snip] > > > > Then why has there been such a big deal about register_globals security? > > Is it because so much code is sloppy? > > From a robustness perspective, it is not a bad idea to be more explicit > about where your user data is coming from and being able to easily > distinguish user-oriented data from internal data. What has been blown a > bit out of proportion is the idea that you cannot possibly write secure > code with register_globals on. That is of course completely false, but > you do have to be a little bit more careful which why the default was > changed to error on the side of safety. > > -Rasmus

« previous php.general (#150222) next »