zalando/beard

XSS prevention

rcillo opened this issue · 6 comments

rcillo commented

I would like to start a discussion around XSS prevention.

Currently, if one is using untrusted data in the template rendering, than we could have problems with XSS.

What I propose is to escape every value, unless explicitly told not to.

That would be backward incompatible, since what can be seem as an improvement could break current features. Since it's not 1.0 yet, maybe it's not a big problem.

The proposal goes as follow:

{{ safe the.title }} would not escape the content. Otherwise all content would be escaped.

If you think this is something we should add to the project, I would move on to discussing implementation details.

danpersa commented

I agree that escaping should happen by default.

But you should also be able to configure that you don't want escaping by default.

This is relevant for projects which don't render html.

aryszka commented

Hi! sorry for just chiming in just so, but I have this opinion for this, that beard is on one hand a generic templating lib for any kind of text output and not only for HTML, but on the other escaping is in best place in the templating when generating web pages. To solve this, I have this suggestion to make the escaping in beard a bit more 'abstract', by providing only an initialization argument, where one can plug any kind of escaping that implements a simple interface. This would allow using escaping for any type of output. As a nice to have addition, beard can also ship an implementation for the HTML escaping. How does that sound?

danpersa commented

Sounds like a good idea. Having different strategies for escaping. And make it configurable.

axyz commented

I was thinking to something like that on a plug-in architecture also for #19

in my "javascriptish" imagination there is something like

render = Beard
  .use(HTML) // default escaping
  .use(filterPackage1)
  .use(singleFilter)
  .use(arbitraryMiddleware)
// etc...
rweyand commented

Is this already done by the implemented escaping strategies?
Further, would a proper sanitization based on whitelists (i am thinking about something like http://jsoup.org/apidocs/org/jsoup/safety/Whitelist.html) be appropriate?

danpersa commented

Maybe having the whitelisting is too granular for the moment...