Closed
Bug 265987
Opened 20 years ago
Closed 20 years ago
Cross-tab scripting issue
Categories
(SeaMonkey :: Tabbed Browser, defect)
SeaMonkey
Tabbed Browser
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: csthomas, Unassigned)
Details
(Keywords: fixed-aviary1.0, fixed1.7.5)
Attachments
(3 files)
(deleted),
text/html
|
Details | |
(deleted),
patch
|
bryner
:
review+
brendan
:
superreview+
brendan
:
approval-aviary+
brendan
:
approval1.7.5+
dbaron
:
approval1.8a5+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
Details | Diff | Splinter Review |
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".
Reporter | ||
Updated•20 years ago
|
Flags: blocking1.8a5?
Flags: blocking1.7.x?
Flags: blocking-aviary1.0?
Reporter | ||
Comment 1•20 years ago
|
||
Testcase
Comment 2•20 years ago
|
||
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.
Reporter | ||
Comment 3•20 years ago
|
||
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").
Comment 4•20 years ago
|
||
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+
Comment 5•20 years ago
|
||
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•20 years ago
|
Attachment #163368 -
Flags: superreview?(brendan)
Attachment #163368 -
Flags: review?(bryner)
Updated•20 years ago
|
Attachment #163368 -
Flags: review?(bryner) → review+
Comment 6•20 years ago
|
||
Interesting... so what will this do for a collapsed sidebar?
Comment 7•20 years ago
|
||
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 8•20 years ago
|
||
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+
Comment 9•20 years ago
|
||
(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.
Is the collapsed-sidebar thing an issue on the 1.7.x branch for seamonkey, though?
Comment 12•20 years ago
|
||
testcase opens in a new background tab as seen on windows firefox branch build
2004102607
Comment 13•20 years ago
|
||
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
Comment 14•20 years ago
|
||
(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....
Comment 15•20 years ago
|
||
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•20 years ago
|
Flags: blocking1.8a5? → blocking1.8a5+
Comment 16•20 years ago
|
||
Need the fix on seamonkey trunk for 1.8a5
Comment 17•20 years ago
|
||
Johnny, can you get this into the trunk for us, please?
Comment 18•20 years ago
|
||
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...
Comment 19•20 years ago
|
||
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
Closed: 20 years ago
Resolution: --- → FIXED
Updated•20 years ago
|
Attachment #163368 -
Flags: approval1.8a5+
Comment 20•20 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.
Comment 21•20 years ago
|
||
Note that this is still around in a different guise -- see bug 273984
Updated•16 years ago
|
Product: Core → SeaMonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•