Shulou(Shulou.com)05/31 Report--

How to realize the principle analysis of CSRF, in view of this problem, this article introduces the corresponding analysis and solution in detail, hoping to help more partners who want to solve this problem to find a more simple and feasible method.

CSRF

Brief introduction:

CSRF cross-site request forgery (Cross-Site Request Forgery)

In the CSRF attack scenario, the attacker forges a request (which is usually a link) and then tricks the target user into clicking on it. Once the user clicks on the request, the whole attack is completed. So the CSRF attack also becomes the "one click" attack. For example, the attacker stole your identity and sent a malicious request in your name, which is perfectly legal for the server, but completed an operation expected by the attacker, such as sending e-mails and messages in your name. Steal your account, add a system administrator, and even buy goods, virtual currency transfer and so on.

CSRF vulnerability detection:

Detecting CSRF vulnerabilities is a tedious task. The easiest way is to grab a normally requested packet, remove the Referer field and resubmit it. If the submission is still valid, you can basically determine that there is a CSRF vulnerability.

With the in-depth study of CSRF vulnerabilities, some special tools for detecting CSRF vulnerabilities, such as CSRFTester,CSRF Request Builder, continue to emerge.

Take the CSRFTester tool as an example, the testing principle of the CSRF vulnerability detection tool is as follows: when testing with CSRFTester, we first need to grab all the links and forms we have visited in the browser, and then resubmit them by modifying the corresponding forms and other information in CSRFTester, which is equivalent to a forged client request. If the modified test request is successfully accepted by the website server, there is a CSRF vulnerability, of course, this tool can also be used to carry out CSRF attacks.

The difference between CSRF and XSS:

CSRF is to use the user's authority to complete the attack, the attacker did not get the user's authority, while XSS directly stole the user's authority, and then carried out destruction.

CSRF (GET)

We log in to a user and change their address or other information

You can see that because it is a GET request, you can see the location that can be modified in URL.

Complete this link and change the phone number to 1234

Http://192.168.229.130/pika/vul/csrf/csrfget/csrf_get_edit.php?sex=girl&phonenum=1234&add=shandong&email=lucy%40pikachu.com&submit=submit

CSRF (POST)

POST requests cannot be viewed directly in URL, so they are similar to reflective XSS (POST). We can also create a page form to tempt users to click and complete the attack.

Defend against CSRF attacks:

CSRF Defense:

Verify the HTTP Referer field; add token to the request address and verify; customize the properties in the HTTP header and verify.

(1) verify the HTTP Referer field

According to the HTTP protocol, there is a field in the HTTP header called Referer, which records the source address of the HTTP request. In general, the request to access a secure and restricted page comes from the same website, for example, if you need to visit http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory, the user must first log in to bank.example and then trigger the transfer event by clicking the button on the page. At this point, the Referer value of the transfer request will be the URL of the page where the transfer button is located, usually the address that begins with the bank.example domain name. If a hacker wants to carry out a CSRF attack on a bank website, he can only construct a request on his own website. When a user sends a request to the bank through the hacker's website, the Referer of the request is directed to the hacker's own website. Therefore, to defend against CSRF attacks, the bank website only needs to verify its Referer value for each transfer request. If it is a domain name that begins with bank.example, the request comes from the bank website itself and is legitimate. If Referer is another website, it may be a CSRF attack by a hacker to reject the request.

The obvious advantage of this method is that it is simple and easy. The average developer of a website does not need to worry about CSRF vulnerabilities, but only needs to add an interceptor to all security-sensitive requests to check the value of Referer at the end. Especially for the current existing system, there is no need to change any existing code and logic of the current system, there is no risk, it is very convenient.

However, this approach is not foolproof. The value of Referer is provided by the browser, although there are clear requirements on the HTTP protocol, but each browser may vary in the specific implementation of Referer, which does not guarantee that the browser itself does not have security vulnerabilities. Using the method of validating Referer values is to rely on third parties (that is, browsers) for security, which is not safe in theory. In fact, for some browsers, such as IE6 or FF2, there are already ways to tamper with Referer values. If the bank.example website supports IE6 browsers, hackers can set the Referer value of the user's browser to an address that begins with the bank.example domain name, so that it can be verified and CSRF attacks can be carried out.

Even with the latest browsers, hackers cannot tamper with Referer values, and this approach is still problematic. Because the Referer value records the source of the user's access, some users think that this will infringe on their own privacy, especially when some organizations worry that the Referer value will leak some information from the organization's intranet to the extranet. Therefore, the user can set up the browser so that it no longer provides Referer when sending the request. When they normally visit the bank website, the website will be regarded as a CSRF attack because the request has no Referer value, denying access to legitimate users.

(2) add token to the request address and verify

The CSRF attack is successful because the hacker can completely forge the user's request, and all the user authentication information in the request exists in the cookie, so the hacker can directly use the user's own cookie to pass the security authentication without knowing the authentication information. To defend against CSRF, the key is to put information in the request that a hacker cannot forge, and that information does not exist in the cookie. You can add a randomly generated token as a parameter to the HTTP request, and set up an interceptor on the server side to verify the token. If there is no token in the request or the token content is incorrect, it may be a CSRF attack and reject the request.

This method is more secure than checking Referer. Token can be generated after the user logs in and placed in the session, and then the token is taken out of the session and compared with the token in the request each time, but the difficulty of this method is how to add the token to the request in the form of parameters. For GET requests, token is appended to the request address so that URL becomes http://url?csrftoken=tokenvalue. For POST requests, add it at the end of the form so that token is added as a parameter to the request. However, in a website, there are many places where requests can be accepted, so it is troublesome to add token to each request, and it is easy to miss it. The usual method is to use javascript to traverse the entire dom tree each time the page is loaded, and add token to all the an and form tags in dom. This solves most of the requests, but it doesn't work for html code that is dynamically generated after the page is loaded, and requires programmers to manually add token as they code.

Another disadvantage of this method is that it is difficult to ensure the security of token itself. Especially in some forums and other websites that support users to post their own content, hackers can publish the address of their own website. Because the system will also add token to this address, hackers can get the token on their own website and immediately launch a CSRF attack. In order to avoid this, the system can add a judgment when adding token. If the link is linked to its own site, add token later, but not if it leads to the external network. However, even if the csrftoken is not appended to the request as a parameter, the hacker's website can also get the token value through Referer to launch a CSRF attack. This is why some users like to turn off the browser Referer function manually.

(3) customize the attributes in the HTTP header and verify

This method also uses token and validates, unlike the previous method, instead of placing token in the HTTP request as a parameter, it is placed in a custom attribute in the HTTP header. With the class XMLHttpRequest, you can add the HTTP header attribute csrftoken to all requests of this class at once, and put the token value into it. This solves the inconvenience of adding token to the request in the previous method. at the same time, the address requested through XMLHttpRequest will not be recorded in the browser's address bar, and there is no need to worry that token will be leaked to other websites through Referer.

However, this method has great limitations. XMLHttpRequest requests are usually used for asynchronous refresh of partial pages in Ajax methods, not all requests are suitable to be initiated by this class, and the pages obtained through such requests cannot be recorded by the browser, so forward, backward, refresh, collection and other operations bring inconvenience to users. In addition, for legacy systems that do not have CSRF protection, to use this method to protect, to change all requests to XMLHttpRequest requests, it is almost necessary to rewrite the entire website, which is undoubtedly unacceptable.

This is the answer to the question about how to realize the principle analysis of CSRF. I hope the above content can be of some help to you. If you still have a lot of doubts to be solved, you can follow the industry information channel to learn more about it.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.