HTTP 请求转发那些事：你可能不知道的 Hop-by-hop Headers 和 End-to-end Headers

本文分享自华为云社区《HTTP请求转发那些事：你可能不知道的Hop-by-hop Headers和End-to-end Headers》，作者：蜉蝣与海。

引子

最近看到 F5 官方发布的公告，给出了一个身份验证绕过漏洞（CVE-2022-1388）的修复方案。这个漏洞允许攻击者发送一些未公开的请求，来绕过身份认证，进而控制系统。通过阅读官网的修复方案，发现这个漏洞的修复居然和 http 请求头的不当使用有关（如下图所示）。而在请求转发时如果没有妥善处理图中“Connection:close”这样的请求头，可能会导致请求频繁失败。今天就来简单聊聊容易让请求转发出问题的 Hop-by-hop Headers。

请求转发中的 http header

目前，微服务成为一种流行的 webapp 部署模式，部署时多个微服务之间难免进行数据交互。考虑下列请求转发场景，这里 App A 可能是一个自己编写的鉴权服务器或者代理服务器：

App A 将一个请求，原封不动地转发给了 App B，并且将 App B 的响应原封不动地返回给客户端。如果 App A 的代码或者 web 容器没有对 App B 的响应头做特殊处理，就容易出现上述情况：响应头中包含了两个 key 值一样的 header：Connection：someValue。

由于响应头中 Connection 字段决定了 http 的长连接是否可用， 当样例中的两个 Connection 字段值不同时，客户端收到请求后无法明确辨析服务端对当前 http 连接的态度，会导致一些不可预知的情况。例如，如果 valueA 是“Close”，而 valueB 是“Keep-Alive”，这个时候客户端无法清晰的知道服务端是否会继续维系当前 http 连接。

在 RFC 2612 中，对响应头划分为了 End-to-end Headers 和 Hop-by-hop Headers，Hop-by-hop Headers 往往会影响客户端对 http 响应的连接维系、内容处理策略等，Connection 字段就是 RFC 2612 所定义的一个 Hop-by-hop Headers。

如图，RFC 2612 给出了 HTTP/1.1 中的响应头，并解释 Hop-by-hop Headers：Hop-by-hop Headers 中的响应头，对一次连接有意义，然而，这些响应头不应该被缓存或者层层转发。反过来理解，也就是层层转发以上响应头，请求可能会出问题。

一个 Transfer-Encoding 被转发的例子：

如图，当 App B 存在分块响应时，Transfer-Encoding 响应头会提醒 App A 进行分块读取。具体来说，App B 的响应体中包含了 Transfer-Encoding：chunked，App A 发现这个响应头后，在读取响应体时，会读取若干个响应分块，对每个分块，会先读取一个分块大小，而后读取分块。当 App A 将 Transfer-Encoding：chunked 携带回客户端时，客户端会试图按理解分块响应的操作对 App A 的响应进行读取，然而，使用 curl 会打印这样的信息，这说明 App A 没有对响应内容做了分块：

当 App A 和 App B 的容器为 tomcat 或者 spring boot 时，容易复现此场景，App A 使用 jetty 作为容器则不易复现此问题。这说明部分 web 容器对 Hop-by-hop Headers 的处理策略是不同的。

总结

不是所有的 web 容器都能帮助开发者屏蔽 hop-by-hop headers，有些容器反而允许开发者自定义 hop-by-hop headers 来实现更大程度的灵活性。

在处理请求转发场景时，开发者面对这样的 header 要分外小心，尽量显示使用或者显示屏蔽这些 header，在更换 web 容器时需要进行必要的测试。

参考资料

[1]F5 公告的漏洞：https://support.f5.com/csp/article/K23605346#proc3

[2]Abusing HTTP hop-by-hop request headers: https://nathandavison.com/blog/abusing-http-hop-by-hop-request-headers

[3]RFC 2612:https://datatracker.ietf.org/doc/html/rfc2616#section-13.5.1

点击关注，第一时间了解华为云新鲜技术~​