curl | 报告 #3480713 - 从代理连接重定向到直接连接后，Proxy-Authorization 标头泄露给源服务器

时间线 yupiy 向 curl 提交了一份报告。2 天前

摘要 cURL 在遵循一个从代理连接过渡到直接连接的 HTTP 重定向后（例如，在使用 --noproxy 或在重定向后代理被绕过时），会将 Proxy-Authorization 标头泄露给源服务器。这导致代理凭据（这些凭据是逐跳的）被发送到非预期的服务器。

受影响版本 测试环境：

• curl 8.17.0 on Linux x86_64
• curl -V 输出：

  1	[在此处粘贴 curl -V 输出]

复现步骤

1. 启动一个伪造的源服务器：

   1	nc -l -p 8080

2. 启动一个伪造的代理，该代理重定向到源服务器：

   1	printf "HTTP/1.1 302 Found\r\nLocation: http://127.0.0.1:8080/\r\nContent-Length: 0\r\n\r\n" | nc -l -p 3128

3. 运行 curl：

   1 2 3 4 5

   curl -v -L \ -x http://127.0.0.1:3128 \ -H "Proxy-Authorization: Basic RAHASIA_NEGARA_BOCOR" \ --noproxy 127.0.0.1 \ http://example.com

4. 观察源服务器接收到的请求。

观察到的行为 cURL 详细输出：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

Trying 127.0.0.1:3128...
Established connection to 127.0.0.1 (127.0.0.1 port 3128)

GET http://example.com/ HTTP/1.1
Host: example.com
User-Agent: curl/8.17.0
Accept: */*
Proxy-Connection: Keep-Alive
Proxy-Authorization: Basic RAHASIA_NEGARA_BOCOR
< HTTP/1.1 302 Found
< Location: http://127.0.0.1:8080/
< Content-Length: 0


Trying 127.0.0.1:8080...
Established connection to 127.0.0.1 (127.0.0.1 port 8080)

GET / HTTP/1.1
Host: 127.0.0.1:8080
User-Agent: curl/8.17.0
Accept: */*
Proxy-Authorization: Basic RAHASIA_NEGARA_BOCOR

源服务器输出 (nc -l -p 8080)：

1
2
3
4
5

GET / HTTP/1.1
Host: 127.0.0.1:8080
User-Agent: curl/8.17.0
Accept: */*
Proxy-Authorization: Basic RAHASIA_NEGARA_BOCOR

预期行为 Proxy-Authorization 标头绝不应被转发给源服务器，当请求被直接发送（而非通过代理发送）时，该标头应被剥离。

支持材料 附件：

• 显示标头泄露的 curl 详细输出
• 显示泄露的 Proxy-Authorization 标头的源服务器日志

影响 如果代理请求被重定向到直接连接，攻击者控制的源服务器可以窃取代理凭据。这违反了 HTTP 语义（Proxy-Authorization 是逐跳的），可能导致凭据泄露和未经授权的代理访问。

讨论 bagder (curl 工作人员) 发布了一条评论。2 天前 感谢您的报告！ 我们将花些时间调查您的报告，并尽快向您反馈详情和可能的后续问题！很可能在接下来的 24 小时内。 我们始终致力于尽快修复报告的问题。对于严重性为低或中等的问 题，我们通常会将其合并到下一个常规发布周期中。只有对于更严重的问题，我们才可能提前发布修复。

bagder (curl 工作人员) 发布了一条评论。2 天前 这是一个用户明确发送此标头的示例。 cURL 并未声称在重定向时不发送此标头。 我们警告用户不要这样做（在重定向时使用自定义标头）。 cURL 提供了设置代理凭据的选项，这些选项没有此问题。 我不认为这是 cURL 的安全问题。

jimfuller2024 (curl 工作人员) 发布了一条评论。一天前 在 RFC7230 中我们有：“逐跳标头仅对单个传输层连接有意义，且不得由代理转发。” 在 RFC7235 中我们有："Proxy-Authorization 请求标头字段允许客户端向需要身份验证的代理标识自身（或其用户）。代理在转发请求前，可以移除请求中的 Proxy-Authorization 字段。" 以上内容基于每个’跳’的上下文参与。例如，在本报告概述的场景中 - 如果用户使用 --noproxy 或在重定向时使用自定义标头，那么标头被转发（因为没有代理），用户不应感到意外。 我们可能会考虑提供更多文档或明确的警告，但这可以作为针对项目的一个 PR 来讨论。 调用 curl 或使用 libcurl 的应用程序的逻辑应该是决定何时设置自定义标头的逻辑。要求 cURL 使原始 curl 调用’更安全’在我看来似乎是个滑坡谬误… 不是安全问题（尽管在获得更多信息后保持开放态度）。

bagder (curl 工作人员) 关闭了报告并将状态更改为不适用。一天前 感谢您的报告。 经过考虑，认为这不是一个安全问题。

bagder (curl 工作人员) 请求公开此报告。一天前 根据项目的透明性政策，我们希望所有报告都被公开。

bagder (curl 工作人员) 公开了此报告。一小时前

报告详情