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: RESOLVED CONFIGURATION CHANGED
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: 2022-07-25 20:55 PDT (History)
7 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.
Comment 4 Ahmad Saleem 2022-07-25 16:36:29 PDT
I am unable to reproduce this issue in Safari 15.6 on macOS 12.5 using test URL, I get following:

First Button - True --> dialog box (on window.opener == null)

Second Button - Nothing --> Though errors in Console to say that window-opener is null.

I think since all browsers are matching each other, this can be considered as "RESOLVED CONFIGURATION CHANGED" or "RESOLVED WORKSFORME". Thanks!
Comment 5 Ryosuke Niwa 2022-07-25 20:55:03 PDT
Thanks for testing