Re: A primer on cross-origin information leaks

On Mon, May 21, 2018 at 10:32 PM John Wilander <wilander@apple.com> wrote:

> 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.
>
> On the narrow point of John's #3 above, I agree that if we're going to
embrace "site" as a security boundary (and define it as Chromium does
<https://www.chromium.org/developers/design-documents/site-isolation#TOC-Threat-Model>,
as scheme+registrable domain), then we should do so wholeheartedly, across
a number of mechanisms. Introducing a `'same-site'` keyword to CSP could
ease adoption just as the `'self'` keyword does, and is a reasonable thing
to consider adding. XFO's `SAMEORIGIN` is already `same-site` in practice,
and I'm not sure it makes sense to add `REALLY-SAMEORIGIN` or similar.

I'll note in passing that I'm a bit uncomfortable about this. Chromium
landed on its current definition of "site" because of cookies and
`document.domain`, which relax the same-origin policy in exciting ways. I
don't think we'd introduce either in their current form today if they
didn't already exist, and I worry a bit about past decisions
overdetermining our present path. Of course, we've started down that path
already with `SameSite` cookies, and though that's somewhat more defensible
as an explicit contraction of an already bad feature, perhaps its enough to
push us solidly over the edge. :)

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

I think you're positing here that the bank is serving its pages over HTTPS,
and serving its images over HTTP? You're correct to note that in that case
including the scheme in the "site" definition would cause
otherwise-embeddable images from non-secure endpoints to be blocked. I'm
not convinced that that's a bad place to create pressure on developers.
Broadly, I don't think it's possible to create security guarantees for
resources that aren't delivered over secure channels. I don't think it's
useful to pretend that we can. I'd prefer to try a scheme-including variant
for new features that don't have existing deployment concerns. We can
always relax things later, but tightening them retroactively is painful.

> 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.
>
>
> Note that scheme is not inherited for *.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 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.
>

In principle, I think you're correct that Artur's `Sec-Site` proposal and
the `Sec-Metadata` extension don't expose much data about the requestor's
origin that the server couldn't get with existing mechanisms. As you say,
folks could set an `isSameSite` cookie to determine the distinction between
`same-origin`/`same-site` and `cross-site`. I don't think they could
determine the difference between `same-origin` and `same-site` easily,
however: domain cookies would be sent in any case.

One important difference, however, is that cookies are easily malleable,
and the `cookie` header doesn't contain any metadata. The server has no
guarantee that the `isSameSite` cookie is, in fact, a cookie with the
`SameSite` attribute. We could address this to some extent, I suppose, by
adding more cookie prefixes
<https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-02#section-4.1.3>
?

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

Given the note above about the malleability of cookies, I think the only
way to deploy them with guarantees about their provenance and meaning is to
give them a value that can't be forged. That's somewhat difficult to do. An
explicit signal, on the other hand, is quite straightforward to consume,
and doesn't seem to have the same deployment complexity.

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

I don't think so, no. A cookie without a domain attribute will be delivered
only to a specific host, but will be delivered to that host regardless of
the origin from which the request was initiated.

-mike