Template unsafe-eval issue

[Nadoedalo]

I'm trying to minimize/eliminate risk of XSS on my site, so I've considered to implement Content-Security-Policy
Is there a way to get rid/bypass the unsafe-eval issue or minimize the risks? I'm considering few things:

1. Minimizing risk by evaluating the code and escaping all data from models/other sources
2. Running no unsafe policy and run every _.template call in sandbox(webworker/etc?)
3. Changing template engine to one that doesen't eval code(is there some?)

Is there any luck of implementing safe mode into default template engine? What's my options?
PS needed to search but the topic seems old. Maybe it should be the case again? It seems like sandbox-mode should be fine.

[jashkenas]

There is no reason to pass user input into _.template. That doesn't make any sense.

[Nadoedalo]

Sorry to bother but what is the whole point of _.template? Any server-side data that is relevant is often some users input. And even the angular-way of re-rendering the page every time model is updated works OK.
So maybe I'm developing a very specific app because it's corporate site wich has a lot of features or just got it wrong, but I don't really like to place data by hands, <%=somedata%> works pretty fine for me.

[knowtheory]

@jashkenas That response is a bit abstruse... Surely it should be possible to use _.template to generate markup that wraps user input. VisualSearch being one such example.

Also presumably user input is the reason for <%- %> tags documented in the _.template section of the underscore docs. Using <%- %> instead of <%= %> may satisfy the query above.

[Nadoedalo]

Yeah, but it won't offer protection if someone won't know about <%-(it's like you will need to review every line of code of other programmist) or if there is a need to output unescaped characters

[jashkenas]

Not that this really needs to be argued, but no.

There is a very clear distinction between the template content that you write — that's what is evaluated — and the user input that is interpolated with <%- or <%=. The question was assuming that _.template was somehow at "risk" and needs to be "sandboxed" because it "evals" user input. That simply isn't how it works.

[Nadoedalo]

The first of all was the question of how to bypass the unsafe-eval security rule. I can't use the templates because security policy restricts me to do so. And If I will keep unsafe-eval it might grow to serious security break one day or anouther. I don't want to have unsafe policies at all BUT I want to use templates. That is the main issue.

[jashkenas]

If the security policy prevents you from using _.template, then you're going to be unable to use _.template. You'll have to choose a different templating library.

[Nadoedalo]

Yeah, it just sounds that simple but there are limitations to those methods. But if template is evaluated in sandbox and then security-policies applied(like no inline scripts or scripts not from whitelisted sources) than there is almost no risks and no limitations to the functionality.

OK, I've got the point. I will research sandbox idea and will reply on what I got.
PS are all of the contributors are so impulsive? I've got all of the answers you wrote in my first post here.

[jdalton]

Would precompiling the template avoid the issue(at least for the csp side of things)?

[megawac]

\2. Running no unsafe policy and run every _.template call in sandbox(webworker/etc?)

Precompiling and using a webworker/iframe template service would be pretty damn secure as long as you're careful whats exposed to global scope.

\3. Changing template engine to one that doesen't eval code(is there some?)

Probably the most practical solution for your use

[sivaprabug]

Try this one

https://github.com/silvermine/undertemplate