Reprint address: http://www.phpddt.com/reprint/csrf.html
CSRF concept: CSRF cross-site request forgery (Cross-Site Request Forgery), like XSS attack, has huge harm, you can understand it in this way:
the attacker steals your identity and sends malicious requests in your name. To the server, this request is completely legal, but it completes an operation expected by the attacker, such as sending emails and messages in your name, stealing your account, adding system administrators, or even purchasing goods, virtualizing Currency transfer, etc. As follows: where Web A is a website with CSRF vulnerability, Web B is a malicious website constructed by an attacker, and User C is a legitimate user of Web A's website.
The attack principle and process of CSRF attack are as follows:
1. User C opens a browser, visits trusted website A, and enters a user name and password to request to log in to website A;
2. After the user information is verified, website A generates cookie information and returns it to the browser. At this time, the user successfully logs in to website A, and the request can be sent to website A normally;
3. Before the user exits website A, in the same browser, open a TAB page to visit website B;
4. After the website B receives the user request, it returns some offensive codes and sends a request to visit the third-party website A;
5. After receiving these offensive codes, the browser sends a request to website A according to the request of website B , carrying the cookie information without the user's knowledge . Website A does not know that the request is actually initiated by B , so it will process the request with C 's authority according to user C 's cookie information , resulting in the execution of malicious code from website B.
CSRF attack example
The victim Bob has a deposit in the bank. By sending a request to the bank's website http://bank.example/withdraw?account=bob&amount=1000000&for=bob2, Bob can transfer the 1000000 deposit to the account of bob2. Normally, after the request is sent to the website, the server will first verify whether the request comes from a valid session, and the user Bob of the session has successfully logged in.
The hacker, Mallory, who has an account at the bank himself, knows that the URL above can transfer money. Mallory can send a request to the bank itself: http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory. But this request is from Mallory and not Bob, he cannot pass security authentication, so the request will not work.
At this time, Mallory thought of using CSRF attack method, he first made a website by himself, put the following code in the website: src=”http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory”, and passed Advertisements etc. lure Bob to visit his website. When Bob visits the website, the above url will be sent from Bob's browser to the bank, and this request will be sent to the bank's server along with the cookie in Bob's browser. Most of the time, the request will fail because it requires Bob's authentication information. However, if Bob happens to have just visited his bank at the time, the session between his browser and the bank's website has not expired, and the browser's cookie contains Bob's authentication information. At this point, tragedy strikes, the url request will be responded, and the money will be transferred from Bob's account to Mallory's account without Bob's knowledge at the time. After Bob finds that the account has less money, even if he goes to the bank to check the log, he can only find that there is indeed a legitimate request from himself to transfer the funds, and there is no trace of being attacked. And Mallory can get the money and get away with it.
CSRF Vulnerability Detection:
Detecting CSRF vulnerabilities is a tedious task. The easiest way is to grab a normal request packet, remove the Referer field, and then resubmit. If the submission is still valid, then it can basically be determined that CSRF exists. Vulnerability.
With the deepening of CSRF vulnerability research, some tools for detecting CSRF vulnerabilities, such as CSRFTester and CSRF Request Builder, have emerged.
Taking the CSRFTester tool as an example, the testing principle of the CSRF vulnerability detection tool is as follows: When using CSRFTester for testing, we first need to grab all the links and all forms and other information we have visited in the browser, and then modify the corresponding information in CSRFTester. Form and other information, resubmit, which is equivalent to a fake client request. If the modified test request is successfully accepted by the website server, it means that there is a CSRF vulnerability. Of course, this tool can also be used to carry out CSRF attacks.
Defense against CSRF attacks:
At present, there are three main strategies for defending against CSRF attacks: verifying the HTTP Referer field; adding a token to the request address and verifying; customizing attributes in the HTTP header and verifying.
(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 security-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 starting with the domain name of bank.example. If a hacker wants to carry out CSRF attack on the bank's 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 its Referer value for each transfer request. If the domain name starts with bank.example, it means that the request is from the bank website itself and is legal. If the Referer is another website, it may be a hacker's CSRF attack and reject the request.
The obvious advantage of this method is that it is simple and easy to implement. Ordinary developers of the website do not need to worry about CSRF vulnerabilities. They only need to add an interceptor to all security-sensitive requests at the end to check the value of Referer. 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, and it is very convenient.
However, this method is not foolproof. The value of Referer is provided by the browser. Although there are clear requirements on the HTTP protocol, each browser may have different implementations of Referer, which does not guarantee that the browser itself has no security holes. Using the method of verifying the Referer value is to rely on the third party (ie the browser) to ensure the security. In theory, this is not safe. In fact, for some browsers, such as IE6 or FF2, there are already ways to tamper with the Referer value. If the bank.example website supports IE6 browsers, hackers can completely set the Referer value of the user's browser to an address starting with the domain name of bank.example, so that they can pass the verification and conduct CSRF attacks.
Even with the latest browsers, hackers cannot tamper with the Referer value, and this approach is still problematic. Because the Referer value will record the user's access source, some users think that this will violate their own privacy, especially some organizations are worried that the Referer value will leak some information in the organization's internal network to the external network. Therefore, the user himself can set the browser so that it does not provide a Referer when sending a request. When they visit the bank website normally, the website will consider it a CSRF attack because the request has no Referer value, and deny access to legitimate users.
(2) Add the token to the request address and verify
The reason why the CSRF attack is successful is that the hacker can completely forge the user's request. All the user authentication information in the request exists in the cookie, so the hacker can directly use the user's own cookie without knowing the authentication information. to pass security verification. 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. A randomly generated token can be added to the HTTP request in the form of a parameter, and an interceptor can be established on the server side to verify the token. If there is no token in the request or the token content is incorrect, it is considered to be a CSRF attack and the request is rejected .
This method is safer than checking the Referer. The token can be generated after the user logs in and placed in the session, and then the token is taken out of the session for each request and compared with the token in the request, but this The difficulty of this method is how to add the token as a parameter to the request. For GET requests, the token will be appended to the request address, so that the URL becomes http://url?csrftoken=tokenvalue. For POST requests, add <input type=”hidden” name=”csrftoken” value=”tokenvalue”/> at the end of the form, so that the token is added to the request as a parameter. However, in a website, there are many places that can accept requests. It is very troublesome to add a token to each request, and it is easy to miss. The usual method is to use javascript to traverse every time the page is loaded. For the entire dom tree, add the token after all the a and form tags in the dom. This can solve most of the requests, but for the html code that is dynamically generated after the page is loaded, this method has no effect, and the programmer needs to manually add the token when coding.
Another disadvantage of this method is that it is difficult to ensure the security of the token itself. Especially in some forums and other websites that support users to publish their own content, hackers can publish the address of their own personal website on it. Since the system will also add a token to this address, hackers can get this token on their own website and launch CSRF attacks immediately. In order to avoid this, the system can add a judgment when adding the token. If the link is linked to its own website, it will add the token later, and if it is connected to the external network, it will not be added. However, even if the csrftoken is not attached to the request in the form of a parameter, the hacker's website can also obtain the token value through Referer to launch CSRF attacks. This is also the reason why some users like to manually turn off the referer function of the browser.
(3) Customize attributes in HTTP headers and verify
This method also uses the token for verification. The difference from the previous method is that the token is not placed in the HTTP request in the form of a parameter, but is placed in a custom attribute in the HTTP header. Through the XMLHttpRequest class, you can add the csrftoken HTTP header attribute to all requests of this type at one time, and put the token value into 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 Referer.
However, the limitations of this method are very large. The XMLHttpRequest request is usually used for the asynchronous refresh of the page in the Ajax method. Not all requests are suitable to be initiated by this class, and the page obtained through this class of request cannot be recorded by the browser, so as to move forward, backward, and refresh. , Favorites and other operations will bring inconvenience to users. In addition, for legacy systems without CSRF protection, to use this method for protection, all requests must be changed to XMLHttpRequest requests, which almost rewrites the entire website, which is undoubtedly unacceptable.