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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
