>Considering all of this... Would it be better simply to turn
>register_globals = On if the vast majority of the stuff you have on your
>site is simple search engine type stuff and/or GET variables?
That's the reason why register_globals was originally ON.
Actually, going way back, I don't think you could even turn it OFF at all...
It's just *SOOOO* convenient.
>Considering the fact that anyone can forge GET, POST, & cookies, is there
>really any purpose in turning register_globals = Off ??
*YES*
Consider the following (stupid but common) code:
<?php
if (valid_user($PHP_AUTH_USER, $PHP_AUTH_PW)){
$valid = 1;
}
.
.
.
if ($valid){
# SECRET stuff here
}
?>
Now, with register globals on, if I visit:
http://example.com/valid=1
Game Over.
In theory, nobody would ever have a variable they were using that was
uninitialized because they set error_reporting to E_ALL (like they should)
and they completely test every line of code and branch of logic in their
application (like they should)...
Here in the Real World, there are a zillion scripts "out there" by
non-programmers (hey, PHP *is* that easy!) and they have Security Holes like
this in them.
Some of these are (or at least were) in widely-distributed third-party PHP
applications, as I understand it. :-(
Turning register_globals ON will make the above hack to pass in $valid
through GET as a "global" not work. Stops the hack cold, because $valid
isn't allowed to "sneak" in through the URL any more.
You could say "register_globals OFF increases the security of a
badly-written application" :-)
This "register_globals" has *nothing* to do with "global" in functions, just
in case the terminology is making anybody think they're the same thing.
They're not. Not related at all.
If you're an expert programmer and you *NEVER* make the mistake of using an
uninitialized variable, then by all means, turn register_globals on and live
happily ever after writing code without all those pesky $_GET and $_POST, or
$_REQUEST if you want to treat both GET and POST data "the same" for a
particular variable.
If you've ever made a single mistake in your life, leave register_globals
OFF and get used to the new paradigm. :-)
For the record, $_GET and/or globals are *NOT* filtered in any way, shape,
or form by PHP. If they *were* filtered somehow by PHP, there is *NO*
reason that filter could not be applied in either paradigm.
It is entirely UP TO YOU to validate the incoming data as kosher, whatever
kosher means in the context of your application, and at the level of
Security is acceptable risk to your organization, application, boss, and
self-pride.
Alas, PHP really *CANNOT* filter your incoming data, since there's simply no
way for PHP to know what is or isn't kosher. Think about it. Try to write
a generic data-validating system. It gets very messy, very fast, and it
just can't be applied across the board to arbitrary data. You have to know,
at a minimum, some business-logic specific information about the data.
register_globals OFF *ONLY* stops the "hack" of somebody over-riding an
un-initialized variable with whatever value they choose. This is NOWHERE
NEAR sufficient for you to TRUST data coming from the big, bad, Internet.
Disclaimer: I originally argued against register_globals OFF as default,
for various reasons (not least of which is the traffic on this list from
this change), and I still have it ON in many places because I actually *DO*
always initialize variables. It's just an ingrained habit with me, and I
daresay there truly are no uninitialized variables floating around in my
personally-written code. Can't say the same for any third-party code I've
installed (not much) and I *should* migrate to register_globals OFF, but
I've got a *LOT* of code to fix, and there's no maintenance budget for any
of it...
--
Like Music? http://l-i-e.com/artists.htm
Off-Topic: What is the moral equivalent of 'cat' in Windows?
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
