Re: A primer on cross-origin information leaks

On Thu, May 17, 2018 at 7:47 PM John Wilander <wilander@apple.com> wrote:

> Thanks for the writeup!
>

Thanks, John! See comments inline.


> Three things that I think we need to add:
>
>    1. 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.

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. This also solves the problem for X-F-O because developers can
instead set CSP with frame-ancestors *.example.org.
- 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. 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.

There are also some other, specific differences: SameSite cookies don't
distinguish same-site vs. same-origin requests, 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/ Available in 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
>
>    Regards, John
>