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: Thu, 29 Jan 2015 01:40:35 +0000 (UTC)
To: Deian Stefan <deian@cs.stanford.edu>, Mike West <mkwst@google.com>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
Message-ID: <552999057.2145370.1422495635379.JavaMail.yahoo@mail.yahoo.com>
Hadn't thought of that - good one.
So, given:
//untrusted.evil/file1.jsfunction f(str) { 
I would expect an error as f is defined in the untrusted file.  

If the engines don't mark or source-map definitions by path, then it's not something CSP can specify/enforce by itself.
Should I take this up with es-discuss and circle back?


     On Wednesday, January 28, 2015 4:39 PM, Deian Stefan <deian@cs.stanford.edu> wrote:

 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:


function f(str) {




Received on Thursday, 29 January 2015 01:41:17 UTC

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