- From: Ian Hickson <ian@hixie.ch>
- Date: Fri, 12 Jun 2009 01:08:11 +0000 (UTC)
On Wed, 27 May 2009, Dmitry Titov wrote:
>
> 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?
Yes. Done. Any redirects to different-origin URIs cause an error now.
On Wed, 27 May 2009, Drew Wilson wrote:
>
> 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.
Yes. The idea is that we can extend this to cross-origin scripts in a
future version, based on the origin of the script.
On Thu, 28 May 2009, Drew Wilson wrote:
>
> I'm not quite sure why importScripts() should behave more like a
> <script> tag than the Worker constructor itself. There's no reason why I
> shouldn't be able to do Worker("http://foo.com/worker.js") if I can do
> importScript(" http://foo.com/worker.js").
You will eventually be able to do that, once we figure out how to make
cross-origin workers work. Right now I'm waiting for us to have more
experience with cross-origin XHR and postMessage() before adding this
feature.
Whenever we do it, though, the importScript() call will never change the
security context, so there will always be a conceptual difference.
On Thu, 28 May 2009, Dmitry Titov wrote:
>
> Returning to the the narrower original question, what should we do with
> redirects during worker loads?
> - should we abort load if any URL in the redirect chain is from different
> origin?
That's what I've done.
> - should we only abort load if the final URL is from different origin?
This would cause security problems for sites where one can redirect to a
page that the attacker can control the contents and make it valid JS.
> - if the same site redirects between schemas (http->https, http->data etc)
> does this abort loading too?
Yes.
> - which URL is used to compute the script's origin and/or base URL in case
> of redirects?
I've clarified the spec to make it after any redirects.
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 11 June 2009 18:08:11 UTC