JSON 网络令牌（JWT）已成为许多组织首选的身份验证方法。它们易于实施，因此成为保护 API 和网络应用程序安全的热门选择。但是，如果管理不当，JWT 可能会带来安全漏洞，使系统面临风险。您可能自己也使用过 JWT。
但是，您是否安全地实施和处理了它们？
Akamai 的一篇博文强调了与 JWT 相关的几个常见安全漏洞。这给我们敲响了警钟，让我们认识到不当管理 JWT 可能带来的风险。在这篇博文中，我想在此基础上，重点谈谈经常被忽视的另一个漏洞：JWTs 不能过期。我们将探讨这个问题是如何产生的，以及相关的安全漏洞。然后，我将提供一些指导，让您知道如何保护自己免受这些安全漏洞的伤害。
常见 JWT 漏洞概述
在深入探讨之前，让我们先简要回顾一下上述博文中强调的 JWT 漏洞。作者提到的 JWT 面临的六大威胁是
- 允许服务器使用未经验证的令牌：如果服务器不检查令牌的完整性，攻击者就更容易操纵和利用令牌。攻击者还可能将验证算法 (alg) 设置为 "无"，试图操纵服务器根本不验证令牌。
- 在不同的应用程序中使用相同的私人密钥：如果密钥暴露，这种做法可能会危及多个应用程序。
- 使用弱签名算法：弱签名算法更容易被破解，导致未经授权的访问。
- 选择简短和/或低熵的私人密钥：太短或缺乏随机性的密钥更容易受到暴力攻击。
- 在 JWT 有效载荷中保留敏感数据：如果令牌被拦截，存储在有效载荷中的敏感信息就会暴露。
- 混淆密钥：密钥管理不善会导致错误验证，从而允许未经授权的访问。
有关这些漏洞的详细信息，请查看博文。接下来，让我们看看另一个漏洞：JWT 未过期。
附加漏洞：未过期的 JWT
让我们来看看下面的 JWT，它是基于我不久前遇到的一个真实世界的例子：
这是用于验证和授权用户访问 API 的 JWT。它使用安全密文签名，以防止伪造。乍一看，它还不错。但让我们仔细看看有效负载：
{ |
当你看到 ttl claim 时，你可能会想到 time-to-live，因为这就是 TTL 的典型含义。因此，这可能与 JWT 的有效期有关。这一定是过期时间。
我们可以做一些简单的计算。也许 86,400,000 是秒数，在这种情况下，发行者希望这个 JWT 的有效期为 1000 天。或者，他们指的是毫秒，在这种情况下，他们希望这个 JWT 的有效期为 1 天。这样也说得通。
但问题是：JWT 规范规定过期时间为 exp，而不是 ttl：
| exp"（过期时间）声明确定了 JWT 在过期时间或过期时间之后不得接受处理的过期时间。 对 "exp "声明的处理要求当前日期/时间必须在 "exp "声明中列出的过期日期/时间之前。 实现者可以留出一些小余地（通常不超过几分钟），以考虑时钟偏差。 其值必须是一个包含 NumericDate 值的数字。 该声明的使用是可选的。 |
那么，我们就有几个问题了。
首先，该 JWT 的签发者使用 ttl 来指定过期时间，但 ttl 并不是标准的 JWT 声明。大多数设计用于处理 JWT 的库都不会将 ttl 识别为与令牌过期有关的指令。这将导致兼容性问题，令牌很可能会被当作非过期令牌处理。
其次，exp 索赔要求的是过期的实际时间戳，而不是距离发布时间的相对毫秒数（或秒数）。这种混淆可能是因为使用了 ttl 而不是 exp。尽管如此，发行者还是需要了解 exp 索赔的预期格式，以确保令牌正确过期。
无论您是忽略了设置 JWT 的过期时间，还是设置了错误的过期时间（如我们的示例），您的 JWT 都将被视为非过期状态。这就存在一个重大的安全漏洞。
| 如果没有适当的过期时间，JWT 就可能被攻击者重复使用或在其预期寿命之外泄漏、增加未经授权访问的风险。 |
缓解 JWT 安全漏洞
既然我们已经介绍了潜在的安全漏洞，那么后续问题就是：您应该如何应对？幸运的是，缓解这一漏洞的方法简单而直接！
始终使用 过期 声明。为生成的每个令牌设置过期时间。这样做时，请确保使用带有预期值格式的标准 exp 声明，以确保其符合 JWT 规范并按预期过期。
更新应用程序和库。确保您的应用程序和使用的任何库都已更新，并符合最新的 JWT 标准。定期更新有助于修复安全漏洞并提高兼容性。
就是这样。遵循这些简单的指导原则，就能大大降低通过未过期的 JWT 进行未经授权访问的风险。这将提高 JWT 实施的整体安全性。
总结
了解并解决 JWT 漏洞对于维护应用程序的安全至关重要。在这篇文章中，我们强调了令牌不能过期的风险。通过正确使用过期声明并不断更新库，您可以有效降低这一风险。
有关进一步的安全解决方案和最佳实践，请浏览Linode 文档中的可用资源。Linode 提供全面的指南，帮助您消除应用程序中的安全漏洞。
注释