- From: Devdatta Akhawe <dev.akhawe@gmail.com>
- Date: Sun, 27 Nov 2011 15:10:19 -0800
- 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. ~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 >> >> >
Received on Sunday, 27 November 2011 23:11:07 UTC