> At 01:35 27/07/2001, Rasmus Lerdorf wrote:
> >I think you missed my point. People use empty() and isset() on a variable
> >to check to see if that variable was set by the user. As such that
> >variable is unclean and whether it came in via register_globals or not is
> >quite irrelevant. If it is unclean it is unclean. It doesn't matter at
> >all which mechanism (GET/POST/COOKIE) populated the data from a security
> >perspective.
>
> I got your point, but I disagree on it. I think that lots of users use
> isset() for implementing the same logic you demonstrated in your example,
> only in a clean, E_NOTICE-free way. I know I used to do that, Heikki says
> he does, and my assumption is that it's a very common practice.
I think that assumption is wrong. And also your previous assumption that
the E_ALL error_reporting level change would break just as many scripts as
the register_globals change.
The way to figure this out would be to actually go and check instead of
making such broad assumptions. Take the first 25 projects listed at
php.net/projects.php, install them and run them with E_ALL and then with
register_globals=off and see how they do. It's almost 3am, and I am
rather tired, but I grabbed the first one listed and installed it. Then
clicked through it and did various things. So here is my entry for it if
someone wants to actually take on this task of auditing the first 25 (or
more) projects:
Adaptive Website Framework
URL: http://www.liquidbytes.net/index.php?id=143&subject=/awf/
Worked perfectly without even a single warning when run under with
E_ALL, but failed to work at all with register_globals = Off. A look through the
code revealed decent checking and isset() consistently used on
user-supplied data.
> >Baby-steps are needed for changes like this. We can get away with the
> >E_NOTICE change I think. The register_globals change is much too drastic
> >and it changes the basic nature of the language. There are plenty of
> >people using PHP today who have no clue what an array is.
>
> I respectfully disagree :) I think this issue is critical, and the way we
> handle it would show a lot on how serious we (less important) and PHP (more
> important) are considered. In this case, making decision according to the
> least common denominator doesn't make since IMHO, and we should derive our
> decision from a security/reliability perspective, and not the
> newbie-friendliness perspective.
Sure the issue is critical. I have never said otherwise. Security is
critical. My disagreement is in how to help users write more secure
scripts. I do not agree that turning off register_globals will result in
significantly more secure PHP scripts out there. It will simply cause
scripts to break in non-obvious ways and the knee-jerk fix will be to
swear at those annoying PHP folks and then turn register_globals on, or
they will do something like:
foreach($HTTP_POST_VARS as $key=>$val) $$key = $val;
foreach($HTTP_GET_VARS as $key=>$val) $$key = $val;
foreach($HTTP_COOKIE_VARS as $key=>$val) $$key = $val;
And yes, I have run across code like this.
Assuming E_ALL, register_globals only fixes the case where users forget to
initialize a variable and at the same time they use isset() or empty() to
check to see if they have set that variable. I contend that the instances
of this are actually very rare and do not warrant the massive breakage a
change to the default register_globals change will cause.
And we haven't even explored alternative approaches to perhaps help users
catch this particular situation. I could see a some sort of audit mode
or lint that produced a little report of external variables (anything
checked/used with or without isset/empty before they are assigned),
internal variables, constants and perhaps unused variables.
Or as has been brought up a few times, something similar to Perl's taint
mode. Tough to do in our architecture, sure, but simply changing things
without exploring alternatives or researching the real state of the
problem doesn't make any sense to me.
-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]
