【AppScan深入浅出】修复漏洞：启用不安全的HTTP方法 （中）

3 月，跳不动了？>>>

最近一直刷新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可能副作用。

来源：oschina

链接：https://my.oschina.net/u/555019/blog/136818