Why must SameSite=none?

[anderspitman]

I've searched the repo and read through #212 and #248 but I'm still confused about the SameSite=none requirement.

LastLogin currently uses SameSite=lax for all cookies. Changing to none potentially opens up several vulnerabilities that need to be carefully considered. I get some protection from CORS, but there are so many edge cases that things can slip through with "simple requests" etc. I could also add a tiny sentinel cookie set with SameSite=lax and then require both cookies for all endpoints except FedCM, but again that requires me to get it right everywhere, which is dangerous.

Overall, why is this necessary in the first place? It seems like a very intentional decision, but I haven't found a clear explanation yet. As @samuelgoto mentions here it seems to me that FedCM already is secure enough to be trusted sending lax cookies.

[sebadob]

That's a big pain point for me as well and I would actually never deploy something to prod with this setting.

I think the browser should just sent even host only cookies to the IdP in that case and since it's behind the scenes anyway, I don't see an issue with doing that. The other way around, setting SameSite=None is something I would never do these days, as it would be like 3 steps back in terms of security.

[anderspitman]

@samuelgoto any additional info on this?

[samuelgoto]

@samuelgoto any additional info on this?

We are working with our privacy and security reviewers to figure out what we can do about this. Will report back.

[samuelgoto]

We are working with our privacy and security reviewers to figure out what we can do about this. Will report back.

@johannhof I hear that this is working as intended. Can you help us understand why SameSite=None is required and SameSite=Lax wouldn't suffice?

[cbiesinger]

@bvandersloot-mozilla @annevk fyi

[johannhof]

I think I understand your concern and that you consider requests initiated by FedCM to meet a higher bar than "regular" cross-site fetch requests, however, let's look at the available options and their current definitions:

