At 04:33 27/07/2001, Phil Driscoll wrote:
>I must be much more stupid than I give myself credit for.
>Changing to register globals=off surely does very little in terms of security
>for the easily fakeable GPC variables. I can see that for environment
>variables the picture is slightly different - you do need to be sure that
>this *really* is an SSL connection etc.
Have you read the advisory? That's simply not true.
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
(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.
>I propose the following - which will break *NO* scripts.
>Examine the environment variable issues such as those which pertain to SSL
>and then, just as recently happened with the file upload vulnerability,
>implement some functions which do 'full strength' checking for the user
That's the unthorough and prone-to-errors approach. It's like trying to
fill each and every hole in a piece of Swiss cheese.
>Then to address the uninitialised variables issue, modify the error reporting
>system so that the default setting (E_SECURE) emails warnings and errors to
>the administrator rather than displaying them in the output.
>Maybe some other refinement of the technique involving a sensible mixture of
>display_error, error_reporting, and a new email_errors directive might be
>With this solution, we break no scripts and we encourage more secure
>So now, tear it to pieces :)
It won't really address the issues that were raised in the advisory, will
be prone to errors (i.e., it's pretty much impossible for us to think of
everything), and I'd argue that it'd be less convenient on the long run, as
people know and expect to rely on environment/server variables.
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]