Closed Bug 343175 Opened 18 years ago Closed 18 years ago

PopupBlocker XSS

Categories

(Core :: Security, defect)

defect
Not set
normal

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)

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
Attached file testcase
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
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.
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.
Flags: blocking1.8.1? → blocking1.8.1+
Assignee: dveditz → jst
Flags: blocking1.8.0.6? → blocking1.8.0.6+
Whiteboard: [sg:moderate?]
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...
Attachment #229581 - Flags: review?(mrbkap) → review+
Attachment #229581 - Flags: superreview?(bzbarsky) → superreview+
Fix checked in.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Attachment #229581 - Flags: approval1.8.1?
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+
Keywords: fixed1.8.1
Attachment #229581 - Flags: approval1.8.0.6?
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+
Fixed on the 1.8.0 branch.
Keywords: fixed1.8.0.7
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
interestingly, the behaviour on 1.0.x is upside-down. With the patch I get bugzilla cookies displayed, without the patch, something else.
Group: security
Flags: blocking1.9a1?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: