1034470 - Popup hijacking

Status: NEW

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

Description

[Romain Bertin]

Attachment: hijackpopup.zip

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0 (Beta/Release)
Build ID: 20140605174243

Steps to reproduce:

Put the file domainA.html on a domain
Put the file spoof.html on another domain
Open the file domainA.html in firefox
Click on "Go to my webapps !" ( a popup should open )
Reduce the popup
Click on the link in the comment 
And see that the popup content has changed.


Actual results:

A web site is opening a popup ( for web apps for example )
If the user reduces the popup and clicks on another link on the parent page, it's possible with the new link to overwrite the popup URL without restriction.

For example the real web site is opening a named popup like that:
window.open("http://www.mozilla.org", "hijackPopup", "toolbar=no");

The visitor reduces the popup and clicks on the "attacker" web site (in comments for example, favorites..)
At this time it's possible to overwrite the named popup from the attacker web site.
This bug can be useful for attackers because it's very common for web apps to open paypal, login forms etc in popup.


Expected results:

I think a popup should be associate at a website with SOP, because at this time there two problems, it's possible to overwrite the popup opened from another domain (even with https etc) and it's possible to open a popup without user interaction. 

I'm sorry for my english i'm french..
Don't hesitate to ask me for questions about this bug

Comment 1

[Romain Bertin]

I also found that the page of the attacker doesn't need to replace the real web site .. for example, if the named popup is open, any tabulation can overwrite it.

Comment 2

[Kamil Jozwiak [:kjozwiak]]

I went through the steps provided in comment #0 and reproduced what Romain was describing. I placed both domainA.html and spoof.html on two separate domains:

- I loaded domainA.html into fx
- clicked on "Go to my webapps !" (domainA.html) which opens a new window named "hijackPopup" that points to http://www.mozilla.org without the toolbar
- clicked on "superBlog.com" (domainA.html) which points to spoof.html that's located on the second domain that will redirect the "hijackPopup" window to "http://www.google.fr"

I used m-c 20140720030203 [changeset: 0894d2cdb16d]

Comment 3

[Daniel Veditz [:dveditz]]

jst: I thought we prevented re-use of windows-by-name as part of the frame ancestors policy rewrite?

Comment 4

[Johnny Stenback (:jst)]

I thought we did so too, at least for cross origin windows. Cc:ing bz to get his thoughts.

Comment 5

[Boris Zbarsky [:bzbarsky]]

If a site opens a popup window, it can always navigate it, no matter what's currently loaded in that window.  Last I checked, this was the behavior of every browser, had lots of pages depending on it, and was therefore required by the HTML spec.

Comment 6

[Daniel Veditz [:dveditz]]

Bz: the problem is not that SiteA can navigate a popup that it created, the problem is that SiteB can target a link at that same popup window. I _thought_ that a different origin trying to do that would get it's own (now unnamed) popup instead of re-using one opened by someone else.

