Closed
Bug 343175
Opened 19 years ago
Closed 19 years ago
PopupBlocker XSS
Categories
(Core :: Security, defect)
Core
Security
Tracking
()
RESOLVED
FIXED
mozilla1.8.1beta2
People
(Reporter: sync2d, Assigned: jst)
Details
(Keywords: verified1.8.0.7, verified1.8.1, Whiteboard: [sg:moderate?])
Attachments
(2 files)
894 bytes,
text/html
|
Details | |
549 bytes,
patch
|
mrbkap
:
review+
bzbarsky
:
superreview+
dveditz
:
approval1.8.0.7+
dbaron
:
approval1.8.1+
|
Details | Diff | Splinter Review |
Blocked popups requested by subframes inherit the security context from
the top-level document when showing them. This causes some troubles if
the top-level document and subframes are served from different domains.
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/dom/src/base/nsGlobalWindow.cpp&rev=1.863&mark=4206-4209,4216,4218-4220,4258#4200
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/browser/base/content/browser.js&rev=1.654&mark=542-546,555-566#540
this testcase is depending on bug 343168 to make up a mixed document.
popupblocker needs to be enabled. works on:
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.1a3)
Gecko/20060629 BonEcho/2.0a3
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.0.5)
Gecko/20060629 Firefox/1.5.0.5
![]() |
||
Comment 2•19 years ago
|
||
Hmm... I'm not sure why we use the top window, here, exactly. Are there some sort of reasons the popup blocker UI needs that data? If so, we should be passing more data around, sounds like.
![]() |
||
Updated•19 years ago
|
Flags: blocking1.9a1?
Flags: blocking1.8.1?
Flags: blocking1.8.0.6?
at cenzic we used all the information from the popupblocked event and more in order to get work done. please contact colin before breaking this too badly.
Updated•19 years ago
|
Flags: blocking1.8.1? → blocking1.8.1+
Updated•19 years ago
|
Assignee: dveditz → jst
Flags: blocking1.8.0.6? → blocking1.8.0.6+
Whiteboard: [sg:moderate?]
![]() |
||
Comment 4•19 years ago
|
||
timeless, my point was that if the popup blocker needs the originating window, then that window should be a member of the popup blocked event...
Assignee | ||
Comment 5•19 years ago
|
||
Attachment #229581 -
Flags: superreview?(bzbarsky)
Attachment #229581 -
Flags: review?(mrbkap)
Updated•19 years ago
|
Attachment #229581 -
Flags: review?(mrbkap) → review+
![]() |
||
Updated•19 years ago
|
Attachment #229581 -
Flags: superreview?(bzbarsky) → superreview+
Assignee | ||
Comment 6•19 years ago
|
||
Fix checked in.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Assignee | ||
Updated•19 years ago
|
Attachment #229581 -
Flags: approval1.8.1?
Updated•19 years ago
|
Target Milestone: --- → mozilla1.8.1beta2
Comment on attachment 229581 [details] [diff] [review]
Fix. Make the requesting URI be that of the window on which open() was called.
a=dbaron on behalf of drivers. Please check in to MOZILLA_1_8_BRANCH and mark
fixed1.8.1 once you have.
(Did the reviewers mention NS_STATIC_CAST?)
Attachment #229581 -
Flags: approval1.8.1? → approval1.8.1+
Assignee | ||
Updated•19 years ago
|
Keywords: fixed1.8.1
Assignee | ||
Updated•19 years ago
|
Attachment #229581 -
Flags: approval1.8.0.6?
Comment 8•19 years ago
|
||
Comment on attachment 229581 [details] [diff] [review]
Fix. Make the requesting URI be that of the window on which open() was called.
approved for 1.8.0 branch, a=dveditz for drivers
Attachment #229581 -
Flags: approval1.8.0.7? → approval1.8.0.7+
Comment 10•18 years ago
|
||
v.fixed on both branches:
Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.7) Gecko/20060906 Firefox/1.5.0.7
Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1b2) Gecko/20060907 BonEcho/2.0b2
Comment 11•18 years ago
|
||
interestingly, the behaviour on 1.0.x is upside-down. With the patch I get bugzilla cookies displayed, without the patch, something else.
Updated•18 years ago
|
Group: security
![]() |
||
Updated•18 years ago
|
Flags: blocking1.9a1?
You need to log in
before you can comment on or make changes to this bug.
Description
•