At 20:22 02/01/1999, Peter Petermann wrote:

> > I fully agree here with Rasmus and I also think this will
> > be the workaround for most people -- if one _does_ care
> > about security, he even knows what and how to do nowadays.
> > I don't think turning register_globals to off will evangelize
> > people to develop more secure scripts/applications.
>thats it.
>what we could do to make people to write more secure script is:
>- telling them to do so,
>- telling them what is insecure
>- telling them why something is insecure
>- writing a special type of documentation, about  how to write secure scripts

These methods are flawed by definition, since they assume that you'd be 
able to communicate to all, or even just most users.  Are they good things 
to do?  Definitely.  Are they enough?  Not really, because as the advisory 
claims, if the language encourages you to write insecure code (assuming you 
don't read 'general' documentation, which is very common), the language is 
at fault.  Will the applications of such people always be secure now that 
register_globals is off?  Of course not, but it's definitely going to knock 
down a huge amount of exploits in their apps, and there are good chances 
that these would be the only exploits in it.

>maybe we could do something like a php-security-central, where everyone 
>who wants
>to learn about security could read this kind of documenation, a special 
>where issues about security of php-applications is discussed, etc.
>you cant fight security holes without knowing what the hole is, and you
>cant make others writing secure apps without teaching them about how this 
>we shouldnt change php, we should give more information about this problems,
>so everyone is able to learn how to avoid them.

The way I see it, register_globals=on is pretty much like a swiss cheese 
factory as far as it comes to security holes.  No php-security-central is 
going to help here, and closing this factory down *is* going to help a 
lot.  This doesn't come to say it'd eliminate all security holes out there, 
obviously, just a great deal of them.

Again, I want to say that there are some good ideas being raised in this 
discussion, but given the fact (or my view, rather) that 
register_globals=on is *SUCH* a bad thing, none of them has too much to do 
with it.  They're good and should be discussed regardless of this issue, 
which should be resolved specifically, and in my opinion, by changing the 


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