Re: [fetch] Add a bit to Opaque Responses to distinguish redirects (#79)

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