Search for:
Technical

Protect yourself from CSRF attacks with the SameSite cookie attribute

What is a Cross Site Request Forgery Attack?

The CSRF is an attack that forces an end user to perform unwanted actions and without noticing on a web application he/she is currently authenticated.
CSRF attacks specifically target requests that make modifications, not data theft, because the attacker has no way of seeing the response of the falsified request. The outcome of the actions is what interests the attacker.

This type of attack is based on the fact that when a user is authenticated on an application, it will usually provide a session ID that its browser stores in a cookie.

Each time the user sends a request to the server, the browser will also automatically send this session cookie. You can find in linked article more information about CSRF attacks.

Keep in mind that a CSRF attack only needs that the user stays connected (without having an open page or tab of the website) to be working.

With attacks using social engineering (such as sending a link by email or chat), an attacker can cause users of a Web application to perform actions of his choice.

  • If the victim is a normal user, a successful CSRF attack may require the user to make changes, such as a modification of the email address, the IBAN, and so on.
  • If the victim is an administrative account, a CSRF attack can compromise the entire web application, due to the various rights he/she has on the application.

Another way to protect yourself: the SameSite attribute

To protect yourself from CSRF attacks, there is the classic anti-CSRF token solution. In a nutshell, it consists of generating a random value in the forms, so that the request cannot be predicted.

CSRF with SameSite cookie instruction
Click to enlarge

Since then, a new solution has appeared. This is the “SameSite” attribute that an application can put on cookies that it communicates to the client’s browser.

If this attribute is placed on the session cookies, then these will not be sent to the server if the request does not come from the application domain.

The application receiving the request will not be able to link the request to any user and therefore will not treat it. This makes it possible in theory to protect itself completely from this type of attack.

Support for this attribute

At the time of writing this article (October 2018), this attribute is still not really supported by all browsers. Edge, Firefox, and Chrome support this feature properly, but it is not supported for safari versions under iOS 12.

Chart of browsers supporting SameSite Cookie Instruction

You can follow here the evolution of the versions supporting the attribute.

The SameSite attribute in detail

When the application creates the session cookie on the client’s browser, the client must add the flag “SameSite=strict” or “SameSite=lax”.

Example:

Set-Cookie: PHPSESSID=6qc74h21i12ucl4i3l5oc5af07; expires=Thu, 11-Oct-2018 15:47:30 GMT; Max-Age=3600; path=/; domain=192.168.240; secure; HttpOnly; SameSite=strict

The “strict” mode is the most restrictive: if the user requests the site from a third-party site, then his session cookie will be systematically ignored. The disadvantage is that a user who has clicked on a link leading to the site will still be considered by the application as not being connected, and this even if he is authenticated.

To avoid this, it is possible to use the “lax” mode, which will allow the browser to send cookies if the request is a simple GET (example: click on a link) but will not send them for a POST request.

It is important to note, however, that if you use the lax mode, it will still be possible to perform CSRF attacks on the parameters of the GET requests of your application, which should not have a big impact if the usage of the POST method is normally implemented.

Moreover, the implementation of this instruction is not yet fully supported natively by all languages or all libraries. For example, for PHP, it will only be supported in version 7.3 which is not yet available in final version.

 

Conclusion

This new element seems very interesting to protect against CSRF attacks. However, it should not be used for the moment as the only protection, but in addition to more traditional protections like anti-CSRF token.

Author: Romain Garcia

Related Posts