Is the end of the CSRF close?

Per. Under the cut, you will find a translation of a ridiculous and uncomplicated article on CSRF and a newfangled way of protecting against it.

Ancient serpent

Vulnerability CSRF or XSRF (it is synonymous), it seems, has always existed. Its root is the well-known opportunity to make a request from one site to another. Suppose I create such a form on my website.

<form action="https://bankingsite.com/transfer" method="POST" id="stealMoney"> <input type="hidden" name="to" value="John Doe"> <input type="hidden" name="account" value="12416234"> <input type="hidden" name="amount" value="$1,000"> 

Your browser will load my site and, accordingly, my form. I can immediately send it using simple javascript.

 document.getElementById("stealMoney").submit(); 

Therefore, such an attack literally stands for a cross-site request forgery. I forge a request that is sent between my website and your bank. In fact, the problem is not that I send a request, but that your browser will send your cookies along with the request. This means that the request will have all of your rights, so if you are currently logged in to your bank’s website, you have just donated a thousand dollars to me. Danke sean! If you were not logged in, the money is still in place. There are several ways to protect against such malicious attacks.

Ways to protect against CSRF

I will not go into details about how to protect, as the Internet is full of information about them, but let's quickly go over the main implementations.

Source check

By accepting a request in our application, we can potentially find out where it came from by looking at two headers. They are called origin and referer. So we can check one or both values ​​to see if the request came from our application or from somewhere else. If the source of the request is not your site, then you can simply answer it with an error. Checking these headers can protect us, but the problem is that they may not always be present.

 accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 accept-encoding: gzip, deflate, br cache-control: max-age=0 content-length: 166 content-type: application/x-www-form-urlencoded dnt: 1 origin: https://example.com referer: https://example.com /login upgrade-insecure-requests: 1 user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36 

Security Tokens

There are two ways to use unique protective tokens, but the principle of their use is one. When a user visits a page, say a bank page, a hidden field with a unique token is inserted into the money transfer form. If the user is actually on the bank's website, then he will send this token with the request, so that it will be possible to check whether it matches what you inserted into the form. When attempting a CSRF attack, an attacker can never get this value. Even in the case of a request to the Same Origin Policy (SOP) page, it will not allow him to read the page where this token is. This method is well proven, but it requires the application of logic to introduce tokens into forms and verify their authenticity in incoming requests. Another similar method is to inject the same token into a form and send a cookie containing the same value. When a real user submits a form, the token value in the cookie is checked against the value in the form. If they do not match, such a request will not be accepted by the server.

 <form action="https://report-uri.io/login/auth" method="POST"> <input type="hidden" name="csrf_token" value="d82c90fc4a14b01224gde6ddebc23bf0"> <input type="email" id="email" name="email"> <input type="password" id="password" name="password"> <button type="submit" class="btn btn-primary">Login</button> </form> 

So what's the problem?

The above methods of protection have given us sufficiently reliable protection against CSRF for quite a long time. Of course, checking the origin and referer headers is not 100% reliable, so most sites rely on tactics with unique tokens. The difficulty lies in the fact that both methods of protection require the implementation and support of the solution from the site. You will say that it is not difficult at all. I agree! Never had a problem. But it is ugly . In fact, we defend ourselves from browser behavior in a cunning way. But can we just tell the browser to stop doing things that we don’t want it to do? .. Now we can!

Same-Site Cookie

In fact, Same-Site cookies can nullify any CSRF attack. To death. Slightly more than full. Adyos, CSRF! They effectively and quickly help solve the problem of security. In addition, they are extremely easy to apply. Take for example some kind of cookie.

 Set-Cookie: sess=smth123; path=/ 

Now just add the SameSite attribute

 Set-Cookie: sess=smth123; path=/; SameSite 

That's it, you're done. No, really! Using this attribute, you somehow tell the browser to provide cookies with some protection. There are two modes of such protection: Strict or Lax, depending on how seriously you are tuned. Attribute Same-Site without specifying the mode will work in the standard version ie Strict. You can set the mode as follows:

 SameSite=Strict SameSite=Lax 

Strict

This mode is preferable and safer, but may not be suitable for your application. This mode means that c your application will not send cookies to any request from another resource. Of course in this case, CSRF will not be possible at the root. However, here you may encounter a problem that cookies will not be sent also when navigating a high level (i.e., even when clicking on a link). For example, if I now placed a link on Vkontakte, and Facebook used Vkontakte cookies, then when you clicked on the link, you would be logged out, regardless of whether you were logged in to this. This behavior, of course, may not please the user, but you can be confident in security.

What can be done with this? You can do as Amazon. They implemented as though dual authentication using two cookies. The first cookie lets Amazon just know who you are and show you your name. It does not use SameSite. The second cookie allows you to make purchases, change something in your account. SameSite is reasonably used for it. This solution allows you to simultaneously provide users with convenience and to remain an application safe.

Lax

Lax mode solves the logging problems described above, but still maintains a good level of protection. In essence, it adds an exception when cookies are transmitted during high-level navigation, which uses “secure” HTTP methods. According to the RFC , GET, HEAD, OPTIONS and TRACE are considered safe methods.

Let us return to our example of an attack at the beginning.

 <form action="https://bankingsite.com/transfer" method="POST" id="stealMoney"> <input type="hidden" name="to" value="John Doe"> <input type="hidden" name="account" value="12416234"> <input type="hidden" name="amount" value="$1,000"> 

Such an attack will no longer work in Lax mode, since we have protected ourselves from POST requests. Of course, an attacker can use the GET method.

 <form action="https://bankingsite.com/transfer" method="GET" id="stealMoney"> <input type="hidden" name="to" value="John Doe"> <input type="hidden" name="account" value="12416234"> <input type="hidden" name="amount" value="$1,000"> 

Therefore, the Lax mode can be called a compromise between security and user convenience.
SameSite cookies protect us from CSRF attacks, but do not forget about other types of vulnerabilities. For example, XSS or browser attacks on time.

From the author of the translation: Unfortunately, while SameSite cookies are only supported by Chrome and Opera, as well as the browser for android. Proof

Original
Before this appeared here