Re: Re: Using register_globals
| From: | Bobby Patel | 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