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.
~dev
> 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
>>
>>
>