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
better.
With this solution, we break no scripts and we encourage more secure
programming.
So now, tear it to pieces :)
Cheers
--
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]
