4 ms·

> 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 i

> 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.

nailer 10y ago
I'd be interested in knowing the others. So would I imagine most people reading that page.
- ptoomey3 10y ago
  I mentioned this on another related thread: https://news.ycombinator.com/item?id=11554080 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/ 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.
  - nailer 10y ago
    Re: http://lcamtuf.coredump.cx/switch/ 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?
    - ptoomey3 10y ago
      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.
      - ptoomey3 10y ago
        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.
      - nailer 10y ago
        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.
        ptoomey3 10y ago

nailer 10y ago

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

ptoomey3 10y ago
I mentioned this on another related thread: https://news.ycombinator.com/item?id=11554080 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/ 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.
- nailer 10y ago
  Re: http://lcamtuf.coredump.cx/switch/ 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?
  - ptoomey3 10y ago
    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.
    - ptoomey3 10y ago
      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.
    - nailer 10y ago
      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.
      - ptoomey3 10y ago