Re: Security Issues

At 21:14 25/07/2001, Rasmus Lerdorf wrote:

But you don't acknowledge here that turning on E_NOTICE by default would effectively eliminate this coding mistake.

No, because it won't. As I said, you can cleanly implement this with empty(), and there'd be no E_NOTICE's or anything.

The change I would rather see in php.ini would be to have the default error_level be set to E_ALL because then the above script would generate a warning complaining about the fact that $ok was not initialized. Since PHP can determine when variables are not initialized the case for turning register_globals off in this example is rather weak.

PHP does not require or even encourage initialization of variables - setting $ok to 1, and then checking it with empty() is considered 'clean' code, but it'd be equally insecure. Huh? Please show a code example here.

Just replace your if ($ok) with if (!empty($ok)), and you have a perfect exploitable code that produces no warnings.

As I said, it's easy, but it is considerably less easy than it is to add GET variables. Let alone the fact that we're also dealing with SERVER and ENV vars, which cannot be injected at all. How about people who check server variables, such as HTTPS, using isset()? register_globals *is* evil. We are talking about default settings here. You cannot spoof this script using the current default: <? echo $REMOTE_ADDR ?> You can stick all the ?REMOTE_ADDR=foo you want in the URL and the server var will always overwrite it in the default config due to the default variables_order setting.

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.

And the case for leaving register_globals on is that it is a whole lot easier for people to figure out how to get started with PHP when the data is just there and you don't have to do any strange array tricks to get at your data.

I don't think that this arguments holds much water, as register_globals is the mother of many many security bugs, found in the most popular PHP apps out there. We need to find a way to access form variables easily, but without encouraging insecure coding, the way we do now. I disagree. Please show examples of this mother of all security bugs here. Examples of this not caught by E_NOTICE are difficult to come up with.

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. Zeev