In the previous post, a demonstration was shown of how Chrome’s soon to be default behaviour (if the same site attribute is not explicitly set) will affect CSRF in this instance. Also, to show Chrome’s exception that will happen alongside it.

In this post, there will be a further demonstration showing each of the attribute values. The first one we will talk about is Lax. To recap, Lax would allow cookies to be sent along with any top-level navigation via a safe HTTP method (e.g. GET) only.

However, Chrome’s default behaviour has a 2-minute exception (as previously shown in the last post), which allows cookies to be sent along with the unsafe POST request. If the Lax value is explicitly set, then 2- minute exception doesn’t apply.  Except for this exception, this will be the same as the last demonstration, but here it will be shown again. To try this for yourself go to https://samesite2-demo.herokuapp.com/.

Here shows the second demonstration application and we’ll be using the first text box:

Once a value has been entered and submitted, we have the following displayed just like the first demonstration application showed. But note, the cookie now shows Lax explicitly set:

Use the same POC from the last application, except for adding the anchor tag which just references the same URL which is shown in the screenshot:

From here, when clicking the POC POST request, this returns “No cookie found”. With the 2-minute exception Chrome allows, this would have gone through. However, this did not, meaning the cookie didn’t get sent along with the request:

However, when going back and clicking the anchor tag, we get the cookie value displayed, meaning the cookie was sent along with the request. This is because this was a top-level navigation GET request, which Lax allows:

Now on to Strict. When entering a value into the second text field and submitting it will show the same as before, except having the cookie explicitly set to Strict:

When trying the POC POST request, this will show the same message “No cookies found” as no cookie were sent along with the request:

Now, when we click the anchor tag, Lax allowed this so the cookie value was displayed. However, clicking this with Strict doesn’t send the cookie via GET either. Thus, displaying that default page:

The last one None, will turn the safeguard off. There are two fields for this, both are the same except for the last None in which Chrome will display a warning that in a future release Chrome will only send cookies with the ‘None’ value if Secure is set:

When clicking the POC POST request, this goes through fine and changes the cookie value. Here you can see that the requested cookie value was Test, and the response value is CSRF:

Also, no warnings are shown within Chrome having the ‘None’ value set along with Secure attribute set:

Doing this with the last text field will give the same result. However, there will be a warning as previously mentioned:

A new discussion / demonstration will be presented in the next article.