W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2009

[whatwg] Workers and URL origin check

From: Drew Wilson <atwilson@google.com>
Date: Wed, 27 May 2009 18:15:17 -0700
Message-ID: <f965ae410905271815s77e8e84di53370f0da6035076@mail.gmail.com>
Along the same lines, I'm wondering why we require a same-domain check for
initial worker URLs, but not for script imported via importScripts(). Seems
like we ought to have workers inherit the origin of the script context that
invoked the Worker constructor, but allow the script URL passed to the
constructor to point at any domain.

Is there a motivating security concern for this language from section
4.8.2?:

> If the origin of the resulting absolute URL is not the same as the origin
> of the script that invoked the constructor, then throw a security
> exception.
>
It seems like it makes it harder for people to share script across domains
without actually providing any security.

-atw

On Wed, May 27, 2009 at 5:13 PM, Dmitry Titov <dimich at chromium.org> wrote:

> Hi WHATWG!
> I have a question about URL origin check for Workers: the spec, in 4.8.2,
> mandates a check for the Worker URL to be the 'same origin' with the parent
> document's URL. At the same time, 4.2 says the origin of the worker is
> derived later from the URL represented by the 'location' object of the
> worker context.
>
> However, the spec doesn't say how redirects should be processed. If a
> browser gets 30x redirect request, the final URL of a worker can be
> different from the original one which has passed the check before loading.
> Current spec ignores the fact that origin can be changed via redirect. If
> the origin of the loaded worker is based on the final (potentially
> redirected) URL that 'location' object represents, then subsequent XHR
> requests, nested workers and importScripts() will work in the origin of that
> final URL. As specified, in case of redirect the page from "
> http://applicationInternals.com" can use a worker from "
> http://application.com" (via redirect) to access APIs of application.comthat were not necessarily intended for such consumption.
>
> Should the spec simply require the redirected, final URLs to be checked
> against parent's and reject the script if redirection results in a different
> origin?
>
> Thanks,
> Dmitry
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090527/c087e932/attachment.htm>
Received on Wednesday, 27 May 2009 18:15:17 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:49 UTC