Part 2: SameSite Attribute

Part 2: SameSite Attribute

February 22, 2020
Samesite attribute issue on computer screen

In part 1 we looked at the SameSite attribute, here we will run through a quick demo of an CSRF (Cross site request forgery) attack being performed with Chrome’s enforcement enabled.

Note: when attempting this on the latest version of Chrome (version 80 at the time of writing) it didn’t work. The following reference here says this change will be in place later on in February. This meant that currently, this feature had to be enabled via chrome://flags/#same-site-by-default-cookies. To try this yourself please go to http://samesite-demo.herokuapp.com/.

This demo application provides the following greeting page when first visited with no cookie set:

Samesite

Simply entering a name and clicking “Set Name” will set the cookie “name” with this value that is entered:

Viewing this in the browser shows the SameSite attribute is not set. Thus, Chrome will treat this as Lax, except for the 2-minute exception:

Now, there is a change feature which simply changes the name value with what is again entered:

This shows that it has been changed:

This change feature performs a POST request to “change.php” using the name attribute with the value name. So, creating a simple CSRF Proof of Concept (POC) with the following that automatically submits the form when visited:

When visited, this gets issued and the change gets made. At this same time Chrome shows a message advising the 2-minute exception is in place. Thus, this being allowed:

Changing the POC slightly, in this case changing the value to “csrf2”:

When visiting this csrf.html POC again, after the 2-minute exception, the page now shows “No cookie found”. This means that the cookie wasn’t include in this second CSRF request. Furthermore, Chrome shows a message indicating the cookie was blocked due to not having the SameSite attribute with the value “None”, along with the Secure attribute set.

When using Chrome for now, until later on in February, CSRF will still be allowed. Once default and providing developers don’t set the SameSite attribute explicitly, CSRF’s will have its limitations. However, when the use of the SameSite attribute is used, CSRF’s may still be performed depending on how developers explicitly set the cookies (e.g. Setting a cookie has SameSite=None and Secure when it doesn’t need to be).

Share with your network

Related Articles
  • Server-Side Request Forgery Demo

  • 2nd Update: SameSite cookie changes

  • Introduction to Server-Side Request Forgery