- From: Brandon Sterne <bsterne@mozilla.com>
- Date: Tue, 29 Mar 2011 15:06:21 -0700
- To: Adam Barth <w3c@adambarth.com>
- CC: "sird@rckc.at" <sird@rckc.at>, public-web-security@w3.org
The current Gecko implementation does enforce the script-src restrictions on importScripts, but does *not* enforce the no-code-into-strings base restriction inside Workers. The thinking is that since Workers are already very much restricted from the DOM and the rest of the page, and are forced to communicate through postMessage, that imposing this base restriction there is needless. In order to exploit this, the page has to do something unsafe with the data returned by the Worker (like pass it to eval), and those things are already restricted by CSP. Does that seem reasonable? -Brandon On 03/28/2011 05:05 PM, Adam Barth wrote: > How do these requirements interact with workers? For example, workers > have setTimeout and setInterval as well. Also, there's an > importScripts API in WorkerContext. Should that be restricted by > script-src? > > Adam > > > On Mon, Mar 28, 2011 at 4:55 PM, sird@rckc.at <sird@rckc.at> wrote: >> If this is supposed to take IE quirks into consideration, then >> execScript should be added to that list of forbidden functions. >> >> -- Eduardo >> >> >> >> >> On Mon, Mar 28, 2011 at 3:06 PM, Adam Barth <w3c@adambarth.com> wrote: >>> Sorry for spamming the list with lots of questions. I'm just emailing >>> questions as they come up in the implementation. >>> >>> [[ >>> User-agents must prevent strings from being converted to ECMAScript >>> code, including calls to: >>> >>> eval() >>> new Function() constructor >>> setTimeout() called with a String argument >>> setInterval() called with a String argument >>> ]] >>> >>> Suppose the page does call setTimeout with a string. How should the >>> user agent handle the error? >>> >>> For example, in Step 6 of >>> http://www.whatwg.org/specs/web-apps/current-work/#dom-windowtimers-settimeout, >>> the user agent is instructed to "Return handle". Should that step >>> occur or should we return a null handle? Should setTimeout throw an >>> exception? >>> >>> There are similar questions for the other functions that convert >>> strings to code. >>> >>> Also, what about non-ECMAScript code? For example, if the user agent >>> supported VBScript as a scripting language (e.g., Internet Explorer), >>> should the user agent prevent strings from being turned into that sort >>> of code? >>> >>> Proposal: We should return a null handle from setTimeout and >>> setInterval. That lets the page detect the error would being so >>> drastic as to throw an exception. We could also log to the error >>> console (and of course report via the reporting-uri) to make the error >>> more visible to developers. >>> >>> Adam >>> >>> >> >
Received on Tuesday, 29 March 2011 22:04:16 UTC