CSRF attack mechanism

CSRF attack, English full name is Cross Site Request Forgy, meaning Cross Site forgery Request. CSRF simply means to use the trusted information of the site to forge a request from the user to request the trusted site to perform illegal operations.

The destructive power of CSRF mainly depends on the permissions of the attacked. If the permissions of the attacked are very small, the data or functions of some users will be affected at most, for example, some garbled codes or illegal pictures are inserted in a certain place. If the permissions being attacked are administrator permissions, the impact will be great or even directly affect the security of the entire site, such as stealing user database or triggering transaction logic resulting in capital loss.

CSRF is more dangerous than XSS because it is more difficult to guard against.

In today’s browser, can support multiple open window, since support multiple open means that may be logged in several sites at the same time, so, this may have the risk of CSRF attack. The trick here is to avoid session sharing by using one browser for important sites and one for web surfing instead of just one. In other words, get a second trumpet and “play.”

CSRF attack mechanism

The principle of his attack is to send an illegal connection address to the user in a way that causes the user to click, and clicking on this will send a request message to another interface, unknowingly carrying out some sensitive operations.

The attack flow is as follows:

  • A/B: A and B indicate normal communication between the user and the site.
  • C: The hacker sent out a link with a malicious script disguised as a picture or text.
  • D: The user is attracted by the picture or text and clicks on it.
  • E: After clicking this link, the malicious script executes a request to the website site to forge a user request.

Characteristics of CSRF attacks

The most prominent feature of CSRF attacks is that they use users’ identity information to perform illegal operations without users’ awareness. But there is also a premise, the site to be attacked is the need for users to log in, that is, the user has logged in information.

CSRF attack defense

same-site

Same-site, as the name implies, only allows cookies from the same site. In other words, disables cookies from third parties to reduce security risks. He does this by setting cookies with the same-site property.

This method can protect against CSRF, however, the same-site method has compatibility issues, this property was originally added in Chrome 51, the best support is Google Chrome itself. Therefore, it is not a good solution to the CSRF attack problem.

referee

Referer is the HTTP request header, in which the information is the source address of the request information, and what needs to be done is to verify whether the address of the referer is the current domain, if not, reject it, which means that the request of the third party website is prohibited, so as to prevent CSRF attacks.

What needs to be noted here is that it is better to use a more rigorous method for the verification of the referer, because the referer is a section of website, and whether it comes from a domain is to determine whether it contains a domain name information, for example:

referer = "www.ke.com";
referer.indexOf('www.qq.com') > 0 
// false
Copy the code

The above method obviously can, but if the address changes slightly

referer = "www.ke.com?id=www.qq.com";
referer.indexOf('www.qq.com') > 0 
// ture
Copy the code

This is obviously a problem, so we must use the method of regular check to verify:

let referer = "www.ke.com?id=www.qq.com";
let Reg = /^https? :\/\/www\.qq\.com/;  
Reg.test(referer) 
// false
Copy the code

Only in this way can the referer be verified correctly. However, in some scenarios, the jump does not have the referer or the referer is allowed to be sent, etc. Generally, the referer is not used to verify whether the request is legitimate. Unless the business is purely internal or small in scope, consider this approach.

Verification code

As mentioned above, the attack feature of CSRF is to use users’ login information to perform illegal operations without users’ awareness. The purpose of using a captcha is to verify that an action is a user action.

Taking graphic verification code as an example, its implementation principle is that the front end introduces SDK to generate a section of rules, and then the user operates through some method. After the operation is completed, if the operating conditions are met, a section of verification code will be generated according to the rules.

This section of the captcha will be sent to the backend with the next request. The first thing the back end does when it receives a request is verify that the verification code is correct. If it matches, the operation is executed legally. If it does not match or is empty, it is an illegal operation. The process is shown as follows:

  • A: The user visits website to send A request
  • B: Graph validation is triggered under some condition
  • C: Perform specified verification operations on the front-end interface
  • D: The next request carries the verification code to the server

Another note, under certain conditions of the above said is because the graphical verification code doesn’t appear, every time for the user experience is poor, so are generally the background has its own set of judgment rules, such as the IP request more frequently or login request for many times, this time to judge trigger logic verification code for the abnormal operation.

I remember when I was doing H5 activities, there was a button in one of the activities that involved the operation of adding bonus points to works. Normally, the button should be set with the highest level of graphic verification, but the product student suggested not to set it too high. Because the addition of the highest level of graph checksum means that the probability of graph checksum is higher and the loss rate is greater.

In large factories, the verification code component does not need to be developed by students at the WEB end. It is developed by some infrastructure related departments at the company level. For example, Tencent’s most common WEB QQ login sometimes requires a process of dragging a small square to the right, which is their own waterproof wall.

To get a feel for the process, go to one of the programmers’ back gardens (NPMJS) and run a simple server installation locally. I just did a search, and it looks like the one below is okay, EMM, although I haven’t used it

token

Token provides a slightly better experience than graphic captchas. First, it generates an encrypted string from the back end, which is then written to cookies and attributes defined in the form field or HTTP header at a location on the page. When submitting data, it will be taken out from a certain location on the page and sent to the background together with the form and cookie. The background will compare these two pieces of data and the operation will be legal only when they pass.

In other words, the token issued by the server is an identity token for the user after the login authentication passes. Each request will carry this ID.

Note that both data segments must exist simultaneously. If either data segment is missing, the operation is considered illegal.

This method seems to solve the problem, but consider another case, the browser can open more pages, if the browser opens the same page at the same time, then these pages only the latest token is valid, because they will overwrite the previous one.

There’s an easier way to do it, and that’s the CSRF Guard, and there’s probably a better way to do it now, which I won’t describe here.

So that’s the introduction to CSRF.

The non-spicy Maosafang and the sugared iced Americano are soulless.