解決 Tomcat禁用OPTIONS協議（不安全的HTTP方法）

轉載：https://blog.csdn.net/A_Runner/article/details/80618023

最近我們平台的項目被送去掃描漏洞,在測試結果中,其中有一項漏洞是: 啟用了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">

然后在下面追加:

<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>

 

<http-method> 元素里面的的協議即是要被禁止的協議類型; 
看效果: 
用命令測:

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

在沒有禁止前,測試結果如下圖: 

很明顯可以看到把頁面的內容全部直接返回了,這是很危險的; 
替換了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(客戶端證書驗證)：以客戶端證書來確認用戶的身份

參考至:https://blog.csdn.net/lisheng19870305/article/details/40819481 
https://my.oschina.net/u/2419285/blog/1591406