WebSocket 身份验证安全性

Posted 2023-03-10

【中文标题】WebSocket 身份验证安全性

【英文标题】：WebSocket authentication security

【发布时间】：2014-04-30 21:32:23

【问题描述】：

我正在尝试向注册会员区的安全 WebSocket 服务器 (wss) 验证客户端。

一旦成员连接到 Web 服务器，我会在数据库中记录一个唯一令牌（与成员相关联），该令牌显示在页面上的隐藏字段中，以启动与 Web Socket 服务器的连接。

然后将令牌发送到使用令牌对帐户进行身份验证的 WebSocket 服务器。

我真的不是安全专家，我希望您对我的身份验证的安全性提出意见。

是否存在任何风险（cookie 劫持除外）？考虑到 WebSocket 没有规定服务器可以在 WebSocket 握手期间对客户端进行身份验证的任何特定方式，有没有更好的方法可以继续。

我使用 Ratchet WebSocket。

【问题讨论】：

另见Websocket authentication。我不相信它是重复的，因为它在 WebSocket 中询问 HTTP 登录。

令牌中有什么？大多数会话/身份验证令牌具有某种时间限制机制（以减轻泄漏的影响），并且可能是一种机制，用户可以使旧令牌无效（例如在更改密码时）。您的令牌是否包括签名的到期时间，或者充当具有类似属性的服务器端状态存储的密钥？

SocketCluster 最初使用 cookie 来存储 JWT 令牌，但它已不再使用此功能。你可以在这里阅读原因：github.com/SocketCluster/socketcluster-client/issues/9

【参考方案1】：

是的，一种选择是使用 cookie（和 TLS 以避免 cookie 劫持）：

在“plain old html form based”登录后设置cookie，将cookie传输到WebSocket服务器，并使用cookie对WebSocket进行身份验证。

这是使用 WebSocket 进行基于 Mozilla Persona 身份验证的complete example。

您询问了 Ratchet。这个例子不是 Ratchet，但它可能会给你一些线索——这就是为什么我认为可以指出来。

【参考方案2】：

有没有风险...

是的，很多。 PKI/PKIX 和 SSL/TLS 有许多架构缺陷。有关完整的处理方法，请参阅 Peter Gutmann 的 Engineering Security。

另外，WebSockets 不允许您查询底层连接的属性。所以，据我所知，你甚至无法判断你是否真的在使用 SSL/TLS。您唯一会知道的就是您请求了它。

---

考虑到 WebSocket，有没有更好的方法来继续

我上次检查时，WebSockets 很糟糕。你要做的就是open、read 和write。它们旨在易于使用，但缺乏与安全相关的任何有用信息。

---

为了完整起见，我最后一次检查是在 2013 年 3 月，当时我正在对使用它们的应用进行安全评估。现在情况可能已经改变。

我还尝试让WebSockect RFC 作者和 RFC 编辑从安全角度讨论一些问题。所有的电子邮件都没有得到答复。

---

更新（2015 年）：它变得更好......浏览器和其他用户代理现在有 Host Public Key Pinning。

但是如果你看细节，它应该被称为“Host Public Key Pinning with Overrides”。内置的覆盖允许攻击者破坏一个好的 pinset。更糟糕的是，浏览器是掩盖行为的同谋，因为它必须抑制失败的 pin 报告。

您可以在Comments on draft-ietf-websec-key-pinning 阅读有关它的更多投诉（以及反驳）。

这是一个不应该标准化的垃圾标准。它更不安全的浏览器垃圾。

【讨论】：

需要区分浏览器中的 WebSocket protocol (RFC6455) 和 W3C WebSocket API。在浏览器中运行的 javascript 无法检索，例如安全连接上的证书 - 这与使用 WebSocket、AJAX 或其他任何东西无关。这是设计使然。运行在 Intranet 上的恶意 JS 可能会在网络上“四处探查”。

不，不是那个意思。证书由浏览器验证（在这种情况下验证意味着：检查证书是否对浏览器内置的信任链有效）。如果在浏览器之外运行，WebSocket 客户端当然可以并且应该验证服务器证书本身。

浏览器确实知道哪些 CA 可以使服务器证书有效：信任存储中的 CA 证书。对于 Windows 上的 IE/Chrome，例如使用了操作系统范围的信任存储。 PC 的用户/管理员可以修改信任库。因此，您可以删除除一个 CA 证书之外的所有证书，并且如果服务器证书是由该 CA 颁发的，则浏览器将仅通过 TLS 连接到服务器。

问题是复数 - “CAs”。有一个有效的颁发 CA（没有使用 PKI 桥接的交叉签名或交叉认证）。无需信任 CA zoo（或 DNS）。这让我们在过去遇到了麻烦。这就是 Comodo 黑客成功利用受感染的 Diginotar 根进行攻击的原因。这也是 Trustwave 在他们的中间人攻击中成功的原因。

是的。我同意那个。服务器证书没有“固定”到特定的颁发 CA 是一个问题。正在进行的修复：security.stackexchange.com/questions/29988/…