What is a CSRF

Before we can understand CSRF, we need to understand two premises. First of all, there are many ways to verify login permission. At present, most websites still use the mode of session task. The session mechanism simply means that the server uses a key-value pair to record the login information and stores the session ID (i.e. the key mentioned above) in the cookie. We also know that HTTP(S) requests in the browser automatically carry cookies to the server. In this way, the user obtains the session ID through the cookie during each request, and then obtains the login information from the server through the cookie to complete the user permission verification.

That would have been a nice feature, too. However, because cookie is too open, if A user logs in to website A, if the user sends A request to website A when visiting website B, the request actually contains the user’s login information on website A. If at this time B station A website request is the user does not know, that is very serious harm. The above process is called cross-site Request Forgery.

The harm of CSRF

To sum up, CSRF vulnerability is to use the vulnerability of website permission verification to send requests without users’ awareness, so as to achieve the purpose of “disguising” users. Attackers use CSRF to implement the following attacks:

  1. The attacker can trick the victim into performing any of the state-changing operations that the victim allows, such as updating account details, completing shopping, logging out or even logging in
  2. Access to users’ private data
  3. Cooperate with other vulnerability attacks
  4. CSRF worms

The CSRF worm, as its name implies, produces the worm effect, which will spread the CSRF attack ten, ten hundred. Such as: A community of friends DMS interface and access to buddy list interface have CSRF vulnerability, an attacker can be combined into a CSRF worms – when a user access to malicious pages by CSRF the friends list information, and then re-use of friends DMS CSRF vulnerability to each friend send a point to malicious pages of information, As long as someone checks the link in this message, the CSRF worm will continue to spread, and its possible harm and impact is very large!

defense

From the above description, we can know that CSRF has two characteristics: automatic cookie carrying and XSS attack. The following solutions can be used for these two features.

Check the Referer field

It is well known that there is a Referer field in the HTTP header, which indicates which address the request came from. By validating this field in the request on the site, we can tell if the request was made from this site. We can reject all requests that are not from this site, thus avoiding the cross-site nature of CSRF.

const { parse } = require('url');
module.exports = class extends think.Logic {
  indexAction() {
    const referrer = this.ctx.referrer();
    const {host: referrerHost} = parse(referrer);
    if(referrerHost ! = ='xxx') {
        return this.fail('REFERRER_ERROR'); }}}Copy the code

Also take ThinkJS as an example, as long as the simple judgment in Logic can be. This method takes advantage of the fact that the client cannot construct the Referrer. Although it is simple, it will become very troublesome when the website has multiple domain names or frequently changes domain names, and it also has certain limitations.

Token authentication

Because CSRF makes use of the automatic cookie transmission feature of browsers, another defense idea is to add random encrypted strings to other parameters for verification instead of sending verification information through cookies. Here are two more options:

  1. Random string: A random string parameter is added for each submission. The server delivers this parameter through the page and adds it to the submission parameter each time. The server verifies whether the parameter is consistent to determine whether it is a user request. In CSRF attacks, the attacker cannot know the value of the random string in advance, so the server can reject the request by checking the value.
  2. JWT: In fact, in addition to session login, JWT token login verification is becoming more and more popular. In this mode, the login token is recorded in the front end, and the authentication Header is added to each request to implement login verification. In a CSRF attack, the attacker cannot know the token value. In this way, CSRF attacks can be prevented. For information on how to use JWT in ThinkJS, see the previous article “ThinkJS JWT Authentication Practices.” Of course, there are many ways of token login besides JWT, such as OAuth.

Afterword.

In addition to the CSRF attack caused by the cookie login problem mentioned above, there is also a GET request to complete the operations such as add, delete and change. When the request does not verify the login information, it is easy to cause CSRF attack. Of course, this is low level, but still need to pay attention to. Especially with the popularity of SPA and more and more AJAX requests, we should pay more attention to the possibility of CSRF attacks.

References:

  • Cross-site Request Forgery

  • Cross-site Request Forgery (CSRF)

  • Understanding CSRF from The Perspective of Defense

  • Cross-site Request Forgery/CSRF