Is CSRF End Near?

Per. Under the cut you will find a translation of a ridiculous and uncomplicated article about CSRF and a new-fangled way to protect against it.

Ancient serpent

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

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

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

Therefore, such an attack literally stands for cross-site request forgery. I fake a request that is sent between my site and your bank. In fact, the problem is not that I will send the request, but that your browser will send your cookies along with the request. This means that the request will have all 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, then the money is still in place. There are several ways to protect against such malicious attacks.

CSRF protection methods

I will not go into details about the methods of protection, since 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 the two headers. They are called origin and referer. So we can check one or both of the values ​​to see if the request came from our application or from somewhere else. If the request source 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 the same. 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 really on the bank’s website, then he will send this token along with the request, so that it can be checked whether it matches what you inserted into the form. When trying a CSRF attack, the attacker can never get this value. Even in the case of a request to the page, Same Origin Policy (SOP) will not allow him to read the page where this token is. This method has proven itself well, but it requires a logic application to inject tokens into forms and verify their authenticity with incoming requests. Another similar method is to inject the same token into the form and transfer cookies, containing the same value. When the real user submits the form, then the token value in the cookie is verified with the value in the form. If they do not match, then such a request will not be accepted by the server.

Login

So what's the problem?

The above protection methods have given us fairly reliable protection against CSRF for quite some time. Of course, checking the origin and referer headers is not 100% reliable, so most sites rely on tactics with unique tokens. The difficulty is that both methods of protection require the site to implement and support the solution. You will say that it is not difficult at all. I agree! Never had a problem. But it is ugly . In essence, we are defending ourselves from browser behavior in a tricky 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

Essentially Same-Site cookies can negate any CSRF attack. To death. A little more than full. Adyos, CSRF! They effectively and quickly help solve a security problem. In addition, it is extremely simple to apply. Take for example some cookie.

Set-Cookie: sess=smth123; path=/ 

Now just add the SameSite attribute

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

Everything, you are done. No really! Using this attribute, you kind of tell the browser to provide cookies with some protection. There are two modes of such protection: Strict or Lax, depending on how serious you are. The Same-Site attribute without a mode will work in the standard version i.e. Strict You can set the mode like this:

SameSite=Strict  
SameSite=Lax 

Strict

This mode is preferable and safer, but may not be suitable for your application. This mode means that 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, one may encounter a problem here that cookies will not be sent also during high-level navigation (i.e. even when clicking on a link). For example, if I posted a link to Vkontakte now, and Facebook used Vkontakte cookies, then when you clicked on the link you would be logged out, regardless of whether you were logged in before. This behavior, of course, may not please the user, but you can be sure of safety.

What can be done with this? You can do like Amazon. They implemented a kind of double 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. For it reasonably uses SameSite. This solution allows you to simultaneously provide users with convenience and remain safe for the application.

Lax

Lax mode solves the logging problems described above, but at the same time maintains a good level of protection. In essence, he throws an exception when cookies are sent during high-level navigation that uses “secure” HTTP methods. According to RFC , GET, HEAD, OPTIONS, and TRACE are considered safe methods.

Let's get back to our attack example at the beginning.

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.

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

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

The original
appeared here before.