1214375 - Stringifying a cross-origin Location object throws an exception

Status: RESOLVED INVALID

(Core :: DOM: Core & HTML, defect)

Description

[Josh Matthews [:jdm]]

Attachment: testcase.html

Run the attached testcase in your favourite HTTP server and look at your web console.

Expected:
"http://joshmatthews.net"

Actual:
"Error: Permission denied to access property Symbol.toPrimitive"

Comment 1

[Boris Zbarsky [:bzbarsky]]

The key issue for me is that this throws an exception even if the actual location of the current document is same-origin.

That is, if you have a testcase which loads a cross-origin web page in an iframe, grabs its Location object, then navigates that iframe to a same-origin url, then tries to stringify that object, the result throws.

Or is that not expected to work?

The testcase I'm thinking of is to load http://example.com and then run this in the console:

  var ifr = document.createElement("iframe");
  document.body.appendChild(ifr);
  var loc;
  ifr.onload = function() {
    loc = ifr.contentWindow.location;
    ifr.onload = function() {
	console.log(loc.toString());
	console.log(loc + "")
    }
    ifr.contentWindow.location.href = "https://example.com/foo";
  }
  ifr.contentWindow.location.href = "http://web.mit.edu"

I guess that throws for the toString() as well, so maybe the throwing on getting toPrimitive is correct?

Comment 2

[Bobby Holley (:bholley)]

(In reply to Boris Zbarsky [:bz] from comment #1)
> The key issue for me is that this throws an exception even if the actual
> location of the current document is same-origin.
> 
> That is, if you have a testcase which loads a cross-origin web page in an
> iframe, grabs its Location object, then navigates that iframe to a
> same-origin url, then tries to stringify that object, the result throws.
> 
> Or is that not expected to work?

It is not expected to work. We need to handle the inverse case (a same-origin Location object describing a browser context whose current document is cross-origin), which we handle by all the nsLocation::CallerSubsumes checks. But handling the case you're talking about would basically involve punching a hole through the security wrapper and adding more special-cases in the spec. I see no compelling reason to do that.

Though this is probably a good moment to let Anne know that same-origin Location objects still need to have security checks on most of their accessors, which didn't make it into the etherpad and may not be in the tests.

Comment 3

[Boris Zbarsky [:bzbarsky]]

> same-origin Location objects still need to have security checks on most of their
> accessors

Right, this is specced at https://html.spec.whatwg.org/multipage/browsers.html#security-location with the big caveat there.

Comment 4

[Boris Zbarsky [:bzbarsky]]

But if this is not expected to work, then invalid.

Comment 5

[Bobby Holley (:bholley)]

(In reply to Boris Zbarsky [:bz] from comment #3)
> > same-origin Location objects still need to have security checks on most of their
> > accessors
> 
> Right, this is specced at
> https://html.spec.whatwg.org/multipage/browsers.html#security-location with
> the big caveat there.

Right, but IIUC that spec is out if date - it's basically saying that Location security checks should be performed against the browsing context. The new spec says they get performed against the document, and so the key point here is that we need to spec an _additional_ set of checks against the browsing context, assuming the document checks pass.

Comment 6

[Bobby Holley (:bholley)]

And note that the time at which these checks are applied is different. The etherpad security checks happen at property access time, whereas these additional checks need to happen at method/getter call-time.

Comment 7

[Anne (:annevk)]

Mentioned this bug in https://www.w3.org/Bugs/Public/show_bug.cgi?id=20701 so I can study it more closely once we have a plan in place for what the standard should actually say.

Comment 8

[Bobby Holley (:bholley)]

Thanks Anne!