【第 3337 期】解密 Cookies 和 Tokens_AI阅读总结 — 包阅AI

前言

讲解了 Web cookies 和 tokens 的概念、类型、作用以及它们在安全性方面的考量。今日前端早读课文章由 @飘飘翻译分享。

正文从这开始～～

最近，我深入研究了 tokens 和 cookies 的世界。我的一个客户正在尝试防止 token 和 cookie 被盗，这促使我挖掘更多的信息并深入了解。我打赌你已经听过这些术语，并且很可能每天都在使用它们。但 tokens 和 cookies 有很多变体以及一些相关的背景知识，我们应该了解它们，以便更好地理解整个情况。

目标设定

在这篇博客文章中，我们将了解什么是网页 cookies 和 tokens 以及它们的用途。我们还将探讨最常见的网页 Cookie 和 tokens 类型。本文不会涉及如何防止令牌或 Cookie 滥用的内容。这将是另一篇文章的主题。

什么是 cookies？

让我们首先试图理解什么是网页 cookies 以及我们如何使用它们。本文中使用的通用术语 “cookies” 指的是网页 cookie。

【第3158期】为 Web 上的 cookies 建立稳健的长期安全模型

Cookies 解释

Cookies 是网站（网络服务器）访问时创建并存储在设备中的小型文本文件。我们都遇到过它们。几乎每个你访问的网站都会用一个 cookie 通知栏来 “迎接” 你。cookie 的用途取决于 cookie 的类型以及网站希望 cookie 执行的任务。例如，一个在线商店可以使用 cookies 来跟踪用户在其网站上的活动、最后访问的页面、选择的语言、浏览的商品以及放入购物车的商品。当用户离开网站但后来返回时，网站可以读取 cookie，例如，继续用户上次离开的地方。但并非所有 cookies 都服务于相同的目的。

下图以非常高的抽象层次解释了 cookies 的工作原理。

图片 1：cookies 如何诞生的高级概述

但我们为什么需要 cookies 呢？我们需要使用 cookies，因为 HTTP 是一种无状态协议。HTTP 不记得客户端的会话信息，因此客户端负责存储这些信息 —— 使用 cookie。对于某些网站，无状态行为可能没问题，也许网站上没有需要在用户会话期间保留的元素或用户操作。但对于大多数交互式网站，cookies 是必要且必不可少的，我们作为网站访客也期望网站以某种方式运行。多亏了 cookies，这一切才成为可能。当客户端从网络服务器请求网站时，网络服务器响应 “200 OK” 并使用 Set-Cookie 头向客户端发送 cookie。cookie 包含会话 ID，通常还包含其他属性。Web 服务器也在服务器端跟踪其分发给客户端的会话 ID。

Cookies 主要用于：

浏览器会将 Cookies 存储在您的计算机上。更确切地说，它们存储在硬盘上的临时目录中。存储 cookies 的确切位置和方法取决于浏览器和操作系统。通常情况下，你会通过浏览器界面进入设置来管理 cookies，但不同操作系统和浏览器的文件路径可以在互联网上找到。例如，Microsoft Edge 将 cookies 存储在以下路径：C：\Users\[username]\AppData\Local\Microsoft\Edge\User Data\Default\Cookies-MSEDGEPROFILE.DEFAULT其中，[username] 是用户的登录名。

图 2。在浏览文件路径时可能会出现此类文件

通常你会使用浏览器的界面来管理、查看或删除 cookies。

图片 3：Microsoft Edge 浏览器设置中的 cookies

Cookie 属性

Cookies（有时也被称为 “标志”）具有一些非常重要的属性，因为它们定义了 cookie 的工作方式。以下是 cookie 可以具有的一些属性列表。

• Session ID：是一个用于识别和匹配客户端和网络服务器之间会话的唯一随机字符串

• Expires：定义了 cookie 的过期日期

• Domain：指定了该 Cookie 可用的域名或多个域名

