Re: A primer on cross-origin information leaks

> On May 21, 2018, at 12:46 PM, Artur Janc <aaj@google.com> wrote:
> 
> On Thu, May 17, 2018 at 7:47 PM John Wilander <wilander@apple.com <mailto:wilander@apple.com>> wrote:
> Thanks for the writeup!
> 
> Thanks, John! See comments inline.
>  
> Three things that I think we need to add:
> A more thorough analysis of ease of adoption. This should include what we think might break, complexity of the technology, data transfer impact, 
> Adoptability is definitely close to my heart because it's the main differentiator between mechanisms with similar security properties, e.g. Sec-Metadata and SameSite cookies (more on that below). I'll write up something about it, though probably separately from the linked doc because this area is less clear-cut and more subjective than the security benefits offered by each mechanism. As it stands, the fairly terse pro/con notes for each feature in the doc summarize some of the major adoption issues that we're familiar with; but we should really discuss this in more detail (while also keeping in mind the security properties of the proposals).
> 
> and how the technology interacts with existing cross-origin controls. For example, what should happen if a response contains conflicting CORS, XFO, and From-Origin directives?
> 
> My guess is that each should have a chance to deny the load *if* the load falls under its scope, and they should ideally be checked in some well-defined order. Note that for various reasons it may be better to reduce the overlap between them and e.g. have From-Origin apply only to resources (and not frames), but that's a detail we should probably discuss on GitHub.
>  
> 2. Privacy impact. The more meta data we send to servers, the more they know about the user.
> 
> I feel strongly about this as well -- it would be ironic if mechanisms to protect users' security by preventing cross-origin attacks resulted in exposing sensitive information about the user. However, from what I've seen so far, the proposals seem to be cognizant of this problem and tread lightly in that regard. For example in Sec-Metadata -- which, predictably, intends to provide the server with information about the context of the request -- the values are generally either limited to a small number of enums (e.g. if a request is a {resource load, top-level navigation, framed navigation} sent {same-origin, same-site, cross-site}), or map to data already present in the request, such as the Accept or Origin header.
> 
> We should carefully review the privacy characteristics for each proposal, but I'm fairly confident that all these mechanisms can be implemented in a way that doesn't provide servers with any interesting new data about users.
> 
> 3. Adding the concept of Same-Site (eTLD+1, potentially scheme+eTLD+1) to all of these origin controls. I believe adoption will be easier if developers can deploy CSP, XFO, From-Origin, and Cross-Origin-Options with Same-Site.
> 
> There are some important benefits to defining same-site = scheme+eTLD+1 (otherwise using it would open up HTTPS application to attacks by local attackers and MitM who could forge HTTP responses from the attacked domain); a convenience mechanism to express this relationship wouldn't hurt.

I worry about same-site causing unintentional mixed content blocking. Say we encourage banks to adopt From-Origin: same-site and they want to take the easy path and apply it to all responses. If same-site enforces scheme, any legacy http image loads will fail and the bank may opt out.

> One thing to note, though, is that not having this concept in the specs you mentioned isn't a huge problem for most of them:
> - CSP supports wildcards so developers can define whitelists of *.example.org <http://example.org/>. This also solves the problem for X-F-O because developers can instead set CSP with frame-ancestors *.example.org <http://example.org/>.

Note that scheme is not inherited for *.example.org <http://example.org/>, so that notion of "same-site" is just eTLD+1.

The wildcard notation differs in meaning across specs. In the case of wildcard certs I believe an asterisk only matches one segment, i.e. *.example.com <http://example.com/> only matches a single subdomain, not subdomains of subdomains.

I like the same-site concept because:
It’s short and simple.
It never covers more or less than eTLD+1 whereas CSP’s wildcard notation can be eTLD(?), eTLD+1, eTLD+2 etc.
It's aligned with SameSite cookies.

> - Cross-Origin-Options likely doesn't need the concept of same-site, because direct DOM interactions from non-same-origin-but-same-site windows are already treated the same as cross-site interactions and disallowed (modulo document.domain weirdness). So I think same-site may not help much there, unless you wanted to make its security model more elaborate, e.g. allow postMessage only from same-site origins.
> - From-Origin could indeed use that concept, but it may be moot if we allow developers to specify a whitelist, similar to what CSP does.
> 
> So given that the backwards-compatibility story when adding this concept to existing mechanisms might get fairly complicated, I'm not entirely sure if adding this would buy us very much.  
> 
> 4. Doesn’t SameSite cookies provide the same information to servers as the Sec-Site {same-origin, same-site, cross-site} request header?
> 
> Sec-Metadata follows the same conceptual model as SameSite cookies, and offers similar security benefits, but its main advantage is that it's more flexible because it can be used on a per-endpoint basis, rather than enforce the "same-site" requirement on the entire application.

How is this different than setting a SameSite cookie isSameSite: 1 and looking for it per endpoint? SameSite cookies don’t have to be authentication cookies. I would even set two cookies isSameSiteLax: 1 and isSameSiteStrict: 1 to provide my servers with maximum visibility.

> The goal is to address some of the deployment difficulties that currently make the cookie-based approach difficult to adopt.
> 
> Specifically, using SameSite cookies for authentication is tricky because it breaks several common application behaviors; for example:
> - If the application has any documents which can be framed cross-origin, then any resource loads from such documents will arrive without cookies (because the top document is not same-site). Making subresource loads unauthenticated breaks a lot of things.
> - Using SameSite cookies in "Strict" mode causes cross-origin top-level navigations to be sent without cookies; this means that if users arrive on any page of the application as a result of following a cross-origin link, they will appear as if they aren't logged in.
> - The application cannot provide any authenticated APIs that respond with JSON/JSONP or use CORS, because cross-origin requests to such endpoints will not carry credentials.

Again, I expect sites to make use of SameSite cookies for increased security and flexibility, not to switch to them completely. SameSite for the “ground truth” on authentication and then more relaxed cookies for cross-site cases.

> There are also some other, specific differences: SameSite cookies don't distinguish same-site vs. same-origin requests,

Can’t you do that by omitting an explicit domain directive, creating a so called host-only cookie?

   Regards, John

> they don't provide information about the destination/initiator of the request or whether the request is a navigation (e.g. top-level vs. framed vs. resource request). But in practice, the critical difference is related to the ease of adoption.
> 
> Cheers,
> -Artur
>  
> Here’s an update on experimental implementations:
> From-Origin (including 35 test cases, not yet upstreamed) https://trac.webkit.org/changeset/230968/webkit/ <https://trac.webkit.org/changeset/230968/webkit/> Available in Safari Technology Preview 56: https://webkit.org/blog/8296/release-notes-for-safari-technology-preview-56/ <https://webkit.org/blog/8296/release-notes-for-safari-technology-preview-56/>
> Cross-Origin-Options (including 7 upstreamed test cases) https://trac.webkit.org/changeset/231622/webkit <https://trac.webkit.org/changeset/231622/webkit>   Regards, John