开发现代 web 应用程序时,最常见的身份验证方法之一是使用 json web 令牌 (jwt)。 jwt 很强大,但如果不安全地实施,它们可能会让您的应用程序面临各种风险。在这篇博客中,我将通过 jwt 分析开发人员面临的常见陷阱(ps:我也遇到过......)以及确保整个应用程序安全的最佳实践。
jwt 是一个开放标准 (rfc 7519),它定义了一种以 json 对象的形式在两方之间安全传输信息的方法。它最常用于无状态系统中的身份验证。
jwt 由三部分组成:
继续查看 www.jwt.io
尽管 jwt 简单且强大,但不正确的 jwt 实现可能会导致严重的安全漏洞,以下是我遇到的一些常见陷阱以及改进方法。
陷阱: 由于 jwt 的简单性,许多开发人员将 jwt 存储在本地存储中,但这种方法容易受到 xss(跨站脚本)攻击,即黑客可以轻松地通过您的浏览器窃取该令牌,并可能构成攻击作为一个真实的用户。
解决方案: 将 jwt 存储在仅 http 的 cookie 中,而不是本地存储。 javascript 无法访问这些 cookie,这让黑客的日子变得更加艰难。
陷阱:如果创建的 jwt 没有过期时间,则即使在用户注销或令牌被泄露后,它们也可以无限期地使用。
解决方案: 始终在有效负载中设置过期 (exp) 声明。合理的到期时间迫使用户定期刷新令牌,减少潜在令牌滥用的窗口。
var token = jwt.sign({email_id:'123@gmail.com'}, "Stack", { expiresIn: '3d' // expires in 3 days });
陷阱:这是一个非常常见的错误,我仍然容易忘记,jwt 有效负载是 base64 编码的,但未加密,存储敏感信息(如密码或密钥)任何人都可以轻松读取有效负载中的内容,甚至无需密钥!
解决方案: 始终仅在 jwt 负载中存储非敏感、非关键信息,例如用户角色或 id。如果您需要发送敏感数据,请加密整个令牌有效负载。
陷阱: jwt 本质上是无状态的,因此撤销令牌(例如注销后)可能很棘手。由于没有默认的方法来处理这个问题,我们需要一个自定义的解决方案。如果没有适当的撤销,jwt 将保持有效直到过期,从而允许每个用户同时激活多个 jwt。
解决方案:实施令牌黑名单或使用刷新令牌。注销时将令牌存储在黑名单中,并确保服务器检查每个请求的黑名单。或者,使用短期访问令牌与刷新令牌相结合来强制更频繁地重新身份验证。
jwt 是无状态身份验证的优秀工具,但需要谨慎处理以避免引入安全风险。通过避免常见的陷阱并遵循最佳编码实践,我学会了创建安全的身份验证系统,并作为初学者面临所有这些问题。
采取这些步骤不仅可以提高应用程序的安全性,还可以展示您对安全令牌管理的深刻理解——这是开发领域备受追捧的技能。