• Path：指定了该 Cookie 可用于访问的资源或路径

• HttpOnly：启用时将防止客户端 API（如 JavaScript）访问 cookie。这有助于减轻跨站脚本（XSS）攻击的风险

• Secure：启用时将只允许通过 HTTPS 发送 Cookie，而禁止使用 HTTP 等未加密连接，这使得 Cookie 更不容易受到 Cookie 窃取的攻击

• Session：定义 cookie 是一个临时 cookie，当浏览器关闭时过期

• SameSite：可以有 strict、lax 或 none 值

• Strict = 浏览器仅将 cookie 发送到与来源域相同的目标域

• Lax = 浏览器将 cookie 发送到不同于来源域的目标域，但仅限于安全请求（如 GET）且不是第三方 cookie。

• None = 允许第三方 cookie（跨站点 cookie）

你可以通过右键单击并选择 “Inspect” > “Application” > “Storage” > “Cookies” 查看你正在浏览的网站的 cookies。当你选择一行时，你可以在页面底部看到值（见图片 5）。

图片 4：网站 “Inspect” 将让你查看该特定网站的 cookies 以及用户已接受的 cookie 同意

图片 5：cookie 同意也可见

图片 6：打开 Google Chrome 默认打开 www.google.com 网站并检查活动 cookie 的结果！

Cookies 的类型

当你需要处理 cookies 时，可能会遇到一些 cookie 术语。可以从多个角度将 cookies 粗略地分为不同的类别。有第一方 cookies 和第三方 cookies。有必需 cookies（绝对必要）和非必须 cookies（非必要）。我们将在这里使用后者来对我们的 cookies 进行分类。分类并不重要，这只是为了让人们更容易将东西放在心理盒子里。此外，有些 cookies 只是其他 cookies 的变体。例如，你可能会听到 “安全 cookie”，但实际上这可能只是启用了_secure_属性的会话 cookie 或第一方 cookie。即使如此，会话 cookies 和第一方 cookies 也可能非常相似。尽管在我看来，这些术语的定义相当模糊，不同的网站可能会互换使用不同的 cookie 术语，但我们至少应该尝试为它们中的每一个给出某种定义。

必需 cookies

必需 cookies 对于网站正常运行是必要的，通常使用户的浏览体验更方便。

• 会话 cookies

• 第一方 cookies

• 认证 cookies

• 用户中心安全 cookies

• 用户输入 cookies

会话 cookies（又称非持久 cookie、内存 cookie、临时 cookie）

会话 cookies 是临时 cookie 文件，当用户关闭浏览器或其会话变为非活动状态时会被删除（如果用户注销，会话将结束）。它们是单次会话 cookies。当用户重新启动浏览器并返回创建 cookie 的网站时，网站将无法识别用户，因为用户的浏览器中没有 cookie 供网站读取。如果网站需要登录，用户将需要重新登录。登录后，将生成一个新的会话 cookie，它将存储用户的浏览信息并在用户离开网站并关闭浏览器之前保持活动状态。由于会话 cookie 具有其独特的 ID，它还可用于跟踪网站访问者数量。如果您正在计划一次度假旅行，并且每天多次访问旅行社的网站，会话 cookie 的 ID 将向该网站透露您只是一个独特的访客。

第一方 cookies（又称持久性 cookies、永久 cookies、存储 cookies）

第一方 Cookie 会一直存在于浏览器中，直到用户手动删除它们，或者浏览器根据持久 Cookie 文件中的持续时间将其删除。这种类型的 cookie 可以用其他术语来表示，例如持久性 cookie、永久性 cookie 或存储 cookie，因此它们在单次会话中具有持久性。如果在 1-2 年内没有访问网站，大多数第一方 cookies 将过期。当 cookie 过期时，浏览器将自动删除它们。第一方 cookie 最为人知的作用是让用户保持登录状态，从而避免每次访问网站时重新输入凭据的繁琐过程。

