First-Party-Only cookies

[Mark Goodwin]

As you know, Mike West has been poking around at First-Party-Cookies (
https://tools.ietf.org/html/draft-west-first-party-cookies-04). My main
reservation with his version of this idea is the relaxation of the rules
for 'safe' HTTP methods.

It turns out, others share my views on this. Because of this, Mike's open
to persuasion - that said, removing the safe methods exception makes
implementation harder for some sites (github have been playing with
First-Party-Only cookies for a while and like Mike's currently specified
semantics).

My questions: What are your opinions on the relative merits of the stricter
/ more relaxed variants of this proposal? What are your opinions in
providing both mechanisms via an option?

Thanks

[Martin Thomson]

On Wed, Jan 20, 2016 at 3:45 AM, Mark Goodwin <mgoo...@mozilla.com> wrote:
> My questions: What are your opinions on the relative merits of the stricter
> / more relaxed variants of this proposal? What are your opinions in
> providing both mechanisms via an option?

It would be good to know specifically what scenario caused the
exception to be created. On face value, I agree with you: the
exception doesn't seem to belong. GET might be unique in the sense
that it is heavily used, but from the perspective of how credentials
are used and the damage that might be caused, a complete separation is
cleaner. More so, the exception is surprising.

[Tanvi Vyas]

I believe the intention here is to prevent sites that use safe methods
for state changing actions from depending on the First-Party-Only flag
for CSRF protection. In that case, the attacker could still attack the
victim by doing a top level load of the state changing GET in a
background tab. This will send the First-Party-Only cookie along with
the request. If a site (like github) only uses unsafe methods for state
changing actions, the First-Party-Only is sufficient CSRF protection
(and it's a lot easier to use and understand than CSRF tokens!).

If we remove the restriction, developers may start using
First-Party-Only for CSRF protection without realizing it isn't going to
work for their site. The attacker would just have to do a little extra
work to make their exploit work. Perhaps we could mitigate this risk
with good documentation.

> _______________________________________________
> dev-security mailing list
> dev-se...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security

[Martin Thomson]

Any site that relies on this for CSRF protection is going to be sad
given that no browser currently respects it. The flag only provides
protection once a browser supports it (and that will never be 100%).
In support of other mechanisms (defense in depth), I get it, but this
will never be a primary defense mechanism.

Besides, sites shouldn't be using safe methods to change state. I
know that that is often convenient, but don't we provide plenty of
better alternatives already?

[Anne van Kesteren]

On Tue, Jan 19, 2016 at 5:45 PM, Mark Goodwin <mgoo...@mozilla.com> wrote:
> My questions: What are your opinions on the relative merits of the stricter
> / more relaxed variants of this proposal? What are your opinions in
> providing both mechanisms via an option?

Apart from this, https://github.com/mikewest/internetdrafts/issues/3
seems like a more fundamental problem I still haven't heard a good
story for.


--
https://annevankesteren.nl/

[Mark Goodwin]

On Wed, Jan 20, 2016 at 1:53 AM, Tanvi Vyas <ta...@mozilla.com> wrote:

> I believe the intention here is to prevent sites that use safe methods for
> state changing actions from depending on the First-Party-Only flag for CSRF
> protection. In that case, the attacker could still attack the victim by
> doing a top level load of the state changing GET in a background tab. This
> will send the First-Party-Only cookie along with the request.
>

Actually, no. I agree the spec isn't explicit enough in this (we should
make it clearer). The opened document will be a new first-party context -
but the request to fetch that document wouldn't itself have the cookie. So
for this to be an issue we'd need an XSS to forge the request - in which
case it's game over anyway

[Mark Goodwin]

On Wed, Jan 20, 2016 at 2:46 AM, Martin Thomson <m...@mozilla.com> wrote:

> Besides, sites shouldn't be using safe methods to change state. I
> know that that is often convenient, but don't we provide plenty of
> better alternatives already?
>

Yes. But it's frighteningly common (particularly in older applications) to
see things like:

doGet(request, response) {
doPost(request, response);
}

(or vice versa)

[Mike West]

Thanks for starting this thread, Mark. I'll reply to some of the questions
inline, but I'll first note that I'm working on an -05 draft which might be
helpful in terms of clarifying the mechanism under consideration at
https://mikewest.github.io/internetdrafts/first-party-cookies/draft-west-first-party-cookies-05.html.
That should make the Fetch story clearer, and hopefully address Anne's
question about workers (it also renames the feature to "SameSite", for
reasons that aren't worth getting into here).

Broadly, the "safe" top-level navigation carveout is meant to deal with the
confusion that might otherwise result from an auth cookie not being present
for a request. Since GitHub is the only implementation I know of, let's use
them as an example: it would be confusing if I clicked on a link to a
private repository in an email, navigated to GitHub.com, and got a 403
error telling me I wasn't logged in. Likewise, it would be strange if I
popped up a window as part of a "Sign in with GitHub" OAuth dance and had
to sign in every time.

They certainly _could_ rewrite their session management system to deal with
multiple cookies granting different levels of access (just as Amazon
requires reauth to actually buy things), but based on some conversations,
they're more likely to simply not use the feature than to undertake that
rewrite.

At the moment, I'm thinking that it might be reasonable to have the
carveout as an option; `SameSite=Lax` or something. I've been reluctant to
do so, as I'm not sure the extra complexity is worth it, but if folks like
GitHub wouldn't use the strict form of the feature, then such an option
starts sounding more reasonable.

On Wed, Jan 20, 2016 at 2:53 AM, Tanvi Vyas <ta...@mozilla.com> wrote:

> I believe the intention here is to prevent sites that use safe methods for
> state changing actions from depending on the First-Party-Only flag for CSRF
> protection.

For clarity, this isn't the intention of the carveout. The spec plainly
states that this feature constitutes defense in depth, on top of a already
robust CSRF protection. If we decide, however, that the carveout should be
removed (optionally), then I certainly wouldn't block that decision based
on the fact that some developers might mistakenly rely on it too heavily.
We should give developers sharp tools. *shrug*

-mike

[Martin Thomson]

Wouldn't it be possible to use the first-party cookie in those cases
at the cost of one extra request?

The third-party initiated, top-level load would have no first-party
cookies, but that page could initiate a new request to check
credentials, which would have the first-party cookie.

It's a little extra latency, but it would seem to retain the
properties we're looking for. For simplicity, a same-origin redirect
might be permitted to gain access to first-party cookies.

[Mike West]

On Wed, Jan 20, 2016 at 11:30 PM, Martin Thomson <m...@mozilla.com> wrote:

> Wouldn't it be possible to use the first-party cookie in those cases
> at the cost of one extra request?
>

Sure. That seems like a large cost, but it's certainly one we could ask
folks to pay.

> The third-party initiated, top-level load would have no first-party
> cookies, but that page could initiate a new request to check
> credentials, which would have the first-party cookie.
>

How would you know when to do this? You'd have to do it for basically every
incoming request, right?

> It's a little extra latency, but it would seem to retain the
> properties we're looking for.

For some value of "little" that might not actually be little.

> For simplicity, a same-origin redirect
> might be permitted to gain access to first-party cookies.
>

My suspicion is that the general flow would be something like this:

* User gets an email with a link to `github.com/sekrit/project/pull/1`
* User clicks on the link.
* GitHub returns a 404 because it doesn't want to leak the fact that the
project exists to folks who shouldn't be able to see it.
* User is sad.

Your suggestion is that the 404 page could be a 302 instead? To itself?

-mike

[Martin Thomson]

Hmm, it's tricky, I agree. If the goal is to prevent side-effects
from top-level loads being exploited, then that where things end up.
Unless you want to specially privilege top-level loads. You might be
able to do that automatically for URLs that are provided to the
browser from other applications, or from the URL bar, but that doesn't
help webmail much.

An option might be to have the 404 page have all the (public) script
content for the type of page and to fetch() in any privileged content
(and get 404s on those fetches). That would result in a round trip
worth of delay for those loads. More complicated to implement,
granted.

The self-redirect in absence of cookies is easier to implement, but
fairly clunky. You would have to set a short-term (first-party)
cookie to avoid looping too.

I'm not enamoured with the idea, but it's not like sites aren't opting
in to this sort of complexity by tagging their cookies as same-site (I
should stop saying first-party now, right?)

[jwa...@mozilla.com]

I'd like to see better browser support for preventing CSRF. I think it's still hard to solve properly in some cases [1].

And I think it's overly pessimistic to discount First-Party-Only / SameSite as never providing primary defense against CSRF.

Maybe support will never reach 100% in an absolute sense, but would argue that it will get close enough that it's no longer a viable attack vector for many use cases, in a few years.

Having a 'read-cookie' (without SameSite) and a 'write-cookie' (with strict SameSite) feels like it's not too hard to document?

Joe.

[1]: Example - I was looking at CSRF protection in a Node site that used Socket.io recently. The expressjs csurf middleware doesn't work for the XHR fallback case, so to be safe, I think you have to handle csrf tokens manually for socket connections.

[Mike West]

On Fri, Jan 22, 2016 at 12:43 AM, Martin Thomson <m...@mozilla.com> wrote:

> Hmm, it's tricky, I agree. If the goal is to prevent side-effects
> from top-level loads being exploited, then that where things end up.
>

For the developers I've explicitly talked to, POSTs have been the problem
and they're happy to have a GET carveout.

> Unless you want to specially privilege top-level loads. You might be
> able to do that automatically for URLs that are provided to the
> browser from other applications, or from the URL bar, but that doesn't
> help webmail much.
>

Yeah, I've made that explicit in the current draft: address bar typings are
"same-site".

An option might be to have the 404 page have all the (public) script
> content for the type of page and to fetch() in any privileged content
> (and get 404s on those fetches). That would result in a round trip
> worth of delay for those loads. More complicated to implement,
> granted.
>
> The self-redirect in absence of cookies is easier to implement, but
> fairly clunky. You would have to set a short-term (first-party)
> cookie to avoid looping too.
>
> I'm not enamoured with the idea, but it's not like sites aren't opting
> in to this sort of complexity by tagging their cookies as same-site (I
> should stop saying first-party now, right?)
>

The nice thing about the current definition is that it can easily layer on
top of existing session management systems. That is, folks like GitHub can
add `SameSite` to their session cookie, and basically everything just works
(or, just worked, a year ago when they were experimenting with me).

Excluding GET would make that more difficult, but would certainly improve
security. That's basically why I'm now leaning towards something like
`SameSite=Lax`, which would allow a stepwise improvement in CSRF protection
over time.

-mike

[Martin Thomson]

On Sat, Jan 23, 2016 at 1:33 AM, Mike West <mk...@google.com> wrote:
> Excluding GET would make that more difficult, but would certainly improve
> security. That's basically why I'm now leaning towards something like
> `SameSite=Lax`, which would allow a stepwise improvement in CSRF protection
> over time.

I can tolerate that.

While the patient is on the table, why not define both labels.
SameSite=Unsafe/All perhaps?

[Mike West]

Sure. I ran with "Strict"/"Lax" as they made the most sense to me (and
because "Unsafe" in this context seems wrong: `SameSite=Unsafe` is _safer_
than not having the attribute at all).

Details in the -06 draft at
https://tools.ietf.org/html/draft-west-first-party-cookies-06. Feedback
ever so welcome (especially feedback that went to the HTTP WG, as mnot@, et
al. have noted that there's not much support for this proposal from folks
other than me. :) ).

-mike