Re: Security Issues

> Just replace your if ($ok) with if (!empty($ok)), and you have a perfect > exploitable code that produces no warnings. But in this case someone has gone to the trouble to figure out what empty() does. And generally they use empty() on things that come from the user anyway. I don't think I have ever seen people use empty() to check to see if they themselves have set an internal variable to something. > Right, but I gave a more specific example - HTTPS, which doesn't always > exist, and its very existence implies something. Not all variables are > exploitable, perhaps even most aren't, but many are. Don't people use $SERVER_PORT for this? Would seem to make more sense. But sure, there may be a few variables like this. > They're trivial to come up with; Pretty much any good code (E_NOTICE free) > that doesn't take into account the fact that variables can pop out of > nowhere into your global namespace is exploitable. I still think that turning on E_NOTICE by default is a good first step that we can take right away without waiting for a 4.1 and adding more emphasis to the documentation about these issues. With the E_NOTICE people at least get a warning and a line number and most apps will still work, they will just look very ugly forcing people to go and address the warnings. Turning off register_globals will simply break the applications with absolutely no hint as to why the application was broken and the end result will be that people simply turn register_globals back on to get things to work. -Rasmus