Because not everyone agrees that this is actually "highly recommended".
Most third-party PHP code you may want to run will not work very well with
register_globals off. And turning register_globals off isn't actually as
helpful from a security perspective as many people seem to think.
The basic thing it would help would be in cases like this:
<?
if($user=='rasmus') {
$ok = true;
}
if($ok) {
... secure code ...
}
?>
Here if someone injected ?ok=1 in the URL then the secure code part would
be run regardless of the $user setting. Obviously the fix here is to make
sure that $ok is initialized to false at the top of the script. But since
many people forget to do that, turning off register_globals "fixes" the
problem.
The change I would rather see in php.ini would be to have the default
error_level be set to E_ALL because then the above script would generate a
warning complaining about the fact that $ok was not initialized. Since
PHP can determine when variables are not initialized the case for
turning register_globals off in this example is rather weak.
Many people also seem to think that it is somehow more secure if you know
exactly where data is coming from. So that if you use
$HTTP_POST_VARS['var'] then somehow $var is not spoofable because if you
put ?var=foo in the URL it won't affect anything. But injecting variables
into POST or Cookie data is trivial so I don't see this argument holding
much water either.
And the case for leaving register_globals on is that it is a whole lot
easier for people to figure out how to get started with PHP when the data
is just there and you don't have to do any strange array tricks to get at
your data.
-Rasmus
On Wed, 25 Jul 2001, Andy wrote:
> If register_globals = off is highly recommended,
> why does the default php.ini have
> register_globals=on
>
> Many people do not change this.
>
> On Tue, 24 Jul 2001, Zeev Suraski wrote:
> > Setting register_globals to off (which is highly recommended) would prevent
> > PHP from defining form variables as global variables. For quite a while,
> > since the PHP 3.0 times, PHP provided an alternative way of accessing
> > variables - using special designated arrays - $HTTP_POST_VARS,
> > $HTTP_GET_VARS, and so forth. As of PHP 4.0.3 (IIRC), these variables are
> > always defined, and are protected (to a degree) by PHP. Setting
> > register_globals to off effectively prevents any outer access to your
> > namespace, outside $HTTP_*_VARS[].
> >
> > Zeev
> >
> > At 12:28 24/07/2001, PHP wrote:
> >
> > >Hey all,
> > >
> > > I am new to this list so if this topic has already been beaten to
> > > death let me know.
> > >
> > > I assume that many of you have already read this article
> > >
> > > http://lwn.net/2001/0704/a/study-in-scarlet.php3
> > >
> > >
> > > about many of the basic security risks you need to be aware of
> > > when developing in PHP. I was curious what ideas have already been
> > > covered in the areas of stopping this. I also wanted to offer up my own
> > > suggestion.
> > >
> > > It seems that all the issues arise from the feature that sets PHP
> > > variable to be form variables. The cleanest solution I can think of
> > > (albeit it breaks backward compatibility) would be to split the
> > > names-pace of form variables. If normal or session variable stayed as
> > > $foo and $bar then form variables would be %foo and %bar, or something
> > > similar. Breaking backward compatibility is bad but it would allow
> > > future applications to be free of these dangers and could be something
> > > set in the php.ini or rather a directive in the php script to allow old
> > > an new style scripts on the same server.
> > >
> > > If there is work already being done in this area please point me
> > > to where I can read more about it. PHP is far and away the best web
> > > development language and is really only hindered by security issues like this.
> > >
> > > Orion
> > >
> > >
> > >
> > >--
> > >PHP Development 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]
> >
> > --
> > Zeev Suraski <[EMAIL PROTECTED]>
> > CTO & co-founder, Zend Technologies Ltd. http://www.zend.com/
> >
> >
> > --
> > PHP Development 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 Development 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]
