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

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

From: Deian Stefan <deian@cs.stanford.edu>
Date: Wed, 28 Jan 2015 16:39:34 -0800
To: david kaye <dfkaye@yahoo.com>, Mike West <mkwst@google.com>
Cc: "public-webappsec\@w3.org" <public-webappsec@w3.org>
Message-ID: <87oapibet5.fsf@cs.stanford.edu>
david kaye <dfkaye@yahoo.com> writes:

> Thanks for responding.
>
> Given your example of the two files:
>
>     // file1.js
>     function doEval(str) {
>       eval(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?


I suspect that doing this in Gecko will also not be easy.

And I agree wth Mike: the semantics and trust model for this will get
very complicated.

What do you do about the reverse situation:

//untrusted.evil/file1.js

function f(str) {
 eval('alert("w00t")')
}

//trusted.com/file1.js

f('3+4');

Best,
Deian
Received on Thursday, 29 January 2015 00:39:59 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:09 UTC