[Openid-specs-ab] 3rd party and SameSite cookies (was Browser Interactions STC - Meeting Notes - 2021-05-05)

David Waite david at alkaline-solutions.com
Sat May 8 05:44:23 UTC 2021


> (As best I understand it anyway) a previously set cookie with SameSite=None will be sent by the browser on such a top-level cross-site POST request. Some folks have suggested that that will change with 3rd party cookies going away and that even a SameSite=None cookie will no longer be sent in that situation. But in my mental model of this stuff, the situation will be unchanged by 3rd party cookies going away - it's a cross-site request but because it is a top-level navigation the cookies are 1st party. SameSite enforcement is in place so SameSite=None cookies will be sent. But it's not 3rd party so is not impacted by disappearance or partitioning of 3rd party cookies. 

SameSite applies in navigation capacities as well, e.g. the first HTTP request to the new site on link, redirect, or post. None and the temporary chromium default workaround behavior would be the only ones that would send state along with a HTTP POST. A world with just lax and strict would require more complex server acrobatics.

I’m (also) not Sam, but I can try to supply a bit of color:

SameSite is meant to limit state outside first-party contexts, e.g. limit XSRF-style attacks by having the browser not send state for request originating from outside your domain. It was NOT intended as a privacy restriction.

SameSite is a per-cookie setting when interacting outside your current context. Examples would be cookies not being sent when following links, when being redirected, on cross-domain POSTs (manual or javascript) - in addition to embedded resources (images, iframes) and XHR/fetch.

The current behaviors of SameSite are:

Setting.            Behavior
---------	        -----------
None               Always send cookies
Lax                  Send on ’Safe’ requests (GET, HEAD, OPTIONS)
“Chromium”     Lax but send also on POST when cookie < 2 minutes old
Strict                Never send

Chromium-based applications will typically default to the implicit “Chromium” behavior if SameSite is not set and the cookie is set to Secure, otherwise Strict.  This temporary default behavior is specifically to avoid immediately breaking SSO software, but will still break if you need state older than two minutes - including if your login process winds up taking a bit longer due to a slow emailed OTP or mandatory password change.

Other browsers have other defaults - they may default to None, or default to None only for Secure cookies. Chrome also unfortunately mandated SameSite=None for legacy behavior before it was part of any officially proposed standard - other browser makers did support it, but there are some not-super-old environments which have to be detected so you don’t send an illegal SameSite value of None (and thus have your attempt to set a cookie be rejected).

My understanding is that even with Strict-mode causing cookies to be omitted on a cross-domain form post, the _next_ server response within the context of the domain will have these cookies sent. Catching the form and doing a redirect for processing would be one way to get state back.

SameSite settings are meant to control cross-site usability of your domain, and are more in the family of CORS restrictions than privacy restrictions. However, it does make several tracker integration strategies more complex (e.g. javascript processing of inbound decorated links, XHR calls, iframe embedding)

Restricting SameSite as a privacy setting brings up piles of edge cases that I just don’t know about. E.g.:
- on first page load on a new site, would the javascript have cookie access?
- would there be corresponding limitations for javascript access to local storage?
- are cookies still settable, and does _that_ depend on same site at all? 
- wouldn’t leaving ‘lax’ as an option be a large loophole for data on GETs?

As such, I suspect removing SameSite=None is really being talked about as a potential part of a suite of changes. Unfortunately, I have not found a reference to that for Chromium, let alone a reference that makes me think all browsers are collaborating on a gameplan in the open. If others know of one, please share!

-DW

> On May 7, 2021, at 3:37 PM, Brian Campbell via Openid-specs-ab <openid-specs-ab at lists.openid.net> wrote:
> 
> My apologies for joining this call late and in the middle of discussions on a topic that I'm hoping to reconcile understanding on. I said I'd send a message seeking clarification on that topic. So here is that message. But I'm struggling to articulate it so please bear with me.
> 
> In identity protocols, a cross-site navigation resulting in a POST request is typically happens by the first site returning an HTML page that has a form that is auto-submitted via javascript to the second site. That's how SAML Post binding works. And so does the OIDC/OAuth form post response mode. 
> 
> 
> Anyway, that's what I'm hoping Sam can provide clarification on. Mostly for the benefit of my own understanding but also for the benefit of the group here as recent discussions have suggested that folks have divergent understanding and expectations of things. 
> 
> That behaviour changing would be problematic, for example and as others have pointed out, because OIDC RPs receiving an ID token via the form post response mode need the 'nonce cookie' value (which ties the ID token to the browser the SSO flow was initiated on) at that point in validating the token. Maybe further confusing things is that at least in Chrome there was a temporary(?) exception made for the nonce cookie case with the rollout of the SameSite default change to Lax - the "Lax + POST mitigation" section at https://www.chromium.org/updates/same-site/faq and it looks like there's an attempt to capture that in the coming update to RFC 6265 https://github.com/httpwg/http-extensions/pull/1435/files
> 
>  
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Wed, May 5, 2021 at 12:49 PM Tim Cappalli via Openid-specs-ab <openid-specs-ab at lists.openid.net> wrote:
> Hey all,
> 
> Here are the meeting notes from today's special topic call. Please feel free to add or correct anything.
> 
> openid / connect / wiki / Browser Interactions Special Topics Call - 20210505 — Bitbucket
> 
> Next meeting is in two weeks on May 19th (UTC).
> 
> Tim
> 
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
> 
> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab



More information about the Openid-specs-ab mailing list