WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
Bug 26989
unsaferedirect
Should allow cross-origin navigation of top-level openers
https://bugs.webkit.org/show_bug.cgi?id=26989
Summary
Should allow cross-origin navigation of top-level openers
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+
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Mark Rowe (bdash)
Comment 1
2009-07-06 11:24:26 PDT
<
rdar://problem/7034025
>
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
Created
attachment 40030
[details]
patch
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.
Top of Page
Format For Printing
XML
Clone This Bug