921007 - "Permission denied" on inspecting location.href of frames

Status: RESOLVED WONTFIX

(DevTools :: Console, defect, P2)

Description

[Matteo Ferretti [:zer0] [:matteo]]

In the past, I used web console to do simple inspection of the current document. For instance, if I need to check all frame's location in a given document, I simply execute:

    Array.forEach(window.frames, frame => console.log(frame.location.href));

But now, in all Firefox versions (from release up to nightly) I got a "Permission denied". Not sure if because the domain of the frames are different – and therefore is against the SOP – but the web console should be able to dump them as well, like it was able to do in the past and in other browsers too.

This is to me a breaking change, and especially makes the web console a bit useless because doesn't have enough privileges to perform such operations; and users should be able to do so. The scratchpad has the same limitation.

Currently as workaround, the only way to inspect the document as before is execute scratchpad in the browser context, obtain the current content window, and do my stuff. That is, honestly, a bit annoying.

To me is a regression, and should be fixed, at least to match the users' expectations. If we're not going to fix, and diverge also by the rest of the browsers, we should have a very, very good reason IMVHO.

Comment 1

[Mihai Sucan [:msucan]]

Thanks for the bug report!

Comment 2

[Rob Campbell [:rc] (:robcee)]

cc'ing jim and adding needinfo.

Sounds like this will need to give the debugger api some extra capabilities to walk frames with different domains. I smell a security bug!

Comment 3

[Jim Blandy :jimb]

There are historical exceptions allowing JS code from one iframe to access the Location objects of iframes in other origins, but that spec is in flux:

http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#security-location

That does look to me like JS code shouldn't be able to *read* a Location's href property, though. So I don't really understand why this code used to work.

I *definitely* don't understand why the web console would evaluate code any differently from code running in the page itself. It's supposed to be evaluated exactly the way web content is, now that we're using Debugger.Object.prototype.evalInGlobal.

Matteo, what happens if you use the browser console to evaluate your expression?

bholley, could you explain what's expected here in FF at the moment? Have we changed our policies recently?

Comment 4

[Bobby Holley (:bholley)]

Script is not allowed to toString() a cross-origin location object. There was a time when this was the case, and we chemspilled for it about a year ago (see bug 720619).

As far as the web console goes, the behavior has varied, because it depends on the environment in which the actual object is toString()ed - see bug 730431. We should probably decide what behavior we want here, and add a test so that it doesn't change again.

The semantics here are debatable. Script running in the web console is supposed to run with the origin of the page, but one could argue that the stringification and pretty-printing of results should happen in chrome (as it has in the past). This leads to weirdness though, because:

myframe.contentWindow.location.toString()

will throw (since the toString happens explicitly), wheras

myframe.contentWindow.location

will not throw, and display the location, because the toString happens implicitly during the pretty-printing stage.

IMO we should pretty-print with page principal, so that our behavior here is consistent (throw in both cases). If people want to bypass the same-origin policy, they should do that with chrome. If we want to make it easier, we could add some mechanism to do a "chrome web console", similar to a chrome scratchpad.

Comment 5

[Panos Astithas (he/him) [:past] (please ni?)]

I would say that the Browser Console is for all intents and purposes the "chrome web console" mentioned above and it seems to not exhibit the problem described in comment 0.

Comment 6

[Bobby Holley (:bholley)]

(In reply to Panos Astithas [:past] from comment #5)
> I would say that the Browser Console is for all intents and purposes the
> "chrome web console" mentioned above and it seems to not exhibit the problem
> described in comment 0.

Oh yes, I didn't know that existed.

So I'd say WONTFIX this bug, but we should also probably add a test for this behavior.

Comment 7

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

(In reply to Matteo Ferretti [:matteo] [:zer0] from comment #0)
> In the past, I used web console to do simple inspection of the current
> document. For instance, if I need to check all frame's location in a given
> document, I simply execute:
> 
>     Array.forEach(window.frames, frame => console.log(frame.location.href));

On the test page I tried, I do indeed see a "Permission denied" error when I tried your snippet.  I also tried it in Chrome 32, and (after converting the syntax a bit), I also got a security error there as well.

However, the following worked well enough for me:

    Array.forEach(window.frames, frame => console.dir(frame.location));

You'll be able to see the href property in each of the logged location objects.  Maybe this workaround is good enough for you?

Not sure if it's a security problem that I was able to log these object cross-frame...  Perhaps others can say more about that.

Comment 8

[Bobby Holley (:bholley)]

(In reply to J. Ryan Stinnett [:jryans] from comment #7)
> You'll be able to see the href property in each of the logged location
> objects.  Maybe this workaround is good enough for you?

Because console is privileged.

> Not sure if it's a security problem that I was able to log these object
> cross-frame...  Perhaps others can say more about that.

It's not, because the entries written to the log are not accessible to content script.

Comment 9

[Mihai Sucan [:msucan]]

Once we have UI for selecting the target frame for evaluation this problem will be less of a concern. I agree we should WONTFIX this bug.