在阅读您发布的链接之前，我不知道这一点，因此不要将此答案视为权威。我建议您现在采取“立即缓解”下列出的预防措施，直到您完全确定自己没有受到影响。

首先，这个漏洞是如何工作的？这是“工作原理”下解释的 PHP 示例的简短形式：

1. 攻击者发送一个请求，Proxy标头设置为攻击者控制的恶意 IP。
2. 如果服务器运行 CGI，则所有标头的值都以 结尾getenv("HTTP_NAME_OF_HEADER")，或者在这种情况下为getenv("HTTP_PROXY")。
3. 如果在服务器上运行的脚本也使用 HTTP 客户端（如 Guzzle）来发送它自己的请求，它可能也会读取getenv("HTTP_PROXY")，但不是为了获取标头，而是要知道它是否应该使用代理来处理传出流量。攻击者发送的 IP 将被用作代理。
4. 攻击者现在可以 MITM 服务器发出的所有传出请求。

需要注意的重要一点是，这里有两个请求：

• A. 第 1 步中的一个，攻击者向易受攻击的服务器发出请求。
• B. 第 3 步中的一个，其中易受攻击的服务器充当客户端并在其他地方发出请求。

如果您对 A 使用 HTTPS，那没关系（我猜这就是“通过 TLS 服务的站点”的意思）。无论如何，它都会被加密为普通的旧 HTTP。所以你很脆弱。

但是，如果您对 B 使用 HTTPS，这可能很重要，因为（正如hectorct在评论中指出的那样）攻击者无论如何都无法 MITM 请求，假设客户端检查证书并且 TLS 是好的等等。这是他们在这些段落中谈论的第二个请求（我的亮点）：

有几件事情是脆弱的：

• 在类似 CGI 的上下文中运行的代码，其中HTTP_PROXY变为真实或模拟的环境变量
• 信任 HTTP_PROXY 并将其配置为代理的 HTTP 客户端
• 该客户端在请求处理程序中使用，发出 HTTP （而不是 HTTPS）请求

当然，另一种有效的纵深防御策略是将 HTTPS 用于内部请求，而不仅仅是保护您的站点与外部世界的连接。那些不受HTTP_PROXY.

TLS 是端到端加密，这意味着客户端和服务器之间的流量是加密的，例如执行中间人攻击的人无法访问。这不会以任何方式保护您的服务器，它只会保护传输的数据。所以是的，它可以通过 http 和 https 被利用。