Explanation of the logic used in this example

[morrow95]

I am implementing samesite and came across a scenario, in my opinion, which does not behave as it should.

a.com

• form is posted to b.com with username/password

b.com

• receives the posted variables from a.com
• checks username/password
• if they are found to be valid creates session/cookies with samesite=strict then redirects to b.com/loggedin.php

In this example, the session and cookies, while created on b.com will not exist on b.com/loggedin.php. From my understanding, the samesite logic sees a.com as the top of the chain when it reaches b.com/loggedin.php and eliminates the session/cookies. The problem is they were created on b.com.

One could argue, 'but what if you created something harmful in your session/cookie on b.com because of what was posted from a.com?' Yeah, sure that is possible, but that would be due to poor coding on my part on b.com. I am trying to wrap my head around why they have chosen this route in the example. It is blocking what was CREATED ON the SAMESITE.

[rowan-m]

Is there a reason you are using Strict instead of Lax for your session cookie? This means you will never have a session on the user's first navigation to a page on the site, such as following a link from an email.

If you have set a cookie from b.com with SameSite=Strict it will be available on b.com/loggedin.php assuming that the browser considers it a safe method, which does not include things like a cross-site POST request.

[morrow95]

I guess the logic used here is what confused me and I disagree with. The last thing I expected was this setting to affect anything on the current site based on where the user was before it.

If you set SameSite to Strict, your cookie will only be sent in a first-party context. In user terms, the cookie will only be sent if the site for the cookie matches the site currently shown in the browser's URL bar.

Well, my example above meets that requirement. My example also does not use or care about the cookies from the site it was at previously if any and does not need to access any previously created session/cookie when it is reached. Then you throw in the 'assuming that the browser considers it a safe method, which does not include things like a cross-site POST request'. But remember that I am not using the cookie when I reach this request I am creating it. The issue with my example is the redirect I have in place after I create my session/cookie - because of the redirect, on the same site to the same site, it is chained more or less as being cross-site. If I take the same example above, remove the redirect after creating my session/cookie, and instead use a link on the page to 'continue' it works as I would expect regardless of whether it reached the page cross-site or from a POST request.

I guess what I am getting at here is there should be logic that handles this situation. Session/cookie is created on same site, redirect happens to same site, session/cookie should be available on that redirect regardless of how it reached that initial page. It should be handled as if it was a same site link - which it basically is.

[rowan-m]

Right, I get you now.

SameSite=Strict cookies will not be sent with a same-site GET redirect if it results from a cross-site request. However, they will be sent for any safe, same-site requests subsequently triggered by the user. I've created a demo here:

1. https://samesite-sandbox.glitch.me/crosssite.html a form that will make a cross-site POST to:
2. https://crosssite-sandbox.glitch.me/ which will set a Lax and Strict cookie, then redirect to:
3. https://crosssite-sandbox.glitch.me/redirected.html which will receive the Lax cookie, but not the Strict.
4. Click the link on that page to navigate to it again, both the Lax and Strict cookie will be sent.

So, for these use cases either:

• use a SameSite=Lax cookie
• require some form of user interaction on the initial page to trigger a new, safe, same-site request with the SameSite=Strict cookie