认证 cookies

认证 cookies 是会话 cookies 的一种变体。它们将在成功登录后识别用户并在用户导航到授权内容的网站时携带该认证信息。例如，当用户登录到在线银行时，他们被授权查看其银行账户余额。如果他们转到另一个页面查看其贷款，认证 cookie 确保用户不需要为该页面提供新的认证。

用户中心安全 cookies

以用户为中心的安全令牌可以跟踪认证错误，并通过跟踪登录页面上的错误登录尝试次数来检测可能的认证滥用。

用户输入 cookies

用户输入 cookies 是第一方会话 cookies，跟踪用户在网站上输入的操作和项目，如填写表单或点击某些按钮（如添加到购物车）。

非必要 cookies

非必要型 cookies 对于用户的浏览体验或网站的正常运行并非必要。

• 分析和定制 cookies

• 广告 cookies

• 第三方 cookies

• Supercookies

分析和定制 cookies

分析和定制 cookies 跟踪用户活动，以便网站管理员更好地了解其网站的使用情况。例如，网站管理员可以使用的一种分析方法是某些信息在网站上非常 “冷”，这意味着用户很少打开该页面（不感兴趣）或无法找到它。

【第1857期】Cookie 的 SameSite 属性

广告 cookies

广告 cookies 仅用于定制用户在网页上看到的广告。它们使用用户的浏览历史记录使广告 “更相关”。这就是为什么我们开始看到关于我们之前搜索过的内容的广告。

第三方 cookies（又称跟踪 cookies）

第三方 cookies 是 “cookieland” 的坏人。这些是我们不喜欢的 cookies，也是 cookies 声誉不佳的原因。第三方 cookies 来自用户正在访问的不同域，因此它们不提供会话 cookies 或第一方 cookies 的任何好处。这些 cookies 只有一个目的，那就是跟踪你。

Supercookies

超级 cookies 在技术上不是真正的 cookies，在某些情况下不会存储在用户的设备上。普通 cookie 最多可容纳 4 KB 的数据，而 Supercookies 可以容纳 100 KB。Supercookies 的作用类似于跟踪 cookies，但它们的控制方式与其他 cookies 不同。在某些情况下，Supercookies 已被发现存储在浏览器缓存中，某些形式的 Supercookies 被注入到 ISP 唯一标识符头（UIDHs）中。由于 Supercookies 的性质，它们更难识别，而在 UIDH Supercookies 的情况下，你无法清除它们。

什么是 tokens？

Tokens 是用于信息交换的自包含紧凑型 JSON 对象。典型的 token 是客户端（应用程序）与另一个服务（如网络服务器）之间使用的 JSON Web Token（JWT）。具体细节取决于确切的认证流程。在本文中，我们将使用 JWTs（读作 “JOT”）这一术语，因为它更方便并在专业文献中广泛使用。

Tokens 解释

与存储用户在网络会话中的活动信息的 cookies 不同，tokens 在软件之间传输信息。存储在 token 中的信息取决于 token 的类型。例如，ID token 携带已认证用户的信息。访问 token 通常包含关于安全主体及其授权访问权限的信息。这就是 tokens 和 cookies 交集的地方：某些 tokens 存储在客户端，例如在本地存储中或在 cookie 中。为了安全起见，最好存储在 HttpOnly cookie 中。我不是一个 Web 开发人员，但我了解到开发人员倾向于使用 cookies，因为本地存储被认为是较不安全的选项。还值得一提的是，tokens 作为协议的一部分，并非所有令牌都属于同一协议。

我将在这里提及并简要解释的协议是 OAuth 2.0 和 OpenID Connect（OIDC），因为它们被 Microsoft Identity Platform 使用。

