Re: Security Issues

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 e.g. is_secure_connection()

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 better. With this solution, we break no scripts and we encourage more secure programming. 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. Zeev