OPTION请求打到10.10.10.5的渗透80端口，返回了一个302。渗透跳转地址是渗透http://10.10.10.5:8080/。我盯着Burp里的渗透响应包看了两秒，把请求方法从GET改成OPTIONS，渗透重新发送。渗透

响应头里躺着一行：Allow: GET,渗透 POST, OPTIONS, PUT, DELETE。PUT和DELETE开着。渗透这东西在生产环境里可不常见。渗透

OPTIONS方法本身没什么神秘的渗透。HTTP/1.1规范里它就是渗透个探测工具，客户端问服务器“这个资源支持哪些方法”，渗透服务器老老实实列出来。渗透问题在于，渗透很多开发者和运维人员压根不关心它。渗透Nginx默认配置下OPTIONS请求直接返回405，Apache倒是大方，经常把支持的方法全抖出来。IIS更离谱，WebDAV模块一装，OPTIONS响应里连PROPFIND、MKCOL这些方法都给你列上。

我见过一个真实案例。某企业的OA系统部署在IIS 7.5上，WebDAV没关。攻击者发了一个OPTIONS请求，响应里出现了PUT。然后他直接往服务器上写了一个.asp文件，内容是<%eval request("cmd")%>。菜刀连上去，服务器就没了。整个过程不到三分钟。管理员后来查日志，发现那个OPTIONS请求躺在IIS日志里，状态码200，没人多看一眼。

OPTIONS的渗透价值不在它本身能做什么，而在于它泄露的信息。一个正常的REST API，OPTIONS响应可能返回Allow: GET, POST, OPTIONS，这没问题。但如果返回了PUT或者DELETE，你就得想想了——这个接口真的需要这些方法吗？开发人员图省事，在Spring MVC里配了@RequestMapping(method = RequestMethod.GET)，但全局CORS配置里写了allowedMethods("*")。OPTIONS请求过来，框架把*展开，所有方法都暴露了。攻击者看到DELETE，试着发一个过去，接口真把数据删了。这事我亲自遇到过，某电商后台的商品删除接口，就是这么没的。

还有一种情况更隐蔽。OPTIONS响应里的Allow头有时候会暴露内部方法名。比如Allow: GET, POST, OPTIONS, X-CUSTOM-SYNC。这个X-CUSTOM-SYNC是开发人员自定义的，用来触发数据同步。正常用户根本不知道它的存在，但OPTIONS把它卖了。攻击者构造一个X-CUSTOM-SYNC请求，可能直接触发全量数据同步，或者更糟——同步接口没做权限校验，把整个数据库拖走了。

防御这事其实不复杂。Nginx里加一行if ($request_method !~ ^(GET|POST)$) { return 405; }，把不需要的方法全掐掉。Apache关掉mod_webdav，或者在.htaccess里用<LimitExcept GET POST>包住目录。IIS更简单，WebDAV模块直接卸载。Spring Boot项目里检查WebMvcConfigurer的CORS配置，别用allowedMethods("*")，老老实实写清楚需要哪些方法。

但现实是，很多团队根本不知道自己的服务器响应了OPTIONS。我拿Shodan搜过Allow: PUT，结果里有大量暴露在公网的IIS和Tomcat。有些是测试环境忘了关，有些是开发人员压根没意识到。你发一个OPTIONS过去，服务器就像个话痨一样把家底全说了。

下次渗透测试的时候，别只盯着GET和POST。发个OPTIONS，看看服务器怎么回你。那个Allow头里藏着的，可能比你想的多得多。