SameSite: The CSRF Killer

Introduction

Last but not least, let’s look at the SameSite flag, one of the latest entries in the cookie world.

Introduced by Google Chrome v51, this flag effectively eliminates Cross-Site Request Forgery (CSRF) from the web, SameSite is a simple yet groundbreaking innovation as previous solutions to CSRF attacks were either incomplete or too much of a burden to site owners.

In order to understand SameSite, we first need to have a look at the vulnerability it neutralizes. A CSRF is an unwanted request made by site A to site B while the user is authenticated on site B.

Sounds complicated? Let me rephrase, suppose that you are logged in on your banking website, which has a mechanism to transfer money based on an HTML <form> and a few additional parameters like destination account and amount. When the website receives a POST request with those parameters and your session cookie, it will process the transfer. Now, suppose a malicious third party website sets up an HTML form as such.

<form action="https://bank.com/transfer" method="POST">
<input type="hidden" name="destination" value="attacker@email.com" />
<input type="hidden" name="amount" value="1000" />
<input type="submit" value="CLICK HERE TO WIN A HUMMER" />
</form>

See where this is getting? If you click on the submit button, cleverly disguised as an attractive prize, $1000 is going to be transferred from your account. This is a cross-site request forgery, nothing more, nothing less.

Traditionally, there have been two ways to get rid of CSRF:

Origin and Referrer headers

The server could verify that these headers come from trusted sources (ie. https://bank.com). The downside to this approach is that, as we’ve seen in previous chapters, neither the Origin nor Referrer are very reliable and could be turned off by the client in order to protect the user’s privacy.

CSRF tokens

The server could include a signed token in the form and verify its validity once the form is submitted. This is a generally solid approach and it’s been the recommended best practice for years. The drawback of CSRF tokens is that they’re a technical burden for the backend, as you’d have to integrate token generation and validation in your web application: this might not seem like a complicated task, but a simpler solution would be more than welcome.

SameSite cookies aim to supersede the solutions mentioned above once and for all. When you tag a cookie with this flag, you tell the browser not to include the cookie in requests that were generated by different origins. When the browser initiates a request to your server and a cookie is tagged as SameSite, the browser will first check whether the origin of the request is the same origin that issued the cookie. If it’s not, the browser will not include the cookie in the request.

We can have a practical look at SameSite with the example at github.com/odino/wasec/tree/master/cookies. When you browse to wasec.local:7888/?samesite=on the server will set a SameSite cookie and a regular one.