OAuth 是 Open Authorization 的缩写，是一种用于处理应用程序或网站代表用户访问资源的授权流程的标准。简单来说，OAuth 是一种主要用于 Web 平台的授权协议。OAuth 使用访问 token，通常但不限于 JSON Web Tokens。Microsoft Identity Platform 中的 OAuth 协议使用格式化为 JWTs 的访问 tokens。OAuth 2.0 授权流程有多种不同类型。

OpenID Connect 扩展了 OAuth 2.0 授权协议，使其也用作认证协议，使用 ID token。OpenID Connect 登录流程用于获取发送给验证用户身份的应用程序的 ID 令牌。

OpenID Connect 登录流程。来源：Microsoft Learn

登录流程后，通过 OAuth 授权流程获取访问 token。来源：Microsoft Learn

Tokens 解决的问题

让我们描述一个传统的认证和授权场景，其中不存在 tokens。用户首先登录，Web 服务器通过检查其数据库中的输入凭据来认证用户。一旦凭据匹配，服务器就会发出一个唯一的会话标识符并将其发送给客户端。用户的客户端将会话 ID 存储在设备上。客户端每次向服务器发送请求时，都会在 cookie 或 http 请求头中发送会话 ID。服务器需要再次从其数据库中查找会话 ID，以识别用户并检查授权级别。

【第1328期】八幅漫画理解使用JSON Web Token设计单点登录系统

这种情况的问题在于，对于客户端的每个请求，服务器都需要向数据库发送一次请求，这使得应用程序的使用速度变慢。

而使用 tokens 的场景通过发出包含用户信息和验证 token 内容真实性的签名的 JWT 解决了随后的数据库查找问题。JWT 发送到客户端，客户端再次存储它。每次客户端向服务器发送请求时，客户端都会包含 JWT。服务器只需验证 token 的签名以确保其真实性，当验证通过时，服务器可以从 token 中提取身份和授权详细信息，而无需数据库查找。

Tokens 的类型

以下是一些常见的 token 类型：

• ID token

• 访问 token

• 刷新 token

• 持票人 token

接下来，我将简要介绍这些 tokens 和术语。

ID token

ID tokens 是通过 OpenID Connect（OIDC）登录流程获取的，这是一个用于去中心化认证的开放标准。ID tokens 必须采用 JSON Web Token 格式。它们由授权服务器（Microsoft Entra ID）向客户端应用程序签发。ID token 包含关于用户或安全主体的声明，并可以包含关于多重认证（MFA）状态的声明。例如，客户端应用程序可以使用 ID token 中的信息和声明验证用户的身份。默认情况下，Microsoft Identity Platform 中的 ID tokens 有效期为一小时。ID tokens 不用于调用受保护的 API。

Microsoft 有两个版本的 ID tokens，并且它们具有不同的端点。版本之间的区别在于它们可以包含的信息和声明。

用户正在登录将用户重定向到 Entra ID 以完成认证的网络应用程序。认证成功后，Entra ID 将发出一个 ID token 并发送给客户端（浏览器）。浏览器不会试图理解 ID token，只是将其发送到网络服务器。

访问 token

访问 token 是授权服务器签署的短期（JWT）token，它使客户端能够安全地调用受保护的 Web API。访问 tokens 不需要采用 JSON Web Token 格式，但在 Microsoft Identity Platform 中，它们采用 JWT 格式。客户端的每个 http 请求都包含访问 token。通常是在 HTTP 请求的 Authorization 头部使用 “Bearer” 模式来实现这一点。这样可以避免服务器在每次请求时都需要对用户进行身份验证。客户端将访问 token 存储在 cookie 或本地存储中。与 ID tokens 类似，访问 tokens 也有两个版本，每个版本都有不同的端点。访问 tokens 是为了在服务器端使用。客户端不需要也不应使用访问 token 的内容。

刷新 token

