Allow dynamically enabling/disabling unsafe-eval

[devd]

This allows us to limit these unsafe constructs to the cases where you know its happening.

[mikewest]

Hello, and welcome to the bug you filed several months ago that I'm only just now looking into. :)

How would you expect this to look and behave? I'm having trouble coming up with anything.

What's the back-compat story?

[mikewest]

@wycats suggested on Twitter that this kind of thing is important for Ember and other frameworks. So let's take another shot at discussing it.

As a strawman, given a nonce-based policy:

eval('<exciting>template</exciting> goes here', 'nonce123')

Good enough?

[devd]

This is fine too. But I think that it is easier to ask for the nonce for the API that enables/disables eval. Otherwise migrating old libs as well as asking current libs to pass nonce around for new browsers and support old browsers all becomes a mess. But I am fine with either; the approach you outlined is more secure but more painful to roll out IMO

[mikewest]

Can you spell out what you're thinking in a little more detail? I'm not at all wedded to the strawman. :)

[devd]

eval("alert(1)"); // fails
window.csp.enableEval('wrongNonce');//throws or maybe nothing happens
eval("alert(1)"); // still fails
window.csp.enableEval('nonce123');
eval("alert(1)"); //works
window.csp.disableEval();
eval("alert(1)"); // fails

But as I said even you strawman is fine. I defer to @wycats

[mikewest]

It seems like that boils down to the same thing, just with more verbosity. :)

It would allow things like new Function() though, which I don't have a good idea for otherwise. Do y'all care about new Function() or setTimeout([string]) or any of the other string sinks?

[devd]

well I think we will need a version of your strawman that allows new function and setTimeout with the right nonce.

[mikewest]

And I think we need a version of your strawman that at least sketches out answers to the design questions we started addressing in https://w3c.github.io/webappsec-csp/api/ but with which we never got anywhere. :)

While we could make setTimeout/setInterval, etc. understand a nonce pretty trivially, we can't add things to new Function(...) without substantial hackery. If y'all need that mechanism in particular, then we need to do some more work together.

[mikesherov]

IM(layman)O, there are upsides and downsides to both approaches, but it seems as if we want new Function() to work, we need the window.csp.enableEval() approach. I'm wary of trying to introduce new functionality into the Function constructor, and forcing that through TC39 at the language level. Of course, this leaves open the notion of accidentally forgetting to disable when you're done with the eval.

[annevk]

Yeah, I don't think we can realistically expect to change eval() either. Changing this globally seems much more doable, though also less safe.

[mikewest]

If changing eval() is out (though I guess I don't share your skepticism, @annevk, since my (hasty) spot-check of browsers shows that they consistently ignore a second argument), then we need an API. I'm a little worried about adding a one-off API without designing the framework into which that bit would fit, but at the same time, that's a lot of work that no one has taken up in the last ~5 years. So. Anyone interested? :)

@arturjanc: FYI.

[annevk]

My skepticism is about convincing TC39.

[mikewest]

I see.