Bug 26989 (unsaferedirect) - Should allow cross-origin navigation of top-level openers
Summary: Should allow cross-origin navigation of top-level openers
Alias: unsaferedirect
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Major
Assignee: Sam Weinig
URL: http://msdesign.dk/oes/filer/_test.htm
Keywords: InRadar, NeedsReduction
Depends on:
Reported: 2009-07-06 07:37 PDT by Steen Nielsen
Modified: 2009-09-23 18:57 PDT (History)
2 users (show)

See Also:

patch (5.06 KB, patch)
2009-09-23 16:52 PDT, Sam Weinig
abarth: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Steen Nielsen 2009-07-06 07:37:54 PDT
Feature or bug, I don't know. people on the IRC channel (#webkit) said I should report it as a bug and get my answer that way.

On domain http://example1.com we visit the page "page1.html", here we open a popup with the page http://example2.com/popup1.
Inside "popup1" is a javascript, window.opener.location.href = "http://example1.com/page2.html" that runs onload.

In Firefox 3.5 and Internet Explorer 8 this will result in the opener (http://example1.com/page1.html) will be set to "http://example1.com/page2.html".

On Safari 4 and Chrome 2 this returns a common error: "Unsafe JavaScript attempt to initiate a navigation change for frame with URL %s1 from frame with URL %s2."
Safari 4 furthermore returns the error: "Unsafe JavaScript attempt to access frame with URL %s1 from frame with URL %s2. Domains, protocols and ports must match."

%s1 = http://example1.com/page1.html
%s2 = http://example2.com/popup1

I know that there have been a great amount of security enhancements lately, but is this supposed to be one of them?

If it is supposed to, how is it possible to get around this restriction?
Many payment companies use this method for webshops, at least in Denmark. You open a popup window with creditcard payment options (mastercard, visa and so forth) and when you have gone through the payment, the popup would close and redirect the user to a order confirmation on the webshop - this is a vital element.
If the user is not redirected back to the webshop, the webshop system won't know that the order have gone through and the user will not be presented to a order confirmation, but the payment will have gone through. This results in a lot of users paying for things they don't get.

I have tried to find a document describing if there's a workaround - where you could allow a certain website to make this redirect, but it have not been possible for me to find this.
I've read that there is an "Access-Control-Allow-Origin" response header for cross domain requests, but after trying it out, it doesn't seem to have an effect.

I have a very simple test-case here: http://msdesign.dk/oes/filer/_test.htm
It will open a popup at the page http://www.swine.dk/spil/_test2.html?things=tadaa
The popup tries to redirect the window.opener to http://msdesign.dk/oes/filer/_test2.htm

In firefox 3.5 and Internet Explorer 8 it works, but not in Safari 4 or Chrome 2.

I hope there is a solution to this.
Comment 1 Mark Rowe (bdash) 2009-07-06 11:24:26 PDT
Comment 2 Sam Weinig 2009-09-22 22:16:34 PDT
Adam, do you have any thoughts on allowing a popup to navigate its opener, even if they are of different origins?
Comment 3 Adam Barth 2009-09-22 23:09:29 PDT
It sounds like the opener restriction is preventing the navigation (because example2.com is not the opener of example1.com).  In general, it's hard to state a threat model in which the opener restriction buys you much security.

It seems fine to allow this case, especially if that makes us more compatible with Firefox 3.5.  It seems similar to allowing frame-busting (just popups instead of iframes).
Comment 4 Sam Weinig 2009-09-23 16:52:26 PDT
Created attachment 40030 [details]
Comment 5 Adam Barth 2009-09-23 18:42:14 PDT
Comment on attachment 40030 [details]

Comment 6 Sam Weinig 2009-09-23 18:57:23 PDT
Fixed in r48695.