一台没做任何访问控制的远端服务器，开着HTTP的请求TRACE方法，等于把自家钥匙插在门锁上还贴了张纸条告诉路人“随便转”。漏洞这不是远端夸张。TRACE请求原本是请求HTTP/1.1协议里用来做诊断的工具，客户端发过去，漏洞服务端把收到的远端请求原样回显。问题就出在这个“原样”上——如果中间有代理、请求有负载均衡、漏洞有WAF，远端每一跳都可能往请求里塞东西，请求比如Cookie、漏洞Authorization头、远端内部IP。请求TRACE一开，漏洞这些全给你吐回来。

我最早注意到这个问题是几年前翻一个政府网站的响应头。顺手用curl发了个TRACE，返回的body里赫然躺着我的Cookie和一个内网地址10.0.3.17。那个站前面挂着一台F5，F5往请求里加了X-Forwarded-For，TRACE把整条链路的信息全反射回来了。攻击者要做的就是诱导受害者点一个链接，或者直接构造XST（Cross-Site Tracing）攻击，把原本HttpOnly的Cookie偷出来。

很多人以为TRACE早该绝迹了。Apache从2.0.55开始默认关，Nginx压根不实现，IIS倒是默认开着直到IIS 7。但现实是，大量老旧系统、嵌入式设备、内部管理后台还在跑。去年扫了一个C段，发现三台Tomcat 7开着TRACE，其中一台是某医院的预约挂号前置机。运维说“不知道谁开的”，大概率是某次调试完忘了关。

TRACE的杀伤力取决于中间层。没有代理的情况下，它只能回显客户端自己发的东西，危害有限。但现代Web架构哪有不挂代理的？CDN、反向代理、API网关，每一层都可能注入敏感头。更麻烦的是TRACE配合XSS，浏览器里XMLHttpRequest可以发TRACE，虽然现代浏览器禁了，但IE6/7时代这是标配攻击链。现在虽然浏览器层面堵了，服务端没堵照样能被Burp、curl这类工具利用。

检测方法简单到可笑。一条命令：curl -X TRACE http://target/ -i。如果返回200并且body里出现你发的请求内容，就是开着。修复也简单，Apache在httpd.conf里加TraceEnable off，IIS在applicationHost.config里把<traceRequests>设为false，Nginx不用管因为它默认返回405。但难的是知道有多少台机器、多少个虚拟主机、多少个老版本中间件需要改。

我见过最离谱的案例是一个金融客户的测试环境。TRACE开着，而且代理把Authorization: Bearer <token>也回显了。那个token是测试环境的，但权限跟生产一样。攻击者拿到token直接调生产API，客户还以为是内部泄露。后来查日志，发现攻击者只是用浏览器插件发了个TRACE请求。

有些安全扫描器会把TRACE标成低危，理由是“需要配合其他漏洞”。这种评级有误导性。TRACE本身不是漏洞，它是放大器。一个中危的XSS加上TRACE就变成高危的会话劫持。一个信息泄露加上TRACE就变成凭据窃取。评级应该看它跟什么组合，而不是孤立地看。

修复建议就三条：关掉TRACE，关掉TRACK（IIS特有），检查所有中间件和代理的默认配置。别信“我们没开”这种话，跑一遍脚本比拍胸脯可靠。另外，如果业务真需要诊断，用OPTIONS或者自定义的debug端点，别用TRACE。那玩意儿从设计上就不该暴露在公网。

最后说个观察：TRACE漏洞的修复率极低。我跟踪过一批2019年发现的TRACE站点，到2023年还有40%没关。不是技术难，是没人管。安全团队觉得低危，运维团队不知道在哪改，开发团队说“不是我们管的”。一个本可以一条配置解决的事，在组织缝隙里活了四年。