security - 破坏基于 JWT 的服务器是否更具破坏性？

Question

更新 : 我已经结束了对这个问题的研究，并发表了一篇长篇博文来解释我的发现:The Unspoken Vulnerability of JWTs .我解释了使用 JWT 进行本地身份验证的巨大插入力如何遗漏了一个关键细节:必须保护签名 key 。我还解释说，除非您愿意竭尽全力保护 key ，否则最好通过 Oauth 委托(delegate)身份验证或使用传统的 session ID。

我已经看到很多关于 JSON Web token 安全性的讨论——重放、撤销、数据透明度、 token 指定的算法、 token 加密、XSS、CSRF——但我没有看到任何对依赖于签名 key 。

如果有人破坏了服务器并获得了 JWT 签名 key ，在我看来，此人随后可以使用该 key 来伪造未过期的 JWT 并 secret 获得访问权限。当然，服务器可以在每个请求上查找每个 JWT 以确认其有效性，但服务器完全使用 JWT，因此它们不必这样做。服务器可以确认 IP 地址，但如果 JWT 不可信，这也涉及查找，显然这样做会排除可靠的移动访问。

将此与基于 session ID 的服务器入侵进行对比。如果此服务器正在对密码进行哈希处理，则攻击者必须在 session ID 过期之前为每个用户单独获取和使用 session ID。如果服务器只存储 session ID 的哈希值，攻击者将不得不写入服务器以确保访问。无论如何，似乎攻击者的优势较小。

我发现一种使用 JWT 的架构没有这个缺点。反向代理位于外部不受信任的客户端和内部微服务的后端集合之间，described here by Nordic APIs .客户端从授权服务器获取不透明 token ，并使用该 token 与服务器应用程序通信以处理所有请求。对于每个请求，代理将不透明 token 转换为 JWT 并缓存它们的关联。外部世界从不提供 JWT，从而限制了窃取 key 造成的损害(因为代理转到身份验证服务器以确认不透明的 token )。但是，这种方法需要取消引用每个客户端 token ，就像 session ID 需要取消引用每个请求一样，从而消除了 JWT 对客户端请求的好处。在这种情况下，JWT 只允许服务在它们之间传递用户数据，而不必完全信任彼此——但我仍在尝试理解这种方法的值(value)。

我的担忧似乎只适用于不受信任的客户端使用 JWT 作为身份验证 token 。然而，包括 Google API 在内的许多知名 API 都在使用 JWT。我错过了什么？也许服务器违规很少是只读的？有没有办法降低风险？

Answer 1

我相信你在想这个错误的方式。不要误会我的意思，您正在考虑安全性很好，但是您在服务器端仔细检查事物、添加违反无状态 session 目标的额外检查等方面的处理方式似乎是一致的一条通往你自己理智尽头的单行道。

总结两种标准方法:

JWT 是无 session 状态对象，由服务器端保存的 key 进行 MAC'd。

传统的 session 标识符要么存储在内存中，要么存储在数据库服务器端，正如你所说，通常会被散列以防止 session 被劫持，如果这些数据被泄露。

您也是对的，攻击者通常更难以实现写访问。原因是数据库数据通常是通过 SQL injection 从目标系统中提取的。开发。这几乎总是提供对数据的读取访问，但使用这种技术插入数据更难，尽管并非不可能(一些漏洞实际上导致目标机器的完全根访问)。

如果您有一个在使用 JWT 时允许访问 key 的漏洞，或者在使用 session 标识符时允许写入数据库表的漏洞，那么游戏就结束了——您会受到威胁，因为您的用户 session 可能被劫持。

所以不一定更具破坏性，这完全取决于漏洞的深度。

仔细检查您的 JWT key 的安全性是否符合您的风险偏好:

它们存储在哪里？

谁有权访问？

备份存储在哪里？

您的应用程序的预生产和生产部署中是否使用了不同的 key ？

缓解的方法与任何 Web 应用程序的良好实践一样:

定期安全评估和渗透测试。

安全代码审查。

入侵检测和预防 (IDS/IPS)。

WAF。

这些将帮助您评估您的真正风险所在。如此专注于应用程序的一个特定方面是没有意义的，因为这会导致忽略其他方面，这很可能会给您的业务模型带来更高的风险。 JWT 并不危险，并且不一定比系统的其他组件具有更大的风险，但是如果您选择使用它们，则应确保正确使用它们。无论您是否是应用程序的特定上下文，这在一般意义上很难评估，所以我希望我的回答能够引导您朝着正确的方向前进。