Implement csrf defense in spring MVC applications, GenerallyEyal LupuThe basic idea of this solution is to insert a random number as the signature when generating the form, and then sign the form after it is submitted. Verify , According Verify The result indicates whether the form is a valid form signed by the application. If the signature is incorrect or the signature does not exist, the request may have been hijacked.
The clever use of the Eyal Lupu solution is that by using the combination of the reuqestdatavalueprocessor introduced in handlerinterceptoradapter and spring3.1, the signature and verification processes are seamlessly integrated into existing applications. Objects at the Controller or model layer can still focus only on their own business logic, so there is no need to consider the existence of the csrf process. The only restriction is on the view layer, you must use the <form> label of spring to render the form.
The request is verified in the prehandle method of the Interceptor. When the verification succeeds, the method returns true, and the request continues to be passed along the processing chain. However, if the verification fails, the method returns false, the request will be intercepted and an HTTP 400 status will be sent.CodeAs a response.
If. use error-page in XML to customize the error page for the application. The 400 status code is sent directly to the client browser, and the browser displays a default error page, so far, everything is perfect.
However, if an error page is specified using error-page, the servlet container first forwards the original request to the specific error page based on the response status code, then the error page is sent to the client browser. Note that because the interceptor is used, this forward request will be blocked again, and the verification process in the prehandle method will be triggered again, verification will fail again, because the specific request is still the original request.
The solution is as follows: 1. Add MVC: default-servlet-handler to spring's dispatcher-servlet. The purpose of this operation is to ensure that requests that are not actually processed by the dispatcher, such as forwarding to the error page or accessing static resources, will be sent back to the servlet container.
2. Modify the prehandle method to check the type of the third parameter of the method at the beginning of the method. This parameter indicates the next object in the processing link that will process the request. If this parameter is an instance of the defaultservlethttprequesthandler class, the request will be processed by the servlet container and can be directly released for such requests.
3. Finally, make sure that all URLs declared in errro-page are not processed by any controller or resourcehttprequesthandler. After being processed by the Controller, there is no chance to send the request along the processing chain to the servlet container. In addition, the application
Average
MVC: resources will be used in dispatcher to declare static resources. If the error page is included, the request will be first sent to defaservservlethttprequesthanlder
Resourcehttprequesthandler matches. To optimize the processing of static resources, the latter only supports the get and head methods by default. In this case, the request is sent from the form post, therefore, a request method 'post' not ororted error is thrown, while the browser can only get a 405 response, and the expected error page cannot be displayed.
The adjusted prehandle method is similar to the following:
Public Boolean prehandle (httpservletrequest request, httpservletresponse response, Object Handler) throws exception {If (handler instanceof defaservservlethttprequesthandler) {return true;} If (! Request. getmethod (). equalsignorecase (webcontentgenerator. method_post) {// ignore non-POST request return true;} else {// verify csrf signature // If (passed) // return true; // else {// response. senderror (httpservletresponse. SC _bad_request, // "bad or missing csrf value"); // return false ;//}}}
