CSRF's attack and defense

CSRF is a common vulnerability of web applications, and its attack characteristics are large but very covert, especially in the context of a large number of Web 2.0 technology applications, where an attacker can launch a csrf attack without the user's awareness. This paper will make a systematic exposition of its basic characteristics, attack principle, attack classification, detection method and precautionary means, and enumerate the attack examples.

Wen/H3C defense Team

1 CSRF Vulnerability Profile

CSRF (Cross-site request forgery, cross-site forgery requests) is a network attack that can be sent to the compromised site without the victim's knowledge of the victim's name forgery, thereby performing an unauthorized operation under rights protection, is of great harm. Specifically, the CSRF attack can be understood in this way: An attacker steals your identity, sends a malicious request on your behalf, is perfectly legal for the server, but accomplishes an action that the attacker expects, such as sending a message in your name, texting, stealing your account, adding a system administrator, Even buy goods, virtual money transfer, etc.

CSRF attack mode is not known to everyone, in fact, many websites have csrf security loopholes. As early as 2000, CSRF's attack was made by foreign security personnel, but at home it was not until 2006 that it began to be watched. 2008, a number of large-scale community and interactive sites at home and abroad have burst csrf loopholes, such as: Baidu Hi, nytimes.com (New York Times), MetaFilter (a large blog site) and YouTube. But until now, many sites on the Internet are still unprepared for this, so that the security industry called CSRF as "sleeping giants", and its threat to the extent of the "reputation" can be seen.

2 CSRF attack Principle and example

CSRF Attack principle

The CSRF attack principle is relatively simple, as shown in 1. Where Web A is a Web site with a csrf vulnerability, Web B is a malicious Web site built by an attacker, and user C is a legitimate user of a Web site.

Figure 1 CSRF Attack principle

1. User C opens the browser, accesses a trusted site A, enters a username and password request to log on to website A;

2. After the user information is verified, website a generates cookie information and returns it to the browser, at which point the user logs on to site a successfully and can send the request to site a normally;

3. Before the user exits site A, in the same browser, open a tab page to access site B;

4. After receiving the user request, website b returns some offensive code and makes a request to access the third party site A;

5. After receiving these offensive codes, the browser, upon request of site B, carries cookie information without the user's knowledge and makes a request to site A. Web site A does not know that the request is actually initiated by B, so the request is processed in accordance with the user C's cookie information, which causes malicious code from site B to be executed.

CSRF Attack Classification

CSRF vulnerability is generally divided into two types of station and station.

CSRF outside the station type of vulnerability is essentially an external data-submission problem in the traditional sense. Usually the programmer will consider a few comments or comments on the form watermark to prevent spam problems (here, spam can be easily understood as spam, spam comments, or a malicious reply with outbound links), but sometimes in order to improve the user's experience, there may be no restrictions on some operations, Therefore, the attacker can predict and set the parameters of the request in advance, in the Web page outside the site to write a script to forge a file request, or the automatic submission of the table as a single use to achieve get, post requests, when the user in the session state click the link to access the external Web page, the client is forced to initiate the request.

CSRF the type of vulnerability in the station is due in part to the misuse of $_request class variables by programmers. In some sensitive operations (such as changing passwords, adding users, etc.), the user is required to initiate a POST request from the form submission to pass parameters to the program, but because of the use of variables such as $_request, the program in addition to support to receive the post request passed parameters, but also support receive GET request pass parameters, This creates conditions for attackers to use CSRF attacks. A typical attacker would be forced to initiate these requests by placing the expected request parameters in the image link of a post or message within the station, where the victim browses to such a page.

CSRF Attack Example

The following is an example of axous 1.1.1 CSRF Add Admin Vulnerability (Vulnerability CVE number: cve-2012-2629), which describes the implementation of the CSRF attack.

Axous is an online store application software. Axous 1.1.1 and earlier versions have a CSRF vulnerability in implementation, which can be exploited by a remote attacker by constructing a specially crafted Web page that can entice the software administrator to gain access to the system administrator by an attacker who successfully exploits this vulnerability. This vulnerability is primarily composed of the following three procedures:

1. The attacker constructs a malicious Web page. Before implementing an attack, an attacker would need to construct a Web page that is basically the same as the normal addition of an administrator user, assign a value to the necessary parameter item in the malicious webpage, and point the action of the webpage to the URL that was accessed when the administrator user was added normally, as shown in core code 2;

2. Attackers use social engineering to entice axous system administrators to access malicious Web pages of their construction;

3. Execute malicious code. When a system administrator accesses a malicious webpage, the malicious code is executed without the administrator's knowledge, and the attacker's bogus administrator account is added successfully.

Figure 2 CSRF attack add admin Core code

3 CSRF Vulnerability Detection

Detection of CSRF vulnerability is a tedious task, the simplest way is to crawl a normal request packet, remove the Referer field and then resubmit, if the commit is still valid, then basically can determine the existence of a csrf vulnerability.

