W3C home > Mailing lists > Public > public-web-security@w3.org > November 2011

Re: Workers inheriting CSP

From: Devdatta Akhawe <dev.akhawe@gmail.com>
Date: Sun, 27 Nov 2011 15:10:19 -0800
Message-ID: <CAPfop_0_OOpRVfafjaUGYSJBX2LQ3hFfxhsNy73PSs5-TFNM8A@mail.gmail.com>
To: Adam Barth <w3c@adambarth.com>
Cc: public-web-security@w3.org
On 27 November 2011 12:55, Adam Barth <w3c@adambarth.com> wrote:
> Another possibility is for the worker to be subject to the CSP policy
> that comes with it's script.

My model of the worker was that it essentially runs with the
privileges of the document that started the worker: the "no privileges
other than XHR" is really for managing the concurrency, and not a
security decision. It is some code that the main document runs without
having to worry about blocking the UI; the no access to DOM is for
preventing races. As a result, conceptually, it seems that the right
model is to limit it to the security policy of the main document.

> Also, it's always trivial for a script running in a document to bypass
> connect-src.  A better threat model to think about is a site that
> executes only trusted script but that might accidentally make an
> XMLHttpRequest for a URL supplied by the attacker.  In that model, it
> doesn't matter whether a worker uses a different CSP policy from the
> main document.

Why wouldn't the worker have the same problem? The URL can be sent by
the main document, or the worker can get it via an (allowed by
connect-src) XHR.


> Adam
> On Sun, Nov 27, 2011 at 12:50 PM, Devdatta Akhawe <dev.akhawe@gmail.com> wrote:
>> Hi folks
>> The CSP draft currently doesn't mention anything about CSP being
>> inherited by workers. In particular, a worker's XMLHttpRequest should
>> be subject to the original document's connect-src (or default-src as
>> the case may be). Else, it is trivial to bypass connect-src.
>> -devdatta
Received on Sunday, 27 November 2011 23:11:07 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:26:19 UTC