刷新 token 通常与访问 token 一起获取。它用于在之前的访问 tokens 过期时获取新的访问 tokens 和新的刷新 token。在 Microsoft Identity Platform 中，刷新 tokens 是加密的，不能被其他人读取。客户端将访问 token 存储在 cookie 或本地存储中。刷新 token 的有效期为 90 天，单页应用程序是例外，其有效期为 24 小时。

持票人 token

持票人 token 是指任何持有该 token 的人都可以使用的 tokens。token 持有者不必证明持有加密密钥。可以将其视为酒店房卡。如果你丢失了房卡，其他人捡到后可以使用它进入房间，而不需要证明他们是房间的合法所有者。

JSON Web Token (JWT)

JSON Web Tokens 是用于在两方之间安全传输数据的标准化对象。为了确保在传输过程中 JWT 的内容未被更改或篡改，JWT 使用加密密钥进行签名。需要重复的是：JWTs 是签名的，不是加密的。签名验证数据的发送者，而加密将数据从明文转换为只有授权接收者才能阅读的密文。如果在传输过程中签名的 token 内容被更改，公钥（用于验证 token 签名的私钥对）将无法再验证签名。强烈建议与 JWTs 一起使用 HTTPS 等协议，以保护传输过程中的 token 内容的机密性。

【第348期】JSON Web Token – 在Web应用间安全地传递信息

互联网工程任务组（IETF）在 RFC 7519 中描述了 JWT 标准。

JSON Web Token 由三个部分组成：

头部

通常来说，证书头包含两个部分，分别描述令牌的类型和签名算法。

 {
   "alg": "HS256",
   "typ": "JWT"
 }

有效负载

负载是包含所有实际信息的部分，例如声明。在 RFC 7519 的第 4 章中，注册声明被定义如下：

• “iss” = 发行者声明。发行者声明标识发行 JWT 的主体

• “sub” = 主题声明。主题声明标识 JWT 的主题主体

• “aud” = 受众声明。受众声明标识 JWT 的预期接收者

• “exp” = 到期时间声明。到期声明标识 JWT 不应被接受处理的时间

• “nbf” = 生效时间声明。NFB 声明标识 JWT 应被接受处理之前的时间

• “iat” = 签发时间声明。签发时间声明标识 JWT 的签发时间

• “jti” = JWT ID 声明。JWT ID 声明为 JWT 提供唯一标识符

该标准并未强制要求使用注册的名称，因此它们仍然是可选的。其他类型的名称包括公共名称和私有名称。

 {
   "session": "ch72gsb320000udocl363eofy",
   "client_id": "YzEzMGdoMHJnOHBiOG1ibDhyNTA=",
   "response_type": "code",
   "scope": "introscpect_tokens, revoke_tokens",
   "iss": "bjhIRjM1cXpaa21zdWtISnp6ejlMbk44bTlNZjk3dXE=",
   "sub": "YzEzMGdoMHJnOHBiOG1ibDhyNTA=",
   "name": "John Doe",
   "aud": "https://login.microsoftonline.com/{tid}/oauth2/v2.0/authorize",
   "jti": "1516239022",
   "exp": "2024-05-17T07:09:48.000+0545"
 }

签名

头部和负载都经过 Base64Url 编码。为了签名 token，需要使用编码后的头和负载，以及密钥和签名算法来完成签名。

 HMACSHA256(
   base64UrlEncode(header) + "." +
   base64UrlEncode(payload),
   secret)

以下屏幕截图显示了左侧的签名 JWT 以及右侧的头部、负载和签名。

你可以在签名 JWT 中看到 JSON Web Token 的所有三个部分，不同部分由点（.）分隔

示例 token

最简单的查看 JWT 方法是访问 Microsoft Graph Explorer https://developer.microsoft.com/en-us/graph/graph-explorer 并登录。登录后，我们运行‘GET my profile’查询并打开 Access token 选项卡，复制 token。

为了安全原因，部分访问 token 被编辑

然后我们访问 https://jwt.ms 并粘贴 token。

为了安全原因，部分访问 token 被编辑

