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.

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()

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 :)

Phil Driscoll

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]

Reply via email to