如何通过 3 个步骤修复 JWT 安全漏洞

1）损坏的库

2）不安全的代币生成和分发

3）不安全地处理密钥

1.托管服务

2. 企业内部机密管理

错误使用 JWT 的方式实在太多了。😢

我也曾陷入其中...不要惊慌，但你也可能遇到这种情况。

检查 JWT 实现中这 3 个常被忽视的安全领域。只需几分钟即可完成。

1）损坏的库

npm 上有 +1,600 个与“jwt”匹配的库。😳

Pypi 上+ 300。😲

我们都需要它们吗？当然不需要。它们都安全吗？我不会相信。😖

您选择的 JWT 库可能会通过多种方式受到损害。

我们能找到一个简单的解决方案吗？

是的，我也对安全等等等等感到厌烦。💤

请访问此资源，仔细检查哪些图书馆遵循了已证实安全的做法。现在大多数图书馆都会这样做。但谨慎行事总比后悔好。

2）不安全的代币生成和分发

快乐的实现：🍀

a. 前端请求用户身份验证

b.后端认证并生成JWT

c. JWT 在响应主体有效负载中发送

d. 前端将 JWT 存储在localStorage

啊，是的……如果没有坏人，如果没有丑陋的事情发生，世界将会很美好。😇

好吧。回到现实世界吧。😎

避免遵循上述大纲。

为了帮助解决 (a) 和 (b) 问题，请确保你选择的 JWT 库遵循最佳实践，或者你自己正确实现了它。其实并不难，只要你足够用心就可以了。

记录每次身份验证尝试（成功和失败）以及可能拥有的所有上下文数据也是一种很好的做法。

JWT 经常用于无服务器环境中（因为两者都是无状态的，好极了！）。

如果您的情况如此，请确保有专业人员监控您的日志并主动发出警报。如果不是，这个建议仍然适用。😉

针对第 (c) 和 (d) 项：

不要在响应主体有效负载中发送 JWT

不要将JWT 存储在localStorage

问题是：你前端的任何 JavaScript 代码都可以访问 JWT，并执行任何它想做的事情。

这很危险。

想象一下，如果有人设法在你的前端注入恶意代码...并获取所有用户的 JWT，会发生什么？......嗯......休斯顿......

不。相反，后端应该将 JWT 设置为用户浏览器中的 Cookie。确保将其标记为cookie 。Secure这httpOnly可是多用途 Cookie SameSite。

这样，JWT 将在所有后续请求中可供后端使用，同时又不受潜在的肮脏 JS 的控制。

在响应主体的有效负载中，仅发送前端提供用户期望功能所需的必要内容。我是否提到过不要包含任何敏感信息？不应该。

我知道。饼干没那么酷localStorage。但是，你看，它们可以五彩缤纷！而且很安全。他是我们的朋友。我们好好对待他吧。成交？🙌 🍪

3）不安全地处理密钥

任何 JWT 实现都会涉及某种秘密数据。无论使用对称（一个密钥）还是非对称（公钥/私钥）方式对令牌进行签名。

就我个人而言，我更喜欢用 HMAC 来实现对称加密。这样比较简单。不过我有时也会用非对称 RSA。最近我只用了后者。好吧，他们永远也不知道我到底用的是哪一种。😜

任何人都不应该知道你是如何实现 JWT 的。更不用说你的密钥或私钥了。

尽可能避免使用秘密/私钥进行以下操作：

• 💻 存储在config文件中并提交到你的 Git 仓库
• 📣 通过 Drive、Dropbox、Slack 等方式与你的团队共享
• ♻️ 本地、测试和生产环境使用相同的密钥

反而：

• ✌️ 为您的开发团队分发密钥，仅供本地和测试环境使用
• 👍 将生产密钥存储在安全的地方，仅供生产应用程序使用
• 🔐 将生产密钥远离窥探，按需加载它们作为环境变量，防止意外访问

进一步阅读：

• Auth0 博客文章：关于 JWT 库漏洞
• 关于 JWT 的OWASP 备忘单
• OWASP 关于管理安全密钥的备忘单
• 无服务器应用程序的关键安全日志

全面披露：我是Dashbird的开发倡导者。

图片来源：

• 封面图片：Unsplash上的Vincent van Zalinge
• 纸杯蛋糕：Viktor Forgacs在Unsplash上
• 《蝎子》：Shayna 接受Unsplash采访
• 饼干（其实不是，它们实际上是马卡龙）：Unsplash上的Mockaroon