Chrome 引入 DBSC 设备绑定会话凭据：Cookie 被盗也无法跨设备复用
谷歌 Chrome 浏览器在 Windows 版 146 更新中正式引入了一项名为 DBSC（Device Bound Session Credentials，设备绑定会话凭据）的安全功能，旨在从根本上遏制 InfoStealer 恶意软件通过窃取 Cookie 劫持用户账户的攻击链路。
Cookie 盗取：当前最紧迫的认证威胁
传统 Web 认证模型依赖浏览器 Cookie 维持登录状态。一旦恶意软件（如 RedLine、Raccoon、LummaC2 等 InfoStealer 家族）感染用户设备，即可在数秒内导出浏览器中存储的全部 Cookie，并将其上传至攻击者控制的 C2 服务器。攻击者随后可在任意设备上复用这些 Cookie，绕过密码和二次验证，直接接管受害者账户。
这类攻击之所以屡屡得手，根本原因在于 Cookie 本身并不包含任何设备绑定信息——一个合法会话令牌可以在世界任何角落被无缝复用。
DBSC 的技术原理
DBSC 的核心思路是将身份验证会话与物理设备进行加密绑定。其实现机制如下：
- 硬件级密钥生成：利用设备上的安全模块（Windows TPM、macOS Secure Enclave、Android Keystore）生成非对称密钥对。私钥由硬件安全模块保护，存储在本地且无法导出。
- 会话绑定：当用户完成身份认证后，浏览器将该会话凭据与设备生成的公钥进行绑定注册。后续每次发起请求时，浏览器必须使用对应的私钥对请求进行签名，服务器端验证签名有效性后才允许访问。
- 跨设备失效：即使攻击者成功窃取了 Cookie 内容，由于缺少原始设备的硬件私钥，无法伪造合法签名，Cookie 在其他设备上完全无效。
项目背景与实测数据
DBSC 项目由 Chrome 浏览器团队与谷歌账户安全团队联合开发。根据谷歌公布的数据，在 Beta 通道的测试中，DBSC 已实现 100% 成功率阻止 Cookie 被导出或在其他设备上复用。这意味着即便用户设备已被 InfoStealer 感染，攻击者获得的 Cookie 也无法在其控制的服务器上产生任何效用。
值得注意的是，从 Chrome 134 开始，DBSC 已迁移至新的 Session Bound Credentials API 设计，提供了更清晰的接口规范和更好的跨平台扩展性。
平台支持与用户体验
目前 DBSC 支持以下平台的硬件安全模块：
- Windows：TPM（Trusted Platform Module）
- macOS：Secure Enclave
- Android：Keystore
该功能在支持平台上默认启用，无需用户进行任何手动配置。网站开发者可以通过标准的 Web API 接入 DBSC，为用户提供额外的安全防护层。
行业影响
DBSC 的推出标志着浏览器厂商从「检测并拦截恶意软件」转向「从根本上消除凭证复用的可能性」。这一范式转变有望大幅压缩 InfoStealer 生态的经济回报，推动整个行业朝着硬件绑定认证的方向演进。
来源：