Bug 26989 (unsaferedirect)

Summary: Should allow cross-origin navigation of top-level openers
Product: WebKit Reporter: Steen Nielsen <steen>
Component: JavaScriptCoreAssignee: Sam Weinig <sam>
Status: RESOLVED FIXED    
Severity: Major CC: abarth, sam
Priority: P2 Keywords: InRadar, NeedsReduction
Version: 528+ (Nightly build)   
Hardware: All   
OS: All   
URL: http://msdesign.dk/oes/filer/_test.htm
Attachments:
Description Flags
patch abarth: review+

Steen Nielsen
Reported 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.
Attachments
patch (5.06 KB, patch)
2009-09-23 16:52 PDT, Sam Weinig
abarth: review+
Mark Rowe (bdash)
Comment 1 2009-07-06 11:24:26 PDT
Sam Weinig
Comment 2 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?
Adam Barth
Comment 3 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).
Sam Weinig
Comment 4 2009-09-23 16:52:26 PDT
Adam Barth
Comment 5 2009-09-23 18:42:14 PDT
Comment on attachment 40030 [details] patch Precisely.
Sam Weinig
Comment 6 2009-09-23 18:57:23 PDT
Fixed in r48695.
Note You need to log in before you can comment on or make changes to this bug.