I wrote:

> > If you are careful, you can defend against Scenario 1 with 
> register_globals
> > on, but you need to understand all the stuff that PHP is 
> doing with the
> > data, and that is a fairly complicated picture. Your 
> application can still
> > work even if you don't understand that picture, and that is 
> how unsecure
> > applications come about. With register_globals off, the 
> data movement
> > picture is much simpler, and this is more of a "fail-safe" 
> mode: if you
> > don't understand how the data moves around in PHP, your 
> application simply
> > breaks ;)

And Rasmus added:
> In your scenario setting your error_reporting level to E_ALL 
> will throw a
> warning when you use an uninitialized $admin variable.  That 
> will prompt
> you to initialize $admin correctly and thus be fine with 
> register_globals
> turned on.

This is a good point, Rasmus. At the same time, it reenforces the point at
the top: there is more one needs to know in order to write safe code with
register_globals. Not much more, but it is more: one needs to know what the
problem is, what E_ALL is, and how E_ALL helps address the problem. And
clearly, there are a lot of people on this list who are not yet to that

> I don't think it is quite as hard as everyone says to write
> register_globals-safe code.

I agree, completely do-able, if one just knows a little bit more.


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

Reply via email to