不受信任的 URL 参数允许任意 WebSocket 连接 (对 #2011 的跟进)

描述错误

尊敬的noVNC 维护人员， 我正在为客户进行渗透测试，并发现了最新版noVNC（之前在 https://GitHub.com/novnc/noVNC/issues/2011 中报告过的）中存在的一个潜在问题。从我的角度来看，问题 https://GitHub.com/novnc/noVNC/issues/2011 正确地提出了，但我认为 0xspade 所描述的影响可能没有完全捕捉到风险，这可能导致它被关闭。 正如 0xspade 所概述的那样，攻击者可以控制受害者连接的主机和端口。然而，问题并不仅限于 IP 曝光。通过允许未经验证的、由用户控制的连接参数通过 URL，攻击者可以使受害者的浏览器与一个由攻击者控制的 VNC 服务器建立 WebSocket 连接，同时将会话置于受信任的源下。 我理解这是预期的用法，但如果没有保障措施，这种行为可能会被滥用来进行钓鱼攻击，例如呈现登录界面以捕获用户凭据。这在受害者预期连接到合法的远程访问门户的情况下尤其重要，例如我在进行的渗透测试中。 重现 下面是两个示例 URL，攻击者可以通过电子邮件链接（例如 Cross-Site Request Forgery）将其传递给受害者，同时托管一个恶意 VNC 服务器，该服务器模仿攻击者想要竞价凭据的目标主机： vnc.html：https://<host>:<port>/vnc.html#host=<adversaryhost>&port=<adversaryport>&autoconnect=true&encrypt=1 vnc_lite.html：https://<host>:<port>/vnc_lite.html?host=<adversaryhost>&port=<adversaryport>&password=

预期行为 从我的角度来看，0xspade 正确地建议了适当的缓解措施：实施主机白名单。即使在“无服务器”环境中（如上述提交中的提示中所述），这种方法也是可行的，并将防止上述描述的攻击场景。 具体来说，通过参数提供的主机值应验证为来自可信位置（例如文件系统、Web 根）的预定义主机集合中的一项。如果值与批准的条目匹配，则允许连接继续；否则，它被拒绝，从而有效阻止了攻击。 **或者，该问题可以通过正确配置的内容安全策略（CSP）来缓解，该策略限制了允许的 WebSocket 端点（ws: / wss:）。然而，在实际中，许多系统管理员可能不熟悉正确配置 CSP。因此，提供明确的指导（例如硬化指南）对于确保有效地应用此缓解措施至关重要。 屏幕截图 我将提供一些屏幕截图，以说明攻击者如何利用该漏洞。 我将在下一步中提供更多详细信息。 感谢您的关注