-- Jakub Vrana <[email protected]> wrote (on Sunday, 12 February 2012, 08:15 PM -0800): > Please read the article > http://php.vrana.cz/defense-against-xss-in-zend-framework.php and > consider changing the way how Zend Framework escapes data on output > before Zend Framework 2 is out.
My team, our security team, and members of the community review team have read this at this point. There are a few things we disagree with in the post, and several we agree with, and we'll be taking under consideration for our next two beta releases. The "problem" with the current solution is that because we are executing view scripts as plain PHP, we cannot easily introduce context-specific escaping -- that requires a full-blown template engine that parses the template first and compiles it in order to intoduce cut points. Such a design is completely opposite the original goals of the PhpRenderer. This leaves the following approaches: * Ditch the current approach and go for a compiled template solution. Pros: better initial security (though not bullet proof). Cons: Potentially introduces a new DSL into the framework, introducing new barriers to learning. Degrades performance and/or adds a deployment step (to compile the templates). Additionally, the only way to ensure markup returned by helpers is safe is to have a post-processor using something like HTMLSanitiser on the final output -- incurring a performance cost on each render call. * Strengthen our escaping mechanism to better escape quotes for HTML attributes, but otherwise leave as-is (with auto-escaping). Pros: "reasonable" initial security. Fast templating engine. Cons: Requires education about what is escaped and what is not, as well as how to ensure your custom helpers produce output that's safe. * Strengthen our escaping mechanism to better escape quotes for HTML attributes, but revert to remove the auto-escaping. Pros: same as previous, with addition that the story is: all variables are unsafe. Cons: more work and more verbose templates to ensure escaping is performed. We need to balance the various pros and cons of each approach and determine what is best for the users in terms of security, performance, and API in order to find a good solution for the framework. The fact is, your output, regardless of the templating solution you use, is only one layer to look at of many when building your security policy. If you're going to inject user data into HTML attributes, you had best do some excellent validation and normalization of that data well before it ever goes to the output layer; this is true of _any_ user generated content. -- Matthew Weier O'Phinney Project Lead | [email protected] Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- List: [email protected] Info: http://framework.zend.com/archives Unsubscribe: [email protected]
