[whatwg] Workers and URL origin check

[Ian Hickson]

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.   `._.-(,_..'--(,_..'`-.;.'