At 07:44 27/07/2001, Rasmus Lerdorf wrote:
> > Peter Petermann wrote:
> > > i dont think it is easier to write more secure applications
> > > with turning a feature of.
> > In this particular case, it would. There are several reported cases of
> > security-holes caused by this feature. Without it, there would be fewer
> > insecure PHP-applications out there.
> > Thats a fact. Thats the past. Now let's talk about the future.
>Please, everyone keeps stating this and immediately jumping to turning
>register_globals off as being the one and only solution simply because it
>is the most obvious solution.
>Think about whether in each of these cases it would have happened if the
>developers of the app had developed with E_NOTICE on. In a high number of
>these cases it probably wouldn't. And if this number is close to 100%,
>then it would point to the fact that there is another less destructive
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
- On the contrary, if we disable register_globals, than we get rid out of
all of the security issues related, without forcing people to have E_NOTICE
on. For instance, Perl::CGI has E_NOTICE's off by default (Perl), but it's
not prone to these attacks because it behaves like register_globals=off.
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
> > 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
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]