Upgrade Header Smuggling
最后更新于
最后更新于
Try Hard Security Group
H2C，或明文http2，通过将标准HTTP连接升级为持久连接，偏离了短暂HTTP连接的常规。这种升级后的连接利用http2二进制协议进行持续通信，而不是明文HTTP的单请求性质。
劫持问题的关键在于反向代理的使用。通常，反向代理会处理并转发HTTP请求到后端，然后返回后端的响应。然而，当HTTP请求中存在Connection: Upgrade头部（通常在websocket连接中看到），反向代理会维持客户端和服务器之间的持久连接，从而促进某些协议所需的持续交换。对于H2C连接，遵循RFC需要存在三个特定的头部：
漏洞出现在升级连接后，反向代理停止管理单个请求，假设其路由工作在连接建立后已完成。利用H2C Smuggling 可绕过反向代理在请求处理期间应用的规则，如基于路径的路由、身份验证和WAF处理，假设成功启动了一个H2C连接。
该漏洞取决于反向代理对 Upgrade 和有时 Connection 头的处理。以下代理在代理传递期间固有地转发这些头，从而固有地启用 H2C 走私：
HAProxy
Traefik
Nuster
相反，这些服务在代理传递期间不固有地转发这两个头。但是，它们可能配置不安全，允许未经过滤地转发 Upgrade 和 Connection 头：
AWS ALB/CLB
NGINX
Apache
Squid
Varnish
Kong
Envoy
Apache Traffic Server
值得注意的是，并非所有服务器固有地转发用于符合 H2C 连接升级所需的头。因此，像 AWS ALB/CLB、NGINX 和 Apache Traffic Server 等服务器自然地阻止 H2C 连接。尽管如此，值得尝试使用不符合标准的 Connection: Upgrade 变体进行测试，该变体在 Connection 头中排除了 HTTP2-Settings 值，因为一些后端可能不符合标准。
无论在 proxy_pass URL 中指定的具体 路径 是什么（例如 http://backend:9999/socket.io），建立的连接默认为 http://backend:9999。这允许与该内部端点中的任何路径进行交互，利用这种技术。因此，在 proxy_pass URL 中指定路径不会限制访问。
工具 h2csmuggler by BishopFox 和 h2csmuggler by assetnote 通过建立 H2C 连接，有助于尝试绕过代理施加的保护，从而访问被代理屏蔽的资源。
有关此漏洞的更多信息，特别是关于 NGINX 的信息，请参考 此详细资源。
与创建到通过代理可访问的端点的 HTTP2 隧道不同，Websocket 走私建立了一个 Websocket 隧道，以绕过潜在的代理限制，并促进与端点的直接通信。
在此场景中，一个提供公共 WebSocket API 和无法访问的内部 REST API 的后端被恶意客户端攻击，试图访问内部 REST API。攻击分为几个步骤：
客户端通过在标头中使用不正确的 Sec-WebSocket-Version 协议版本向反向代理发送升级请求。代理未能验证 Sec-WebSocket-Version 头，认为升级请求有效，并将其转发到后端。
后端以状态码 426 响应，指示 Sec-WebSocket-Version 头中的不正确协议版本。反向代理忽略后端的响应状态，假设已准备好进行 WebSocket 通信，并将响应转发给客户端。
结果，反向代理被误导以为客户端和后端之间已建立了 WebSocket 连接，而实际上，后端已拒绝了升级请求。尽管如此，代理保持客户端和后端之间的开放 TCP 或 TLS 连接，使客户端通过此连接无限制地访问私有 REST API。
受影响的反向代理包括 Varnish，它拒绝解决此问题，以及 Envoy 代理版本 1.8.0 或更早版本，后续版本已更改了升级机制。其他代理也可能受到影响。
此场景涉及一个具有公共 WebSocket API 和用于健康检查的公共 REST API 的后端，以及一个无法访问的内部 REST API。攻击更为复杂，包括以下步骤：
客户端发送 POST 请求以触发健康检查 API，包括额外的 HTTP 头 Upgrade: websocket。作为反向代理的 NGINX 仅基于 Upgrade 头解释此请求为标准升级请求，忽略请求的其他方面，并将其转发到后端。
后端执行健康检查 API，访问由攻击者控制的外部资源，返回带有状态码 101 的 HTTP 响应。一旦后端收到此响应并转发给 NGINX，由于代理仅验证状态码，它会被欺骗以为已建立 WebSocket 连接。
警告： 该技术的复杂性增加，因为它需要与能够返回状态码 101 的端点进行交互。
最终，NGINX 被欺骗以为客户端和后端之间存在 WebSocket 连接。实际上，并不存在这样的连接；健康检查 REST API 是目标。尽管如此，反向代理保持连接开放，使客户端通过它访问私有 REST API。
大多数反向代理都容易受到此场景的影响，但利用取决于外部 SSRF 漏洞的存在，通常被视为低严重性问题。
检查实验室，测试两种场景：https://github.com/0ang3el/websocket-smuggle.git
Try Hard Security Group
