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
>solution here.

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 
newbie-friendly, actually.


PHP Development Mailing List <>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Reply via email to