> 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
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
