Quote:
I have no control over number 2 (register_globals ON)
"Buyer Beware!"
Every site on a shared server with
register_globals set ON is potentially a sitting duck. If you use such a server, you should be surprised if your site is NOT compromised.
Note that turning
register_globals OFF on your site does nothing to protect you from other sites where it is still on. You do get some cross-site protection from good
open_basedir settings, but that's a little like leaving the front door open and hoping everyone's safe because the bedroom doors are closed.
For security reasons, the use of
register_globals has been depreciated on the official PHP site for years. Any ISP who doesn't turn it off is just trying to placate lazy customers who don't want to fix vulnerable code.
Note that
register_globals is one of the 'features' that makes PHP a joke in many hardcore programmer circles.
register_globals breaks one of the cardinal rules of good programming: Always know exactly where, when, and how your variables are set.
Q: How do you write an insecure application?
A: Use PHP!
Often followed by general laughter and very quiet groans.PHP CAN be secure, but ONLY if nutty options, such as
register_globals are tuned OFF!
Best advise I can give is to find an ISP that does not support lazy customers. Rise above that muddle.
Note that your ISP contract will release them from all responsibility in the event of an attack. If your site gets blamed for causing a vulnerability, it may get shut down, and recovery will be your problem.
It's much easier to deal with the relatively minor challenge of using well written code.
Not coincidentally, that's what someone should have pointed out loud and clear when
register_globals was first proposed. Note that as of PHP6,
register_globals disappears from PHP for good.
Who wants to bet that no fool will write a PHP6
register_globals emulator, and some fool ISP will install it by default (as a convenience), and all that vulnerable code will continue to haunt us?