发现通过options探测服务器信息

一个HTTP OPTIONS请求能暴露多少信息？发现比你想象的多。上周我测试某个客户的通过s探内网应用，浏览器地址栏输入目标IP，测服F12打开开发者工具，信息在Console里敲下一行代码：

fetch('http://192.168.1.105',发现 { method: 'OPTIONS'})

响应头返回的`Allow`字段直接列出了一串方法：`GET, HEAD, POST, PUT, DELETE, OPTIONS`。看到PUT和DELETE，通过s探我立刻意识到这台服务器允许客户端直接修改资源——如果WebDAV也开着，测服那基本等于把文件系统敞开了一半。信息这不是发现理论，是通过s探真实存在的风险。

OPTIONS请求本身无害，测服它只是信息询问服务器“你支持哪些操作”。但服务器回复的发现`Allow`、`Public`、通过s探`DAV`等头字段，测服就是一份免费的技术情报。攻击者拿到这份清单，等于拿到了攻击面的地图。比如`Allow: GET, PUT`意味着可以尝试上传webshell；`DAV: 1,2`直接告诉你WebDAV协议版本，配合`MS-Author-Via`头还能确认是不是IIS服务器。

还有个容易忽略的点——OPTIONS响应里的`Content-Length`和`Content-Type`。有些服务器会返回一段XML或JSON描述支持的扩展方法，里面可能包含版本号、内部路径甚至框架名称。我见过一个Spring Boot应用，OPTIONS响应里直接带上了`X-Application-Context: app-name:prod:8080`，部署环境、端口、项目名全暴露了。

更隐蔽的是，某些代理服务器对OPTIONS请求的处理逻辑和GET/POST不同。Nginx默认会转发OPTIONS到后端，但Apache可能会直接拦截并返回自己的默认响应。你可以利用这个差异做探测——如果直接访问返回403，而OPTIONS返回200，说明后端可能存在访问控制绕过。去年我测试一个金融系统，就是用OPTIONS确认了WAF只拦截GET和POST，对OPTIONS完全放行，然后通过PUT方法上传了测试文件。

当然，不是所有OPTIONS响应都有价值。有些服务器配置得当，只返回`Allow: GET, HEAD`，甚至直接返回403。但问题在于，很多开发者和运维根本没意识到这个请求的探测价值。他们花大价钱买防火墙、做渗透测试，却忽略了HTTP协议本身泄露的信息。

我的建议很直接：在Web服务器层面统一禁用或限制OPTIONS方法。Nginx里可以这样配：

if ($request_method = OPTIONS) {  return 403; }

或者更精细地，只允许特定路径使用OPTIONS用于CORS预检。别嫌麻烦，你每多屏蔽一个方法，就少给攻击者递一块拼图。你永远不知道哪个看似无害的响应头，会成为下一次攻击的起点。