【AppScan深刻淺出】修復漏洞：啓用不安全的HTTP方法 （中）

最近一直刷新AppScan的下限，對於Appscan報出的中危漏洞「啓用不安全的HTTP方法」。分析了其掃描機制，以及處理方法和繞開方法。若是不耐煩看分析過程，請直接跳到文章最後看處理方法。

0. 漏洞背景

「啓用了不安全的 HTTP 方法」屬於「中」危漏洞。漏洞描述是：根據APPSCAN的報告，APPSCAN經過OPTIONS請求，當響應中發現DELETE、SEARCH、COPY等方法爲容許方法時，則認爲是漏洞。 詳見下圖：

 

 

Web服務器（以IIS爲例）在沒有任何設置是，使用OPTIONS命令，能夠返回全部可以響應的HTTP方法，如OPTIONS, TRACE, GET, HEAD, COPY, PROPFIND, SEARCH, LOCK, UNLOCK。

發送OPTIONS請求：（使用telnet或者secureCRT等軟件）：

 

 

服務器響應能夠使用的 HTTP 方法，見 Allow 部分。

 

1. 實驗環境

Web服務器環境：IIS6。站點結構以下，使用了主機頭myapp.com指向了個人測試應用app。

 

 

配置只有讀取權限，還有執行權限設置爲「純腳本」。

 

 

2. 實驗

實驗1：裸實驗

未啓用WebDav，OPTIONS命令的返回中，只顯示只有OPTION、TRACE、GET、HEAD和POST。

APPSCAN掃描結果也沒有掃描出「啓用了不安全的 HTTP 方法」這個漏洞。 

 

 

實驗2：開啓WebDAV

啓用WebDAV後，OPTIONS命令的返回中，顯示多了不少新的HTTP方法，包括APPSCAN會認爲是不安全的COPY、SEARCH、LOCK和UNLOCK等。

 

APPSCAN的掃描結果以下，掃描到了「啓用了不安全的HTTP方法」這個漏洞。

 

結論1：若是關閉WebDAV支持，APPSCAN則沒法掃描出「啓用了不安全的 HTTP 方法」漏洞。

 

實驗3：URLScan正向實驗

安裝URLScan（URLScan是微軟提供給IIS6的路徑重定向工具，在這裏下載），在URLScan.ini中配置，只容許GET、HEAD和POST這三個經常使用命令（UseAllowVerbs=1）。

運行OPTIONS命令，則服務器返回響應失敗，沒法列出全部的HTTP方法

 

 

APPSCAN掃描結果顯示，禁用OPTIONS命令後沒法掃描出「啓用了不安全的 HTTP 方法」這個漏洞。

 

實驗4：URLScan正向實驗2

安裝URLScan，在URLScan.ini中配置，只容許GET、HEAD、POST和OPTIONS命令。

因爲URLScan的模式，要麼設置容許命令，要麼設置禁止命令，不能同時設置。所以容許這4個命令，表示不能禁用其餘命令，所以OPTIONS會顯示其餘的可用命令。

因爲APPSCAN默認是以OPTIONS命令來看漏洞的，所以天然本次掃描會有漏洞。

 

實驗5：URLScan反向實驗

 

在URLSCAN中，採用禁止模式（UseAllowVerbs=0），只禁止OPTIONS命令。

結果OPTIONS被禁用。

固然此時其餘不安全的HTTP方法，實際上是沒有禁用的，如LOCK、UNLOCK等，只是是否可用要看服務器是否設置了對應的程序。

 

實驗5：URLScan反向實驗2

在URLSCAN中，採用禁止模式（UseAllowVerbs=0），禁止不安全HTTP方法- DELETE- SEARCH- COPY- MOVE- PROPFIND- PROPPATCH- MKCOL- LOCK- UNLOCK- PUT等。

可是使用OPTIONS命令後，仍然顯示這些不安全的方法，即便這些方法實際已經被禁用了。

