Cross-tab scripting issue

RESOLVED FIXED

Status

SeaMonkey
Tabbed Browser
--
major
RESOLVED FIXED
14 years ago
7 years ago

People

(Reporter: Chris Thomas (CTho) [formerly cst@andrew.cmu.edu cst@yecc.com], Unassigned)

Tracking

({fixed-aviary1.0, fixed1.7.5})

Trunk
fixed-aviary1.0, fixed1.7.5
Bug Flags:
blocking1.7.5 +
blocking-aviary1.0 +
blocking1.8a5 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

It is possible to create a page that when opened in a new tab replaces the tab
from which it was opened, by using "content.document".
Flags: blocking1.8a5?
Flags: blocking1.7.x?
Flags: blocking-aviary1.0?
Created attachment 163325 [details]
Testcase [may replace this tab if opened in new tab]

Testcase
So to clarify, opening the testcase in a new tab overwrites the parent document
too.  It does change the URI in the URI field, so it's not a huge spoofing risk,
but it's still pretty disconcerting.
To get this to work, you have to have new tabs open in the background
(browser.tabs.loadInBackground set to true).

Note that this code is in use in the wild, although it appears to be accidental
(the malicious page I took it from had an iframe named "content").
Yikes.  Nominating.  Danm, whoever: how can |content| be bound in a content
window's DOM?

/be
Flags: blocking1.7.x?
Flags: blocking1.7.x+
Flags: blocking-aviary1.0?
Flags: blocking-aviary1.0+
Created attachment 163368 [details] [diff] [review]
Don't return the primary content window to hidden tabs.

The problem here is that 'window.content' ends up leaking the current tab's
window into any and all tabs in the same window, whether they're visible or
not. That's not a security problem per se as the calling tab doesn't have
access to the calle in any other ways than it would if the callee had opened
the window. But it's still bad, and this plugs the hole as safely as I could...

Updated

14 years ago
Attachment #163368 - Flags: superreview?(brendan)
Attachment #163368 - Flags: review?(bryner)
Attachment #163368 - Flags: review?(bryner) → review+

Comment 6

14 years ago
Interesting... so what will this do for a collapsed sidebar?
Created attachment 163371 [details] [diff] [review]
Alternate patch that makes 'content' be null in non-chrome script.

This is an alternate fix for this bug, this makes 'content' be null, in stead
of the top-most same-type window (which it is in "normal cases" for non-chrome
callers). This *should* be fine as well, but it would break any existing code
on the web that assumes it can use content to reach the top window (same as
window.top). I don't know for a fact that such code exists tho.
Comment on attachment 163368 [details] [diff] [review]
Don't return the primary content window to hidden tabs.

sr/a=me.  Thanks again, jst.

/be
Attachment #163368 - Flags: superreview?(brendan)
Attachment #163368 - Flags: superreview+
Attachment #163368 - Flags: approval1.7.x+
Attachment #163368 - Flags: approval-aviary+
(In reply to comment #6)
> Interesting... so what will this do for a collapsed sidebar?

Depending on how a sidebar is hidden (i.e. depending on if
nsIBrowserWindow::GetVisible() says true or false) this could prevent a
collapsed sidebar from accessing the content window. Not an issue in Firefox
AFAIK though.
Fixed on branches.
Keywords: fixed-aviary1.0, fixed1.7.x
Is the collapsed-sidebar thing an issue on the 1.7.x branch for seamonkey, though?
testcase opens in a new background tab as seen on windows firefox branch build
2004102607
tested on linux fc2:

with 2004102509-0.9+, the new tab says "Replaced original tab"
with 2004102609-0.11, the new tab says "Replaced original tab  New tab content"
OS: Windows XP → All
Hardware: PC → All
(In reply to comment #11)
> Is the collapsed-sidebar thing an issue on the 1.7.x branch for seamonkey, though?

What shaver asked.  I probably want this for 1.4, too....
Oh, yes, sorry, forgot to update this bug. Seems like this *is* a problem for
sidebars in SeaMonkey. The remaining question then is, I guess, do we care?

Updated

14 years ago
Flags: blocking1.8a5? → blocking1.8a5+
Need the fix on seamonkey trunk for 1.8a5

Comment 17

14 years ago
Johnny, can you get this into the trunk for us, please?
Asa, I could land the patch in this bug, but it would kinda break sidebars. It
would make it such that the webpage that you're currently viewing won't be
reachable from a sidebar that's not currently displayed. Not all that big of a
deal I don't think, but it might break random sidebars, maybe. I don't know of a
easy fix for that problem... 
Fix landed on the trunk after discussion with Asa. If this breaks existing
sidebars we'll file new bugs on that and deal with those problems there.
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
Attachment #163368 - Flags: approval1.8a5+

Comment 20

14 years ago
(In reply to comment #19)
> Fix landed on the trunk after discussion with Asa. If this breaks existing
> sidebars we'll file new bugs on that and deal with those problems there.

I guess bug 271308 and bug 271314 are the first ones.
Note that this is still around in a different guise -- see bug 273984
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.