756589 - testcase: importScripts works only with same-origin

Status: RESOLVED FIXED

(Firefox Graveyard :: SocialAPI, defect)

Description

[Shane Caraveo (:mixedpuppy)]

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.

Comment 1

[Mark Hammond [:markh] [:mhammond]]

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

[Shane Caraveo (:mixedpuppy)]

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

http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html
section 9.3.1

Comment 3

[Mark Hammond [:markh] [:mhammond]]

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.  9.3.1.4 has the word "fetch" with a link, and following that link it mentions an optional "same-origin flag" - but 9.3.1.4 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)

Comment 4

[Shane Caraveo (:mixedpuppy)]

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

pushed https://github.com/mozilla/socialapi-dev/commit/ba53096bdf93f614d38776e5e9cf78404852c924