1.1, attack principle
CSRF (Cross-site request forgery) cross-site request forgery, also known as "One Click Attack" or Session Riding, usually abbreviated as CSRF or XSRF, is a malicious use of websites. Although it sounds like cross-site scripting (XSS), it is very different from XSS. XSS is caused by the arbitrary execution of input from the browser, while CSRF is caused by over-trusting users and allowing them to come from so-called legitimate users who have passed authentication. An attack carried out by requesting to perform a certain function of the website. Compared with XSS attacks, CSRF attacks are often less popular (so the resources to prevent them are also quite scarce) and difficult to prevent. CSRF is more dangerous than XSS.
1.2, case analysis
Background: A user was attacked by CSRF during normal transfer, and his account balance was stolen
1) User Bob initiates a transfer request to the bank http://bank.com.cn/transfer?account=bob&amount=1000000&for=bob2, at this time, the server verifies Bob's identity through the verification session, and Bob completes the normal transfer operation
2) The hacker Lisa also opened an account in the same bank and initiated a transfer request to the bank: http://bank.com.cn/transfer?account=bob&amount=1000000&for=lisa, Lisa identity verification failed, the request failed
3) There is a CSRF vulnerability in this website. Lisa forged a URL or a hyperlink image with the embedded code http://bank.com.cn/transfer?account=bob&amount=1000000&for=lisa, and induced Bob to click on this URL or image At this time, the request will initiate a request from Bob’s browser to the bank with Bob’s cookie attached. Bob has just visited the bank’s website and the Session value has not expired. The browser’s cookie contains Bob’s authentication information
4) Tragedy happened! The request http://bank.com.cn/transfer?account=bob&amount=1000000&for=lisa sent to the bank server through Bob's browser will be executed, and the money in Bob's account will be transferred to the Lisa account
5) Traceability and accountability cannot be traced. The bank log shows that there is indeed a legitimate request from Bob himself to transfer funds, and there is no trace of being attacked.
1.3, APPSCAN test process
APPSCAN removes the HTTP headers that may interfere with the CSRF attack, and uses the forged Referer header http://bogus.referer.ibm.com/ to initiate a request to the server. If the application server returns normally, it is judged that the application is vulnerable to cross-site request forgery attacks .
POST /tg/supplier/supplyFreezeSearch.do HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Accept-Language: en-US
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Referer: http://bogus.referer.ibm.com
Host: pxxx-core-xxxx.com.cn
User-Agent: Mozilla/4.0 (compatible; MSIE 9.0; Win32)
ec_i = ec & ec_eti = & ec_ev = & ec_efn = & ec_crd = 15 & ec_f_a = & ec_p = 1 & ec_s_supplyId = & ec_s_supplyName = & ec_s_reason = & ec_s_flagMean = & ec_s_cdate = & ec_s_beginDate = & ec_s_acceName = & __ ec_pages = 2 & ec_rd = 50 & ec_f_supplyId = 1234 & ec_f_supplyName = 1234 & ec_f_reason = 1234 & ec_f_flagMean = 1234 & ec_f_cdate = 1234 & ec_f_beginDate = 1234 & ec_f_acceName = 1234
HTTP/1.1 OK
Date: Mon, 10 Apr 2018 15:17:54 GMT
Location: http://pxxx-core-stg2.paic.com.cn/login
X-Powered-By: Servlet/2.5 JSP/2.1
Set-Cookie: WLS_HTTP_BRIDGE=Ln1YOmot2_3Gzn7sonux8lIOYaSafCnOVQZzmUl8EjaP1lHMMwqP!-1955618416; path=/; HttpOnly
<html><head><title>Welcome to XXX system</title></head>
1.4, defense suggestions
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. Under normal circumstances, a request to access a secure restricted page comes from the same website. For example, to access http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory, the user must first log in to bank.example and then pass Click the button on the page to trigger the transfer event. At this time, the Referer value of the transfer request will be the URL of the page where the transfer button is located, usually an address beginning with the bank.example domain name. If a hacker wants to implement 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 points to the hacker's own website. Therefore, to defend against CSRF attacks, the bank website only needs to verify the Referer value for each transfer request. If it is a domain name starting with bank.example, it means that the request comes from the bank website itself and is legitimate. If the Referer is another website, it may be a CSRF attack by a hacker and reject the request.
2) Add the token to the request address and verify that the CSRF attack is successful because the hacker can completely forge the user’s request. All the user authentication information in the request is in the cookie, so the hacker can do without knowing these verifications. In the case of information, the user’s own cookie is directly used to pass the security verification. To resist CSRF, the key is to include information that hackers cannot forge in the request, and that information does not exist in the cookie. You can add a randomly generated token as a parameter to the HTTP request, and establish an interceptor on the server side to verify the token. If there is no token in the request or the content of the token is incorrect, the request may be rejected because of a CSRF attack. .
3) Customize attributes and verify in the HTTP header. This method also uses tokens and performs verification. The difference from the previous method is that instead of putting the token in the HTTP request as a parameter, it It is placed in a custom attribute in the HTTP header. Through the XMLHttpRequest class, you can add the HTTP header attribute csrftoken to all requests of this type at one time, and put the token value in it. This solves the inconvenience of adding a 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 about the token being leaked to other websites through the Referer.
4) Use audited libraries or frameworks that do not allow this weakness, such as: OWASP CSRFGuard: http://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet
"ESAPI Session Management" control http://www.owasp.org/index.php/ESAPI
5) Ensure that there are no XSS vulnerabilities, because XSS usually leads to the theft of user identity information
6) Do not use the GET method for any request that triggers a state change
1.5, the actual repair plan
By configuring the filter in web.xml to filter the corresponding request, inherit the OncePerRequestFilter.java parent class in the filter class, and then perform the corresponding matching judgment on the request header in the corresponding filter. If it does not match, it is considered to be a kind of The request of CSRF attack will not be executed.
The filter condition (url-pattern) should be configured according to the actual situation, sometimes it is not necessarily the request at the end of .do or .html to report this vulnerability. At this time, other configurations need to be performed according to the actual situation, and /* may be required for globalization Request a match.
At the same time, the web.xml in the server may be overwritten by the cache file web_merged.xml, causing the configuration newly added to the web.xml to become invalid, resulting in the old configuration in the cache file being executed. This requires attention. Solution: Shut down the server, delete the cache file, and then restart the service.
