Since you're opening a new window from another domain and writing arbitrary HTML into it, I wonder if this vulnerability could be used to bypass cross-domain restrictions...
Just a general question but were there any unexpected vulnerabilities discovered through developing these tools? I haven't taken a look into the code but from the descriptions of the limitations with iframes and cross-domain windows it seems like your having to hack around the barriers and venture into unsettled territory.
yes, please, if you could explain for non security experts what we can do to protect our pages from this vulnerability, and also please clarify if it's relevant to web pages that don't use frames / iframes (I guess some of us just shrug and say, "hm.. clever post, I wish I had the time to dive into this, but I don't plan to try to use this to attack other sites, and it's probably not relevant for me since I don't have any frames" so a simplified clarification will be highly appreciated)
It seems like you'd need to inject malicious Javascript into the page before you could run an attack like this. General XSS attacks would be the larger, encompassing vulnerability.
> The newly opened tab can then change the window.opener.location to some phishing page.
This is true, and is a vulnerability I have been looking at for a while now, though I've not actually seen it exploited yet in the real world. For anyone interested, there are some pretty interesting exploits involving pages where an auth token is in the querystring and thus sent in the referer field by the browser. Also, consider what happens when you use an alert() in javascript to yank context back to the now attacker controlled tab...
> Or execute some JavaScript on the opener-page on your behalf…
Not true, this implies the "attacker" can run javascript in the context of the original page. They can only run javascript after redirecting the original page to one they control, so it's not like they can run code on the facebook.com domain, which would be a _huge_ exploit.
But the specific HTML that causes the problem is a common error that can be seen on plenty of pages, and the window which the vulnerability was active for was huge. How could you know that someone is intentionally using that erroring page to exploit the vulnerability?
good point. What it passes via URL parameter is URL encoded JSON - which is parsed using JSON.parse()... so shouldn't expose an attack vector.
The alternative - creating about:blank windows and moving DOM elements into them comes with a wealth of glitches and restrictions
So how do they technically do this? If there's an open browser window they shouldn't be able to access it. That's an xss exploit. This is not authorization, this is stealing leaked info.
Oh yeah, sure. I think we're on the same page here. It's literally no different than an XSS vulnerability (done on purpose or otherwise), which basically boils down to: yeah, don't do that.
This exploit uses the history API, which allows JavaScript to change the URL in the browser URL bar to another URL with the same origin without actually causing a new full page request. The same-origin policy has always been in place, because it would obviously be a huge vulnerability to allow any web page to pretend to be a different website.
Changing window.location is different: it allows you to change the browser URL bar to any URL (including google.com, etc.), but it actually causes the browser to do a normal page load of the new URL, just like if the user had clicked a link to the new URL. Thus there is no spoofing vulnerability exposed by the window.location feature.
How would an attacker have used this vulnerability? It seems to me that they'd already have to be able to inject code into the chrome context, to be able to point it towards content they control. Maybe I misunderstand how this works.
reply