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