Consider Using Contextual Auto-Escaping

[schmittjoh]

Contextual auto-escaping often produces more intuitive escaping than simply turning auto-escaping on/off. This could be configured on a per-template basis via a compile-time directive.

see Google Closure Templates for more info:
http://code.google.com/closure/templates/docs/security.html

[nikic]

I don't quite understand what you mean by "contextual". In the sense that Twig automatically recognizes whether the output is done in JS or HTML?

[schmittjoh]

I really recommend reading the entire article I linked above. The basic philosophy is that dynamic input can never change the semantics of the template.

For example if you have the following template <a href="#">{{ foo }}</a>, then the input for "foo" of </a><a href="#">Bar would be escaped, but an input of Foo <strong>Bar</strong> would not be escaped.

[fabpot]

@schmittjoh: I've just read the article you mentioned. It looks very clever but I doubt that it fits Twig. First, Twig is not limited to HTML templates. Then, I don't see how we can always be aware of the context as anytime you can include another template (with a dynamic name); so, depending on where the include is called, the context can be different and so the escaping rules can also be different.

[schmittjoh]

I haven't really looked at the implementation of Google Closure Templates, but I know that they also support includes and non HTML templates (here Twig's behavior would simply be the same as it is now).

I can see that this escaping strategy can be very useful and solve some of the problems we had in the past when we discussed whether a certain filter/function should be marked as safe or not. It would also move some work from the developer to Twig and make templates more secure. Maybe, it makes sense to first try to implement this strategy in certain places where it is simple to implement, but the decision is yours.

[fabpot]

After thinking about it a bit more, that's something that we can do on top of the existing escaping mechanism (as an option). I've looked for more input and found the following interesting reads and references:

• http://js-quasis-libraries-and-repl.googlecode.com/svn/trunk/safetemplate.html
• http://code.google.com/p/py-html-contextual-escaping/source/browse/#git%2Fsrc
• http://code.google.com/p/owasp-esapi-java/source/browse/trunk/src/main/java/org/owasp/esapi/Encoder.java
• https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#XSS_Prevention_Rules

[schmittjoh]

Implementation-wise this might give some good pointers:
http://code.google.com/p/closure-templates/source/browse/#svn%2Ftrunk%2Fjava%2Fsrc%2Fcom%2Fgoogle%2Ftemplate%2Fsoy%2Fparsepasses%2Fcontextautoesc

[hason]

Context aware escaping has the Nette framework - the most popular and most used framework in the Czech Republic.

Documentation: http://doc.nette.org/en/templating#toc-context-aware-escaping
Article: http://php-security.org/2010/05/05/mops-submission-02-context-aware-html-escaping/

Parser: https://github.com/nette/nette/blob/master/Nette/Latte/Parser.php
Writer: https://github.com/nette/nette/blob/master/Nette/Latte/PhpWriter.php#L281

[fabpot]

As of Twig 1.9.0, we now have escapers for css, js, html, url, and html attributes. This is a first step towards context-aware escaping.

[mikesamuel]

I'm the author of the first three links. My current project ( https://www.usenix.org/lets-parse-prevent-pwnage ) is trying to solve the "not limited to HTML templates" problem you mention. Is there any interest in that kind of approach in twig?

[fabpot]

@mikesamuel: Yes, we are indeed really interested in implementing what you describe as that would be a huge step forward for the built-in security mechanisms we want to promote in Twig.