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.

[cbiesinger]

Chrome Canary now (starting in 128.0.6589.0) supports sending SameSite=Lax cookies for credentialed FedCM requests behind a flag, --enable-features=FedCmSameSiteLax (needs to be specified on the commandline, there is no chrome://flags entry)

@bvandersloot-mozilla let me attempt to summarize my understanding here:
SameSite=None cookies get sent on all cross-site requests, including fetch(), <img>, etc
Lax cookies only get sent for navigations (e.g. <iframe>)
So today, you can get third-party signin functionality by using an iframe from the IDP domain while using Lax cookies.

But if FedCM requires None, that means you have to allow your cookies to be sent in a lot more cases, which is undesirable.

Can someone confirm whether I summarized the issue correctly?

[bvandersloot-mozilla]

Chrome Canary now (starting in 128.0.6589.0) supports sending SameSite=Lax cookies for credentialed FedCM requests behind a flag, --enable-features=FedCmSameSiteLax (needs to be specified on the commandline, there is no chrome://flags entry)

@bvandersloot-mozilla let me attempt to summarize my understanding here: Lax cookies only get sent for navigations (e.g. <iframe>)

Not quite, Lax cookies are more strict than that. They are only sent on top-level navigations, using safe methods. There are additional relaxations in place for cookies that are Lax because they have no attribute set, but those are sort-of-bad to rely upon and are an artifact of failing to migrate the default SameSite attribute fully.

So today, you can get third-party signin functionality by using an iframe from the IDP domain while using Lax cookies.
I'm not sure how these things are working now- maybe it is the SameSite-Lax-by-default exceptions.

But if FedCM requires None, that means you have to allow your cookies to be sent in a lot more cases, which is undesirable.

Agreed that this is probably the case, but if that is because the previous behavior was using the SameSite-Lax-by-default exceptions we should find a better answer for them.

[cbiesinger]

Hi @anderspitman, could you explain how you use SameSite=Lax cookies today, especially with respect to Ben's last comment? Do you only use redirects today?

[anderspitman]

@cbiesinger sorry for the late response. Yes, I'm only using redirects currently.

[samuelgoto]

Chrome Canary now (starting in 128.0.6589.0) supports sending SameSite=Lax cookies for credentialed FedCM requests behind a flag, --enable-features=FedCmSameSiteLax (needs to be specified on the commandline, there is no chrome://flags entry)

@anderspitman, could you give this a try and see if what @cbiesinger implemented works for you and your deployment?

[anderspitman]

@samuelgoto didn't realize I might not be blocked on this. I'll give it a shot.

[anderspitman]

@samuelgoto @cbiesinger unfortunately this doesn't seem to be working. Running on version 130.0.6683.2 on Linux. I have an idea for a workaround involving extra cookies but not 100% sure that will work yet, and I'm worried about introducing subtle vulnerabilities.

[anderspitman]

I've implemented my workaround for prod LastLogin. The way it works is I set a simple lax cookie for all requests, and made my login cookies SameSite=none. I then gated them behind a check to verify the lax cookie is present for all requests except FedCM /accounts and /id-assertion.

I would appreciate feedback from those in this thread to make sure I'm not missing any subtle security holes.

[npm1]

I am curious regarding why it did not work for you. Did you enable the feature, restarted Chrome, and tried it out? Did you not get the Lax cookies or what didn't work?

[anderspitman]

@npm1 with the feature enabled looks like Chrome is sending the cookies for /accounts, but not /id-assertion. Without the flag it doesn't send them for either.

[npm1]

Ok thanks! I pointed this out in https://issues.chromium.org/issues/350944661 although Christian is out till Wednesday

[anderspitman]

Thanks for passing that on. And no worries, I'm pretty sure my workaround is secure and there's no rush to get this implemented on my end.

It definitely would still be very useful in the future for added security and for ease for new implementers. I know @sebadob has stated he wouldn't deploy FedCM for Rauthy unless lax cookies can be used. Not sure if his position has changed.

[samuelgoto]

I'm pretty sure my workaround is secure

Can you expand on what workaround you used?

[anderspitman]

I mentioned it here: #587 (comment)

I can give more details if that's confusing. Basically since we have to use SameSite=None, the browser is always sending the login cookies, even cross-domain. So I added another SameSite=Lax cookie that acts as a "key" that turns on the login cookie. All endpoints require that key to be present except for /fedcm/accounts and /fedcm/id-assertion

[cbiesinger]

So it turns out that making SameSite=Lax is harder than it initially seemed. Since the ID assertion request is a POST request, and POST requests do not receive SameSite=Lax cookies, it is not enough to treat these requests as top-level requests.

We also can't treat ID assertion requests as same-site requests due to the CORS requirement.

So this might require discussions involving the fetch spec and/or cookie layering...

It seems @anderspitman has a workaround for now, so am not planning to work on this issue for now.