Re: [Workers] CSP and SharedWorkers

Le 27/09/2013 18:02, Hill, Brad a écrit :
>> -----Original Message-----
>> From: Jonas Sicking [mailto:jonas@sicking.cc]
>> What do implementations do with regards to linking <script> to
>> blob/data/filesystem? Are they treated like normal protocols, or are they
>> treated like eval()? If they are treated like normal protocols then maybe we can
>> simply not have any special rules for them and say that for now they never get a
>> CSP.
> [Hill, Brad] We're working through this at the moment, actually, since we've uncovered issues related to this in testing.  The proposals on the table are:
>
> 1) Allow blob/data/filesystem if 'self' (or equivalent) is allowed for everything but script and style, but require unsafe-eval for script and style.
> 2) Require that these schemes be explicitly listed (exclude them from the * production) with a warning that doing so is equivalent to unsafe-eval.
> Happy to hear further thoughts on this.
Maybe add an "unsafe-eval" rule to everything to cover these cases? In 
most cases, these values have been forged by trusted scripts (filtered 
after CSP) or these trusted scripts make the decision to use these values.
data URIs are a bit different because they can be inlined in the HTML 
(unlike blob and filesystem). Maybe add an "unsafe-inline" rule to all 
types to cover these case?
That would allow to differenciate the case where a data URI came from 
the HTML (server-side generation with user data which is its own threat) 
or used from script (where the threat ranges from "I forged it, so I 
know what I'm doing" to "someone which trust I can evaluate passed this 
URI to me and I'll make an educated decision myself")

I'm not sure a scheme-by-scheme thing is relevant. What matters is where 
these resources come from and how much where they come from is trusted; 
scheme describes how these resources are loaded, which is a largely 
orthogonal concern.

David

Received on Tuesday, 1 October 2013 07:30:29 UTC