W3C home > Mailing lists > Public > public-webappsec@w3.org > January 2015

Re: CSP unsafe-eval alternative for a 'trusted' or 'eval-src: self'?

From: david kaye <dfkaye@yahoo.com>
Date: Wed, 28 Jan 2015 17:33:33 +0000 (UTC)
To: Mike West <mkwst@google.com>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
Message-ID: <1818338750.1909716.1422466413731.JavaMail.yahoo@mail.yahoo.com>
Thanks for responding.

Given your example of the two files:

    // file1.js
    function doEval(str) {

    // file2.js
    doEval('alert("Hello, world!");');

Assume that these files come from different URI domains:

+ //trusted.com/file1.js 
+ //untrusted.evil/file2.js

The 'eval-src' directive is just a whitelist of domains or paths, such that:

+ 'eval-src: //trusted.com; //another-trusted.com' ~ means js from those domains are ok to eval, so trusted.com/file1.js works.
+ //untrusted.evil ~ is not listed, so eval in file2 results in EvalError (think that's the type).

Make sense?


     On Wednesday, January 28, 2015 1:45 AM, Mike West <mkwst@google.com> wrote:

 On Tue, Jan 27, 2015 at 11:04 PM, david kaye <dfkaye@yahoo.com> wrote:

Would it be possible to define the eval restriction a bit differently, for instance with 'eval-src: self' to allow Function() calls *only* from trusted sources?

Practically, V8 only offers a global switch to turn code generation from strings on or off. Gecko might have an easier time with this proposal, perhaps?
Theoretically, the notion of a "trusted source" becomes hazy quite quickly. As a simple example, consider the following two files:
    // file1.js    function doEval(str) {      eval(str);    }
    // file2.js    doEval('alert("Hello, world!");');
If you include both files, which one do you gate on `eval-src`?

Received on Wednesday, 28 January 2015 17:34:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:45 UTC