At 05:08 27/07/2001, [EMAIL PROTECTED] wrote:
>Addressed to: Rasmus Lerdorf <[EMAIL PROTECTED]>
> <[EMAIL PROTECTED]>
>
> > 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
--
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]
