3 ms·

Google considers (1) it unfixable: "Unfortunately, we believe that this class of attacks is inherent to the current design of web browsers and can't be meaning

by rdslw 9y ago

Google considers (1) it unfixable: "Unfortunately, we believe that this class of attacks is inherent to the current design of web browsers and can't be meaningfully mitigated by any single website; in particular, clobbering the window.opener property limits one of the vectors, but still makes it easy to exploit the remaining ones." (1) https://sites.google.com/site/bughunteruniversity/nonvuln/phishing-with-window-opener https://sites.google.com/site/bughunteruniversity/nonvuln/ph...

fniephaus 9y ago
Lighthouse Audit - Opens External Anchors Using rel="noopener": https://developers.google.com/web/tools/lighthouse/audits/noopener https://developers.google.com/web/tools/lighthouse/audits/no...
- madeofpalk 9y ago
  The 'popular' eslint-plugin-react can also make this a lint error https://github.com/yannickcr/eslint-plugin-react/blob/master/docs/rules/jsx-no-target-blank.md https://github.com/yannickcr/eslint-plugin-react/blob/master...
Matheus28 9y ago
Couldn't `window.opener` be opt-in instead of opt-out? It would break some websites, but I have no idea how many...
jorangreef 9y ago
What are the remaining vectors which would need to be mitigated? The Google article does not mention any details?
- parenthephobia 9y ago
  One is that if you open a window, you can change the URL that's loaded later. In the example that Google's page links to they change it to a data: URI - which no longer works in Chrome - but they could just as easily change it from http://good.com/ http://good.com/ to http://evil.com/ http://evil.com/ - which would still work in Chrome - and hope you don't notice.
  - Ajedi32 9y ago
    But how can they do that without access to `window.opener`?
    - parenthephobia 9y ago
      In the example, a nefarious page opens a new window and then uses its connection to that opened window - the window object is returned from "window.open()" - to manipulate it. No window.opener required, and the two windows don't even need to be in the same website for this to work. Google's page isn't just about abusing "window.opener", it's generally about abusing JavaScript-accessible connections between windows/tabs. Additionally, the site it's in isn't about browser bugs, but bugs in Google's websites. Google knows these issues are fixable, but they consider them to be flaws in browsers rather than in their websites. That's why Google says it's still easy to exploit the other vectors for the attack. A website can protect itself by clearing "window.opener", but similar attacks are possible that a website can't prevent. e.g. A window can't prevent the window that opened it from later forcing it to navigate to a different URL.
deleted 9y ago
[deleted]
parenthephobia 9y ago
Whilst they might not consider it fixable, that doesn't mean they're not going to do the best they can! Chrome does support rel=noopener, _and_ the "fairly good demonstration" that page links to doesn't work in Chrome any more. https://caniuse.com/#search=noopener https://caniuse.com/#search=noopener

by rdslw 9y ago

fniephaus 9y ago

Lighthouse Audit - Opens External Anchors Using rel="noopener": https://developers.google.com/web/tools/lighthouse/audits/noopener https://developers.google.com/web/tools/lighthouse/audits/no...

madeofpalk 9y ago
The 'popular' eslint-plugin-react can also make this a lint error https://github.com/yannickcr/eslint-plugin-react/blob/master/docs/rules/jsx-no-target-blank.md https://github.com/yannickcr/eslint-plugin-react/blob/master...

Matheus28 9y ago

Couldn't `window.opener` be opt-in instead of opt-out? It would break some websites, but I have no idea how many...

jorangreef 9y ago

What are the remaining vectors which would need to be mitigated? The Google article does not mention any details?

parenthephobia 9y ago
One is that if you open a window, you can change the URL that's loaded later. In the example that Google's page links to they change it to a data: URI - which no longer works in Chrome - but they could just as easily change it from http://good.com/ http://good.com/ to http://evil.com/ http://evil.com/ - which would still work in Chrome - and hope you don't notice.
- Ajedi32 9y ago
  But how can they do that without access to `window.opener`?
  - parenthephobia 9y ago
    In the example, a nefarious page opens a new window and then uses its connection to that opened window - the window object is returned from "window.open()" - to manipulate it. No window.opener required, and the two windows don't even need to be in the same website for this to work. Google's page isn't just about abusing "window.opener", it's generally about abusing JavaScript-accessible connections between windows/tabs. Additionally, the site it's in isn't about browser bugs, but bugs in Google's websites. Google knows these issues are fixable, but they consider them to be flaws in browsers rather than in their websites. That's why Google says it's still easy to exploit the other vectors for the attack. A website can protect itself by clearing "window.opener", but similar attacks are possible that a website can't prevent. e.g. A window can't prevent the window that opened it from later forcing it to navigate to a different URL.

deleted 9y ago

[deleted]

parenthephobia 9y ago

Whilst they might not consider it fixable, that doesn't mean they're not going to do the best they can! Chrome does support rel=noopener, _and_ the "fairly good demonstration" that page links to doesn't work in Chrome any more. https://caniuse.com/#search=noopener https://caniuse.com/#search=noopener