Re: [whatwg/fetch] From-Origin (#687)

I've been following this thread while on vacation and didn't have time to comment until now, but this is an  important problem that I also feel strongly about solving (thank you @johnwilander for starting this discussion!). Since there are a lot of ideas here, I wanted to summarize the discussion as I understand it, and compare the benefits of the proposals that came up.

As background, in the past we've thought a fair amount about protecting applications from cross-origin information leaks -- allowing developers to prevent their applications' endpoints from being loaded as subresources of an attacker-controlled document goes far beyond protecting the exploitation of Spectre-like bugs, and can address a large number of cross-origin attacks we've seen over the past decade. 

Specifically, having the browser refuse to load protected resources in the context of the attacker's origin/process, could help solve the following classes of issues: [cross-site script inclusion](https://www.owasp.org/images/f/f3/Your_Script_in_My_Page_What_Could_Possibly_Go_Wrong_-_Sebastian_Lekies%2BBen_Stock.pdf) (XSSI), [cross-site search](https://www.owasp.org/images/a/a7/AppSecIL2015_Cross-Site-Search-Attacks_HemiLeibowitz.pdf), [CSS-based exfiltration](https://scarybeastsecurity.blogspot.ch/2009/12/generic-cross-browser-cross-domain.html), as well as Spectre. Telling the server about the requester's origin as Mike suggested above would also give developers the chance to prevent most kinds of attacks based on [cross-origin timings](https://securitee.org/files/timing-attacks_ccs2015.pdf) and CSRF -- the server could be configured to only accept subresource requests coming from trusted origins.

For completeness, addressing these kinds of issues was part of the motivation for [EPR](https://www.w3.org/TR/epr/) and [Isolate-Me](https://wicg.github.io/isolation/explainer.html), as well as for [same-site cookies](https://tools.ietf.org/html/draft-west-first-party-cookies-07). But these proposals are fairly heavy-weight to implement and adopt, and there is value in having a simpler mechanism to tackle the classes of issues mentioned above.

IIUC the discussion here focused on two main alternatives:
1. The `From-Origin` response header as outlined in Anne's [original proposal](https://www.w3.org/TR/from-origin/) which would prevent the browser from exposing the contents of the response to non-safelisted origins.
2. Adding a request header to subresource requests, which would allow servers to decide what to do with the request depending on its source.

The first option is somewhat simpler and makes the protection more explicit; in some cases, developers might be able to set `From-Origin: same` on all responses and that would be sufficient to protect against Spectre and some cross-origin leaks. The second option requires more work on part of the server (adding logic to decide whether to respond to a request based on its sender), but it's more flexible and more powerful because it can also protect against CSRF and timing attacks, though with some caveats.

As a data point from someone who works with a large number of non-trivial applications, I feel that it might be somewhat easier to adopt this if we go with option 2, possibly with a new request header, e.g. `Sec-Requesting-Origin` -- we might not be able to reuse `Origin` because of backwards compatibility issues, though I'm not 100% sure about this. On the server side, the logic would boil down to checking if the header is present in the request, and if so, rejecting requests if the requesting origin isn't trusted (if there is no header, or the origin is trusted, return the response as usual).

If browsers were to consistently set this header, developers could start by collecting data about origins which are already requesting authenticated resources from their application by collecting header values, and then turn on enforcement by returning empty responses if the requesting origin isn't trusted. This could also work even if there is a Referrer Policy of `no-referrer` if we make the user-agent send a special identifier to include some coarse-grained information about the source (e.g. `same-origin`, `same-site` or `cross-site` as Mike suggested above). If we're worried about the number of bytes on the wire this would add to requests, it could be require an opt-in via an Origin Manifest or a header-based mechanisms similar to HSTS. Finally, we could also consider having a special way to annotate navigational requests to protect against the exploitation of CSRF via top-level navigations.

I think this would be powerful enough to allow application developers to protect from Spectre, especially if combined with default protections via [CORB](https://github.com/whatwg/fetch/issues/681), and would simultaneously allow developers to protect against other cross-origin leaks. `From-Origin` as originally described in Anne's doc seems workable as well, but is a little more constrained -- perhaps there really is value in doing both things?

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