I wrote a thorough response while being disconnected, but it's kind of
pointless to send it considering the face to face discussion we had
today. The only thing I'd like say here is that in my opinion, the fact
form variables are defined as globals (as opposed to being defined just as
automatically inside $_GET/$_POST or $_FORM) is hardly what makes PHP what
it is. Auto form variable registration is very important and is one of the
cornerstones of PHP, but it'd be equally good if it had a different
syntax. Other cornerstones that make PHP what it is are the clean and non
obscure syntax (I bet Thies doesn't use PHP for his shell scripts because
of auto form variable registration...), the easy to use database APIs which
come within the binary, and the fact it contains a full set of Web tools
built into it. I think that portraying PHP as some weak version of Perl
with auto global form variables is not even an understatement, but just
plain wrong...
Anyway, to be more constructive - Andi had an idea when we were catching a
cab earlier today (yesterday). His idea (which I'm just pitching, we
haven't thought this through at all yet) is that instead of having
register_globals on, or off, we would have it as unset, by default. When
unset (i.e., on new installations) - PHP will not run, but instead display
information about register_globals, its security implications, examples,
and a general recommendation to turn it off if at all possible. We can
easily point the user to the location of the php.ini file that he has to
edit in order to modify register_globals to be either on or off.
Again, I'm just pitching this idea, I'm not entirely sure if it's good or
not. Personally, I still lean towards having register_globals off by
default for new installations. This will have a very small effect on
existing apps (for better and worse), it'd encourage (force) application
developers to write portable applications (which is a good thing - apps
based on register_globals=on are not portable, since many security-aware
people turn it off), and obviously, solve the security issues we've been
discussing.
If we release it as 4.1.0, it's going to generate enough noise to make
people aware of this issue, which is also a good thing.
Zeev
At 10:30 27/07/2001, Rasmus Lerdorf wrote:
> > This is an important step, that as I said, I wanted to make for years. I
> > just argue that as protective as you are over register_globals=on, the real
> > flaw is there, and this is the place it should be fixed. Fixing the fact
> > that E_NOTICE is on may also be viable, but in practice:
> > - A huge number of cases where E_NOTICE's will be generated isn't related
> > to security in any way, and people will be kind of pissed by it, and
> > probably turn it back off
>
>That's an issue that can be addressed. We perhaps need better granularity
>on the E_NOTICE.
>
> > If we distribute a php.ini-recommended, we can, and probably should enable
> > E_NOTICE's by default. It's not the solution to the problem raised in the
> > advisory.
>
>The very first and primary example in the advisory would most definitely
>have been caught by an E_NOTICE, so I don't see how this doesn't address
>the advisory.
>
>For reference the first example in the advisory is:
>
> <?php
> if ($pass = "hello")
> $auth = 1;
> ...
> if ($auth == 1)
> echo "some important information";
> ?>
>
>First, the guy who wrote the advisory didn't check his code, because the
>above could never actually be a problem since he confuses == and = and
>actually always sets $auth=1, but ignoring that and fixing his code, if
>you turn on E_NOTICE this script generates:
>
>Warning: Undefined variable: pass in foo.php on line 2
>
>Warning: Undefined variable: auth in foo.php on line 5
>
>And the second example is:
>
> <?php
> if (!($fd = fopen("$filename", "r"))
> echo("Could not open file: $filename<BR>\n");
> ?>
>
>Again, an obvious bracket mismatch so this example also doesn't run, but
>running this with E_NOTICE gives:
>
>Warning: Undefined variable: filename in foo.php on line 2
>Warning: Undefined variable: filename in foo.php on line 3
>
>Same goes for example 3 which is:
>
> <?php
> include($libdir . "/languages.php");
> ?>
>
>Then he talks about the file upload issues which is a separate problem and
>one we have addressed. And then he talks about .inc files and suggests
>that people who just use .php for include files are vulnerable because
>their scripts could be run out of context. This is a different issue as
>well.
>
> > > > But that's not the point. The point is that people who don't care about
> > > > security or coding style (beginners or professionals, doesn't really
> > > > matter) are less likely to write insecure code, because there's one
> > > > mistake less that they can make. As long as they stick to the defaults,
> > > > anyway.
> > >
> > >And one language less that these people are able to use.
> >
> > That's an empty statement, Rasmus... The auto-registered form variables
> > are not any less usable if we change the access method to them
> > slightly. I'd argue it actually makes the code much more readable and
> > newbie-friendly, actually.
>
>Why are new users latching onto PHP instead of Perl:CGI? PHP is not an
>inherently better scripting language. In fact it is probably
>significantly weaker. People use PHP because they find it easy to
>understand and easy to learn and because it is targeted to the Web
>problem.
>
>We have a responsibility to help people write more secure scripts, but we
>also cannot keep adding complexity to the point where we lose what makes
>PHP what it is. And we need to explore all the options we have here
>instead of jumping to conclusions.
>
>-Rasmus
--
Zeev Suraski <[EMAIL PROTECTED]>
CTO & co-founder, Zend Technologies Ltd. http://www.zend.com/
--
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]
