Posted by "Richard Lynch" on 09/14/05 18:40

On Wed, September 14, 2005 9:46 am, Jay Blanchard wrote:
> At the risk of starting another globals holy war, the reply that you
> received was a generalization that reflects the potential (<---- NOTE
> THAT)
> security risks from having register globals 'on'. The poster was
> essentially
> correct, misuse of globals opens up a whole can of potential security
> issues. I will refer you to several good PHP security resources at
> http://www.shiflett.org

I was frankly rather pissed when register_globals went "off"

*I* do not have any uninitialized variables anywhere in any scripts on
any site I ever built. Period.

Upon reflection, though...

In the unlikely event that I break down and give in to client demands
to install some lame-ass bulletin board with all its *other* security
holes, it's pretty much guaranteed their crappy PHP code ALSO has a
zillion uninitialized variables.

Even phpLIB, which sort of morphed into PEAR (???) used to have a
bunch of uninitialized member variables. It wouldn't even run on my
server since I had E_ALL cranked up. Their first patch for that was
to just change my warnings dynamically. Then not change them BACK at
the end of their code. Blech.

Sure, I'd LIKE to educate every PHP scripter to never use an
uninitialized variable. And I'd LOVE to change the default
error_reporting in php.ini to E_ALL.

But neither of those is likely to happen, and the best band-aid we can
muster is register_globals "off"

That said, the real culprits, as far as I can tell, are just doing
extract($_POST), at which point they might as well have just left
register_globals "on" anyway...

register_globals "off" is a band-aid.

How the PHP community can "fix" this problem for real is not something
to be figured out in a 10-minute PHP-General discussion.

--
Like Music?
http://l-i-e.com/artists.htm

[Back to original message]