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

更新：我已经结束了对这个问题的研究，并发布了一篇长篇的博客文章，解释了我的发现：。我解释了使用JWTs进行本地身份验证的巨大推动是如何忽略了一个关键细节的：签名密钥必须受到保护。我还解释说，除非您愿意竭尽全力保护密钥，否则最好通过Oauth授权身份验证或使用传统会话ID

---

我看过很多关于JSON Web令牌安全性的讨论——重播、撤销、数据透明、令牌指定的alg、令牌加密、XSS、CSRF——但我没有看到任何关于依赖签名密钥所带来风险的评估

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

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

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

---

我的担忧似乎只适用于不受信任的客户端将JWT用作身份验证令牌。然而，jwt被许多引人注目的api使用，包括googleapi。我错过了什么？也许服务器漏洞很少是只读的？有没有降低风险的方法？

我相信你的想法是错误的。别误会我的意思，你考虑安全性很好，但是你在服务器端进行双重检查、添加额外的检查以挫败无状态会话的目标等方面的做法似乎是沿着一条单行道走向你自己的理智的尽头

总结两种标准方法：

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

• 传统的会话标识符要么存储在内存中，要么存储在数据库服务器端，正如您所说的，它们经常被散列，以防止在数据泄漏时会话被劫持

您还说得对，对于攻击者来说，写访问通常更难实现。原因是数据库数据通常是通过利用漏洞从目标系统中提取的。这几乎总是提供对数据的读取访问，但是使用这种技术插入数据会更加困难，尽管这并非不可能（一些利用漏洞的行为实际上会实现对目标机器的完全根访问）

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

因此，不一定更具破坏性，这完全取决于脆弱性的深度

仔细检查JWT密钥的安全性是否与您的风险偏好一致：

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

缓解的方法与任何web应用程序的良好实践要求相同：

• 定期安全评估和渗透测试
• 安全代码审查
• 入侵检测和预防（IDS/IPS）
• 瓦夫

---

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

当攻击者能够在基于JWT的系统中获得签名密钥时，这意味着他能够访问服务器后端本身。那样的话，一切希望都破灭了。相比之下，当相同的攻击在基于会话的系统中成功时，攻击者将能够拦截到后端的用户名/密码身份验证请求，和/或自己生成会话id，和/或更改验证会话id和/或修改会话id指向的数据所需的验证例程。随时