見下圖，使用LOCK命令已經顯示沒法訪問了，但APPSCAN實際也會說有漏洞，因爲OPTIONS方法告訴它有這些HTTP方法。

結論2：消除「啓用了不安全的 HTTP 方法」漏洞，關鍵在因而否可以阻止OPTIONS命令。

3. URLScan參數討論

 

使用URLSCAN確實能夠禁用掉無用的HTTP方法，但根據參數配置，有可能會產生反作用。所以須要瞭解每個參數，以減小對現有系統的影響。

參數（默認值）	描述	建議值
UseAllowVerbs=1	; If 1, use [AllowVerbs] section, else use the [DenyVerbs] section.	0，使用禁用模式，禁用OPTIONS
UseAllowExtensions=0	; If 1, use [AllowExtensions] section, else use the [DenyExtensions] section.	0，使用禁用模式，並將禁用列表清空
NormalizeUrlBeforeScan=1	; If 1, canonicalize URL before processing.	0，不掃描
VerifyNormalization=1	; If 1, canonicalize URL twice and reject request if a change occurs.	0，不掃描
AllowHighBitCharacters=0	; If 1, allow high bit (ie. UTF8 or MBCS) characters in URL.	0，不啓用
AllowDotInPath=0	; If 1, allow dots that are not file extensions.	0，不啓用
RemoveServerHeader=0	; If 1, remove the 'Server' header from response.	0，不啓用
EnableLogging=1	; If 1, log UrlScan activity.	0，不啓用
PerProcessLogging=1	; If 1, the UrlScan.log filename will contain a PID (ie. UrlScan.123.log).	0，不啓用
AllowLateScanning=0	; If 1, then UrlScan will load as a low priority filter.	0，不啓用
PerDayLogging=1	; If 1, UrlScan will produce a new log each day with activity in the form 'UrlScan.010101.log'.	0，不啓用
UseFastPathReject=0	; If 1, then UrlScan will not use the RejectResponseUrl or allow IIS to log the request.	0，不啓用
LogLongUrls=0	; If 1, then up to 128K per request can be logged. If 0, then only 1k is allowed.	0，不啓用
MaxAllowedContentLength =30000000	請求內容最大長度，默認爲3G	不修改
MaxUrl=260	URL長度，默認260字符	不修改
MaxQueryString=2048	QueryString的最大長度，默認2048字符	不修改
RejectResponseUrl=		不修改
LoggingDirectory		不修改
AlternateServerName=		不修改

4.處理方法

回顧一下實驗過程當中的結論：

消除「啓用了不安全的 HTTP 方法」漏洞，關鍵在因而否可以阻止OPTIONS命令。

若是禁止OPTIONS命令，但沒有禁用其餘危險命令如MOVE等，APPSCAN不會提示漏洞

若是禁止全部危險命令如MOVE等（實際調用出錯），可是OPTIONS命令沒有禁止而且顯示這些危險命令能夠使用，APPSCAN提示漏洞。

若是關閉WebDAV支持，APPSCAN則沒法掃描出「啓用了不安全的 HTTP 方法」漏洞。 

由於不開啓WebDAV，則不開啓OPTIONS命令。 

 

所以 

王道方法是：禁用全部危險命令以及OPTIONS（OPTIONS命令並不危險，但不由用是不行的）

邪道方法是：只禁用OPTIONS命令，其餘危險命令APPSCAN是不會主動掃描，留着也不會報漏洞。但實際是否是有，這個就要具體分析了。 

 

綜上：解決「啓用了不安全的 HTTP 方法」，可採用3種方法：

方法	描述
1	禁用WebDAV功能	根本解決。不引入新的不穩定因素URLSCAN
2	使用URLSCAN禁用OPTIONS	實際沒有真正禁用，但縮小了影響範圍。URLSCAN可能有反作用。
3	使用URLSCAN禁用OPTIONS和其餘HTTP方法 或者只容許GET/POST/HEAD方法（自動禁用其餘方法）	等效於取消WebDAV，但URLSCAN可能反作用。