This is inspired by the paper Privilege Separation in HTML5 Applications by Devdatta Akhawe, Prateek Saxena, and Dawn Song but addresses a slightly different use case:
We want to run fully isolated web workers — they should not have any network or local storage access.
We reuse the technique from the paper of using a null-origin IFRAME as sandbox (to prevent access to same-origin resources like IndexedDB).
Inside the IFRAME, we set a CSP of "default-src 'none'" to prevent network access. We allow a main SCRIPT tag in the IFRAME to run with a script-src nonce. We also allow data: URIs to run the web workers.
(Compared to the paper, the only untrusted code runs in a web worker. The main page and IFRAME are trusted, but could additionally be locked down using the techniques described in the paper.)
-
Go to https://manuel.github.io/fully-isolated-web-workers/index.html in Chrome or Firefox.
-
Check the console for errors. You should see the following error messages:
-
Failed to execute 'open' on 'IDBFactory'— the worker has no access to IndexedDB. -
Refused to load the script 'https://manuel.github.io/test.js'— the worker can not load scripts from the domain on which the page is hosted. -
Refused to load the script 'https://cors-test.appspot.com/test'— the worker can not load scripts from CORS-enabled hosts. -
Refused to connect to 'https://manuel.github.io/test'— the worker can not make XHR requests to the domain on which the page is hosted. -
Refused to connect to 'https://cors-test.appspot.com/test'— the worker can not make XHR requests to CORS-enabled hosts.
-
An attacker could bring the browser to load the iframe.html outside of the
sandbox established by index.html, making the workers run not in a null-origin,
but on the same origin as index.html.
To prevent this, the technique from Listing 1 of the paper should be used (constructing the IFRAME dynamically with a data: URI). I will do this in a future version.