> 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
--
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]
