testcase: importScripts works only with same-origin




5 years ago
5 years ago


(Reporter: mixedpuppy, Assigned: mixedpuppy)


Firefox Tracking Flags

(Not tracked)




5 years ago
The code does use nsIURI.resolve on any urls passed to importScripts, we should have a unit test for that.  As well, importScripts should support data URIs.
Please clarify: does this mean the "same origin" used by the browser itself, or the more relaxed "provider origin" we are using (which doesn't include the scheme)?  The distinction may be important.

Also, what is the use-case for supporting data URIs?  IIUC, a data url would have the javascript source embedded in it, so eval() could be used directly by the worker to support this?

Comment 2

5 years ago
importScripts is defined in the web worker spec.  IIUC, you can only import relative scripts, or at most same origin (proto+host+port) urls.

section 9.3.1
I'm actually not sure the worker spec says this at all:

http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html implies the origin is used to resolve relative URLs. has the word "fetch" with a link, and following that link it mentions an optional "same-origin flag" - but doesn't mention this flag - just the "synchronous flag".

* http://petelepage.com/blog/2011/05/tweeterfall-web-workers/ has an example where importScripts is used to load from twitter.com.

* http://code.google.com/p/chromium/issues/detail?id=70336 is a chromium bug which talks about information leakage in cross-origin importScripts.  It implies the error is simply the leakage, not the fact that cross-domain importScripts works.

* http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-November/017543.html implies no such restriction too.

FWIW though, gecko *does* currently have such restrictions - http://mxr.mozilla.org/mozilla-central/source/dom/workers/ScriptLoader.cpp#296 - but that may well end up being considered a bug...

All that said though, it would be prudent for us to enforce it too.  I think this means we should *only* accept relative URLs, otherwise we end up with a problem of http:// vs https:// (ie, bug 756021 is so we can have the same provider from a http and https URL, but if we enforce the same origin restriction here, the worker can't use a fully-qualified URL as either the http or the https one will fail to load in the other context)
Blocks: 733414


5 years ago
Assignee: nobody → mixedpuppy
Severity: normal → blocker

Comment 4

5 years ago
for now, enforcing same-origin for importscripts.  We can loosen later if that makes sense.

pushed https://github.com/mozilla/socialapi-dev/commit/ba53096bdf93f614d38776e5e9cf78404852c924
Last Resolved: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.