Yet know we're getting "security advisories" warning, hey, if you change the defaults and ignore all the warnings, you too can write insecure code!In this sense, I agree. Default configuration is one thing, but active negligence is another. That said, Squirrelmail apparently thinks this issue is important enough to release an advisory: http://www.squirrelmail.org/security/issue/2006-06-01 So maybe they know more about the implications on their consumers than we do.
Did you look at the patch?It's almost 40 lines of code designed to *force* register_globals to "off" no matter what the idiot behind the wheel does.
I understand that there are many shared hosting sites that have register_globals set to "on". IMNSHO opinion they are putting their customers at risk unnecessarily. The default setting should be "off", and if someone needs it turned on in the application they're using, they can turn it on there and assume the risk themselves.
It wouldn't take much for web hosting companies to educate their users. A few lines of advice on a webpage would suffice. For example, for Apache users, you can set the php_flag register_globals on/off in a VirtualHost context (inside <Directory>.) So the hosting company can enable it on request but use the proper default setting for most sites.
Or the individual webmasters can set php_register_globals = [on|off] in a .htaccess file (Apache 1.3.x only!) or php_value register_globals [0|1] (Apache 2.x only!) if they don't like the default setting the hosting company uses. Or they can simply include a file with the setting in it and add an include statement to the code of the app.
I'm sure there are other methods that could be used as well. Since there are many options available, the default should be secure.
Paul Schmehl (pauls@xxxxxxxxxxxx) Adjunct Information Security Officer The University of Texas at Dallas http://www.utdallas.edu/ir/security/
Attachment:
p7sHVOpWVszUi.p7s
Description: S/MIME cryptographic signature