We need to retest what Kamil set up in comment 2 but instead of opening SiteB in the same window (in case we're checking opener?) just open the SiteB page in a new window from the address bar and see what happens then.

Comment 7

[Matt Wobensmith [:mwobensmith][:matt:]]

I'm able to reproduce. Here's another summary of what appears to be going on.

You are on a site that you trust. You click on a link, and the site spawns its own pop-up window with a custom name. On the same site, if you click on a link to a site that you *don't* trust, this new site now has the ability to renavigate that same pop-up window just by referring to its name. 

I confirmed that both Chrome and Safari do the exact same thing, using the test files provided here. Didn't get a chance to try IE.

(I did, however, find a variation of this that affects Firefox only, which involves putting the second link in an x-domain iframe. In that case, Firefox allows x-domain window renavigation, where the other browsers don't. I don't want to clutter this bug with that detail, but there you go.)

Comment 8

[Romain Bertin]

The only difference I found between Firefox/IE and Chrome is that if we modify the siteA's url with siteB's url, the popup is blocked. Firefox and IE allows it.

Comment 9

[Matt Wobensmith [:mwobensmith][:matt:]]

Two questions: is this by design, and is it a security issue?

If it is by design, then we could then pose the question, "do we want to change it?" 
If it's not by design, we'd then consider it a bug and rate its severity.

Boris, with the additional information provided here, do you feel that the ability given to a 3rd party to renavigate the parent site's pop-up window is correct? Is it the right thing for us to do?

Comment 10

[Boris Zbarsky [:bzbarsky]]

> Two questions: is this by design

Yes.  The spec explicitly calls out this behavior.  Specifically, in http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#the-rules-for-choosing-a-browsing-context-given-a-browsing-context-name step 4, which uses http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#familiar-with which explicitly mentions:

  The browsing context B is an auxiliary browsing context and A is familiar with B's opener
  browsing context

as one of the cases where the navigation should be allowed.  So yes, we're basically checking the opener.  The spec does also have some weasel-wording in step 4 to the effect that:

   the user agent determines that the two browsing contexts are related enough that it is 
   ok if they reach each other

with nothing defining what "related enough" means.  But changing this sort of interoperable behavior would need to be coordinated across UAs anyway, at which point we should just spec it.

It's worth filing a bug on the iframe issue from comment 7, because it sounds like we're more permissive than other browsers, or the spec, there, and should fix that.

> do we want to change it?

That depends, in the first instance, on whether doing that would break websites, right?

We could certainly modify the checks, for example, to require being same-origin with the opener.  The question is whether that's web-compatible.

Comment 11

[Daniel Veditz [:dveditz]]

(In reply to Boris Zbarsky [:bz] from comment #10)
> It's worth filing a bug on the iframe issue from comment 7, because it
> sounds like we're more permissive than other browsers, or the spec, there,
> and should fix that.

Are we going to change anything in _this_ bug if we think we're following the spec? If not why not morph this to cover the comment 7 case.

Comment 12

[Boris Zbarsky [:bzbarsky]]

> Are we going to change anything in _this_ bug

Maybe.

> If not why not morph this to cover the comment 7 case.

Because the comment 7 case could benefit from a clear bug covering that one case, with a testcase covering that one case, without 12 long comments of noise, imo.

Comment 13

[Matt Wobensmith [:mwobensmith][:matt:]]

Boris, here's an example of where introducing an iframe that sources a link functions differently in Fx than some of the other browsers.

http://people.mozilla.org/~mwobensmith/bugs/1034470/domainA.html

!. Click on "Go to my web page" - should open x-domain pop-up window
2. Click on "superBlog.com" inside the iframe - should renavigate x-domain pop-up window

(Note: the two domains used here are "people.mozilla.org" and "people.mozilla.com".)

On Chrome, the second step is caught by their pop-up blocker.
On Safari, the second step spawns the page in a new tab, but does not renavigate the pop-up window.

IE appears to function the exact same way as Fx.

If you think that looks incorrect, say the word and I'll file a bug, but this seemed to be the appropriate place to ask.

Comment 14

[Boris Zbarsky [:bzbarsky]]

Please file a separate bug, since that testcase is quite different from the one this bug is filed on.  I said that already in comment 10....

Comment 15

[Matt Wobensmith [:mwobensmith][:matt:]]

Filed bug 1064499 from comment 13 as per bz's request.

Comment 16

[Matt Wobensmith [:mwobensmith][:matt:]]

As per pre-CritSmash triage, removing security-sensitive flag. Since this bug is the same across all browsers, and behavior appears to be as designed, discussion can take place publicly.

Comment 17

[Daniel Veditz [:dveditz]]

Not eligible for a bounty since this is spec'd behavior and does not raise any new security concerns.

Comment 18

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, >=3 years untouched DOM/Storage bug's priority.

If you have reason to believe this is wrong, please write a comment and ni :jstutte.