0

We have a web service where GET is always safe and all unsafe POST requests use single-use CSRF tokens. We have some cases where cross-origin domain would need to pass us POST request with data that should be used with currently active user session (top-level cross-site POST) so we need the session cookie while handling this request. The cross-origin is trusted and the request is signed with HMAC signature but the cross-origin doesn't know and shall not know the session cookie value used by the user which is the reason we need the cookie from the browser. (In short the flow goes like this: we redirect logged in user to 3rd party service where user uses UI to select data items that get passed to us with details. We don't know the credentials to the 3rd party service and they cannot know the session details of our service.)

We can currently get this to work with setting session cookie with SameSite=None; Secure; HttpOnly but I have three questions:

  1. Does SameSite=Lax or SameSite=Strict offer any other protection but CSRF attacks? We already have CSRF token protection so we don't need SameSite cookies for this.
  2. I know that Google has published a plan to kill third party cookies which use SameSite=None; would our use of 1st party cookies be affected, too? I'd like to have a setup which would work in the future, too.
  3. Is there any way to declare that we want SameSite: Lax plus allow 1st party cross-origin POST requests (that is, when browser location bar shows our domain, allow submitting the cookie always without the 2 minute hack that Chrome used to have when SameSite was not set at all)? We're not interested in user tracking and would want to avoid stamped as such by the browser UI.

Basically I'm asking if SameSite=None; Secure; HttpOnly is safe to use safely both in sense of security and longetivity, or if there's a better way to do this.

Mikko Rantalainen
  • 513
  • 2
  • 11
  • I haven't found any strong evidence but it seems that `SameSite=None; Secure; HttpOnly` only has risk for CSRF attacks (which can be mitigated by the server with a correct CSRF token implementation). In addition, Google may kill those cookies in 3rd party case because they can be used for tracking but I don't think Google can kill those cookies for 1st party case because SAML login protocol requires this exact same behavior and that's too widely used to kill anytime soon. – Mikko Rantalainen Aug 26 '21 at 10:26
  • If possible, protocols such as SAML should be replaced with style similar to OpenID Connect where browser transfers single use token code via GET request and the actual data is fetched via server-server connection in the background. That way `SameSite=Lax` cookies can be used for the login flow, too. – Mikko Rantalainen Aug 26 '21 at 10:28

0 Answers0