Re: About script-nonce

Le 18/03/2013 11:55, Mike West a écrit :
> Hi David,
> Yes, if 'unsafe-eval' is enabled, then it's perfectly possible to 
> emulate 'script-nonce' on current pages by evaluating the content of 
> script blocks that were otherwise blocked.
...but the point is to be able to do that without unsafe-eval?

> There would be a bit of difficulty around delivering the random nonce 
> safely to JavaScript, but I'm sure some clever mechanism could be 
> worked out.
I don't understand the difficulty... or I guess I understand better now 
the idea of making corresponding an HTML attribute and an HTTP header. 
It's likely easier than playing with JS.

> Regarding the loader API, what questions do you have specifically?
I was asking whether it should be treated as eval and Function are...

> I'm not familiar with the details of the proposal, but based on a 
> quick glance, it appears that  we would want to govern 
> 'Loader.prototype.eval' and 'Loader.prototype.evalAsync' under the 
> same rules as 'eval', and govern the fetching semantics under the same 
> rules as 'script-src' matching.
... which you answered here.

> In general, I'd say that if it loads something over the network or 
> directly executes plaintext, the same rules should apply.
unsafe-eval is a part of CSP I find controversial. It's always possible 
to bring in a full parser to re-implement (indirect) eval&friends, so 
unsafe-eval looks a bit odd.

One of the reason of the loader API to exist is to enable sandboxed 
loading, removing the flaws of naive eval (if you care to opt-in). I 
wonder if it's appropriate to treat it as eval.


Received on Tuesday, 19 March 2013 16:31:25 UTC