TRACE

用法

TRACE 请求是一种用于检查客户端与源服务器之间请求链路的诊断工具。服务器以 200 响应，并在响应体中包含所收到的请求消息。一种公认的格式是 Content-Type message/http。响应体包含所收到请求消息的一份副本，其中排除了服务器认为敏感的字段，从而可与原始请求进行比对。

特性

TRACE 请求不携带请求体。客户端有责任不在 TRACE 请求中包含凭据或 Cookie 等敏感字段，因为回显的响应会暴露所有收到的请求头。

Microsoft IIS 历史上曾支持 TRACK 作为 TRACE 的专有别名。两者都存在相同的 XST 漏洞，且都需要在生产环境中禁用。

中间设备检测

当请求经过代理或网关时，每个中间设备都会追加一个 Via 请求头条目，列出用于转发的协议版本。将原始请求与回显的副本进行比对，可揭示每一跳所添加、修改或移除的请求头。

Max-Forwards 请求头限制 TRACE 请求可传递的距离。将此值设为零会使第一个代理进行响应，这有助于在多跳链路中隔离出特定的中间设备。在每一跳处递减计数器可防止无限转发循环。

安全与 XST

跨站追踪（XST）是一种利用 TRACE 来捕获 HTTP 请求头（包括身份验证令牌和 Cookie 值）的攻击途径。恶意脚本向目标服务器发送 TRACE 请求，回显的响应会暴露脚本原本无法访问的请求头。

注意

大多数生产服务器禁用 TRACE 以防止 XST 攻击。Apache 和 Nginx 等 Web 服务器默认禁用 TRACE。浏览器也会阻止 TRACE。WHATWG Fetch 标准将 TRACE 列为禁止的方法，从而阻止 JavaScript 发出 TRACE 请求。在服务器上禁用 TRACE 仍然是所有面向互联网的服务器所推荐的加固措施。

示例

一个针对根资源的 TRACE 请求。服务器在响应体中回显原始请求，并包含一个 Via 请求头，显示该请求经过了两台代理服务器。

请求

TRACE / HTTP/1.1
Host: example.com

响应

HTTP/1.1 200 OK
Content-Type: message/http
Content-Length: 91
Via: 1.1 proxy1.example.re, 1.1 proxy2.example.re

TRACE / HTTP/1.1
Host: example.com
Via: 1.1 proxy1.example.re, 1.1 proxy2.example.re

Via 请求头将 proxy1.example.re 和 proxy2.example.re 列为中间设备。两者均使用 HTTP/1.1 转发请求。每个中间设备都必须为转发的请求追加一个 Via 条目，因此回显的响应体中包含由这两个代理添加的累积 Via 字段。

CORS

TRACE 是 CORS 禁止的方法。浏览器会阻止一切通过 fetch() 和 XMLHttpRequest 等浏览器 API 发送 TRACE 的尝试。

禁用 TRACE

Apache 在服务器配置中使用 TraceEnable Off 禁用 TRACE。nginx 默认不支持 TRACE，因此无需任何操作。IIS 需要在请求筛选（Request Filtering）中从允许的谓词里移除 TRACE（和 TRACK）。Caddy 默认不支持 TRACE。

OWASP 建议在所有生产服务器上禁用 TRACE。尽管现代浏览器会通过将 TRACE 列为禁止方法的 Fetch 标准来阻止 TRACE 请求，安全扫描器仍会将启用的 TRACE 标记为漏洞。

在服务器层面禁用 TRACE 仍然是抵御 XST 的主要防线，因为非浏览器的 HTTP 客户端和脚本不受 Fetch 标准限制的约束。