CSRF is really not hard to understand

These days, I have summarized the principles and causes of CSRF.

Why summarize, because I always forget… When I read it before, it was just cloudy and foggy. This time, I deepened my understanding and impression by writing it on paper.

What is a CSRF

A request is made on a third-party website using the user’s login credentials (previously logged in to the website), and the request is faked as initiated by the user himself, so as to achieve the purpose.

Attack process

  1. The user logs on to the website a.com and opens a new TAB to go to the website b.com without logging out (keeping the login credentials Cookie)
  2. Site B has A request to Site A (tampered with)
  3. Inducing the user to click on site B to make a tampered request or to open site B and send the request directly
  4. Since the user has logged in, A request sent from website B will carry A’s login credentials (this is the setting of the browser, and the pot belongs to the browser).
  5. As the login credentials of A are carried, the tampered request is considered by the server to be A real user’s request, thus achieving the purpose of attack

The preset conditions

I didn’t understand why this process works when I was looking at this section. After careful study in the past few days, I found that a premise was ignored in my previous study. If I accepted the premise of this setting, it would be very easy to understand:

The browser automatically carries the cookie of the request, regardless of whether the current request originated from the current site or another site.

Prevention ideas

Once you understand how this happens, you can prevent cross-site request forgery attacks by simply cutting off any step in the process.

I summarize the following three points:

  • Not throughcookiesTo make the login credentials
  • Determine the source of the request
  • Check whether the request is sent by the user

The following is a detailed explanation of the preventive thinking

Do not use cookies for login credentials

In fact, the question here is what to use to do login credentials, we can use token to achieve the purpose.

In a word, token is a string of random codes generated by the server to identify users. Obviously, this token cannot be stored in cookies, but can be stored in the server session. The front end can be placed in sessionStorage. The specific steps are:

  1. After the user logs in, the server generates a token and sends it to the client
  2. All front-end requests carry tokens
  3. The server verifies the token validity in the request

Determine the source of the request

Attacks are usually made on third-party websites, so we can filter out third-party requests by judging the source of the request, so as to avoid attacks. So how do we know that the request is coming from a third party?

In HTTP, there are usually two headers to mark the source domain name: Origin and referer. So the server can use these two headers to filter third-party requests, but note that this method is not perfect and some browsers may not carry this information.

The difference and inapplicability of these two headers may need to be written in another article, which will not be discussed in this article.

Check whether the request is sent by the user

In fact, this method is very simple, is to add verification code in the page for users to enter, through the verification can be judged is the user’s real operation.

It’s just not very user friendly and doesn’t protect against GET requests.

Write in the last

Personally, I think the above methods can be used according to different situations, after all, the implementation cost of each method is different.

Alternatively, you can use a combination of two approaches.