Re: A primer on cross-origin information leaks

On Tue, May 22, 2018 at 7:09 AM Mike West <mkwst@google.com> wrote:

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

The mixed content concern makes sense, but I'd be similarly worried about
applications using From-Origin: same-site not having any protections
against the attacks we're talking about when users are on an unsafe/public
network. In practice, because of cacheability, it would be enough for the
user to connect to such a network once and the attacker could later use
injected HTTP frames from any victim subdomain to conduct the attack;
preventing this would require setting HSTS with includeSubDomains, and
that's still fairly difficult to pull off.

I expect that making a global decision about the semantics of same-site
would be hard, but we could sidestep this problem by giving developers a
more flexible whitelisting mechanism. "From-Origin: https://*.example.org"
vs. "From-Origin http://*.example.org https://*.example.org" seems quite
easy to reason about.


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

I think there might be a way to make cookie prefixes work here. Another
option for developers would be to cryptographically tie the value of the
isSameSite cookie to the authentication cookie, so that it can't be forged
(Google does this for its HttpOnly and Secure cookies) -- but that takes a
fair amount of work.

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

Sorry, I wasn't precise -- I meant that requests from
cross-origin-but-same-site windows will cause a SameSite cookie to be sent,
so applications will still be open to attacks from code in neighboring
subdomains.

Overall, the idea behind SameSite cookies is great, but their behavior does
make them difficult to deploy (for example, even the relatively small quirk
of only being sent if the top-level browsing context is same-site means
that developers can't protect any resources loaded from *any* document
which can be loaded in a cross-origin frame). Sec-Metadata iterates on this
concept in a way that addresses the main adoption difficulties (by giving
developers more flexibility to make security decisions without requiring
large infrastructure changes), and the security concerns (by providing more
information about the context of the request, e.g. same-origin vs.
same-site requests, whether the request is a result of a navigation or
resource load, etc.)

Cheers,
-Artur