Hacker News Reader

Comment by throwawaybookst | Hacker News Reader

> PS. Interestingly, Google doesn’t seem to care.

That's not fair. They state it's a problem that is inherent to browsers, not that they don't care about the issue.

Also be mindful of Google's warning regarding the author's workaround:

> in particular, clobbering the window.opener property limits one of the vectors, but still makes it easy to exploit the remaining ones.

View on HN

I'd be interested in knowing the others. So would I imagine most people reading that page.

I mentioned this on another related thread: https://news.ycombinator.com/item?id=11554080. In short, the solution here only closes one of potentially many other similar attacks: http://lcamtuf.coredump.cx/switch/

The attack I linked to originates from the malicious site and links to the trusted site (the reverse of the attack in this post). There is nothing a site can do to prevent this since there is no way for a linked to site to prevent the linking site from getting a window reference to it. So, imagine a scenario like this:

* trusted site implements the guidance here and links to malicious site.

* The malicious site, detecting that they can't get a reference to "window.opener" immediately opens a new tab back to the trusted site (maybe to the login page if the site has any logout CSRF issues).

* The user is slightly confused, but they were just on the trusted site, so it doesn't feel too strange.

* If the user is super savvy, the look up at the URL bar and are assured that they actually are back in the trusted site (possibly staring at a login prompt).

* the attacker has a reference to the window they opened back to the trusted site. They set a timer for a couple seconds (like the attack I referenced above). After a few seconds they change the trusted site to load a malicious site and/or malicious data URL.

* user "logs in to the trusted site" and gives up their creds.

Re: http://lcamtuf.coredump.cx/switch/, couldn't browsers simply do a better job of showing the address when window.location.href is 'data:text/html;-peak.us/banking_interface/' or any other data URL?

Re: malicious sites linking back to a parent that opened the, could browsers not also disable cross-origin .opener?

Sure...but that is another thing that needs to be added to all browsers; it begins to feel like a game of whack-a-mole. In the end, browsers rely on an admittedly fragile premise...the only thing that guarantees your current location is a persistent awareness of what domain you are on. Most of the time that works for savvy users (normal users have no fighting chance/nor should they be expected to have to do this). But, these various edge cases break the reasonable expectation that the domain I'm on will stay the domain I'm on until I explicitly do something.

In my opinion, the better place for a more holistic fix to this is within Conntent Security Policy. That could, theoretically, address all attacks that somehow obtain a window ref. The CSP policy could say "window-ref: 'none'". That would be a declarative policy that the browser could enforce in any situation where a window ref might be available.

Another benefit of implementing it in CSP is that you could retroactively fix existing sites without having to go back and fix up potentially thousands of links that didn't set the attribute mentioned in this article.

Of course it's whack a mole. Moat things in infosec are, that doesn't mean browsers shouldn't ship with secure defaults or present trustworthy info in the address bar.

Agreed CSP would be a good place to fix.

This game off whack-a-mole feels different. Unlike the typical "memory corruption of the week", this kind of stuff isn't fixed by a simple browser update and inherited "for free" by all sites. And, this kind of fix doesn't enable a browser to ship with a secure default. Instead, it adds a new thing you have to opt into and retroactively add to all existing links on your site. That is a fair bit of work, and adding more and more of those kinds of features for nominal gain is a tough sell. That is a much more painful game of whack-a-mole and isn't an approach that scales well. The CSP solution at least has a potentially simpler scaling solution to the problem.

> this kind of stuff isn't fixed by a simple browser update and inherited "for free" by all sites

Why not? What's stopping browser from disabling window.opener unless CSP specifically allows it?

(totally appreciate there may be something I'm missing here, and thanks for responding)

Unless we are talking about something terribly dire (arbitrary code execution) browser vendors are super unlikely to change behavior that has existed, and potentially relied upon, for many years. The bar for changing existing behavior is extremely high and this kind of attack won't come anywhere near meeting it. So, the only realistic solution is something that a site opts into (or out of depending on your perspective). CSP would at least let the site that is a potential victim protect itself. And, if there was a good reason to let a partner site have window ref (I could imagine something related to payment providers and modal pop up payment flows), they could opt in to that. It would look something like.

window-ref 'self' PayPal.com

Something like that would let the site reference their own windows as well as grant access to a "trusted partner" like PayPal.

Browser vendors do 'phase out' old behavior and phase in new ones. I understand "don't break the web", but as someone else famously replied, "the web is a self healing mechanism". Look at what browsers have done re: forms submitted over HTTP.

A maintained site that relies on window.opener should, after a 24 month period of angry console warnings saying a change needs to be made, actually make that change.

Reply on news.ycombinator.com