To enable the unsafe HTTP method solution

Recently through the AppScan scanning procedures, found a lot of security problems, through a large number of access and try to finally solve the problem, so collated a bit for easy access. 1. An unsecured HTTP method is enabled

The problem is described in this way:

Check the "Allow" header of the original test response and verify that it contains one or more of the following options that are not required: Delte,searce,copy,move,propfind,proppatch,mkcol,lock,unlock,put.

The response header information is as follows:

http/1.1 OK
server:apache-coyote/1.1
allow:get, HEAD, POST, PUT, DELETE, OPTIONS
content-length:0
Date:mon, 10:12:23 GMT

Let's first look at the origins of these methods: HTTP1.0 defines three request methods: GET, POST, and head method; HTTP1.1 adds five new request methods: Options, PUT, DELETE, TRACE, and CONNECT methods.
WebDAV takes a completely HTTP1.1 approach, extends some of the methods, and extends some other methods:
-Options, Head, Trace: Mainly by the application to discover and track the device support and network behavior;
-Get: Retrieve documents;
-Put and Post: Submit the document to the server;
-Delete: Destroys a resource or collection;
-Mkcol: Create Collection
-PropFind and Proppatch: Retrieving and setting properties for resources and collections;
-Copy and move: Manage collections and resources in the context of a namespace;
-Lock and Unlock: Overwrite protection

It is obvious that the above operation details can be uploaded, modified, deleted and so on by the Web server, which poses a threat to the service. Although WebDAV has permission to control but the night of a search is still a lot of attack methods, so if you do not need these methods or recommend the direct blocking is good.

Here's a detailed look at the solutions:
The simplest way to do this is to modify the Web application's XML deployment file. Insert the following lines of code in the inside to get it done, add the method that needs to be blocked inside. If the application package is more or less necessary to change, directly modify the Tomcat Web. XML, so that the instances running in Tomcat will be valid.

<security-constraint>
    <web-resource-collection>
        <web-resource-name>fortune</ web-resource-name>
        <url-pattern>/*</url-pattern>
        
<security-constraint> is used to restrict access to resources, and <auth-constraint> is used to restrict access to resources by those roles, which is set to NULL to prohibit access by all role users; <url-pattern > Specify the resources that need to be validated 
Restarting the service again verifies that there is no problem.