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

Question

更新：我已经结束了对这个问题的研究，并发布了一篇冗长的博客文章来解释我的发现：JWT 的不言而喻的漏洞。我解释了使用 JWT 进行本地身份验证的巨大推动如何忽略了一个关键细节：必须保护签名密钥。我还解释说，除非您愿意不遗余力地保护密钥，否则最好通过 Oauth 委托身份验证或使用传统的会话 ID。

---

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

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

将此与基于会话 ID 的服务器违规进行对比。如果此服务器正在散列密码，则攻击者必须在会话 ID 过期之前分别为每个用户获取并使用会话 ID。如果服务器仅存储会话 ID 的哈希值，则攻击者必须写入服务器以确保访问。无论如何，攻击者似乎没有那么有利。

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

我的担忧似乎仅适用于不受信任的客户端使用 JWT 作为身份验证令牌。然而，JWT 被许多备受瞩目的 API 使用，包括 Google API。我错过了什么？也许服务器漏洞很少是只读的？有没有办法降低风险？

Answer 1

我相信你正在以错误的方式思考这个问题。不要误会我的意思，您考虑安全性很好，但是您处理它的方式涉及双重检查服务器端的事情，添加破坏无状态会话目标的额外检查等，似乎是一致的一条通往你自己理智尽头的单向街道。

总结一下两种标准方法：

• JWT 是无会话状态对象，由服务器端持有的密钥进行 MAC 处理。

• 传统的会话标识符存储在内存中或数据库服务器端，正如您所说，通常会进行散列以防止会话在此数据泄露时被劫持。

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

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

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

仔细检查您的 JWT 密钥的安全性是否符合您的风险偏好：

• 它们存放在哪里？
• 谁有访问权限？
• 备份存储在哪里？
• 在您的应用程序的预生产和生产部署中使用不同的密钥吗？

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

• 定期安全评估和渗透测试。
• 安全代码审查。
• 入侵检测和预防 (IDS/IPS)。
• 华夫。

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