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" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > 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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
