CSRF attack Case Analysis Report

Www.2cto.com: a promotional article on the log store website. You can refer to the technical content.

Recently, a webmaster analyzed the log using the Log service and found that some suspicious IP addresses regularly generate a large number of accesses to the third-party interfaces of the website, affecting the normal operation of the website's business. After communicating with the webmaster, the security team determined that this was a typical CSRF attack.
 
In response to this attack, the log security team released the CSRF attack case analysis report:
 
Event Background:
 
1. When Using Log Service for routine analysis, the webmaster found that the access volume of the IP address in the top 20 statistics was significantly higher than that of the 2nd-bit IP address, resulting in a large number of abnormal access
 
2. The third-party interface of the website is used to get in touch with users through the network phone. Many users have received complaints that they have not used the interface and received a large number of unknown calls.
 
3. A large number of sensitive URL accesses are found in the log security analysis report, and the access source is consistent with the IP address.
 
To solve the preceding problems, we use Log service to analyze website logs and find that there are a large number of access requests similar to the following in log files:
 
X. x -- [25/Aug/2012: 00: 18: 05 + 0800] "GET/manage/call. php? U = 1234 & sms = 13812345678 HTTP/1.1 "200 3284
 
Then contact the user to obtain the source code of the script and find that there are three programming security problems in the script file:
 
1. The script file does not perform permission verification on user login information. external users can directly access this interface without logon.
 
2. The script file uses $ _ REQUEST to obtain parameters. There is no difference between GET and POST methods. As a result, you can directly construct form parameters in the URL.
 
3. The script file does not confirm the user identity. In combination with the XSS vulnerability, You can initiate an access request as any user and call the harassing call to any user through a third-party network call interface, form a CSRF attack.
 
To address these problems, the log security team helped users propose code-level solutions:
 
1. Added permission control. When using interfaces, you must verify whether the user is a logged-on user on this site.
 
2. Use $ _ POST to obtain form variables. Do not use $ _ REQUEST to obtain form variables.
 
3. Defend against CSRF attacks (3 methods ):
 
3.1 Add a verification code. This method adds an additional user interaction behavior, which compromises the user experience of the website and affects the Interface Usage conversion rate.
 
3.2 determine the interface access source (HTTP Referer). This method checks whether the user accesses the interface through normal calls by judging the webpage Referer. However, because the Referer can be forged on the client, therefore, CSRF attacks cannot be effectively prevented.
 
The code for forging a Referer is as follows:
 
<? Php
 
Header ("Referer: www.rizhibao.com");
 
$ A = file_get_contents ('HTTP: // www.secrule.com ');
 
Echo $;
 
?>
 
Through packet capture, we can see that the referer has been tampered:
 
 
 
3.3 Add a one-time session token. This method does not add additional user interaction behaviors and effectively prevents CSRF attacks. The code implementation principle is as follows:
 
Create a one-time random token value and store the token value in the session.
 
$ Decsrf = md5 (mt_rand (0, mt_getrandmax (). 'This _ a_very_strong_key ');
 
$ _ SESSION ['srf'] = $ decsrf;
 
Then, add the hidden input element to the front-end POST form and automatically submit the token value to the background verification page.
 
<Input type = "hidden" name = "decsrf" value = "<? = $ Descrf?> ">
 
Finally, on the background verification page, check whether the request is legal and whether the token value passed by the user is consistent with the token value saved in the seesion.
 
If (empty ($ _ POST ['srf']) | $ _ POST ['decsrf']! = $ _ SESSION ['srf']) {
 
$ This-> errmsg. = "<li> Data Exception! </Li> ";
 
Exit;
 
} Else {
 
Unset ($ _ POST ['srf']); // destroy the one-time token
 
...
 
Normal processing logic
 
...
 
}
 
4. added a time limit to limit the access request interval of this interface. For example, you can only access this interface once in 30 seconds to prevent interface calls from consuming server resources too frequently.
 
Logstore has helped you successfully handle this security attack. From this security attack, we can see that CSRF attacks target website users rather than the website server itself. Although different from SQL injection attacks, attackers can directly obtain sensitive data on the website, however, CSRF attacks can be used to initiate phishing, fraud, and other malicious behaviors against normal users based on the website's own business, which affects the normal operation of the website's services and has a great negative impact on the website, webmasters also need to pay more attention to such attacks.