Cookie Theft 的终结：理解设备绑定会话凭证 (DBSC)

Source: Dev.to

请提供您希望翻译的完整文本内容，我将按照要求保留源链接并仅翻译正文部分。谢谢！

引言：“持有者” 时代的终结

在过去的十年里，未经授权的账户访问和已认证的网页抓取的经济模型都依赖于一个单一且脆弱的前提：cookie 是持有者令牌。
如果某个行为者拥有一个有效的会话 cookie——无论是通过恶意软件泄露、在 Genesis 市场购买，还是通过中间人攻击获取——他们就拥有该用户的身份。服务器并不询问谁在呈现该 cookie，只判断该 cookie 是否有效。

这种 “拥有 = 访问” 的模型催生了整个产业：

• 信息窃取工具（如 RedLine、Lumma）每天抓取数百万凭证，将 cookie 打包成 zip 文件，攻击者只需将这些 cookie 恢复到全新的浏览器配置文件中，即可绕过 MFA。
• 抓取工程师可以序列化手动建立的会话，并在成千上万的无头工作者之间重放，从而将昂贵的认证步骤与廉价的数据提取阶段解耦。

那个时代正在结束。

Source: …

设备绑定会话凭证（DBSC）

设备绑定会话凭证（DBSC） 的引入标志着网络安全架构的根本性转变。

• 起源 – 由 Google 推动，并通过 W3C 标准化。
• 目标 – 将网络从 持有者（bearer）认证转向 拥有证明（proof‑of‑possession）认证。
• 机制 – 在特定设备的底层硬件上对用户会话进行加密绑定，从而使被窃取的 Cookie 失去价值。

为什么 DBSC 很重要

防御者意识到，如果攻击者在进入后能够 偷走通往房子的钥匙（Cookie），那么加强登录入口（MFA、密码钥匙）是徒劳的。DBSC 通过确保在 “设备 A” 上创建的会话在 “设备 B” 上在数学上无效来解决此问题，即使设备 B 完全复制了设备 A 的所有文件、Cookie 和请求头。

工作原理

1. 硬件根密钥对

   • 浏览器在设备的 可信平台模块（TPM） 或等效安全区（例如 Apple 的 Secure Enclave）内生成公私钥对。
   • 私钥不可导出——恶意软件无法读取、复制到文件或通过调试工具提取。

2. 服务器端绑定

   • 用户登录时，浏览器将 公钥 发送给服务器。
   • 服务器将该公钥与用户的会话记录一起存储。

3. 短生命周期的持有者 Cookie

   • 传统会话 Cookie 的 有效期极短（可能只有几分钟）。
   • 当 Cookie 接近过期或服务器发起挑战时，浏览器执行 会话刷新。

4. 刷新握手

   Browser → DBSC refresh endpoint: request
   Server  → Browser: cryptographic challenge (nonce)
   Browser → TPM: sign(nonce) with non‑exportable private key
   TPM    → Browser: signature
   Browser → Server: signature
   Server  → verifies signature against stored public key
   Server  → issues new short‑lived cookie (if verification succeeds)

   签名操作在硬件内部完成。即使恶意软件拥有系统或根权限，也无法导出私钥。它只能请求 TPM 在 该特定机器 上对请求进行签名。

攻击场景：“Pass‑the‑Cookie” vs. DBSC

结果: 被窃取的 Cookie 变成 “有毒的果实”——它们看似有效，但一旦在非本地使用即失效。

对工程社区的影响

纯 HTTP 客户端（例如 requests、httpx）

• 这些客户端 仅复制基于文本的头部和 cookie。
• 它们 没有 TPM 访问权限，也 未实现 DBSC 签名协议或所需的密码学原语。

后果

• 一个仅重放被窃取 cookie 的 Python 脚本 会立即在 DBSC 受保护的站点上失败。
• 即使是执行全新登录的脚本 也无法创建 服务器信任的硬件绑定密钥——除非它运行在带有 TPM 的机器上 并且 完全实现了 DBSC 规范（这是一项非平凡的工作）。

爬取受 DBSC 保护站点的必需方法

1. 使用真实的浏览器实例（无头 Chrome、Puppeteer、Playwright 等），以便能够与主机的密码硬件交互。
2. 让浏览器自动管理 DBSC 握手——包括密钥生成、挑战签名和 cookie 刷新。
3. 对于任何强制使用 DBSC 的端点，避免使用纯 HTTP 库。

TL;DR

• 仅持有者的 Cookie 正在消亡。
• DBSC 将会话绑定到硬件，使被盗的 Cookie 失效。
• 纯 HTTP 客户端无法绕过 DBSC；你必须通过能够与 TPM/安全区通信的真实浏览器来操作。

相应地准备你的工具和工作流——否则，下一波网络安全将使传统的爬虫堆栈变得过时。

基础设施转变

• 资源密集度 – 你已经无法在 1 GB RAM 的 VPS 上运行 500 条并发线程。你需要完整的浏览器上下文。
• 设备合法性 – “Device Farms” 将变为字面意义。 在 Linux 服务器的 Docker 容器中运行浏览器（这些服务器通常缺少 TPM 直通）可能导致 DBSC 注册失败，使服务器回退到“suspicious”状态或完全拒绝登录。
• 会话可移植性 – 你无法在 Workers 之间轮换会话。如果 Worker A 登录，会话绑定到 Worker A 的虚拟 TPM。你不能将该会话转移到 Worker B。

DBSC – 并非灵丹妙药

虽然 DBSC 是一次巨大的进步，但它并非万全之策，也尚未在所有地方部署。

浏览器支持

• Chrome on Windows – 主要驱动，利用 Windows 11 上广泛可用的 TPM。
• macOS & Linux – 支持正在出现，但仍零散。
• Firefox & Safari – 正在评估该标准。

“实时”劫持

• DBSC 能防止 exfiltration（将会话转移到其他设备）。
• 它 不 能防止远程控制。
• 如果攻击者在受害者机器上直接安装隐藏的 VNC 或 SOCKS 代理，他们可以通过受害者的浏览器转发流量。
• 运行在合法硬件上的浏览器会乐意签署 DBSC 挑战。

这将攻击向量从“窃取日志”转变为“保持驻留”，后者风险更大且更难以规模化。

实施复杂性

防御方必须对身份验证后端进行重大更改：

1. 处理密钥注册。
2. 生成随机数（nonce）。
3. 大规模验证签名。

这种摩擦意味着 DBSC 初期可能仅用于高价值目标（Google 账户、银行、企业 SaaS），随后才会逐步渗透到普通电子商务。

结论

Device‑Bound Session Credentials (DBSC) 标志着会话管理的“狂野西部”时代的结束。通过将数字身份锚定到物理硬件，网络标准组织实际上已经废弃了可移植会话的概念。

• 对于安全研究员 – 现代密码学对传统架构的胜利。
• 对于爬虫工程师 – 一个需要进化的信号。

在受保护目标上进行轻量级、高并发 HTTP 爬取的日子已经屈指可数。未来属于重型、硬件感知的浏览器自动化，它遵循其所在设备的规则。