Re: Security Issues

At 05:08 27/07/2001, php4@developersdesk.com wrote:

Addressed to: Rasmus Lerdorf <rasmus@php.net>

              <php-dev@lists.php.net>

Or you can simply stop these people from using PHP which is another effect turning off register_globals will have. Java does not have this problem because Java is so complex that this same set of users can not program in Java. Fixing this problem by making PHP more complex and eliminating these "problem" users is a bad idea as far as I am concerned. YES!!

NO!! :) Saying people would stop using PHP (or won't get started) because of this change is a gross exaggeration. IMHO, the one and only issue at hand here is downwards compatibility, and not usability or ease of use, not even a bit.

As I see it the whole issue revolves around the fact that some people get used to the fact that undefined variables have a value, and rely on it. These are the people who get hit when a hacker slips in his own value in on such variables. If the programmer had just initialized the variable at the top of the program, there would not be a problem. I think the best thing you could do about this issue is: 1. ALWAYS report the use of an uninitialized variable, no matter what level of error checking is in effect. At the very least send a message to the error_log for every undefined variable. If the error level allows it also complain to the browser and send an email to ServerAdmin. That won't break any existing scripts, but depending on the text of the email, it could give system administrators incentive to correct problem scripts. [1] The 'send email' default should be on in the distribution.

That's not going to find half, or a quarter, or whatever of the problems, since PHP has tools to cleanly handle undefined variables - namely isset() and empty(). They, or at least isset(), are quite popular.

2. Make it a FATAL error. Too bad that would break so many scripts... Maybe it could be a major effect of the E_SECURE bit. On the other hand, if you are serious about stamping out the uninitialized variable problem, this will do it.

I'd argue that that's actually going to make an equally messy effect on the PHP developer community, with a much lower gain, and also, a considerable loss. There's *nothing* wrong with the following code: function foo() {

        for ($i=0; $i<10; $i++) {
                $str .= $i;
        }
        return $str;

} It's safe, it's quick, and it uses an uninitialized variable. There are a hell of a lot more cases where using uninitialized variables is entirely secure, than cases where it's not. As a 'purist' coming from C background, I'd always initialize variables. PHP users would not. BTW, I'm just being argumentative here. I personally think that having E_NOTICE on is a very good idea, and that apps should be E_NOTICE-clean. A great deal of PHP programmers will not agree with me, though, so I haven't made up my mind on whether I support changing this default or not. Another main difference between having E_NOTICE turned on and having register_globals=off is that with register_globals being off, your app will not work, fair and square, unless you modify it to read its arguments from the right track vars arrays. As for just setting E_NOTICE - it won't help unless people actually check all the possible control paths of their logic. Of course, they should do it in the testing phase. And yes, I'm willing to bet that a great deal of them does not.

Register Globals is very convienent for people who write code with PHP. Turning it off would be a great loss. The problem is not that values passed to the server appear as variables, it is that some programmers don't make sure they initialize every variable before they use it.

There are two problems: 1. Programmers are humans, and humans are creatures that tend to make mistakes, including stupid ones, and worse, repeat them over and over again 2. PHP, with register_globals=on, mixes information coming from the user with information coming from code written by the developer, to a degree where it's impossible to differentiate between the two. Given problem #1, this often leads to security problems. In a perfect world, you'd be able to address #1 and then #2 would have been a non issue. But we're walking the Earth, and not wonderland, so I think we should concentrate on solving #2 :) Zeev