Bug 17111
Summary: | window.opener reset to non-null after being explicitly set to null | ||
---|---|---|---|
Product: | WebKit | Reporter: | Adam Barth <abarth> |
Component: | Frames | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED CONFIGURATION CHANGED | ||
Severity: | Normal | CC: | ahmad.saleem792, ap, bfulgham, cdumez, collinj, rniwa, sam |
Priority: | P2 | ||
Version: | 528+ (Nightly build) | ||
Hardware: | All | ||
OS: | All | ||
URL: | http://crypto.stanford.edu/~abarth/research/webkit/gmail/ |
Adam Barth
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.
Attachments | ||
---|---|---|
Add attachment proposed patch, testcase, etc. |
Geoffrey Garen
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.
Adam Barth
> 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.
Geoffrey Garen
Modified title to reflect Adam's analysis.
Ahmad Saleem
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!
Ryosuke Niwa
Thanks for testing