Tres Seaver wrote:
Martijn did add a knob to turn the feature off, via a new environment variable. With a security vulnerability, we have to come up with some kind of balance between the need to propagate the fix as quickly as possible and the need (as you point out) not to disrupt production sites unduly. I don't believe we can afford to wait a whole other release cycle for this fix; Brian, Jim, and Martijn deemed the fix too pervasive to be bundled as a hotfix, which offers us little choice except to included it in current releases.
Whithout the fix, virtually every Zope site in the world is vulnerable to URL-based cross-site scripting exploits. For instance, any URL which contains invalid form variable marshalling can generate an error page which includes the erroneous value, unquoted. E.g.:
<URL:http://somezopesite.com/looks/like/legitimate?foo:int=%3Cscript%3Ealert('Owned')%3C/script%3E>
Yeah, but why not fixing that instead? I for one concur that it is a good thing to care for such stuff, but the way it is fixed might really lead to a lot of confusion, because it again introduces some magic which happens behind the users back. As far as I understand the fix, I can imagine some use cases which might break without having been in danger at all. Someone please correct me if I'm wrong. 1. Sending mails with dtml-sendmail If you send plaintext mails, suddendly you get html_quoted stuff which you never wanted. Having to debug this without knowing about the new "feature" will get people up in arms. 2. <textarea ...><dtml-var some_variable_contained_in_request></textarea> 3. Any object which uses dtml to render content from the REQUEST not meant for being displayed in a browser. Some people might use zope for things which have nothing to do with html, so they didn't care about cross-site scripting in the first place. cheers, oliver