With the deepening of the research on CSRF vulnerability, there are a number of tools, such as CSRFTESTER,CSRF Request Builder, which are designed to detect CSRF vulnerabilities.

Taking the Csrftester tool as an example, the CSRF Vulnerability Detection tool is tested as follows: When testing with Csrftester, you first need to crawl all the links we've visited in the browser, as well as all forms, and then by modifying the information in the corresponding form in Csrftester , resubmit, which is equivalent to a fake client request. If the modified test request is successfully accepted by the Web server, there is a csrf vulnerability, and of course this tool can also be used for CSRF attacks.

4 CSRF Vulnerability Defense

CSRF vulnerability defense can be done from three levels, namely the defense of the server, the defense of the client and the defense of the security device.

4.1 Defense of the service side

At present, the industry server-side defense CSRF attack mainly has three kinds of policies: Verify the HTTP referer field, add token in the request address and verify, customize the attribute in the HTTP header and verify. These three strategies are briefly described below.

4.1.1Validating HTTP referer Fields

According to the HTTP protocol, there is a field called Referer in the HTTP header, which records the source address of the HTTP request. In general, requests to access a secure restricted page must come from the same Web site. For example, a bank transfer is done through the user access to the http://bank.test/test?page=10&userID=101&money=10000 page, the user must first log in to the bank. Test, then trigger the transfer event by clicking on the button on the page. When a user submits a request, the Referer value of the transfer request is the URL of the page where the transfer button is located (in this case, usually the bank. The address at the beginning of the test domain name). And if an attacker wants to implement a csrf attack on a bank website, he can only construct the request on his own website, and when the user sends a request to the bank through the attacker's website, the referer of the request is the website that points to the attacker. Therefore, to defend against CSRF attacks, the bank website only needs to verify its referer value for each transfer request, if it is to bank. The domain name at the beginning of test indicates that the request is from the bank website itself and is legal. If Referer is a different Web site, it could be a csrf attack, and the request will be rejected.

4.1.2Add tokens to the request address and verify

The CSRF attack was successful because an attacker could spoof a user's request that all user authentication information in the request existed in a cookie, so an attacker could use the user's own cookie to pass security verification without knowing the authentication information. The key to defending against a csrf attack is to put in the request information that the attacker cannot forge, and that the information does not exist in the cookie. In view of this, the system developer can add a randomly generated token as an argument in the HTTP request and establish an interceptor on the server side to verify the token, and if no token or token content is incorrect in the request, it may be considered a csrf attack to reject the request.

4.1.3Customize the properties in the HTTP header and verify

The way to customize properties is also to use token and validate, unlike the previous method, where token is not placed in an HTTP request as an argument, but instead placed in a custom attribute in the HTTP header. By XMLHttpRequest This class, you can add Csrftoken this HTTP header attribute to all requests at once, and put the token value into it. This solves the inconvenience of adding tokens to the request, while the address requested by this class is not recorded in the browser's address bar, nor does it worry that tokens will be leaked to other websites via Referer.

4.2 User-side defenses

It is unrealistic for ordinary users to learn and have network security knowledge to defend against cyber attacks. But if the user forms good Internet habit, it can reduce the harm of CSRF attack to a great extent. For example, when the user is online, do not easily click on the web forums, chat rooms, Instant messenger or e-mail messages appear in the links or images, in a timely manner to quit unused login accounts, especially the system administrator, should try to log out of the system in the case of unknown links and pictures. In addition, users need to install the appropriate security software on the Internet-connected computer and update the feature library released by the software vendor to keep the security software in real-time tracking of the latest attacks.

4.3 Defense of security devices

Since the discovery of the vulnerability to the release of the patch takes a certain amount of time, and a considerable proportion of the vendor response to the vulnerability is not positive, coupled with some system administrators to the system patches of insufficient attention, these give attackers an opportunity. In view of the above, users can use third-party professional security equipment to enhance the defense of CSRF vulnerabilities.

The essence of the CSRF attack is that the attacker forged a legitimate identity and accessed the system. A csrf attack can be identified if the identity of the visitor is identified. Research has found that some manufacturers of security products can be based on the hardware level of the HTTP header referer field content checks to quickly and accurately identify CSRF attacks. Figure 3 shows a schematic of this defensive approach. At present, H3C Company's IPs products adopt special technology to support the detection and blocking of csrf vulnerability attacks in some common systems.

Fig. 3 Traditional defense methods for safety equipment

5 concluding remarks

CSRF attacks, as a long-established attack pattern, can be found on a large number of commercial websites. For the majority of the system maintainers need to understand the csrf attack deeply, and make the defense plan which is most suitable for the current system, improve the system security without compromising the performance of the application, and for the network application system that will be developed, understand the harmfulness of csrf deeply, In the design phase, it is considered that the prevention of CSRF will achieve a multiplier effect.

CSRF Attack and Defense (RPM)