java禁止不需要的HTTP 方 法

项目安全扫描，报告：
启用了不安全的HTTP 方法
安全风险：
      可能会在Web 服务器上上载、修改或删除Web 页面、脚本和文件。
可能原因：
      Web 服务器或应用程序服务器是以不安全的方式配置的。
修订建议：
      如果服务器不需要支持WebDAV，请务必禁用它，或禁止不必要的HTTP 方法。
WebDAV （Web-based Distributed Authoring and Versioning）是基于 HTTP 1.1 的一个通信协议。它为 HTTP 1.1 添加了一些扩展（就是在 GET、POST、HEAD 等几个 HTTP 标准方法以外添加了一些新的方法），使得应用程序可以直接将文件写到 Web Server 上，并且在写文件时候可以对文件加锁，写完后对文件解锁，还可以支持对文件所做的版本控制。这个协议的出现极大地增加了 Web 作为一种创作媒体对于我们的价值。基于 WebDAV 可以实现一个功能强大的内容管理系统或者配置管理系统。
方法简介：
除标准的GET和POST方法外，HTTP请求还使用其他各种方法。许多这类方法主要用于完成不常见与特殊的任务。如果低权限用户可以访问这些方法，他们就能够以此向应用程序实施有效攻击。以下是一些值得注意的方法：
  PUT   向指定的目录上载文件
  DELETE   删除指定的资源
  COPY   将指定的资源复制到Destination消息头指定的位置
  MOVE   将指定的资源移动到Destination消息头指定的位置
  SEARCH   在一个目录路径中搜索资源
  PROPFIND   获取与指定资源有关的信息，如作者、大小与内容类型
  TRACE   在响应中返回服务器收到的原始请求
其中几个方法属于HTTP协议的WebDAV（Web-based Distributed Authoring and Versioning）扩展。

渗透测试步骤：
使用OPTIONS方法列出服务器使用的HTTP方法。注意，不同目录中激活的方法可能各不相同。
许多时候，被告知一些方法有效，但实际上它们并不能使用。有时，即使OPTIONS请求返回的响应中没有列出某个方法，但该方法仍然可用。
手动测试每一个方法，确认其是否可用。

使用curl测试：

curl -v -X OPTIONS http://www.example.com/test/

查看响应的 Allow: GET, HEAD, POST, PUT, DELETE, OPTIONS

curl -v -T test.html  http://www.example.com/test/test.html

看是否能上载来判断攻击是否生效。

找一个存在的页面，如test2.html

curl -X DELETE http://www.example.com/test/test2.html

如果删除成功，则攻击有效。

解决方案：
如tomcat，配置web.xml

<security-constraint>
<web-resource-collection>
<web-resource-name>fortune</web-resource-name>
<url-pattern>/*</url-pattern>
<http-method>PUT</http-method>
<http-method>DELETE</http-method>
<http-method>HEAD</http-method>
<http-method>OPTIONS</http-method>
<http-method>TRACE</http-method>
</web-resource-collection>
<auth-constraint></auth-constraint>
</security-constraint>
<login-config>
<auth-method>BASIC</auth-method>
</login-config>

重启tomcat即可完成。
以上的代码添加到某一个应用中，也可以添加到tomcat的web.xml中，区别是添加到某一个应用只对某一个应用有效，如果添加到tomcat的web.xml中，则对tomcat下所有的应用有效。



配置web.xml来限制对某些servlet的请求

有时我们只希望通过认证的用户才能请求某些servlet的话，就可以在web.xml中来进行相应的配置，来达到此目的。

这就要用到<security-constraint></security-constraint>元素。
对于tomcat，中web.xml使用security-constraint元素需要在位于<Tomcat-installation-directory>/conf/tomcat-users.xml的XML文件中创建用户名和密码。比如下面的这个tomcat-users.xml文件：

<?xml version='1.0' encoding='utf-8'?>
<tomcat-users>
  <role rolename="tomcat"/>
  <role rolename="manager"/>
  <role rolename="admin"/>
  <user username="tomcat" password="tomcat" roles="tomcat"/>
  <user username="both" password="tomcat" roles="tomcat,manager"/>
  <user username="admin" password="admin" roles="admin"/>
</tomcat-users>

此XML片段包括一个tomcat-users根元素，它包含一个或多个role和user元素。


然后在Web应用程序的web.xml中创建security-constraint、login-config和security-role元素。

<security-constraint>
      <web-resource-collection>
          <web-resource-name>HelloServlet</web-resource-name>
          <url-pattern>/HelloServlet</url-pattern>
          <http-method>GET</http-method>
          <http-method>POST</http-method>
      </web-resource-collection>
      <auth-constraint>
          <description>This applies only to the "tomcat" security role</description>
          <role-name>admin</role-name>
      </auth-constraint>
      <user-data-constraint>
          <transport-guarantee>NONE</transport-guarantee>
      </user-data-constraint>
  </security-constraint>

  <login-config>
      <auth-method>BASIC</auth-method>
  </login-config>
  <security-role>
      <role-name>admin</role-name>
  </security-role>

其中security-constraint元素包含一个或多个web-resource-collection元素，它是描述Web应用程序中的哪些web资源受到指定安全限制的保护。http-method元素指定安全限制覆盖的HTTP方法。上面的例子中，当我们对/HelloServlet的GET或POST请求时将触发配置的安全机制。
auth-constraint元素用于描述允许访问Web组件的安全角色。此例中安全角色的例子有tomcat、manager、admin。而只有当作为admin角色的用户才可以访问HelloServlet。

Web应用程序通过login-config元素来认证用户，并确认该用户是否为正确的角色。
longin-config包含的transport-guarantee子元素用来指定认证方法，BASIC是一种常见的Web认证方式，浏览器给用户提示一个对话框，要求输入用户名和密码，随后Tomcat将给出的用户名和密码与tomcat-users.xml中的用户名和密码进行比较，然后使用前面的security-constraint配置来确定用户是否可访问受保护的servlet。

（除BASIC外，还可以是FORM、CLIENT-CERT、DIGEST等）

其实这种认证方法实际上有两个步骤：
1、检查提供的用户名和密码是否正确。
2、判断用户是否映射到特定的安全角色。例如，用户可能提供了正确的用户名和密码，但没有映射到特定的安全角色，也将被禁止访问特定的Web资源。