What is SameSite Cookies and CSRF Protection?

CSRF stands for Cross-Site Request forgery. It allows an attacker to craft a manipulated request via an email or by other means and thereby making state-changing actions in websites that you are currently authenticated as yourself. The intention of CSRF is not to read sensitive data, but to write or make changes to your data for the attackers’ benefit.

An Example Scenario Of CSRF

For example, you are logged in your net banking website https://mybank.com. The Request URL to make a fund transfer in your net banking application looks like,

https://mybank.com/transferFunds.do?beneficiary=Siva&amount=500

The attacker wants to transact your money to his account. So he crafts an email with the following HTML content,

<img src=’https://mybank.com/transferFunds.do?beneficiary=Attacker&amount=50000′ height=’0px’ width=’0px’ alt=’Logo not available’>

When you open this email, a call is made from your browser where you are logged in to your net banking account to transfer funds to the attacker’s account. Thus, by just opening the email, your account is debited since you are already logged into the banking website. The image may look broken and display all the text but the attacker succeeds in what he expected that is making a state-changing debit account action on your banking website.

Since the attacker can craft and send you the request that executes on your browser, the attacker has no way to read data that is specific to your account. The main intention of CSRF is to perform write actions.

Conventional CSRF Protection Mechanisms

Since CSRF is a serious vulnerability there are multiple protection mechanisms that are tried so far.

1. Usage of the POST method instead of the GET: There is a misconception that only the GET method is vulnerable to CSRF attacks. It is possible to send a JavaScript controlled HTML form link to a user which when opened auto submits to the target website using the POST method using JavaScript. So the method is not viable protection against CSRF attack.
2. Anti – CSRF token: For every link that is generated by a website, the site also appends an Anti- CSRF token in request parameter or request headers. This should be a strong cryptographic hash that an attacker must not be able to predict or tamper. The site also set this hash in its response cookie. Only if the parameter containing CSRF token matches with CSRF cookie, the request will be allowed to proceed. Otherwise, the request is failed. This CSRF cookie may be generated once per session or once per every request and must be invalidated immediately. The attacker who crafts and sends you the request would not have any idea what is the CSRF cookie for the current session/request. Thus, all state-changing actions with CSRF cookie protection will spoil CSRF attack attempts.

SameSite Attribute

For every cookie that is associated with any website, it is possible to set an attribute named SameSite. This is introduced to protect a website against CSRF attacks. Without using a separate cookie to protect a website against CSRF attack, the SameSite attribute can be set as a session cookie of a website indicating whether or not the cookie that authorizes a user into a website should be sent only when the link is from the same website, third party website, etc., This attribute controls this cookie passing behavior.

Solving CSRF issues with SameSite cookie

Since it is a common problem for all websites and each website must maintain a mechanism to generate, pass and invalidate CSRF token, Chrome now introduces SameSite cookie which basically aims at CSRF protection.

Almost all site uses Cookie-based user authentication mechanism. Once a user signs in to a website using his/her credentials, the website sets a cookie in the browser session. This is used to respond to further requests from the user to this particular site without having to log in again. This cookie is called session-cookie. Using one of the following values in the SameSite attribute of a session cookie, a website can protect itself from CSRF attack.

All cookies set on a domain can have a SameSite cookie attribute value associated with it. SameSite cookie can take one of the following values,

SameSite : strict

Cookies set with SameSite : strict will disable cookies being sent to all third party websites.  Cookies will be sent only if the domain is the same as the path for which the cookie is been set.

SameSite : none

Cookies set with SameSite : none will disable SameSite based protection. The website may use its own CSRF protection mechanisms.

SameSite : Lax

Cookies set with SameSite : Lax will allow cookies to be sent for top-level navigation only. When you didn’t add SameSite attribute, Lax is considered as default behavior.

So if you set session cookie with SameSite : Strict, Even in the absence of a dedicated CSRF cookie, links generated to your website from third-party websites will not have session cookies in them. Thus, it is not possible to perform CSRF attacks on them.

It is becoming more and more common since all modern browsers are considering to implement this behavior to protect its users from CSRF attacks.