HTTP PUT方法，本来是用来上传文件的。但很多人忘了，它还有个兄弟叫PUT漏洞——准确说，是服务器对PUT方法的错误配置，让攻击者能直接往服务器上写webshell。

去年我帮一家电商公司做渗透测试，发现他们的图片服务器开了PUT权限。当时我随手传了个txt文件上去，居然成功了。那一刻我后背发凉——如果这是个恶意攻击者，他传上去的就不是txt了，而是一句话木马。测试结束后，我告诉运维，他们一脸茫然："PUT？那不是开发调试用的吗？"

问题就出在这。很多开发框架默认支持PUT，但部署到生产环境时，运维不知道这个细节。Apache、Nginx、Tomcat，这些主流服务器都曾曝出过PUT配置不当的案例。攻击者用curl命令，几秒钟就能探测出目标是否开放了PUT方法：curl -X PUT -d "test" http://target/test.txt。如果返回200，恭喜，漏洞确认了。

但真正危险的不是能上传文件，而是上传的文件能被解析。如果服务器把上传的.jsp或.php文件当作脚本执行，攻击者就能拿到服务器权限。我见过一个案例，某政府网站因为PUT漏洞被植入后门，整整半年没人发现。直到某次安全扫描才暴露出来——攻击者早就把服务器变成了"肉鸡"，用来挖矿和发垃圾邮件。

为什么这种漏洞到现在还频繁出现？我观察到的原因是：开发环境和生产环境配置不一致。开发时为了方便，开着PUT方法调试接口，上线时忘了关。更糟的是，很多云厂商的默认安全组规则只管入站流量，不管应用层方法限制。你防火墙开得再严密，HTTP协议本身还是放行的。

修复其实不复杂。Nginx里加一行limit_except GET POST { deny all; }，Apache里用<LimitExcept>标签。Java应用在web.xml里禁用HTTP方法。但最关键的，是上线前做一次方法级的安全测试——别只测GET和POST，把PUT、DELETE、OPTIONS全试一遍。

说句实在话，PUT漏洞不算高级攻击手法，但它就像你家门没锁——小偷不用撬锁，推门就进来了。安全圈老生常谈的一句话：攻击者不需要多聪明，只需要你犯的错够蠢。PUT漏洞就是这种"蠢错"的典型代表。你不需要多高深的技术功底，curl一敲，漏洞就在那躺着。

最后提醒一句：如果你现在管理着任何一台web服务器，花两分钟测一下PUT方法是否开放。两分钟换来的可能是服务器不被入侵的安宁。别等到被黑的那天才想起来——那时候，日志早被清干净了。