报告 #3474865 - libcurl WebSocket握手接受任何Sec-WebSocket-Accept值

报告人: pwnie 提交时间: 8天前 状态: 已披露 (报告者: pwnie)

摘要

libcurl在升级到WebSocket协议时未验证Sec-WebSocket-Accept响应头，允许伪造的101响应完成握手并注入数据帧；本报告在起草时使用了AI辅助。

复现步骤

1. 克隆并构建curl源码：

   1	git clone --depth=1 https://github.com/curl/curl /tmp/curl && cd /tmp/curl && autoreconf -fi && ./configure --disable-shared --without-ssl --without-libpsl --disable-dependency-tracking && make -j4 && make -C docs/examples websocket

2. 运行一个TCP服务器，该服务器回复一个固定的错误Sec-WebSocket-Accept值和一个文本帧，且不读取请求（示例：HTTP/1.1 101 Switching Protocols + Upgrade: websocket + Connection: Upgrade + Sec-WebSocket-Accept: WRONGKEY + 单个WS文本帧 "hello"）。
3. 在另一个终端中，运行示例客户端：/tmp/curl/docs/examples/websocket ws://127.0.0.1:9000/。
4. 观察输出，即使服务器使用了Sec-WebSocket-Accept: WRONGKEY，客户端仍会显示类似"ws: received TEXT frame 'hello'"的信息；客户端本应拒绝握手，但却接受了。

影响

握手完整性被破坏：伪造的或恶意的中间人可以在不知道客户端随机数（nonce）的情况下完成WebSocket升级，从而导致基于libcurl的WebSocket客户端出现协议混淆或数据注入。这违反了RFC 6455的挑战-响应保护机制，并允许接受盲目的101响应。

curl团队成员bagder的评论 (8天前):

恶意代理始终可以中间人攻击明文协议。这个缺失的实现似乎并没有让情况变得更糟？

bagder关闭了报告并将状态改为“不适用” (8天前):

被认为不是一个安全问题。仍有改进空间。我在首次实现时保留了这一点，假设一旦开始使用，“有人”会站出来实现缺失的部分。

bagder请求披露此报告 (8天前):

根据项目的透明政策，我们希望所有报告都被披露并公开。

bagder披露了此报告 (7天前):

报告详情:

• 报告时间: December 22, 2025, 5:49am UTC
• 报告人: pwnie
• 报告对象: curl
• 报告ID: #3474865
• 严重性: 无评级 (—)
• 披露时间: December 23, 2025, 12:20pm UTC
• 弱点: 无
• CVE ID: 无
• 赏金: 隐藏
• 账户详情: 无