- From: David Bruant <bruant.d@gmail.com>
- Date: Tue, 19 Mar 2013 17:30:54 +0100
- To: Mike West <mkwst@google.com>
- CC: "public-webappsec@w3.org" <public-webappsec@w3.org>
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. David
Received on Tuesday, 19 March 2013 16:31:25 UTC