omcat禁用OPTIONS协议

冷冷七弦上,静听松风寒 
最近我们平台的项目被送去扫描漏洞,在测试结果中,其中有一项漏洞是: 启用了OPTIONS方法:攻击者可以发送OPTIONS方法，从系统的响应中获得系统已启用的HTTP方法列表 
解决方案: 
你可以在项目的web.xml或者tomcat服务器的web.xml上配置,不同在于,配置项目只是对本项目起作用,配置在tomcat上,是对tomcat下的所有项目均起作用; 
打开tomcat–>conf–>web.xml 文件: 

把图中红框中的部分替换为:

<web-app xmlns="http://java.sun.com/xml/ns/j2ee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
         version="2.4">

• 1
• 2
• 3
• 4

然后在下面追加:

<security-constraint>
        <web-resource-collection>
            <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>

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15

<http-method> 元素里面的的协议即是要被禁止的协议类型; 
看效果: 
用命令测:

crul -v -X OPTIONS http://localhost:8080/login.jsp

• 1

在没有禁止前,测试结果如下图: 

很明显可以看到把页面的内容全部直接返回了,这是很危险的; 
替换了Tomcat下的web.xml之后再测试,结果如下: 

效果一目了然; 
接下来,简单解释一下上面各参数: 
<security-constraint> 的子元素 <http-method> 是可选的，如果没有 <http-method> 元素，这表示将禁止所有 HTTP 方法访问相应的资源。 
子元素 <auth-constraint> 需要和 <login-config> 相配合使用，但可以被单独使用。如果没有 <auth-constraint> 子元素，这表明任何身份的用户都可以访问相应的资源。也就是说，如果 <security-constraint> 中没有 <auth-constraint>子元素的话，配置实际上是不起中用的。如果加入了 <auth-constraint> 子元素，但是其内容为空，这表示所有身份的用户都被禁止访问相应的资源。

对于<login-config>: 
当访问服务器中受保护的资源时，容器管理的验证方法可以控制确认用户身份的方式。Tomcat支持四种容器管理的安全防护，它们是：

1. BASIC(基本验证)：通过HTTP验证，需要提供base64编码文本的用户口令
2. DIGEST(摘要验证)：通过HTTP验证，需要提供摘要编码字符串的用户口令
3. FORM(表单验证)：在网页的表单上要求提供密码
4. CLIENT-CERT(客户端证书验证)：以客户端证书来确认用户的身份