检测到目标服务器启用了OPTIONS方法

抓包的检测时候看到`Allow: GET, HEAD, POST, OPTIONS`，我第一反应不是到目“服务器好慷慨”，而是标服“又一台机器把门敞开了”。OPTIONS方法本身无害，启用但它像门上的方法猫眼——攻击者先凑过来看一眼屋里有没有人，灯亮不亮，检测狗凶不凶。到目

上周帮朋友排查一个API网关，标服对方说“我们只开了GET和POST”。启用我随手发了个OPTIONS请求，方法响应头里赫然列着`DELETE,检测 PUT, TRACE`。朋友愣了两秒，到目然后爆了句粗口。标服不是启用他撒谎，是方法框架默认配置把方法全注册了，运维层压根没过滤。这种“隐形开放”比显式开启更危险——你以为锁了门，其实只是把门把手擦亮了。

OPTIONS的妙处在于它不产生副作用。你问服务器“你能干啥”，它老老实实回答。这本来是HTTP协议给客户端用的协商机制，但攻击者拿它来测绘。比如某个老旧Tomcat版本，OPTIONS响应会泄露内部IP；某些云WAF配置不当，OPTIONS请求能绕过拦截规则直达后端。我见过最离谱的一次，某银行测试环境用OPTIONS探到了`PUT /upload`路径，响应码是200——虽然最后没打成，但那个瞬间我后背发凉。

但别急着恐慌。OPTIONS方法本身不是漏洞，就像螺丝刀不是凶器。真正的问题在于响应头里暴露的“能力清单”。如果你服务器上有个遗留的`TRACE`方法，配合XSS就是经典的窃取Cookie组合拳。更阴的是`CONNECT`方法，一旦开启，服务器直接变成代理跳板，内网横向移动的绝佳通道。这些方法平时用不上，但框架默认配置里往往躺着。

怎么查？别用浏览器，浏览器不会发OPTIONS。用curl敲一行命令：`curl -X OPTIONS http://目标地址 -i`。看返回的`Allow`字段。如果列出的方法里有你业务根本不需要的，比如静态资源服务器出现`PUT`，那基本可以判定配置有误。更细的做法是看`Access-Control-Allow-Methods`，这字段跟CORS相关，有时候会泄露跨域允许的额外方法——我见过某系统CORS误配成`*`，同时允许`DELETE`，等于给任何网站一个远程删数据的接口。

处理方式不复杂。Nginx里加一行`if ($request_method = OPTIONS) { return 204; }`就能掐断探测。但别一刀切——有些前端框架的预检请求确实需要OPTIONS，比如axios跨域带自定义头时。更稳妥的办法是精确控制Allow列表：在应用层代码里显式声明允许的方法，而不是依赖框架默认。例如Spring Boot里`@RequestMapping(method = { RequestMethod.GET, RequestMethod.POST})`，把没用的方法直接关在门外。

最后说句实在的：你不需要对OPTIONS风声鹤唳，但得养成习惯。每次上线前扫一遍`Allow`头，跟检查服务器SSH端口是否改默认一样，花不了十秒钟。那些说“我们服务器重要数据都在数据库里，没人会通过OPTIONS搞事”的人，往往就是被`TRACE`方法钓走会话ID的那批。安全这东西，多数时候不是被高科技攻破的，而是被“觉得无所谓”漏掉的。