W3C home > Mailing lists > Public > public-webappsec@w3.org > December 2014

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

From: Deian Stefan <deian@cs.stanford.edu>
Date: Mon, 01 Dec 2014 14:04:49 -0800
To: Brad Hill <hillbrad@fb.com>, "public-webappsec\@w3.org" <public-webappsec@w3.org>
Message-ID: <877fyb2fi6.fsf@stmarks.lan>

Brad Hill <hillbrad@fb.com> 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:
>
> https://w3c.github.io/webappsec/specs/content-security-policy/#which-policy
> -applies 
>
> but it would be good to make it specific as all the sandboxing algorithms
> 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.)

Deian

Received on Monday, 1 December 2014 22:05:18 UTC

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