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

Deian,
Hadn't thought of that - good one.
So, given:
//untrusted.evil/file1.jsfunction f(str) { 
  eval('alert("w00t")')}
//trusted.com/file1.js 
f('3+4');
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?
~DFKaye


 

     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:

//untrusted.evil/file1.js

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

//trusted.com/file1.js

f('3+4');

Best,
Deian