First-Party-Only cookies

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

First-Party-Only cookies

Mark Goodwin-4
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
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: First-Party-Only cookies

Martin Thomson
On Wed, Jan 20, 2016 at 3:45 AM, Mark Goodwin <[hidden email]> 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.
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: First-Party-Only cookies

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.


On 1/19/16 3:00 PM, Martin Thomson wrote:

> On Wed, Jan 20, 2016 at 3:45 AM, Mark Goodwin <[hidden email]> 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.
> _______________________________________________
> dev-security mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-security

_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: First-Party-Only cookies

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?


On Wed, Jan 20, 2016 at 12:53 PM, Tanvi Vyas <[hidden email]> 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.  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.
>
>
> On 1/19/16 3:00 PM, Martin Thomson wrote:
>
> On Wed, Jan 20, 2016 at 3:45 AM, Mark Goodwin <[hidden email]> 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.
> _______________________________________________
> dev-security mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-security
>
>
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: First-Party-Only cookies

Anne van Kesteren
In reply to this post by Mark Goodwin-4
On Tue, Jan 19, 2016 at 5:45 PM, Mark Goodwin <[hidden email]> 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/
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: First-Party-Only cookies

Mark Goodwin-4
In reply to this post by Tanvi Vyas
On Wed, Jan 20, 2016 at 1:53 AM, Tanvi Vyas <[hidden email]> 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
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: First-Party-Only cookies

Mark Goodwin-4
In reply to this post by Martin Thomson
On Wed, Jan 20, 2016 at 2:46 AM, Martin Thomson <[hidden email]> 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)
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: First-Party-Only cookies

Mike West
In reply to this post by Tanvi Vyas
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 <[hidden email]> 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
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: First-Party-Only cookies

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.

On Wed, Jan 20, 2016 at 10:59 PM, Mike West <[hidden email]> wrote:

> 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 <[hidden email]> 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
>
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: First-Party-Only cookies

Mike West
On Wed, Jan 20, 2016 at 11:30 PM, Martin Thomson <[hidden email]> 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
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

First-Party-Only Traffic WAS: Re: First-Party-Only cookies

Kevin Chadwick
I apologise upfront as I haven't looked into the RFC properly at all.

I wonder if this idea could be extended so that I can instruct client
side that all traffic should originate from the primary domain?

Or is that pointless as TLS *should* guarantee this anyway. I guess it
could be stripped from plain text but wonder if it would still be of any
use?

Thinking about it that already exists as the content origin policy
directive, correct?

--

KISSIS - Keep It Simple So It's Securable
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: First-Party-Only cookies

Martin Thomson
In reply to this post by Mike West
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?)



On Thu, Jan 21, 2016 at 8:14 PM, Mike West <[hidden email]> wrote:

> On Wed, Jan 20, 2016 at 11:30 PM, Martin Thomson <[hidden email]> 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
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: First-Party-Only cookies

jwalker
In reply to this post by Tanvi Vyas

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.


On Wednesday, January 20, 2016 at 12:01:13 PM UTC, Mike West wrote:

> 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 <[hidden email]> 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

_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: First-Party-Only Traffic WAS: Re: First-Party-Only cookies

Mike West
In reply to this post by Kevin Chadwick
It's not entirely clear to me what you're asking for, but Entry Point
Regulation might or might not be along the lines of what you're proposing:
https://w3c.github.io/webappsec-epr/

-mike

-mike

On Thu, Jan 21, 2016 at 5:07 PM, Kevin Chadwick <[hidden email]> wrote:

> I apologise upfront as I haven't looked into the RFC properly at all.
>
> I wonder if this idea could be extended so that I can instruct client
> side that all traffic should originate from the primary domain?
>
> Or is that pointless as TLS *should* guarantee this anyway. I guess it
> could be stripped from plain text but wonder if it would still be of any
> use?
>
> Thinking about it that already exists as the content origin policy
> directive, correct?
>
> --
>
> KISSIS - Keep It Simple So It's Securable
> _______________________________________________
> dev-security mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-security
>
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: First-Party-Only cookies

Mike West
In reply to this post by Martin Thomson
On Fri, Jan 22, 2016 at 12:43 AM, Martin Thomson <[hidden email]> 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
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: First-Party-Only cookies

Martin Thomson
On Sat, Jan 23, 2016 at 1:33 AM, Mike West <[hidden email]> 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?
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: First-Party-Only cookies

Mike West
On Sun, Jan 24, 2016 at 2:49 AM, Martin Thomson <[hidden email]> wrote:

> On Sat, Jan 23, 2016 at 1:33 AM, Mike West <[hidden email]> 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?
>

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
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security