• SameSite=Strict, for same-site requests (which e.g. accounts endpoint is clearly not, as it's triggered in a cross-site context)
• SameSite=Lax, for same-site requests and cross-site top-level navigations (which this is also not)
• SameSite=None

Of course, we can revisit and change things if they don't make sense. This was discussed in #248 and the suggestion back then was to add a SameSite=Federated attribute, which probably doesn't work due to backwards/cross-browser compat issues.

We could consider broadening the definition of SameSite=Lax to cover things like browser-UI triggered requests, but we'd need to make sure that we're not inadvertently opening up an attack surface for anyone. If you were previously using the above definition to protect your endpoints you may be surprised to learn that there's a new cross-site way to trigger SameSite=Lax cookies.

cc @arturjanc for thoughts

[johannhof]

@DCtheTall FYI ^

[anderspitman]

Thanks @johannhof.

I think the problem is that FedCM requests feel like a new thing. Is there any precedent for requests that are sent by the browser but which the origin has no direct control over the method, content, or response (only the URI can be controlled by the RP)?

I can see why you technically consider them to be cross-site requests since they wouldn't be fired without visiting an RP, but do they really fit the description of what we've always considered cross-site on the web up to this point? The term is generally used in conversations involving CSRF security concerns and privacy, and I haven't been able to come up with any scenarios where FedCM requests would introduce a security vulnerability (caveat: I am not a security expert). The endpoints are highly prescribed and the results aren't directly accessible to the RP.

On the flip side, forcing all cookies to be SameSite=none for FedCM introduces real, tangible security issues.

[johannhof]

Yeah, I understand the negative security implications this would cause for IdPs in the mid term (that is, until 3rd party cookies are blocked by default without workarounds in all browsers) and I agree it's not a great outcome.

I'm honestly torn on this issue. I'd love to hear from some of the tagged folks (@arturjanc @annevk @bvandersloot-mozilla) regarding their thoughts on a possible inclusion of FedCM requests in SameSite=Lax rules.

[sebadob]

I think it would make a lot of sense to even be able to set host only cookies, even with __Host-* and have the FedCM send them anyway, even it is is technically cross origin. It would not be a security issue or against any "rules", because the FedCM API operates behind the scenes from inside the browser and not on the user-facing side, and can be trusted.

On the other hand, if we would set host only or samesite cookies, they are restricted to the IdPs domain / host and would not leak anywhere else, even when the FedCM is not used.

[johannhof]

Chatted with @arturjanc about this offline, and the fact that all these endpoints have to be pre-registered by the IdP in a config file makes us think that carving this out as a new instance where SameSite=Lax cookies are sent might be acceptable. I would also be interested in @mikewest's thoughts on that idea.

@sebadob relaxing cross-origin restrictions feels like a fundamentally different suggestion and much less likely to happen, as that is a concern of not leaking additional data to the IdP endpoint (which could also be a risk to that endpoint itself, if there are ways for subdomains to set the cookies it is looking for). This is all very hard to reason about and it's important that we don't pull the rug on security concepts people are relying on.

[sebadob]

@johannhof don't get me wrong, I would never want this to be a global change, only for these specific endpoints where we actually need the cookies during the FedCM flow. Basically like you suggested.

The SameSite attribute is one of the best defenses we have against CSRF attacks. I would never want to give that up just to support some new auth flow, even if it provides a really nice UX, and rather stick to OAuth / OIDC on its own.

[annevk]

I don't understand the discussion about __Host- cookies. That's a syntactic mechanism to enforce a couple of attributes of a cookie. It's unrelated to SameSite and can always be used. Are you suggesting to change the semantics in some way? If so, please explain by way of an example involving the multiple parties. But also, if it's not related to SameSite it should probably be its own issue.

Creating a new avenue for SameSite=Lax exploits makes me rather nervous. I guess to some extent the question here is whether the "speedbumps" for attackers as 6265bis puts it are equivalent.

(Also, you never get protection from CORS. The protection is from the same-origin policy. CORS pokes holes in that.)

[sebadob]

I don't understand the discussion about __Host- cookies. That's a syntactic mechanism to enforce a couple of attributes of a cookie. It's unrelated to SameSite and can always be used. Are you suggesting to change the semantics in some way? If so, please explain by way of an example involving the multiple parties. But also, if it's not related to SameSite it should probably be its own issue.

Sorry the __Host- does not belong here, that's true, my bad.

Edit:

The main question was actually only, why the FedCM wants SameSite=None cookies when Lax should not be an issue.

[anderspitman]

I appreciate the time being taken to seriously consider this concern. Honestly the situation makes me a bit uneasy. Just because it seems safer to relax SameSite=lax than to require SameSite=none doesn't necessarily mean that's the case. My instincts tell me this should be treated as a new thing. The SameSite=federated suggestion should work. But if people who know more about security than me (not a high bar) sign off on SameSite=lax being relaxed, I won't complain.

[bc-pi]

I tend to agree that a SameSite=None requirement for cookies to be sent with requests to both the accounts and identity assertion endpoints will make IDP side implementation of FedCM more cumbersome and/or prone to introducing other vulnerabilities.

My intuition is that the FedCM requests are something fundamentally different and it'd be appropriate/okay/safe to send SameSite=Lax cookies or even ignore the SameSite directive. These FedCM requests are sent to new endpoints as part of interacting with this new API that's intended to facilitate federated identity style functionality in a post 3rd party cookie world. And they'll be sent with a Sec-Fetch-Dest header field. They are definitely not top-level navigation but they aren't typical subresource requests either.

I'd note that the document to which @johannhof previously referred is is currently in Working Group Last Call in the IETF's HTTP WG. Would it be worthwhile to provide feedback about this here issue and try and get a carve-out or allowance of some sort for these unique kinds of requests? Is anyone aware of similar platform originating requests and if or how they are handling similar considerations?

[cbiesinger]

Implementation-wise, Chrome used to send SameSite=Strict cookies as well, however there was strong opposition to that so we ended up with what we do now (SameSite=None only).

[samuelgoto]

Implementation-wise, Chrome used to send SameSite=Strict cookies as well, however there was strong opposition to that so we ended up with what we do now (SameSite=None only).

@cbiesinger would it be equally trivial / easy for Chrome to send SameSite=Lax as well?

[cbiesinger]

Implementation-wise, Chrome used to send SameSite=Strict cookies as well, however there was strong opposition to that so we ended up with what we do now (SameSite=None only).

@cbiesinger would it be equally trivial / easy for Chrome to send SameSite=Lax as well?

I am currently inquiring about that

[sebadob]

Even if we would set these cookies to Lax instead of Strict, I don't see how you would protect your IdP from CSRF attacks when you are just using the FedCM without anything on top.

Because there is no additional token or verification. You receive a cross-origin request, which has not been accepted or whitelisted before (because that would destroy the "sign in without upfront registration"). Then you can only validate the users login / session based on a single cookie, which can be sent from anyone and anywhere because it is not set to Strict.
But this means at the same time, that any javascript code in the internet can make a request to your IdP and will simply receive a token (as long as the user is currently logged in), if it just sets the correct headers, which are no secret.

I mean, if I am missing something here, please correct me, but I don't see how this should work in a secure manner with having either a Strict cookie or at least some additional CSRF protection.

Edit:

SameSite=None would not be an issue, if you configure clients upfront and only allow specific origins on your IdP, but this would not work in a dynamic manner. Please correct me if I am missing something.

[cbiesinger]

But this means at the same time, that any javascript code in the internet can make a request to your IdP and will simply receive a token (as long as the user is currently logged in), if it just sets the correct headers, which are no secret.

The FedCM endpoints in particular, which I think you are talking about (?), can/should verify that the sec-fetch-dest header is set to webidentity to avoid this issue. sec- headers can not be set by JS code.

[bc-pi]

@cbiesinger mentioned this over in #212 but I think it is more relevant to this issue and bears repeating here - the last paragraph in https://fedidcg.github.io/FedCM/#browser-api (copied below because content at github.io isn't necessarily stable) actually contradicts the behavior to only send SameSite=None designated cookies.

2. The Browser API
[...]
For fetches that are sent with cookies, unpartitioned cookies are included, as if the resource was loaded as a same-origin request, e.g. regardless of the SameSite value (which is used when a resource loaded as a third-party, not first-party). This makes it easy for an IDP to adopt the FedCM API. It doesn’t introduce security issues on the API because the RP cannot inspect the results from the fetches in any way.

[bc-pi]

Implementation-wise, Chrome used to send SameSite=Strict cookies as well, however there was strong opposition to that so we ended up with what we do now (SameSite=None only).

Does that imply that the google account cookies are SameSite=None?

[sebadob]

The FedCM endpoints in particular, which I think you are talking about (?), can/should verify that the sec-fetch-dest header is set to webidentity to avoid this issue. sec- headers can not be set by JS code.

Ah yes, of course, totally forgot that you can't modify the Sec-* headers from JS.
Thank you!

[johannhof]

I'd note that the document to which @johannhof previously referred is is currently in Working Group Last Call in the IETF's HTTP WG. Would it be worthwhile to provide feedback about this here issue and try and get a carve-out or allowance of some sort for these unique kinds of requests? Is anyone aware of similar platform originating requests and if or how they are handling similar considerations?

If we agree on the SameSite=Lax idea we should specify it and eventually standardize but it seems a bit premature to encode this in an actual standards document without multi-implementer support. After 6265bis It'll also get easier to just specify this in FedCM and/or Fetch going forward, without going through the RFC, as part of the planned cookie layering changes.

Note that browsers can make this change without requiring standardization, the standard usually follows implementation.

[annevk]

Before we can reach agreement I think someone has do the work on explaining the limited protections that exist around SameSite=Lax today and how this feature doesn't make the situation worse for existing SameSite=Lax cookies.

Also, standardization as a concept very much is inclusive of discussions such as this one so I can't really agree with your statement there.

[bc-pi]

If we agree on the SameSite=Lax idea we should specify it and eventually standardize but it seems a bit premature to encode this in an actual standards document without multi-implementer support.

I was more suggesting (or asking about) making a suggestion to the IETF's HTTP WG for 6265bis to make some acknowledgement that other kinds of requests might exist that fall outside the SameSite enforcement requirements stated therein. Such an acknowledgement or allowance would maybe preempt citing the soonish-to-be RFC as reasoning that FedCM requests (or similar) can only attach Samesite=None designated cookies (which you didn't exactly do in #587 (comment) but kinda sorta did).

After 6265bis It'll also get easier to just specify this in FedCM

AFAICT, it is specified in FedCM #587 (comment) and the behavior in chrome is divergent from that (thanks BTW @aaronpk for the pointer/note in FedCM for IndieAuth).

Note that browsers can make this change without requiring standardization, the standard usually follows implementation.

I am well aware that browsers can do whatever they want. However, I might humbly suggest that the interplay between standards and implementation is much more nuanced than that. Or should be anyway.

[bc-pi]

Before we can reach agreement I think someone has do the work on explaining the limited protections that exist around SameSite=Lax today and how this feature doesn't make the situation worse for existing SameSite=Lax cookies.

As best I understand and can summarize things here, this would mean attaching SameSite=Lax cookies only to requests initiated via this new browser API to a few new endpoints that are required to enforce the presence of a Sec-Fetch-Dest: webidentity header and don't directly expose the response content. I'll not claim perfection but there's CSRF and some XSS protections there. I don't see how it exacerbates the situation for existing SameSite=Lax cookies. But it would prevent IDP implementations wanting to adopt FedCM from "downgrading" their existing SameSite=Lax cookies to SameSite=None and/or doing cumbersome and potentially error-prone workarounds.

Also, standardization as a concept very much is inclusive of discussions such as this one so I can't really agree with your statement there.

Yeah, standardization needs to be inclusive and more than just documenting implementation.

[johannhof]

Yeah, to be clear I wasn't trying to say "we can't do this because of some clause in 6265bis". We need to threat model how this impacts developers relying on current SameSite definitions, which happen to be specified in 6265bis. If we do this analysis and get implementer buy-in then we'll make whatever changes are needed in FedCM and the Cookies RFC.

On Chrome side I haven't seen anyone strongly object to this from a security perspective and there seems to be significant upside for developers, so I think we're tentatively positive on sending SameSite=Lax. @mikewest any concerns?

[bvandersloot-mozilla]

Before we can reach agreement I think someone has do the work on explaining the limited protections that exist around SameSite=Lax today and how this feature doesn't make the situation worse for existing SameSite=Lax cookies.

I think this would still be useful, and that @bc-pi's summary of the impact is a start.

I'm coming a little late to the party and may have missed something in the scrollback, but I'm trying to figure out the use case here and am coming at it from the angle of use-case preservation. If these cookies are expected to be sent by a request from a third-party page, how did these applications work before?

IIRC, the way we resolved Fetch issues was to treat the fetches initiated by this API as using the .well-known as basically a subdocument that initiates the requests. So it may be useful to think about why we don't have Lax cookies in iframe subresources.

I think the difference between this case and iframe subresources may just boil down to an opt-in vs opt-out protections. You have to opt-in to FedCM, but you have to opt-out of embedding. I'm not sure if that is the only difference or if it is sufficient to include Lax here.