WebDav是一种基于HTTP协议的分布式创作和版本控制协议，它默认开启了PUT、DELETE、PROPFIND等HTTP方法，这些方法在正常的文件协作场景下非常有用，但在公网网站环境中，如果不加限制，攻击者可以利用PUT方法上传恶意脚本文件（比如webshell），利用DELETE方法删除关键文件，甚至利用PROPFIND方法探测目录结构和敏感信息。所以，禁用WebDav或者至少禁用其中的PUT和DELETE方法，是网站安全防护中非常基础但极其重要的一步。下面我会从原理、配置方法、不同服务器环境的操作、验证手段以及进阶防护策略，把这件事讲透。
一、WebDav为什么会成为攻击面
很多网站管理员根本不知道自己的服务器开了WebDav。在IIS（Windows服务器）中，WebDav模块默认是安装并启用的；在Apache中，如果加载了mod_dav模块也会开启相关功能。攻击者通常会用扫描工具（如Nmap、Burp Suite）对目标站点发送OPTIONS请求或者直接尝试PUT请求，如果服务器返回200或201状态码，说明PUT方法可用，这就意味着攻击者可以直接往你的网站根目录上传一个.php、.aspx、.jsp的恶意文件，拿到服务器权限。DELETE方法同理，攻击者可以删除你的网站配置文件、数据库备份、甚至整个站点的核心文件，造成毁灭性破坏。这不是理论风险，是每天都在发生的真实攻击。
二、IIS服务器禁用WebDav的具体方法
IIS是WebDav的重灾区，因为Windows Server默认就带着这个模块。有三种方式可以处理：
第一种，通过IIS管理器图形界面操作。打开IIS管理器，找到你的站点，双击"WebDAV创作规则"，在右侧操作面板中点击"禁用WebDAV"。这一步会禁用整个WebDav功能。但如果你只是想禁用PUT和DELETE而保留其他功能（比如某些CMS需要），那就需要第二种方法。
第二种，修改web.config文件，精确禁用PUT和DELETE方法。在站点根目录的web.config中加入以下配置：
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<security>
<requestFiltering>
<verbs>
<remove verb="PUT" />
<remove verb="DELETE" />
</verbs>
<hiddenSegments>
<add segment="web.config" />
</hiddenSegments>
</requestFiltering>
</security>
</system.webServer>
</configuration>
这段配置的作用是在请求过滤层面直接拒绝PUT和DELETE这两个HTTP方法，返回404或405状态码。注意，如果你的web.config里已经有<requestFiltering>节点，不要重复添加，而是在已有节点内追加<verbs>部分。
第三种，直接卸载WebDav模块。在Windows的"程序和功能"中找到"Internet Information Services"，点击"更改"，展开"万维网服务"下的"常见HTTP功能"，取消勾选"WebDAV发布"，然后确定。这是最彻底的方式，但需要重启IIS服务。
三、Apache服务器禁用WebDav的方法
Apache的情况相对简单。如果你的Apache加载了mod_dav和mod_dav_fs模块，就需要在配置文件中禁用。打开httpd.conf或者对应站点的虚拟主机配置文件，找到类似下面的内容：
Dav On DavDepthInfinity On <Location /> DAV On </Location>
把Dav On改成Dav Off，或者直接注释掉整个<Location>块。如果你不确定有没有加载mod_dav模块，可以在httpd.conf中搜索"LoadModule dav_module"，如果找到了，在前面加#号注释掉，然后重启Apache。
如果你只想禁用PUT和DELETE而不完全关闭WebDav，可以用Rewrite规则来实现：
RewriteEngine On
RewriteCond %{REQUEST_METHOD} ^(PUT|DELETE)$ [NC]
RewriteRule ^ - [F,L]
这段规则的意思是：当请求方法是PUT或DELETE时，直接返回403 Forbidden。把它放在.htaccess文件或者虚拟主机配置的<Directory>块中即可。
四、Nginx环境下的处理方式
Nginx本身不支持WebDav协议，但如果你通过第三方模块（比如ngx_http_dav_module）开启了相关功能，或者你的后端应用（如PHP、Java应用）自己实现了PUT/DELETE处理，那就需要在Nginx层面拦截。在server块中加入：
if ($request_method !~ ^(GET|POST|HEAD)$) {
return 405;
}
这段配置会拒绝所有非GET、POST、HEAD的请求方法，包括PUT、DELETE、OPTIONS等。如果你只想禁用PUT和DELETE，可以写成：
if ($request_method = PUT) {
return 405;
}
if ($request_method = DELETE) {
return 405;
}
配置完成后执行nginx -t检查语法，然后nginx -s reload重载配置。
五、如何验证WebDav和PUT/DELETE是否真正被禁用
配置完了不验证等于没做。你可以用curl命令快速测试。先测试PUT方法：
curl -X PUT http://你的域名/test.txt -d "test content" -v
如果返回403或405，说明PUT已被禁用。再测试DELETE：
curl -X DELETE http://你的域名/test.txt -v
同样返回403或405就说明DELETE也被禁了。另外还可以发一个OPTIONS请求查看服务器支持哪些方法：
curl -X OPTIONS http://你的域名/ -v
正常情况下，OPTIONS响应的Allow头中不应该出现PUT和DELETE。如果你看到了，说明禁用不彻底，需要回头检查配置。
六、除了禁用方法，还需要做哪些配套防护
光禁用PUT和DELETE还不够，这只是堵住了一个入口。真正的安全防护是多层的。第一，文件上传功能必须做严格的白名单校验，只允许特定扩展名，并且上传目录要禁止执行脚本。第二，网站目录权限要最小化，Web应用运行账户不应该有写入整个站点目录的权限。第三，部署WAF（Web应用防火墙），设置规则拦截异常的HTTP方法请求。第四，定期做漏洞扫描，用工具自动检测WebDav、TRACE、TRACK等危险方法是否被意外开启。第五，关注服务器和中间件的安全更新，很多WebDav相关的漏洞（如CVE-2017-7269、CVE-2017-4971）都是通过补丁修复的，保持更新是最基本的安全习惯。
七、常见误区和注意事项
很多人以为禁用了PUT和DELETE就万事大吉了，但忽略了几个问题。一是有些Web应用框架（比如某些RESTful API框架）本身就需要PUT和DELETE来正常工作，你一刀切禁掉会导致功能异常。这种情况下应该只对不需要这些方法的目录或路径做限制，而不是全局禁用。二是有些攻击者会用POST方法配合X-HTTP-Method-Override头来绕过限制，把POST伪装成PUT，所以WAF规则也要覆盖这种情况。三是禁用WebDav后，如果你的网站依赖某些协作功能（比如在线文档编辑），需要评估是否有替代方案，不能因为安全牺牲了业务需求。
八、总结与建议
WebDav的PUT和DELETE方法在公网网站上就是一个敞开的大门，禁用它们是网站安全加固的必做项，不是可选项。IIS用户优先通过web.config的requestFiltering来精确禁用，Apache用户用Rewrite规则或关闭mod_dav模块，Nginx用户在server块中加if判断。配置完成后一定要用curl实测验证，同时配合文件权限控制、WAF部署、定期扫描等多层防护手段，才能真正把这个风险降到最低。安全没有银弹，但每堵住一个漏洞入口，攻击者的成本就高一分，你的网站就安全一分。
