Bug 17111 - window.opener reset to non-null after being explicitly set to null
Summary: window.opener reset to non-null after being explicitly set to null
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Frames (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Nobody
URL: http://crypto.stanford.edu/~abarth/re...
Keywords:
Depends on:
Blocks:
 
Reported: 2008-01-31 01:45 PST by Adam Barth
Modified: 2008-01-31 14:56 PST (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Adam Barth 2008-01-31 01:45:53 PST
Frames are unable to set their window.opener property to null.

Webmail sites, such as Gmail, commonly set window.opener to null when following hyperlinks to prevent the destination page from navigating the user away from their webmail session.  If the user fails to notice the location bar has changed, they might fall victim to a spoofing attack.

Internet Explorer, Firefox, and Opera all permit sites to set their window.opener property to null.

Steps to reproduce:
1) Send yourself a Gmail message with a hyperlink to
   <http://crypto.stanford.edu/~abarth/research/webkit/gmail/>.
2) Click the hyperlink in Gmail.
3) Click the 'alert(window.opener === null);' button.
4) Click the 'window.opener.location = "http://www.yahoo.com/";' button.

Expected results:
1) Clicking the first button alerts "true".
2) Clicking the second button throws a null pointer exception.

Actual results:
1) Clicking the first button alert "false".
2) Clicking the second button navigates Gmail to http://www.yahoo.com/.

I think this should be straight-forward to fix, but I don't have a patch in hand yet.
Comment 1 Geoffrey Garen 2008-01-31 11:37:21 PST
WebKit allows frames to set window.opener, just not across domains. The same is true of Firefox. I think the difference in behavior here must have some other cause.
Comment 2 Adam Barth 2008-01-31 14:36:13 PST
> I think the difference in behavior here must have some other cause.

Yes, you're right.  The real issue is that the window.opener property is being reset after navigation, see:

http://crypto.stanford.edu/~abarth/research/webkit/gmail/open.html

When you follow a link in Gmail, they first call window.open(""), and then document.write content into the open window that nulls the opener and navigates the window to the destination.  WebKit is resetting the opener during navigation.
Comment 3 Geoffrey Garen 2008-01-31 14:56:13 PST
Modified title to reflect Adam's analysis.