Difference between revisions of "SameSite"
(→Context) |
(→Description of Impact) |
||
| Line 29: | Line 29: | ||
|- | |- | ||
|Lax || Send on ’Safe’ requests (GET, HEAD, OPTIONS) | |Lax || Send on ’Safe’ requests (GET, HEAD, OPTIONS) | ||
| − | } | + | |- |
| + | | “Chromium” || Lax but send also on POST when cookie < 2 minutes old | ||
| + | |- | ||
| + | |LStrict|| Never Send | ||
| + | |} | ||
==Problems== | ==Problems== | ||
Revision as of 11:51, 8 May 2021
Contents
Full Title or Meme
SameSite is an attribute in HTTP that is applied to the Cookie header.
Context
- Cross-site scripting (XSS) attacks have allows an attacker to see and reuse cookies supplied for Authentication of a user by another site.
- New HTTP headers focus on Cross-Origin iFrames which complicates the terms sites and origins which is further explained on that wiki page.
Description of Impact
This is largely from Brock Allen (see below) and D Waite at Ping.
There is another leg to this workflow, though, which is affected by the scenario you describe Brian. And it's what breaks the login workflow (cross-site). My observations are from trying to reverse engineer what the browser is doing, so I don't know if it's intended. Also, it's complicated and I've always had a hard time explaining what I think is happening, so apologies in advance.
During this workflow, if the RP then issues its own SameSite=Strict (and Lax too IIRC) session cookie on that exact POST response and also emits a 302 elsewhere in the RP, then on that next request the browser makes it will omit sending the cookie. I think it does this because it detects that you're in the middle of a long redirect chain which originated at the OP and has crossed the line into the RP (cross-site). The end result is that it won't send the RP session cookie on that final request, and from the end user's (and RP's) perspective this last request is anonymous. I know this is complicated to follow, so apologies.
Interestingly, though, if the user were to just hit refresh in the browser or manually navigate to somewhere in the RP, then the cookie is sent normally since it's the user that initiates the request. IOW, on the POST cross-site, the browser accepts the cookie just fine. It's just that it doesn't send it on the request because the request chain looks initiated from cross-site.
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 |
| LStrict | Never Send |
Problems
- The use of Cookies on various devices and User Agents has be restricted in ever more severe ways. These restrictions have limited the functionality of the Authentication Cookie.
- In particular Apple introduced a restriction on SameSite cookies that caused common implementations of OAuth 2.0 and OpenID Connect to fail. Brock Allen has decoded that issue on his site[1] The basic problem with OAuth front channel Authentication is determining which site is the SameSite. So, while the authentication works, the redirect to the client code is not considered, by iOS 12, to be a same-site operation. Even in the case a refresh of the client site will work and be fully authenticated, because it is not a redirect, but a SameSite operation.
References
- ↑ Brock Allen, Same-site cookies, ASP.NET Core, and external authentication providers. (2019-01-11) https://brockallen.com/2019/01/11/same-site-cookies-asp-net-core-and-external-authentication-providers/
Other Materiel
- The wiki page Cross-Origin iFrame contains more details.
- SameSite cookies from Mozilla.
- Cookies: HTTP State Management Mechanism Google & Apple - caution this draft will likely be changed by the time you are reading this.
