Briefly discuss the understanding of CSRF and some countermeasures

CSRF

CSRF (Cross Site Request Forgery) definition, I believe we are familiar with. It refers to the process of an attacker inducing a user to open a well-designed page and send a request to a website to perform an operation (modify data). There are three premises:

1. The user has logged in to A trusted website (site A, the following site A refers to A trusted website here)

2. There is A request for station A to modify or save the information (e.g. /saveinfo).

3. The user opens the page designed by the attacker before the Session of station A expires, and automatically or triggers sending requests (/saveinfo)

It may seem like a tall order, but it is. “Even Gmail, which is well known, had a CSRF vulnerability at the end of 2007 that caused massive damage to Gmail users.”

To understand how to deal with CSRF, take a look at what attackers do.

What can an attacker do

Because of the restriction of the same origin policy, the attacker cannot get any Cookies or response information of Site A. He can only modify user data by using Cookies to verify login information or permissions when sending requests. Therefore, requests for information that do not involve modifying information (Get) do not need to worry about CSRF risks, but requests that modify information are important. Of course, if you use Get to modify information, you need to consider guarding against CSRF. But this defeats the purpose of HTTP method, and the Get attack is much simpler: an Img tag and JavaScript can trigger it. So it’s not recommended

CRSF preventive measures

As the saying goes, an enemy will be blocked. Understand the attackers use some principles, can find some corresponding measures

Verify the HTTP Referer field on the server.

The cost of this method is small, and it only needs to intercept the request at the server side to determine whether the Referer comes from the same domain name. If there is no OR no CSRF, it is considered as a POSSIBLE CSRF attack and is directly filtered. There is a downside to this approach, however, when some people worry that Referer will reveal personal information (servers, after all, send their own source address). These people will try to shut down Referer. In this way, when these users initiate a request without the Referer, the request will be judged as a possible CSRF attack, because the request header without the Referer is likely to be a CSRF attack according to the above filtering rules.

2. Add token to request address and verify

The idea behind this approach is to construct information that can tell whether a request is being sent from the user or exploited by an attacker. Obviously cookies cannot do this because both the user and the attacker can bring the same Cookie to the server.

The answer is token(token), which is generated by the server through an algorithm that returns a new token to the user each time the user requests a page. The next time the user sends a request, the token is compared with the server’s token. But where does the token go?

There are three scenarios: 1 For Get requests, the token is dynamically added after the Url. This method also has some constraints, the page has a lot of links, one by one is too troublesome, you need to complete the document after loading, through JS to assist. But this approach doesn’t work with dynamically generated content.

The Post request is added to the form strap

< input type= "hidden" name=token Value = "tokenValue" />Copy the code

(Check the personal center of PC Taobao, which uses this method to modify data.) Due to the same origin policy, the attacker cannot get the data in the form. This method also has the same problem as Get request, that is, for multi-link and dynamically generated content, js batch add token method is not available, can only be manually added.

3. For Ajax requests, if they cross domains, cookies of site A will not be carried by default. So, in some ways, it’s relatively safe. But according to the W3C’s description of an Ajax property

4.6.4 The withCredentials attribute

client . withCredentials

True when user credentials are to be included in a cross-origin request. False when they are to be excluded in a cross-origin request and when cookies are to be ignored in its response. Initially false.

If withCredentials is true, the user’s credentials(including cookies) are taken with them in cross-domain requests.

If the withCredentials are set to true, the above security issues also exist, because Cookies are worn at the same time as the request is sent.

conclusion

1. The attacker uses the user to log in to the trusted website and induce the user to open the problematic website before the session expires to achieve the purpose of attack

2. Common defense measures include verifying the referer of the request header, and adding random number tokens (tokens) that cannot be obtained by attackers to achieve defense purposes.

3. Token can be stored in various places. For POST request, construct hideen input tag; For Get, add the token after the link; In the case of Ajax, you add tokens to cookies.

4. Personally, it is relatively safe to verify both the referer and the token. For more esoteric operations, you need to use a verification code or manually enter a password to prevent this.

Reference article: www.w3.org/TR/2014/WD-… www.ibm.com/developerwo… En.wikipedia.org/wiki/Cross-…

The first time you write a Post, there’s so much going on, down to markdown syntax; Big to find problems, explore and analyze problems, access to data and self-test verification. Finally, check the whole article to see if there are any problems. Although the whole process was difficult, it gave me a deeper understanding of CRSF. I will spare no effort to sort out an article after sharing. I believe it will be better in the future.