在我们粘贴的 token 下方是解码后的 token 内容和解释声明缩写如 “oid”、“uti” 等的‘Claims’选项卡。从下面的 token 我们可以推断出以下内容：

• “typ”: “JWT” 表示 token 类型是 JSON Web Token

• “alg”: “RS256” 表示此 token 的签名使用 RSA 签名和 SHA-256 算法

• “aud”: “00000003-0000-0000-c000-000000000000” 表示 token 接收者（受众）是 Microsoft Graph

• “iss”: “https://sts.windows.net/f77b793c-9409-XXXX-XXXX-b793feaadb48/”表示 token 的发行者是 Azure Active Directory v1 端点

• “appid”: “de8bc8b5-d9f9-48b1-a8ad-b748da725064” 表示使用 token 的客户端是 Graph Explorer，因为它使用 token 调用 Microsoft Graph API

• “scp”: “openid profile User.Read email” 列出了应用程序（Graph Explorer）请求的 API 范围、已同意的范围以及 Microsoft Graph 公开的范围

• “ver”: “1.0” 表示 token 版本

嘘！我注意到我获取的所有 tokens 的发行者都是 sts.windows.net。我以为会是 login.microsoftonline.com。快速研究指出了 accessTokenAcceptedVersion 参数，该参数似乎控制 token 的发行端点。稍后需要更多测试以作为事实陈述，但看起来它的工作原理如下：

应用注册清单配置

JWT 的安全问题

与任何技术解决方案一样，JSON Web Token 也有其缺点。

大小限制和存储

一些复杂的应用程序需要在 token 中存储大量信息。当 tokens 存储在 cookies 中时，这会增加每个请求的开销，甚至超过 cookie 允许的大小（4 KB）。当这种情况发生时，常见的解决方法是将 JWT 存储在本地存储中，这有其自身的安全问题，主要是本地存储中的数据对页面内的任何脚本都是可访问的。这可能导致跨站点脚本攻击能够访问 token。

一般来说，cookies 旨在由服务器读取，而 localstorage 只能由浏览器读取。这意味着 cookie 限制较小的数据量而 localstorage 没有这种限制。当 token 存储在本地存储中时，浏览器使用 JavaScript 访问它。这是 token 存储在本地存储中容易受到跨站点脚本攻击的根本原因，因为攻击者可能会将恶意 JavaScript 注入网页并窃取访问 token。本地存储不提供任何安全措施，而 cookies 具有 secure 属性可以保护 token 免受此类攻击。不要误会，如果 token 存储在未正确保护的 cookies 中，我们也容易受到 XSS 攻击。但 cookies 有机制保护 token 免受这些类型的攻击，这也是 OWASP 社区推荐使用 cookies 存储 tokens 的原因。

失效

如开头所述，tokens 是自包含的。没有中央机构跟踪和管理 tokens。这在尝试使 token 失效时成为一个挑战。默认情况下，访问 token 的有效期为一（1）小时，有效期详细信息包含在 token 中。

未加密

请记住，tokens 是签名的，但不是加密的。因此，如果未通过 HTTPS 充分保护，token 内容可能会暴露给未经授权的一方。

总结

我们了解了什么是 cookies 以及浏览器和网站如何使用 cookies 来增强浏览体验。我们列出了一些 cookies 的变体及其独特特征。我们还了解了什么是 tokens，Microsoft Identity Platform 中获取 tokens 使用的协议，以及每种类型的 token 在何种情况下相关。通过这些基础知识，我们能够在即将到来的博客文章中继续我们的旅程，讨论如何利用 cookies 或 tokens，并滥用它们。

关于本文
译者：@飘飘
作者：@Tommi Hovi
原文：https://tommihovi.com/2024/05/demystifying-cookies-and-tokens/

这期前端早读课
对你有帮助，帮”赞“一下，
期待下一期，帮”在看” 一下 。