- From: John Wilander <notifications@github.com>
- Date: Thu, 31 May 2018 13:46:40 -0700
- To: whatwg/fetch <fetch@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/fetch/issues/687/393674179@github.com>
Including scheme or not in `Same-Site` is a tradeoff. Let me explain. Attack target: Authenticated resources on https://bank.example Attack scenarios: 1. The victim is phished and https://phishing.example pulls in https://bank.example resources to spectre them. 2. The victim is logged into https://bank.example and bank.example is neither on the HSTS preload list nor in the HSTS cache. Further, the victim is on an untrusted network and the attacker is in a privileged network position. Last but not least, the victim either loads http://bank.example (types it into the URL bar) or loads http://blog.example and the attacker redirects it to http://bank.example (unlikely that the victim stays there when wanting to go to the blog, but still). The attacker captures the plaintext load of bank.example and responds with a mock of the bank site which pulls in https://bank.example resources to spectre them. In this scenario the attacker already has access to all non-secure cookies and the full UI of the bank. If the victim is willing to use this rogue bank page, it's game over. So we have to assume that the victim doesn't use, maybe doesn't even see the rogue bank page, for spectre to be something the attacker needs to do. I believe this also goes for a cache poison attack where the victim would load the cached, rogue bank page later. If that page is ever used under the assumption that it's real, Spectre is not our main worry. OK, to defend against Spectre attacks, the bank wants to use Cross-Origin-Resource-Policy (formerly From-Origin). If `Cross-Origin-Resource-Policy: Same-Site` ignores scheme, the second attack scenario is still possible whereas if `Cross-Origin-Resource-Policy: Same-Site` does consider scheme, both attack scenarios are covered. However, including scheme makes `Cross-Origin-Resource-Policy: Same-Site` into a passive mixed content blocker. All legacy calls to images from http://*.bank.example will be blocked if the bank's servers always respond with `Cross-Origin-Resource-Policy: Same-Site`. This will make the bank less likely to deploy `Cross-Origin-Resource-Policy` which means _both_ attack scenarios are possible. On intranets, man-in-the-middle attacks are not likely but old crufty http images are. We specifically want `Cross-Origin-Resource-Policy` to be a protection against Spectre attacks from open websites that pull in intranet resources. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/whatwg/fetch/issues/687#issuecomment-393674179
Received on Thursday, 31 May 2018 20:47:03 UTC