- From: Jake Archibald <notifications@github.com>
- Date: Mon, 27 Jul 2015 07:51:42 -0700
- To: whatwg/fetch <fetch@noreply.github.com>
- Message-ID: <whatwg/fetch/issues/79/125233940@github.com>
The attack demo isn't working (not https) so here's what I think the attack is, if I'm wrong, the rest of my post is nonsense. * Good site's SW will serve from cache if it can * Good site's SW will cache content it gets from the network, for a set of urls which includes an anywhere-redirect * Good site allows users to create a CORS request to the anywhere-redirect (via fetch/xhr indirectly, `<img crossorigin>` etc) * Evil player can use this to get their evil-site content cached against a good-site request * Navigating to this url will cause the evil-site content to be served as a response on the good-site origin If this response contains script, it's running on the good-site origin. If that's the attack, I don't see how a "this came from a redirect" bit can help, as this information is already in `response.url`, except in the case of opaque responses. That wouldn't work for navigations, although it would work for `<script>`. This would only be a problem if the good-site had a `<script src>` pointing to the global redirect that was pointing to the evil-site, so security would be broken without SW. Disallowing cross-origin CORS responses in response to "same-origin" navigation requests would help mitigate the navigation case. @annevk - we were trying to think of why we might need this restriction. Another possibility (although I'm not sure we need it) is a redirect mode of "follow-same-origin". --- Reply to this email directly or view it on GitHub: https://github.com/whatwg/fetch/issues/79#issuecomment-125233940
Received on Monday, 27 July 2015 14:52:11 UTC