Same-Site cookies against CSRF attacks analysis

CSRF vulnerabilities

Cross-site request forgery (CSRF) vulnerabilities are extremely common in web applications. Despite they are known since a long time ago, we are used to find them constantly in the most important vulnerabilities included in OWASP top 10 web security audits. .

CSRF attacks are based on the fact that cookies associated to a particular domain are sent automatically by the browser in those requests addressed to that domain, regardless the origin.

This situation means that an attacker is able to force requests containing appropriate values towards a web from an external domain (cross-site requests) despite of unknowing the value of any user’s cookies on that particular web.

In case the application does not count on the corresponding protection measures, the attacker could use CSRF attacks in order to force data manipulation actions on a vulnerable web during the victim’s session.

Same-site cookies

In order to try mitigating security problems associated to the described behavior, some browsers have started implementing support to the new SameSite flag. Basically, this new functionality can be used to prevent the browser from automatically sending a particular cookie when the request is originated from an external domain.

Same-site cookies behavior

Just as what is done with the HttpOnly and Secure flags, the SameSite flag can be activated establishing the corresponding header in web server HTTP responses.

Set-Cookie: MyCookie=value; HttpOnly; Secure; SameSite=Strict

The integration of this new measure can be useful in order to achieve several goals:

• CSRF Attacks protection
• Protection against attacks based on cross-domain requests response time, such as “Pixel-perfect Timing Attacks”.
• Protection against Cross-site script inclusion attacks – XSSI (not against XSS).
• Moreover, this flag can contain an added value regarding privacy policies. Since a web page may offer the user this service as a warranty that user’s cookies shall not be used with browser tracking purposes.

There are two possible values for the SameSite flag behaving differently:

• Strict: Those cookies with this value will only be sent in those requests originated from the domain itself. Therefore, this is the most restrictive value.
• Lax: In this case, a browser could also send cookies in some requests originated from external domains. Particularly, these could be sent in GET type top-level requests which are requests where the URL changes conspicuously in the browser bar. By the way, this is not happening in GET requests generated by images upload, iframes, or ajax requests, for example. In these cases, cookies with this flag value will be restricted.

It is worth mentioning that cookies with the flag Lax could be sent in those GET requests generated with prerendering functions such as or with pop-up windows, since they do not generate cross-domain requests. In these actions, there is no reason for the user to notice a change in the browser URL of the current window.

Same-site cookies considerations

According to what is pointed out in the draft, this new flag should be considered as a support measure to common protections, therefore it should contribute to establish an in-depth defense.

First, it should be taken into account that only a minimum percentage of browsers are currently implementing support for SameSite cookies. That is why the new functionality should be understood as a long-term real protection measure.

It is also interesting to mention that all popular browsers have been implementing the option of not giving access to third parties cookies for a while.

Block third-party cookies option in Chrome

Checking this option would be similar to establishing the attribute “SameSite=Strict” by default in every cookie, therefore involving invulnerability against those CSRF attacks. However, using this measure may affect negatively the browsing experience, since many cases of legitimate use exist where third-party cookies come into play. For example, the authentication process is avoided each time we access a page from a different domain. Then, they are of vital importance for widgets performance and they also provide the possibility of commenting in many webs using our Google or Facebook accounts, among others.

Therefore, Same-site cookies carry out a selective and appropriate restriction by the server in each particular case. In fact, it may be interesting defining multiple session cookies, being the values Lax or Strict allocated depending on the usage needs of the session.

Sometimes, web applications carry out POST request (or other type of methods) using GET methods, transferring the parameters to the URL. In case the developer has not taken into account this fact, an attacker could take advantage in order to prevent the protection provided by Same-site cookies with Lax attribute.

Finally, it must be taken into account that any measure may protect the possibility of forcing actions provoked by a third-party if other vulnerabilities exist, such as cross-site scripting (XSS).

Conclusions

Same-site cookies can provide an effective protection against CSRF attacks without affecting negatively the application functionality.

For this purpose, the use of browsers implementing this new feature should be spread. Additionally, servers should send in HTTP responses the appropriate values regarding Same-site cookies for each case of use, as well as common protection measures should be applied over other types of vulnerabilities that could be used to prevent protection.

Discover our work and cybersecurity services at www.tarlogic.com