(译)别再使用 JWT 作为 Session 系统!问题重重且很危险。
JSON Web Tokens,又称 JWT
。本文作者将详解:为何 JWT 不适合存储 Session,以及 JWT 引发的安全隐患。望各位使用前三思。
原文地址:http://cryto.net/~joepie91/blog/2016/06/13...
断断续续翻译了一周,今天终于审校一下,算是填坑完毕。自己博客广告走一波:https://wi1dcard.cn/。
十分不幸,我发现越来越多的人开始推荐使用 JWT 管理网站的用户会话(Session
)。在本文中,我将说明为何这是个非常非常差劲的想法。
为了避免疑惑和歧义,首先定义一些术语:
- 无状态 JWT(
Stateless JWT
):包含 Session 数据的 JWT Token。Session 数据将被直接编码进 Token 内。 - 有状态 JWT(
Stateful JWT
):包含 Session 引用或其 ID 的 JWT Token。Session 数据存储在服务端。 Session token
(又称Session cookie
):标准的、可被签名的 Session ID,例如各类 Web 框架(译者注:包括 Laravel)内已经使用了很久的 Session 机制。Session 数据同样存储在服务端。
需要澄清的是:本文并非挑起「永远不要使用 JWT」的争论 —— 只是想说明 JWT 并不适合作为 Session 机制,且十分危险。JWT 在其它方面的确有其用武之地。本文结尾,我将简短地介绍一些合理用途。
首先需要说明#
很多人错误地尝试比较 Cookies
和 JWT
。这种对比毫无意义,就像对比内存和硬盘一样。Cookies 是一种存储机制,然而 JWT Tokens 是被加密并签名后的令牌。
它们并不对立 —— 相反,他们可以独立或结合使用。正确的对比应当是:Session
对比 JWT
,以及 Cookies
对比 Local Storage
。
在本文中,我将把 JWT Tokens 同 Session 展开对比,并偶尔对比 Cookie
和 Local Storage
。这样的比较才有意义。
JWT 坊间流传的优势#
在人们安利 JWT 时,常常宣扬以下几点好处:
- 易于水平扩展
- 易于使用
- 更加灵活
- 更加安全
- 内置过期时间功能
- 无需询问用户「本网站使用 Cookies」
- 防止 CSRF 攻击
- 更适用于移动端
- 适用于阻止 Cookies 的用户
我将会逐条阐述以上观点为何是错误或误导性的,其中部分解释可能会有些模糊,这主要是因为这些「好处」的表述本身就比较模糊。你可以在文末找到我的联系方式,我将十分乐意对更加具体的「好处」进行分析阐述。
易于水平扩展?#
这是列表中唯一一条在技术层面部分正确的「好处」,但前提是你使用的是无状态 JWT Tokens。然而事实上,几乎没人需要这种横向扩展能力。有很多更简单的拓展方式,除非你在运维像淘宝这样体量的系统,否则根本不需要无状态的会话(Stateless sessions
)。
一些扩展有状态会话(Stateful sessions
)的例子:
- 在单台服务器上运行多个后端进程:只需在此服务器上安装 Redis 服务用于存储 Session 即可。
- 运行多台服务器:只需一台专用的 Redis 服务器用于存储 Session 即可。
- 在多集群内运行多台服务器:会话保持(又称:粘滞会话)。
以上所有场景在现有软件系统内都具备良好的支持,你的应用需要进行特殊处理的可能性基本为零。
或许你在想,应当为你的应用预留更多调整空间,以防未来需要某些特殊操作。但实践告诉我们,以后再替换 Session 机制并不困难,唯一的代价是,在迁移后所有用户将被强制登出一次。我们没必要在前期实现 JWT,尤其是考虑到它所带来的负面影响。我将在后文进行解释。
易于使用?#
这个真没有。你不得不自行处理 Session 的管理机制,无论是客户端还是服务端。然而标准的 Session cookies
则开箱即用,JWT 并没有更简单。
更加灵活?#
我暂时还没看到有人成功地阐述「JWT 如何更加灵活」。几乎每个主流的 Session 实现,都允许你直接把数据存储进 Session,这跟 JWT 的机制并没有差别。据我所知,这只是个流行语罢了。如果你不同意,可以随时带上示例与我联系。
更加安全?#
一大批人认为 JWT Tokens「更加安全」,理由是使用了加密技术。实际上,签名后的 Cookies 比未签名的 Cookies 同样更加安全,但这绝不是 JWT 独有的,优秀的 Session 实现均使用签名后的 Cookies(译者注:例如 Laravel)。
「使用加密技术」并不能神奇地使某些东西更加安全,它必须服务于特定目的,并且是针对该目的的有效解决方案。错误地使用加密反而可能会降低安全性。
另一个我听过很多次的对于「更加安全」的论述是「JWT 不使用 Cookies 传输 Tokens」。这实在是太荒谬了,Cookie 只不过是一条 HTTP 头信息,使用 Cookies 并不会造成任何不安全。事实上,Cookies 受到特别良好的保护,用于防止恶意的客户端代码。我将在后文进行阐述。
如果担心有人拦截掉你的 Session cookies,那你应当考虑使用 TLS。如果不使用 TLS,任何类型的 Session 机制都可能被拦截,包括 JWT。
内置过期时间功能?#
无意义,又没什么卵用的特性。在服务端也能实现过期控制,有不少 Session 实现就是这么做的。实际上,服务端的过期控制更加合理,这样你的应用就可以清除不再需要的 Session 数据;若使用无状态 JWT Tokens 且依赖于它的过期机制,则无法执行此操作。
无需询问用户「本网站使用 Cookies」?#
完全错误。并没有什么「Cookies 法律」—— 有关 Cookies 的各种法律实际上涵盖了任何类型「对某项服务的正常运行非严格必须的持久性 ID」,任何你能想到的 Session 机制都包括在内。
译者注:然鹅中国并没有。
简单来说:
- 若出于系统功能目的使用 Session 或 Token(例如:保持用户的登录态),那么无论怎样存储 Session 均无需征得用户同意。
- 若出于其他目的使用 Session 或 Token(例如:数据分析、追踪),那么无论怎样存储 Session 都需要询问用户是否允许。
防止 CSRF 攻击?#
这个真・真没有。存储 JWT Tokens 的方式大概有两种:
- 存入 Cookie:仍然易受 CSRF 攻击,还是需要进行特殊处理,保护其不受攻击。
- 其他地方,例如 Local Storage:虽然不易受到 CSRF 攻击,但你的网站需要 JavaScript 才能正常访问;并且又引发了另一个完全不同,或许更加严重的漏洞。我将在后文详细说明。
预防 CSRF 攻击唯一的正确方法,就是使用 CSRF Tokens。Session 机制与此无关。
更适用于移动端?#
毫无根据。目前所有可用的浏览器几乎都支持 Cookies,因此也支持 Session。同样,主流的移动端开发框架以及严谨的 HTTP 客户端库都是如此。这根本不是个问题。
适用于阻止 Cookies 的用户?#
不太可能。用户通常会阻止任何意义上的持久化数据,而不是只禁止 Cookies。例如,Local Storage 以及任何能够持久化 Session 的存储机制(无论是否使用 JWT)。不管你出于多么简单的目的使用 JWT 都无济于事,这是另一个完全独立的问题了。另外,试图让身份认证过程在没有 Cookies 的情况下正常进行,基本没戏。
最重要的是,禁用掉所有 Cookies 的多数用户都明白这会导致身份认证无法使用,他们会单独解锁那些他们比较关心的站点。这并不是你 —— 一个 Web 开发者应当解决的问题。更好的方案是,向你的用户们详细地解释为何你的网站需要 Cookies 才能使用。
JWT 的劣势#
以上,我已经对常见的误解做了说明,以及为什么它们是错误的。你或许在想:「这好像也没什么大不了的,即便 JWT 无法带来任何好处,但也不会造成什么影响」,那你真是大错特错了。
使用 JWT 作为 Session 机制存在很多缺点,其中一部分会造成严重的安全问题。
更费空间#
JWT Tokens 实际上并不「小」。尤其是使用无状态 JWT 时,所有的数据将会被直接编码进 Tokens 内,很快将会超过 Cookies 或 URL 的长度限制。你可能在想将它们存储到 Local Storage,然而...
更不安全#
若将 JWT Tokens 存储到 Cookies 内,那么安全性与其他 Session 机制无异。但如果你将 JWT 存储至其它地方,会导致一个新的漏洞,详见本文,尤其是「Storing sessions」这一部分。
书接上回:Local Storage,一个 HTML5 内很棒的功能,使浏览器支持 Key/Value 存储。所以我们应当将 JWT Tokens 存储到 Local Storage 吗?考虑到这些 Tokens 可能越来越大,或许会很有用。Cookies 通常在 4k 左右的存储时比较占优势,对于较大的 Tokens,Cookies 可能无法胜任,而 Local Storage 或许成了明确的解决方案。然而,Local Storage 并没有提供任何类似 Cookies 的安全措施。
LocalStorage 与 Cookies 不同,并不会在每次请求时发送存储的数据。获取数据的唯一方法是使用 JavaScript,这意味着任何攻击者注入的 JavaScript 脚本只需通过内容安全策略检查,就能任意访问或泄露数据。不光是这样,JavaScript 并不在意或追踪数据是否通过 HTTPS 发送。就 JavaScript 而言,它就只是个数据而已,浏览器会像操作其它数据一样来处理它。
在历代工程师们经历了各种麻烦之后,终于能够确保没有人可以恶意接触到我们的 Cookies,然而我们却试图忽略这些经验。这对我来说似乎是在退步。
简单来说,使用 Cookies 并不是可选的,无论你是否采用 JWT。
无法单独销毁#
还有更多安全问题。不像 Sessions 无论何时都可以单独地在服务端销毁。无状态 JWT Tokens 无法被单独的销毁。根据 JWT 的设计,无论怎样 Tokens 在过期前将会一直保持有效。举个例子,这意味着在检测到攻击时,你却不能销毁攻击者的 Session。同样,在用户修改密码后,也无法销毁旧的 Sessions。
对此,我们几乎无能为力,除非重新构建复杂且有状态(Stateful
)的基础设施来明确地检测或拒绝特定 Session,否则将无法结束会话。但这完全违背了使用无状态 JWT Tokens 的最初目的。
数据延迟#
与上文的安全问题类似,还有另一个潜在的安全隐患。就像缓存,在无状态 Tokens 内存储的数据最终会「过时」,不再反映数据库内最新的数据。
这意味着,Tokens 内保留的可能是过期的信息,例如:用户在个人信息页面修改过的旧 URL。更严肃点讲,也可能是个具备 admin
权限的 Token,即使你已经废除了 admin
权限。因为无法销毁这些 Tokens,所以面对需要移除的管理员权限,除非关闭整个系统,别无他法。
实现库缺乏生产环境验证或压根不存在#
你或许在想,以上的这些问题都是围绕着「无状态 JWT」展开的,这种说法大部分情况是对的。然而,使用有状态 Tokens 与传统的 Session cookies 基本上是等效的... 但却缺乏生产环境的大量验证。
现存的 Session 实现(例如适用于 Express 的 express-session)已经被用于生产环境很多很多年,它们的安全性也经过了大量的改良。倘若使用 JWT 作为 Session cookies 的临时替代品,你将无法享受到这些好处,并且必须不断改进自己的实现(在此过程中很容易引入漏洞),或使用第三方的实现,尽管还没有在真实世界里大量应用。
译者注:实际上,Laravel Passport 便是使用类似「有状态 JWT」的方式来存储 OAuth Access Token。幸运的是,Passport 已经有不少实际应用,且不完全依赖于 JWT。
结论#
无状态 JWT Tokens 无法被单独地销毁或更新,取决于你如何存储,可能还会导致长度问题、安全隐患。有状态 JWT Tokens 在功能方面与 Session cookies 无异,但缺乏生产环境的验证、经过大量 Review 的实现,以及良好的客户端支持。
除非,你工作在像 BAT 那样规模的公司,否则没什么使用 JWT 作为 Session 机制的理由。还是直接用 Session 吧。
所以... JWT 适合做什么?#
在本文之初,我就提到 JWT 虽然不适合作为 Session 机制,但在其它方面的确有它的用武之地。该主张依旧成立,JWT 特别有效的使用例子通常是作为一次性的授权令牌。
引用 JSON Web Token specification:
JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. [...] enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.
在此上下文中,「Claim」可能是一条「命令」,一次性的认证,或是基本上能够用以下句子描述的任何情况:
你好,服务器 B,服务器 A 告诉我我可以 <...Claim...>,这是我的证据:< ... 密钥... >。
举个例子,你有个文件服务,用户必须认证后才能下载文件,但文件本身存储在一台完全分离且无状态的「下载服务器」内。在这种情况下,你可能想要「应用服务器(服务器 A)」颁发一次性的「下载 Tokens」,用户能够使用它去「下载服务器(服务器 B)」获取需要的文件。
以这种方式使用 JWT,具备几个明确的特性:
- Tokens 生命期较短。它们只需在几分钟内可用,让客户端能够开始下载。
- Tokens 仅单次使用。应用服务器应当在每次下载时颁发新的 Token。所以任何 Token 只用于一次请求就会被抛弃,不存在任何持久化的状态。
- 应用服务器依旧使用 Sessions。仅仅下载服务器使用 Tokens 来授权每次下载,因为它不需要任何持久化状态。
正如以上你所看到的,结合 Sessions 和 JWT Tokens 有理有据。它们分别拥有各自的目的,有时候你需要两者一起使用。只是不要把 JWT 用作 持久的、长期的 数据就好。
本作品采用《CC 协议》,转载必须注明作者和本文链接
推荐文章: