Re: [webappsec] Clarifying how CSP sandboxing applies to Workers, ServiceWorkers

As workers are specified today, yes.  I would also like to see
Cross-Origin + Sandboxed workers in the future, which is why
I broke this requirement out into two clauses, so we can
go in that direction if needed or desired.


On 12/1/14, 2:04 PM, "Deian Stefan" <> wrote:

>Brad Hill <> writes:
>> We talked on list in the past about using CSP + sandbox to disable
>> ServiceWorkers.
>> I'd like to propose adding the following normative note to the sandbox
>> directive
>> In CSP.  I believe this is already implied by:

>> -applies 
>> but it would be good to make it specific as all the sandboxing
>> we
>> reference only apply to Documents, not "headless" script execution
>> contexts.
>> Proposal:
>> ======================
>> Note: When delivered via an HTTP header, a Content Security Policy may
>> indicate
>>     sandboxing be applied to a JavaScript execution environment that
>>     is not an HTML Document. One such scenario of particular interest is
>> script
>>     content intended to be used for the creation of a Web Worker, Shared
>> Worker or
>>     Service Worker.  While many of the sandboxing flags do not apply to
>> such
>>     environments, if the sandbox directive delivered with the resource
>> used 
>>     to create a worker implies the <code>sandboxed scripts browsing
>>     context flag</code>, or, if the sandbox directive delivered with
>>     such a resource implies the <code>sandboxed origin browsing context
>>     flag</code> and the creation of the new execution context requires
>>     it be same-origin with its creating context, abort the processing
>> model 
>>     for the creation of the new script environment with a network error.
>I support something along these lines. I do have a question: for Workers
>wouldn't this always imply that you can't create a Worker with a fresh
>origin? (I am happy to discuss sandboxed workers as a separate feature.)

Received on Monday, 1 December 2014 22:14:17 UTC