CSRF (Cross-Site Request Forgery), Chinese name: cross-site request forgery .
In simple terms you landed on the site A, the results did not quit and so went to the landing site B, and site B contains a malicious request, through your legal status in the A site, they kept sending data to the attack site A.
A, CSRF Attacks
CSRF attacks principle is simple, as shown in FIG. Web A website which is the presence of CSRF vulnerabilities, Web B for attackers to build malicious Web site, User C is a legitimate user Web A site.
1. User C opens a browser, visit trusted sites A, enter your user name and password requests visit the website A;
2. After the user information is verified, Site A Cookie information is generated and returned to the browser, then the user site A successful login, can normally send a request to the site A;
3. Before the user does not exit the site A, in the same browser, open a TAB page visit B;
4. Site B receives the user request, return some of the code attack, and issues a request requires access to third-party site A;
5. Upon receiving the browser attacks of the code, according to a request of the site B, carrying Cookie information without the user's knowledge, a request to the site A. A website does not know that the request is actually initiated by the B, so Cookie information based on user permissions C to C of the request is processed, resulting in the malicious code from the site B is executed.
(1): When we landed a site, because the HTTP protocol is stateless, so in order to preserve our landing state, the server program must create a session file, to save our login information.
(2): In order to be able to switch between each access multiple pages, we recorded state, the file delivery session in response to a server will first session_id corresponding to the client browser. After the browser will receive this value written to a cookie file. When the next time you access the site's content, it will be sent to all client server program, including the storage of cookie session_id cookie end of the site belonging to the local store. If the server needs to detect the requester's identity, it is possible to detect the contents of session files, and file server session if there is a response in accordance with the legality of the passed session_id cookie contained. If the test legitimate, then it is legitimate to authenticate users, otherwise illegal.
(3): If the hackers set up a link to another page, this link points to a site transfer system. And the current user is a member of this site, and landed in the state (that is, there is a legitimate session_id store the cookie on the client browser), then when the user clicks on a link after this, the client browser sends the user of these information is passed to the server, but the link specific to do what, users do not know that it will do a fake identity of the user, the user do not know. .
Two, CSRF vulnerabilities defense
There are three solutions:
(1) limits refer
(2) using the token
(3) codes using techniques
Hereinafter will be Java, for example, the above-mentioned three methods were performed using sample code. Regardless of the method used on the server side interceptors is essential, it is responsible for checking the incoming request meets the requirements, then depending on the result of the request and decide whether to continue or discard. In Java, the interceptor by Filter to achieve. We can write a Filter, and configure it in web.xml to make a request for access to all the resources needed to intercept CSRF protection.
2.1: Verify the HTTP Referer field
According to the HTTP protocol, there is a field called Referer HTTP header, it records the source address of the HTTP request. Under normal circumstances, limited access to a secure page request must come from the same website. For example, a bank transfer is accessed by the user http: //bank.test/test page = 10 & userID = 101 & amp; money = 10000 page is completed, the user must first log bank.test, then transfer triggered by clicking a button on the page? event. When a user submits a request, Referer value of the transfer request is the URL of the page where it will transfer button (in this case, usually in the bank. Address beginning with test domain). And if an attacker to implement CSRF attack on the bank's website, he can only own request construction site, when a user sends a request to the bank through the attacker's Web site, Referer of the request is pointing to the attacker's site. Therefore, to defense CSRF attack, the bank site requires only a transfer request verification for each Referer its value, if based bank. Test at the beginning of the domain name, then the request is a request from their own bank site, is legitimate. If the site Referer other words, there may be a CSRF attack, the request is denied.
In the filter of the authentication code request follows Referer
Listing 1. Verify Referer in the Filter
// 从 HTTP 头中取得 Referer 值 String referer=request.getHeader("Referer"); // 判断 Referer 是否以 bank.example 开头 if((referer!=null) &&(referer.trim().startsWith(“bank.example”))){ chain.doFilter(request, response); }else{ request.getRequestDispatcher(“error.jsp”).forward(request,response); }
The above code first obtain Referer value, and then determine when it is not empty and when that begins bank.example, then continue to request, otherwise it may be a CSRF attack, go error.jsp page.
2.2: Using the token
Token , is the token, the biggest feature is random and unpredictable. Generally hackers or software can not be guessed.
Token generally used in two places:
- 1) to prevent the duplicate form submission,
- 2) anti csrf attacks (cross-site request forgery).
Both are in principle through the session token to achieve. When a client requests a page, the server generates a random number Token, and the Token is placed among the session, then the Token to the client (typically configured by hidden form). The next time the client submits a request, Token submitted along with the form to the server.
Then, if applied to "anti csrf attack", the server will verify Token value, it is determined whether the Token value equal to the session and, if equal, the request can prove effective, not a forgery.
However, if applied to "prevent Form to repeat", the first authentication server after the same, the session will be the Token value update, if resubmit user, the second authentication will fail judgment, because the form submitted by the user the Token has not changed, but the server-side session in the Token has changed
2.2: Use codes technology
The idea of this program is: every time a user submits requires users to fill in random string on a picture in the form, Eritrea .... this program can be completely solved CSRF (principle similar token mechanism), but individuals feel in use seems not very good terms, and heard a verification picture involves the use of a Bug is known as MHTML is likely to be affected in some versions of Microsoft's IE.
Code is mostly supported by the site and register for login. Lies in its role effectively prevent malicious login registration code is different each time, which can be ruled out, automatic application user with a virus or other software and automatic landing. Effectively prevent such problems.
This is the true role of code can prevent others from malicious attacks, and we also note that if you frequently send a verification code, the user registration request will be sent a verification code prompt xx time before, in this setting, too well reduce the impact of malicious websites.
So we have a general understanding about the principle of verification code to achieve:
First, understand that the verification code is generated by the server, in the form of a picture or page displayed in the client, the client's users check in the service layer according to the picture identification verification code and register to submit, submit the verification code, if check is successful, the user registration and log in successfully, and if that fails, ask the user to re-register. Then think about how these pictures are generated, how to verify the code design, code designed to why the format of the picture, but it is difficult to visually identify where the verification code.
Image is randomly generated on the server side, these images can be set a predetermined their height and width, and then draw some interference on the line images, of course, the number of interference lines is manageable, different codes plug or a different site codes varying degrees of interference picture, in general, the higher the level of interference to prevent malicious attacks results will be better. But it will also increase the difficulty of identifying the user, the manufacturing line is to prevent interference programming code to identify the picture or draw a picture of someone verification code through some kind of machine to be registered in bad faith or sabotage. If the human eye can not easily identify a picture of the code, we believe that the identification of the machine at a temperature lower than the human eye, the picture is not easy to get the verification code. Verification code image may be a combination of uppercase and lowercase letters, and the array may be in the form of characters, these characters are generated randomly and splicing. After the image synthesis to achieve verification, it is converted to a string of a string, and then transferred to the front end in the form of a byte array output stream, and displays the corresponding position in the page. Not, while the verification code generated will be accompanied by its unique flag id, expiration time , and then the data typically will be packaged together to the cache server, the user input authentication code and returns, be verified on the server , and the results returned to the front end interface verification. These are the general principle verification code.