At 10:26 27/07/2001, Phil Driscoll wrote:
>On Friday 27 July 2001 17:35, Zeev Suraski wrote:
> > Have you read the advisory?  That's simply not true.
>Yes, and I beleive it is true in most cases.
> > There are two main types of security problems related to this:
> > (a) Ones that originate in the fact that people don't know they mustn't
> > trust any input coming from the user, be it GET, POST or cookies, that
> > they're all insecure
>So, you admit that register_globals=off for GPC variables gains us nothing,
>but will break shed loads of code?

Of course not.  The advisory includes several references to cases that 
demonstrate the exact opposite, and it makes perfect sense that many other 
such cases exist.

> > (b) Ones that don't, and there are many of them
> >
> > For those of type (a), register_globals being off or on doesn't change
> > much.  For (b), it does, big time.
>Then if you don't like my suggestion, how about a half way house -
>register-globals=GPC registers the insecure variables in the global namespace
>since we can't trust them wherever they appear in the namespace, whilst env
>variables and possibly session variables have to be read out of arrays.
>I know that this would break none of my scripts, but I can't speak for other
>scripts out there.
>I do feel, however, that you are really missing the point on E_NOTICE which
>IMHO has a much greater effect on the security of PHP than accessing GPC
>variables in a different way. I'd personally be even harsher than E_NOTICE is
>- if a production site generates a notice message for an uninitialised
>variable, then that's a fatal error in my book!

I think you missed the main point of the advisory.  People use global 
variables.  If people from the outside can pollute the global namespace 
using ANY method, it causes a common security pitfall.

I don't want to argue about the E_NOTICE stuff because of lack of time, and 
because IMHO, it's really very loosely related to the issue at hand.

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