http://w3c.github.io/webappsec/specs/content-security-policy/csp-specification.dev.html#script-src modifies the way eval() and new Function() work. That should not be done in that way but rather there should be some way for the host environment to influence execution of those features.
I guess if we really rely on that being a DOMException whose name is "SecurityError" it would be best if the host environment could define the exception object to be thrown.
(This setup seems rather wonky, I wonder if this was ever passed by TC39 for review before it get widely deployed...)
What about the setup is wonky? What can we do to unwonk it?
Having ES features throw non-ES exception objects. I'm waiting for Allen to weigh in as what would be the best way forward here given the status quo.
Status quo (CSP 1.0) says "must throw a security exception", which I suppose isn't much better.
Would changing the spec to EvalError (which I believe is defined, but unused in ES6) be better? If not, what would you prefer?
(In reply to comment #3)
> Status quo (CSP 1.0) says "must throw a security exception", which I suppose
> isn't much better.
>
> Would changing the spec to EvalError (which I believe is defined, but unused in
> ES6) be better? If not, what would you prefer?
Which exception is thrown is probably the least of my concerns but EvalError seems like a good choice. It is no longer used by the ES spec. but this usage is similar to what it was originally intended for.
Regarding the ES specification, the hooks necessary to implement CSP seem trivial.
Now for bigger issues:
1) Is there really any point is trying to restrict the use of eval and the function constructor? Assume the a bad guy understands compilers. If his script has access to some JS source code that it might want to eval (or Function construct) he could provide his own eval/Function. All it takes is the inclusion in his script of a JS parser/interpreter, implemented in JS (consider http://sns.cs.princeton.edu/2012/04/javascript-in-javascript-js-js-sandboxing-third-party-scripts/ but with the sandboxing removed). I believe that using this technique it is possible to recreate a fully functional eval/Function so what has the restriction accomplished?
2) In ES6 there are going to be a number of new ways to evaluate source code. You will need to take those into account in your spec.
3)ES6 is providing new mechanisms (Loaders and Realms) with hooks for controlling capabilities such as eval and directly supporting sandboxing including iframes. It would seem that evolution of CSP needs to take these emerging capabilities into account and also should provide feedback into the ES6 design. (for a start see http://wiki.ecmascript.org/doku.php?id=harmony:module_loaders and https://github.com/ModuleLoader/es6-module-loader )
(In reply to comment #4)
> Which exception is thrown is probably the least of my concerns but EvalError
> seems like a good choice. It is no longer used by the ES spec. but this usage
> is similar to what it was originally intended for.
Great. https://github.com/w3c/webappsec/commit/d310910445161163ccc4d5b612c04962ec8412ab
> Regarding the ES specification, the hooks necessary to implement CSP seem
> trivial.
Also great! I'm happy to poke at the CSP spec in whatever way would make that simplest for you folks.
> 1) Is there really any point is trying to restrict the use of eval and the
> function constructor? ... I believe that using this technique it is
> possible to recreate a fully functional eval/Function so what has the
> restriction accomplished?
You're entirely correct.
That said, one goal of CSP is to _mitigate_ the risk of cross-site scripting and other content injection attacks. It's certainly going to be much more difficult for an attacker to inject a JavaScript compiler than it would be for her to exploit an author's unconsidered use of `eval()` (or similar) with data that the attacker might be able to control. Giving authors the ability to turn off the potentially problematic bits of JavaScript that do the magic of converting text to execution is valuable, though I'd agree that it's nowhere near a 100% promise that no attacker-provided text can be evaluated.
> 2) In ES6 there are going to be a number of new ways to evaluate source code.
> You will need to take those into account in your spec.
Can you point me at some of them? Or, better, can we work out a way that CSP can hook into those methods in a generic way so that the CSP spec can avoid leaving obvious holes with new revisions of the ES spec?
> 3)ES6 is providing new mechanisms (Loaders and Realms) with hooks for
> controlling capabilities such as eval and directly supporting sandboxing
> including iframes. It would seem that evolution of CSP needs to take these
> emerging capabilities into account and also should provide feedback into the
> ES6 design. (for a start see
> http://wiki.ecmascript.org/doku.php?id=harmony:module_loaders and
> https://github.com/ModuleLoader/es6-module-loader )
I spoke with Alex Russell briefly (though I can't seem to CC him here...) about some of these types of concerns a week or two ago, and I agree that it would be a good idea to review these features to see how they interact with CSP. I haven't found time to read the linked documents yet, but they're on my list. :)
Resolving this for ES6, as I believe there is sufficient language in the ES6 spec. to handle the current CSP use cases WRT the eval features that a present in ES6. If you disagree you can open an ES7 bug.
The contemplate new eval-like features didn't make it into ES6. But you should continue to track ES7 work and in particular, the ongoing work to define the browser module loader and loader API