Cross-site request forgery CSRF attack and defense

What is a. csrf?

CSRF (Cross-site request forgery), Chinese name: cross-site requests forgery, also known as: one click Attack/session Riding, abbreviated as: CSRF/XSRF.

Two. What can csrf do?

You can understand that. CSRF attack: An attacker steals your identity and sends a malicious request on your behalf. The things that CSRF can do include: Send mail in your name, message, steal your account, even buy goods, virtual money transfer ... Issues include: personal privacy breaches and property security.

Three. CSRF Vulnerability status

Csrf This attack method in 2000 has been put forward by foreign security personnel, but at home, until 06 began to be concerned, 08, a number of large communities and interactive sites at home and abroad, respectively, CSRF loopholes, such as: NYTimes.com (New York Times), MetaFilter (a large blog site), YouTube and Baidu Hi ... Now, many sites on the Internet remain defenseless, so that the security industry calls CSRF "the Sleeping Giant".

Four. Principle of CSRF

To complete a csrf attack, the victim must complete two steps in turn:

1. Log on to trusted Web site A and generate cookies locally.

2. If you do not log out a, visit the dangerous website B.

See here, you may say: "If I do not meet one of the above two conditions, I will not be attacked by CSRF". Yes, it does, but you cannot guarantee that the following will not happen:

1. You cannot guarantee that once you have logged into a website, you will no longer open a tab page and visit another site.

2. You cannot guarantee that your local cookie will expire immediately after you close your browser, and that your last session has ended. (In fact, closing a browser does not end a session, but most people will mistakenly think that closing the browser is tantamount to quitting the login/end session ...) ）

3. The so-called attack site may be a trusted, often-visited website with other vulnerabilities.

Above about the idea of CSRF attack, I will use a few examples to detail the specific CSRF attack, here I take a bank transfer operation as an example (just an example, the real bank website is not so silly:>)

Example 1:

Bank website A, which completes bank transfer operations with a GET request, such as: http://www.mybank.com/Transfer.php?toBankId=11&money=1000

Dangerous website B, it contains a section of HTML code as follows:

　　

First, you log in to the bank website A, then visit dangerous website B, Oh, then you will find that your bank account is 1000 dollars less ...

Why is that? The reason is that bank Web site a violates the HTTP specification and uses GET requests to update resources. Before visiting the dangerous site B, you have logged into the bank website A, and B in the form of a GET request for third party resources (the third party here refers to the bank website, originally this is a legitimate request, but this is used by criminals), So your browser will take your bank website A's cookie to make a GET request to get the resource "http://www.mybank.com/Transfer.php?toBankId=11&money=1000", As a result, the Bank website server receives the request, thinks this is an update resource operation (transfers the operation), therefore immediately carries on the transfer operation ...

Example 2:

To eliminate the above problem, the bank decided to use the POST request to complete the transfer operation.

The Web Form for bank website A is as follows:

The background processing page transfer.php as follows:

Dangerous site B, still just contains the HTML code:

　　

As in Example 1, you first log on to bank site A, then visit dangerous sites B, and the results ..... As in Example 1, you do not have 1000 ~t_t again, the cause of this accident is: the bank used $_request to obtain the requested data, and $_request can obtain the data of the GET request, but also can get the data of the POST request, This causes the data in the spooler to not differentiate whether this is a GET request or a POST request. In PHP, you can use $_get and $_post to get the data for GET requests and post requests separately. In Java, there is an issue that does not differentiate between GET request data and post data for request data requests.

Example 3:

After the previous 2 painful lesson, the bank decided to get the request data method also changed, instead of $_post, only to obtain the POST request data, background processing page transfer.php code as follows:

However, dangerous website B has changed its code by changing the Times:

If the user still continues the above operation, unfortunately, the result will be missing 1000 blocks again ... Because here Dangerous website B secretly sent a POST request to the bank!

Summing up the above 3 examples, CSRF main attack mode is basically the above 3, of which the 1th, 2 is the most serious, because the trigger is very simple, one can, and the 3rd is more troublesome, need to use JavaScript, so the use of the opportunity is much less than the previous, but regardless of the situation , as long as the csrf attack is triggered, the consequences can be serious.

Understanding the above 3 attack modes, in fact, can be seen, CSRF attack is a web-based implicit authentication mechanism! Although the authentication mechanism of the Web can guarantee that a request is from a user's browser, there is no guarantee that the request was sent by the user!

Five. CSRF's defense

There are many kinds of prevention mechanism of CSRF, and the methods of prevention are constantly evolving according to the escalation of CSRF attack mode. Commonly used to check the Refer head information, using a one-time token, using verification pictures and other means. For performance reasons, if each request is added to the token validation will greatly increase the burden on the server, the use of that method is more reasonable, you need to carefully review the pros and cons of each protection.

1. Check HTTP header Refer information, which is the simplest and easiest way to prevent CSRF from being implemented. According to the RFC definition of Refer inside the HTTP protocol, the Refer information follows the header of each HTTP request. After the Server receives the request, it can check the header information and only accept requests from the domain to ignore the external domain, which can avoid many risks. Of course, this way of checking is too simple and has its own weaknesses:

A) The first is to check the Refer information and not to prevent attacks from this domain. In the Enterprise business website, there will often be the same domain forum, mail and other forms of WEB applications exist, from these places the CSRF attack carries is the domain Refer domain information, therefore cannot be blocked by this kind of defense.

b) Similarly, some of the way to send HTTP requests directly (referring to non-browsers, such as the use of background code, etc.) can forge some Refer information, although the direct header information forgery is directly sent requests, it is difficult to follow the sending of cookies, but due to the current client means endless, flash, JavaScript and other large-scale use, from the client to refer forgery, especially in the client browser installed more and more plug-ins in the case has become possible.

2. Use a one-time token, which is widely used by designers of the current WEB application, by adding a token to the URL for a Get request, and adding a token to the hidden field for a Post request. This token is generated by the server side, which is controlled by the programmer to bring the request with the token and then validate it on the server side when the client sends the request. However, there are several wrong scenarios in the design of tokens:

A) use and Session independent token generation method. The value of this token is independent of the Session and is therefore easily forged by other users. Other users here refer to other users of the current WEB application and listeners who are active in the various settings on the network transmission stage, a malicious user who may use his or her own token to replace it for the purpose of forgery.

b) Fully use Session authentication information as the token generation method. This protection is useful for protecting CSRF, but may cause other hazards, specifically, if certain URLs or Web pages are copied and shared with others, these URLs or pages that are copied may contain user session information that, once obtained by a malicious user, can cause great harm.

Therefore, a correct token design should be the use of Session information to do hash, with the resulting hash value to do CSRF tokens.

3. The use of the verification picture, the appearance of this method is to prevent the violent attack of the robot. But in CSRF's defense, there are some high security requirements of the application combined with the verification of images and a one-time token to do double protection. Because this kind of picture verification information is difficult to be identified by the malicious program on the client, it can improve the protection more strongly. When the client's browser may already be in an insecure environment (for example, the client's security level setting is low, the client browser has an unsafe plugin installed, and so on).

These are just some of the more common ways to guard against CSRF, WEB developers can determine the security level requirements based on their own understanding of the functionality of their application and choose to use different protections, and it is recommended to use multiple methods within the same application for protection.

Note: Add protection will also greatly affect performance, such as on the high-speed road to put a toll station, it is recommended only in the important operation of the defense. As a bit of careful consideration.

