# HTTP 方法覆盖会击穿只看方法的审核 当审核者只看请求行时，按方法审核并不安全。请求可以用 `POST` 到达，携带 `X-HTTP-Method-Override: DELETE`，随后由应用中间件改写方法并进入删除处理器。如果审批界面、网关规则、授权检查或审计记录把它归类为普通 POST，它审核的只是外壳，漏掉了真正的操作。 这种行为不是所有服务器都理解的 HTTP 协议技巧。它是一种应用约定，因此很容易被忽略。是否支持它取决于框架、中间件顺序、路由和部署。正确做法不是假定每个 POST 都暗藏破坏性，而是找出哪些位置接受覆盖，在任何安全判断前解析覆盖，并拒绝有歧义的请求。 ## 线上方法和实际方法是两个不同事实 支持覆盖的技术栈需要记录两个方法：HTTP 请求行中的方法，以及应用最终用于路由的方法。我把它们称为线上方法和实际方法。它们通常一致。危险发生在中间层按线上方法审批或过滤，而后续组件按实际方法路由时。 RFC 9110 规定，方法令牌是请求语义的主要来源。它把 POST 定义为针对资源的处理，把 DELETE 定义为要求源服务器移除目标资源与当前功能之间的关联。RFC 并未标准化 `X-HTTP-Method-Override`。这个标头属于一组兼容性约定，当年用于只能处理 GET 和 POST 的客户端或中间层。 普通软件至今仍实现这些约定。Express 的 `method-override` 中间件默认读取 POST 上的 `X-HTTP-Method-Override`。它接受值后会修改 `req.method`，并把旧值保存在 `req.originalMethod`。ASP.NET Core 也提供 HTTP 方法覆盖中间件，默认标头同样是 `X-HTTP-Method-Override`。Spring 的 `HiddenHttpMethodFilter` 走另一条路：它读取 POST 表单中的 `_method` 参数，并允许 PUT、DELETE 和 PATCH。 这些细节把团队经常混为一谈的概念分开了。“网关允许 POST”描述传输处理，“应用执行 DELETE”描述实际行为。审批或访问决定需要后者。如果做决定的组件无法确定实际方法，就必须拒绝覆盖信号，不能按外层动词静默分类。 框架支持本身不能证明系统暴露了问题。Express 应用必须安装中间件并正确排序，ASP.NET Core 应用必须添加中间件，Spring 应用必须启用并放置过滤器。最终结果由实际部署配置决定，其中还包括反向代理和按路由配置的中间件。检查源码可以找到候选点，感知状态的测试才能提供证据。 ## 获批的 POST 可以进入 DELETE 处理器 当不同组件对操作的权威表示意见不一时，隧道化写入就会溜过去。设想代理要向项目 API 发出以下请求： ```http POST /v1/projects/42 HTTP/1.1 Host: api.example.test Authorization: Bearer [injected outside the agent] X-HTTP-Method-Override: DELETE Content-Length: 0 ``` 审批层把它标为“POST /v1/projects/42”，并套用允许本会话使用 POST 的规则。反向代理转发陌生标头。RFC 9110 通常要求代理转发无法识别的字段，除非配置明确阻止或转换它们。在应用内部，覆盖中间件先改写方法，路由器随后选择 DELETE 处理器，项目就消失了。 这种故障不需要有缺陷的 DELETE 授权检查。应用可能正确确认该身份有删除权限。缺陷出现在更早处：人工或自动审核器忽略了一个受支持的输入，因此批准了实质上不同的操作。同样的分歧还会影响 Web 应用防火墙、限速器、CSRF 控制、请求指标和访问日志。 中间件顺序决定哪些控制能看到哪个事实。Express 文档对此说得很直接：方法覆盖必须放在所有需要了解请求方法的中间件之前。对单个进程内的路由和 CSRF 逻辑，这个建议是对的。但它无法修复进程外的网关，因为网关早已根据请求行做出了基于方法的决定。 还有一种更隐蔽的故障。边缘日志记 POST，应用日志记 DELETE，事件调查者却把它们当成无关请求。共享请求标识符可以关联记录，但前提是两端都保留它，而且团队知道需要比较方法字段。统一的规范化操作记录更不容易出错。 不要仅凭 DELETE 这个词推断影响。RFC 9110 指出，DELETE 移除的是资源与其当前功能之间的关联；是否回收存储、是否销毁内容由应用决定。DELETE 端点可能执行归档、停用、排队或删除数据。审核实际路由后果，不要只看通用动词定义。 ## 用受控的方法矩阵测试端点 可靠测试要在一次性资源上，对比原生方法、覆盖标头和参数约定造成的状态结果。请在预发布环境中运行，或使用专为破坏性测试准备的夹具。测试身份只应拥有真实调用者的权限，而且每个用例前都要重新创建夹具，避免一次成功删除污染后续结果。 先发送不含覆盖的基线 POST，记录状态码、响应正文和夹具状态。然后发送原生 DELETE，以确认路由确实存在，而且测试身份可以执行它。最后对每种约定重复 POST。最小标头探测如下： ```sh BASE='https://staging.example.test' ID='override-probe-17' curl -sS \n -D response.headers \n -o response.body \n -w 'case=x-http-method-override outer=POST status=%{http_code} bytes=%{size_download} ' \n -X POST "$BASE/v1/projects/$ID" \n -H 'Authorization: Bearer test-token' \n -H 'X-HTTP-Method-Override: DELETE' curl -sS \n -o state.body \n -w 'verify=read-after-request status=%{http_code} bytes=%{size_download} ' \n -H 'Authorization: Bearer test-token' \n "$BASE/v1/projects/$ID" ``` 输出刻意采用便于 CI 解析的稳定格式： ```text case=x-http-method-override outer=POST status=204 bytes=0 verify=read-after-request status=404 bytes=71 ``` 这个示例表示覆盖确实删除了夹具，并不代表所有系统都应返回同一状态。有些 API 返回带结果文档的 200，排队删除时返回 202，也有系统保留仍可读取的软删除表示。应按自己应用的契约定义成功。 测试要用矩阵，而不是随手拼接步骤。控制组是不含覆盖的 POST，必须产生普通 POST 行为。原生组是不含覆盖的 DELETE，用来确定文档所述的删除行为。随后分别发送带 `X-HTTP-Method-Override: DELETE`、`X-HTTP-Method: DELETE` 和 `X-Method-Override: DELETE` 的 POST。最后测试查询中的 `?_method=DELETE` 以及表单正文中的 `_method=DELETE`。每个覆盖用例都必须符合你明确设计的隧道方法行为，否则就应失败且不改变状态。 OWASP Web Security Testing Guide 列出了上述三个标头变体，并建议在受限方法被拒绝时用覆盖标头重放请求。我认为只比较状态码还不够，因为差异可能来自验证、路由或中间层。每次探测后都要检查资源、资源版本和任何排队任务。 如果你控制整个技术栈，就在每一跳抓取观察结果：边缘请求日志、审批事件、应用请求日志、所选路由和数据结果。目标是找出不一致。安全结果可以是一致拒绝，也可以是有意规范化后，对它执行与原生 DELETE 相同的授权和审批。 ## 状态码只是线索，状态变化才是证据 单凭 HTTP 状态码无法判断覆盖是否执行。204 之后夹具消失，是强证据。200 可能是普通 POST 响应、删除回执，也可能是错误地用成功码包装的自定义错误。405 可能由覆盖中间件之前的边缘层返回，而另一条路径或内容类型仍能到达中间件。 断言应围绕带唯一标识符和已知初始版本的金丝雀资源建立。探测前先获取资源，保留版本标记或表示摘要。探测后再次读取，并检查 API 返回的操作记录。测试更新时，选择无害且一眼可辨的字段；测试删除时，先弄清产品采用硬删除、软删除还是延迟清理。 响应比较仍有帮助。保存状态码、选定响应标头、正文大小和正文摘要。把覆盖请求同时与两个控制组比较：普通 POST 和原生 DELETE。如果覆盖响应像 DELETE，状态也与 DELETE 一致，结论就很有说服力。如果响应像 POST，状态却按 DELETE 改变，日志层或响应层可能仍在使用外层方法。 重定向需要单独检查。客户端在跟随 301、302、303、307 或 308 时可能改变请求行为，不同工具保留方法和正文的规则也不同。先禁用重定向运行并记录 `Location` 字段，再有意跟随并捕获每一跳。不要把重定向行为和覆盖行为混进一个看不透的结果。 异步 API 需要更长观察窗口，但这不是猜测的理由。如果响应提供操作标识符，就按文档规定的测试契约轮询。如果没有持久句柄，就在预发布环境中查看队列或应用日志。无法确定的用例应标为无法确定，而不是安全。 还要验证负面状态。被拒绝的覆盖不应创建、更新、归档、排队、发送邮件或触发高权限 Webhook。整齐的 4xx 很容易误导团队：后面的组件可能已提交副作用，前面的组件随后才拒绝响应路径。测试夹具的监控必须足以发现这种顺序。 ## 标头变体和歧义应放在同一测试中 只测标准拼写会漏掉兼容代码和解析器分歧。常见标头名是 `X-HTTP-Method-Override`、`X-HTTP-Method` 和 `X-Method-Override`，但应用也能定义自有读取器。查询字符串和表单正文可携带 `_method`，旧集成有时还使用与厂商或框架相关的名称。 标头名大小写不是另一种约定。RFC 9110 规定字段名不区分大小写，因此 `x-http-method-override` 和 `X-HTTP-Method-Override` 指同一字段。只匹配首字母大写写法的安全过滤器有缺陷，即使应用库会规范化标头名。 重复和冲突值暴露了更难处理的问题。字段定义允许时，RFC 9110 允许接收方把重复字段行合并为逗号分隔值，而且提醒实现者，即便字段预期只有一个值也要考虑重复情况。覆盖标头不是具有统一解析规则的标准单值字段。Express 中间件文档称它使用重复标头的第一个值，而安装多个覆盖处理器还会在不同标头名之间形成优先级。 基本矩阵之后加入大小写变体 `x-http-method-override: DELETE`，它必须和标准大小写结果一致。发送两个相同 DELETE 值，要求得到一种有文档说明的结果或明确拒绝。先发 PUT 后发 DELETE，再在两个覆盖标头名中放入不同值，这两类冲突都应因歧义被拒绝。还要拒绝 `PUT, DELETE` 这种逗号值、原生 PATCH 配覆盖 DELETE（除非契约明确规定），以及 DELETE 标头配 `_method=PATCH`。 不要只停在 DELETE。还要探测 PUT 和 PATCH，因为审核系统可能对创建、替换、局部更新和删除有不同分类。用一个不支持的令牌作为负面对照。除非测试环境和范围明确允许，否则不要测试 TRACE 和 CONNECT；它们会触发不同的基础设施行为，却不会让覆盖结论更可靠。 空白和取值大小写也能暴露规范化不一致。在客户端允许时发送 `delete`、` DELETE ` 和空值。安全规则很简单：只规范化文档约定允许的形式，按明确方法集合验证，其余全部拒绝。悄悄选择第一个可解析值，只会在代理或库变化后让绕过再次出现。 ## 代理生成的请求更容易触发盲点 AI 代理不会创造方法覆盖弱点，但会让不完整审核变得更危险。代理可以任意组合标头、复用文档示例，还可能在原生 DELETE 失败后把它改成 POST 隧道重试，却不理解第二种形式跨过了审批边界。查看精简审批卡片的人很可能只盯着显眼的动词和路径。 把代理生成的每个请求组成部分都视为不可信操作输入，其中也包括看似兼容性元数据的标头。在模型外注入凭据可以减少秘密暴露，却不能让请求的操作变得无害。请求仍会把代理选择的路径、方法、标头、查询和正文交给一个可能联合解释它们的系统。 工具模式能在请求产生前减少歧义。允许自由填写标头的通用 HTTP 工具，给了调用者请求覆盖所需的全部词汇。面向具体路由的删除工具可以直接说明破坏性操作，并省去覆盖字段。第二种设计更容易审核，但前提是实现没有通过隐藏出口继续传入额外标头。 如果必须使用通用 HTTP 工具，就在展示给人工审批前解析拟议请求。解析器应与执行器使用同一套覆盖清单和优先级规则。审批后冻结规范化操作，防止执行器稍后解析出不同结果。如果任何中间层会在审批后更改标头，就把确定性转换纳入被审核操作，或者重新解析并要求再次审批。 重试同样需要关注。POST 天生不安全，也不保证幂等。RFC 9110 对 POST 的定义很宽，即针对资源的处理；许多 POST 端点无需任何覆盖就会创建或修改数据。代理工具不能因为外层方法是 POST 就判断可以安全重试，也不能把所有 POST 都升级为破坏性审批。它需要结合路由语义和实际方法。 评估代理行为时，要分开测试身份和生产身份。权限过宽的生产凭据会让每个探测都成功，从而掩盖授权差异。使用代理实际会持有的受限角色，确认原生与隧道形式得到相同决定，并记录人工审批实际展示了什么。只有把拟议操作、展示操作、执行操作和结果状态串成一条链，才能证明这是审核不一致。 ## 最早的控制必须识别实际操作 所有基于方法的决定都必须放在一个统一解析器之后，否则就要拒绝全部覆盖输入。人工审批、授权、CSRF 防护、路由限制、限速和审计分类都适用。让每个控制各自重复临时解析，必然产生分歧。 要明确表示解析结果： ```json { "transport_method": "POST", "effective_method": "DELETE", "override_source": "header:x-http-method-override", "override_value": "DELETE", "target": "/v1/projects/42", "ambiguous": false } ``` 解析器应列出所有受支持标头和参数，收集提供的全部值，只要出现一个以上不同候选值就拒绝请求。它通常只应接受来自 POST 等允许外层方法的覆盖。它要按应用有意支持的方法验证取值，再为下游控制生成不可变的操作记录。 把授权放在解析之后，并绑定路由与实际方法。“这个身份能否向此路径 POST”在 POST 充当隧道时太弱。应问“这个身份在当前条件下能否对该资源执行 DELETE”。无论客户端发原生 DELETE 还是受支持的隧道形式，都应使用同一处理器授权。 审批界面应先显示后果，并在两种表示不同时同时展示。`DELETE /v1/projects/42 via POST override` 这种紧凑标签既给出实际操作，也保留传输细节。如果只把覆盖标头藏在可展开的原始请求面板里，就等于要求审核者在时间压力下自己找出危险事实。 如果上游网关无法复现应用的解析规则，不要只教它理解其中一小部分。要么在审批前拒绝任何已知覆盖信号，要么把审批点移到可信的规范化之后。网关理解一个标头而应用理解三个，只会制造虚假的覆盖感。 解析要和业务语义分开。解析器可以得出实际方法是 DELETE，路由则负责决定它代表归档、撤销、解绑还是擦除。高影响操作的审批系统需要了解路由的操作描述。规范化方法是必要条件，但一个动词无法描述所有效果。 ## 只剥离一个标头并不能修好问题 只有在服务不打算支持任何覆盖路径时，在代理处移除 `X-HTTP-Method-Override` 才安全。这个做法很受欢迎，因为简单，而且常能阻止第一个概念验证。但如果应用还接受别的标头、`_method` 参数、直达上游的路由或后续中间件，它就会失败。 Microsoft 的 YARP 标头指南列出 `X-HTTP-Method-Override`、`X-HTTP-Method` 和 `X-Method-Override`，说明代理默认会转发它们，并建议在运营方需要防止绕过时使用请求标头移除转换。这是实用的边缘加固，却不能证明目标应用忽略查询或正文覆盖，也不覆盖绕过 YARP 直达目标的流量。 有两种可靠设计可选。如果目前没有客户端需要兼容隧道，就在应用中禁用中间件，并在边缘拒绝全部已知信号。如果客户端确实依赖隧道，就只记录一种接受的输入，移除或拒绝其他形式，在所有控制之前规范化，并把原生与隧道请求作为同一个操作测试。 选择前先盘点代码和配置。搜索框架中间件、自定义请求包装器、`_method`、三个常见标头名，以及任何给请求方法赋值的代码。检查路由组，因为中间件可能只应用于某个 API 前缀。还要检查框架升级后保留下来的生成式 API 网关和旧兼容模块。 接着检查网络路径。内容分发层、负载均衡器、服务网格、反向代理、应用服务器和框架，可能用不同方式规范化或记录标头。确认没有公开路由能绕过执行拒绝的组件。对内部代理流量，也不要因为网络是私有的就信任调用者可控标头。 剥离可能破坏合法客户端，所以团队常常推迟。移除前先记录覆盖信号是否出现，但不要记录秘密或完整正文。宣布弃用，在测试环境明确失败，并同时移除服务器支持和边缘规则。让无文档兼容行为永久存在，成本往往高于迁移仍在使用它的客户端。 ## 日志必须同时记录请求行和所选操作 审计记录应保留传输方法、实际方法、覆盖来源、规范化值、所选路由、认证身份、目标资源、决定、响应状态和确认结果。缺少两个方法中的任何一个，审核者都无法重建 POST 为何进入 DELETE 处理器；缺少结果，记录只能说明意图，不能说明效果。 有歧义而被拒绝的请求也要记录。冲突覆盖值即使从未进入处理器，也与安全相关。只存标头名和规范化方法令牌，不要存授权值或无关请求正文。遇到无效值时，保存长度受限且经过转义的表示，防止控制字符伪造日志行。 用第一个可信节点生成的请求标识符关联各层记录。不要直接接受外部标识符，除非先替换或加命名空间。边缘层、解析器、审批服务、应用和异步工作进程都应传递可信标识符，让调查者无需依赖时间戳就能追踪一个操作。 方法字段也要准确命名。通用的 `method` 属性会诱使各组件写入不同含义。用 `transport_method` 表示请求行，用 `effective_method` 表示路由操作。如果中间件暴露 `originalMethod`，应明确映射，不要假定这个名称在所有框架里含义相同。 Sallyport 执行代理的 HTTP 调用，不向代理暴露凭据，并在 Activity 日志中记录调用。这种隔离不会让覆盖变安全，审核仍须在执行前识别实际方法。 自动运行结束后，防篡改证据很重要。只能追加的哈希链记录可以暴露静默修改，但完整性无法补回缺失语义。应在做决定时记录规范化操作，不要让后续任务尝试从访问日志推断。 审核面板应直接显示不一致。按服务和覆盖来源统计 `transport_method != effective_method`，能很快发现意外兼容流量。新出现的来源、有歧义的请求，以及审批事件只记录外层方法的破坏性实际方法，都应触发告警。 ## 回归测试必须以拒绝为默认 持久修复需要一项贯穿实际部署路径的契约测试，只要未获批准的覆盖改变状态就失败。解析器单元测试有帮助，却无法发现代理规则消失、中间件被移到授权之前，或某条路由通过另一入口变得可达。 为矩阵每一行写明预期行为。如果禁用隧道，每个覆盖信号都应返回有文档说明的 4xx，而且夹具不变。如果支持一种约定，其 DELETE 结果应在授权、审批分类、路由和审计字段上与原生 DELETE 一致。冲突和未知令牌必须在产生副作用前失败。 部署路径测试应包括以下断言： - 审批事件明确写出实际方法； - 原生和隧道形式得到相同授权决定； - 被拒绝输入不会改变金丝雀版本或副作用计数； - 日志在同一可信请求标识符下包含两个方法字段； - 直达上游的访问无法跳过规范化。 当代理配置、框架中间件、认证、审批代码、路由或代理工具变化时运行测试套件。每夜运行可发现基础设施漂移，发布门禁可发现有意变更。夹具要保持隔离，确保重复执行永不触碰真实人员数据。 即使框架称其为兼容功能，新接受一种约定也应按安全变更处理。它需要明确负责人、客户端需求、优先级规则、允许的外层方法、允许的实际方法集合以及移除条件。否则，一行中间件配置就会悄悄扩展控制必须理解的操作词汇。 干净的系统从入口到结果只使用一份操作描述。如果线上写 POST，应用里执行 DELETE，这个差异必须在任何人或组件说“同意”前明确出现。再晚一步，就只能做事件重建。