Chrome DBSC技术详解：设备绑定会话凭证如何终结Cookie窃取

账户劫持为何屡禁不止

账户接管（Account Takeover）一直是网络安全领域的顽疾。即便用户开启了双因素认证（2FA），攻击者仍然可以通过窃取会话Cookie绕过所有登录验证环节，直接冒充用户身份。这类攻击被称为"会话劫持"或"Cookie窃取"，近年来随着信息窃取型恶意软件（infostealer malware）的泛滥而愈演愈烈。

双因素认证要求用户在输入密码之外，提供第二种身份验证因素，通常是手机短信验证码、TOTP时间动态口令（如Google Authenticator）或硬件安全密钥（如YubiKey）。2FA的设计初衷是防止密码泄露后账户被直接接管。然而，2FA仅在登录环节发挥作用——一旦登录成功、会话建立后，后续的身份验证完全依赖会话Cookie，2FA不再参与。这意味着攻击者只需绕过登录环节，直接获取已建立的会话凭证，就能使2FA形同虚设。

如今，Google Chrome浏览器正在采用一项被业界评价为"迄今为止最好的账户接管防护措施"的新技术——设备绑定会话凭证（Device Bound Session Credentials，简称DBSC）。这项技术从根本上改变了会话凭证的工作方式，有望大幅削弱Cookie窃取攻击的效力。

传统会话Cookie的致命弱点

为什么开启2FA仍会被劫持

要理解DBSC的价值，首先需要明白现有会话机制的缺陷。当用户成功登录一个网站后，服务器会向浏览器颁发一个会话Cookie，作为后续访问的"通行证"。此后每次请求，浏览器都会自动附上这个Cookie，服务器据此确认用户身份，用户无需反复输入密码或验证码。

从技术实现角度看，会话Cookie通过HTTP响应头中的Set-Cookie字段下发，浏览器在后续同源请求中通过Cookie请求头自动回传。虽然现代浏览器引入了多种Cookie安全属性——如Secure标志确保Cookie仅通过HTTPS传输、HttpOnly标志阻止JavaScript读取Cookie、SameSite属性限制跨站请求携带Cookie——但这些措施主要防范的是网络中间人攻击和跨站请求伪造（CSRF），对于运行在本地设备上的恶意软件几乎毫无抵抗力。因为恶意软件可以直接读取浏览器的Cookie存储文件（Chrome在Windows上的路径为%LocalAppData%\\\\Google\\\\Chrome\\\\User Data\\\\Default\\\\Cookies），完全绕过浏览器层面的安全策略。

会话Cookie机制最早可追溯到1994年Netscape工程师Lou Montulli的发明，最初目的是解决HTTP协议无状态性带来的用户体验问题。在Web早期，每次页面请求都是独立的，服务器无法识别连续请求来自同一用户。Cookie的引入使得购物车、用户偏好等有状态功能成为可能。随着Web应用复杂度的增长，Cookie逐渐承担了身份认证的核心角色，但其设计之初并未充分考虑安全性。从RFC 2109到RFC 6265，Cookie标准经历了多次安全增强，但始终未能解决令牌可复制这一根本性问题。

问题在于，这个Cookie本质上是一段可以被复制的承载令牌（bearer token）。它并不与特定设备绑定。只要攻击者通过恶意软件、跨站脚本攻击或其他手段窃取到这段Cookie，就可以将其复制到自己的设备上，从而完全绕过密码和2FA的保护，直接进入受害者的账户。

承载令牌是一种"见令如见人"的认证凭证，其安全模型假设：任何持有该令牌的实体都被视为合法用户，服务器不会进一步验证持有者的真实身份。这种设计源自OAuth 2.0等授权框架，优点是简单高效，缺点是一旦令牌被窃取，攻击者与合法用户在服务器看来完全无法区分。与之相对的是"持有证明令牌（Proof-of-Possession Token）"，后者要求持有者证明自己拥有与令牌关联的密钥，DBSC正是将会话Cookie从承载令牌转变为持有证明令牌的实践。

信息窃取软件的产业化威胁

专门窃取会话Cookie的信息窃取软件已经形成了成熟的黑色产业链。这些恶意程序悄悄潜入受害者的电脑，批量导出浏览器中保存的Cookie和凭证，然后打包出售给其他攻击者。由于Cookie窃取绕开了所有前端认证，即便是安全意识很强、开启了多重防护的用户也难以幸免——这正是账户劫持屡禁不止的核心原因。

典型的信息窃取软件包括RedLine、Raccoon、Vidar、Lumma等家族，它们通常通过钓鱼邮件、虚假软件下载或恶意广告传播。入侵设备后，这些程序会读取浏览器的Cookie数据库文件（如Chrome的Cookies SQLite文件）、自动填充数据和保存的密码。窃取到的数据通过Telegram频道或暗网市场批量销售，单个有效会话Cookie的售价从几美元到数百美元不等，取决于目标账户的价值。Genesis Market、Russian Market等平台曾专门交易此类数据，形成了从开发、分发、窃取到变现的完整产业链。

信息窃取软件的技术复杂度在过去五年中急剧提升。早期的窃取工具仅能读取明文存储的Cookie文件，而现代变种已能绑定到浏览器进程注入内存、Hook加密API调用、甚至利用浏览器的CDP（Chrome DevTools Protocol）远程调试协议实时导出Cookie。2023年曝光的EvilProxy和Evilginx等中间人钓鱼框架更是将会话劫持推向新高度——它们在用户与合法网站之间充当透明代理，实时捕获用户完成2FA后生成的会话Cookie。这类攻击甚至不需要在受害者设备上安装恶意软件，仅通过钓鱼链接即可完成。这种"实时钓鱼"攻击的存在进一步说明了为什么仅加强客户端防护不够——必须从协议层面让被盗的Cookie本身失去价值。

值得注意的是，Chrome此前曾通过Application-Bound Encryption（应用绑定加密）来保护Cookie存储，使用Windows的DPAPI（Data Protection API）对Cookie数据库进行加密，确保只有Chrome进程本身能够解密。然而，攻击者很快找到了绕过方法——通过注入Chrome进程、利用Chrome的远程调试接口、或者直接调用Chrome内部的解密函数。这场猫鼠博弈表明，仅靠软件层面的加密保护不足以应对高级威胁，必须引入硬件级别的安全保障。

DBSC工作原理：让会话凭证绑定硬件设备

密码学绑定机制

DBSC的核心思想是引入密码学手段，将会话凭证与设备的硬件安全模块（如TPM芯片）绑定。具体流程如下：

1. 密钥生成：用户登录时，浏览器在设备的可信硬件中生成一对公私钥
2. 私钥存储：私钥被安全保存在硬件中，永远不会离开设备，也无法被恶意软件导出
3. 公钥注册：公钥发送给服务器进行关联绑定
4. 持续验证：服务器定期要求浏览器出示用私钥签名的密码学证据

TPM（Trusted Platform Module，可信平台模块）是一种专用安全芯片，通常焊接在主板上或集成于CPU中（如Intel PTT或AMD fTPM）。它提供硬件级别的密钥生成、存储和加密运算能力，最关键的特性是：存储在TPM中的私钥永远无法被读出，所有需要私钥参与的运算都在芯片内部完成。TPM技术由可信计算组（Trusted Computing Group, TCG）制定标准，最早的TPM 1.2规范发布于2003年，主要用于企业设备管理和磁盘加密。2014年发布的TPM 2.0规范大幅扩展了支持的加密算法（从仅支持RSA和SHA-1扩展到ECC、SHA-256等），并提高了灵活性。Windows 11已将TPM 2.0列为系统最低要求，现代PC几乎都配备了这一硬件。在企业环境中，TPM早已广泛用于BitLocker磁盘加密（密钥由TPM保管，确保硬盘被拆出后无法解密）和Windows Hello企业版身份认证。除TPM外，macOS设备使用Secure Enclave（基于ARM TrustZone技术的独立安全协处理器）、Android设备使用StrongBox（独立安全芯片）或TEE（可信执行环境，如ARM TrustZone）提供类似功能。DBSC正是利用这些硬件安全模块的不可导出特性来实现设备绑定。

尽管TPM提供了强大的硬件安全保障，但它并非绝对不可攻破。学术界和安全研究社区曾多次展示针对TPM的攻击：2019年TPM-Fail漏洞通过时序侧信道攻击成功提取了Intel fTPM的ECDSA私钥；2021年的研究展示了通过物理探针嗅探TPM与CPU之间的LPC/SPI总线通信来获取密钥的可能性。然而，这些攻击要么需要物理接触设备，要么需要极高的技术门槛和特定的硬件条件，远非普通网络犯罪分子可以大规模实施。DBSC的安全模型并不假设TPM绝对不可破，而是将攻击成本提升到使大规模自动化窃取在经济上不可行的水平——这正是安全工程中"提高攻击成本"的核心策略。

只有物理上拥有该设备的浏览器才能通过验证。即使攻击者窃取了会话Cookie，由于缺少绑定在硬件中的私钥，也无法在其他设备上完成验证，被盗的Cookie也就彻底失去了价值。

DBSC的协议层设计

在具体的HTTP协议交互层面，DBSC引入了一套精心设计的短期Cookie轮换机制。当用户首次与支持DBSC的网站建立会话时，服务器在响应中通过Sec-Session-Registration头部发起注册流程，浏览器在TPM中生成密钥对并将公钥回传。此后，服务器不再颁发长期有效的会话Cookie，而是颁发有效期极短（通常仅数分钟）的短期Cookie。

当短期Cookie即将过期时，浏览器自动向服务器指定的刷新端点发起请求。服务器发出一个加密挑战（challenge），浏览器调用TPM使用私钥对挑战进行签名，将签名结果回传。服务器验证签名正确后，颁发新的短期Cookie。这个"挑战-响应-轮换"的循环持续进行，确保任何时刻被窃取的Cookie都将在极短时间内失效，且无法在缺少私钥的设备上被续期。这种设计还意味着即便攻击者截获了某一时刻的网络流量，获取的Cookie也会很快过期，大幅缩小了攻击时间窗口。

引入TPM签名操作不可避免地会带来性能开销。TPM 2.0执行一次ECDSA P-256签名操作通常需要50-200毫秒，这对于高频率的Web请求来说并非可忽略。DBSC通过精心的协议设计来最小化这一影响：短期Cookie的有效期设为数分钟而非每次请求都需要签名验证，这意味着在Cookie有效期内的所有请求都可以正常使用Cookie而无需TPM参与。只有在Cookie续期时才需要执行一次签名操作。此外，Cookie续期请求可以在后台异步完成，不会阻塞用户的正常浏览操作。Google在设计文档中还提到了批量签名和预签名等优化策略，以进一步减少用户感知的延迟。这种"低频验证、高频使用"的设计哲学使得DBSC在安全性和性能之间取得了良好的平衡。

与Token Binding的关系及改进

实际上，DBSC并非Google在设备绑定会话领域的首次尝试。早在2014年，Google就曾推动Token Binding协议（RFC 8471），试图将TLS连接与认证令牌进行绑定。Token Binding的思路是在TLS握手过程中生成与连接绑定的密钥对，使得令牌只能在特定的TLS连接中使用。然而，Token Binding最终未能获得广泛采用，主要原因包括：它与TLS 1.3的0-RTT握手模式不兼容、对CDN和负载均衡等网络中间设施造成了巨大的部署障碍、且HTTP/2的连接复用特性使其实现更加复杂。

DBSC从Token Binding的失败中汲取了重要教训。首先，DBSC将绑定层面从TLS连接提升到应用层，不依赖特定的传输层实现，因此与任何TLS版本和网络拓扑兼容。其次，DBSC采用渐进式部署策略，网站可以在不影响现有用户的前提下逐步启用。第三，DBSC的密钥绑定对象是设备而非连接，避免了连接迁移带来的复杂性。这些设计决策使DBSC在实际部署可行性上远超其前身。

与现有Cookie体系的兼容性

DBSC设计的一个重要考量是渐进式部署。它并不要求彻底废弃现有的Cookie机制，而是在其基础上增加一层设备绑定验证。网站可以逐步接入这项能力，同时Google将其设计为一个开放标准，希望其他浏览器厂商和网站服务商共同采纳，而非成为Chrome的专属特性。

DBSC由Google提出并提交至Web孵化器社区组（WICG）进行标准化讨论，这意味着它并非Chrome的私有功能，而是面向整个Web平台的开放提案。WICG是W3C旗下的一个社区组，专门用于孵化早期Web标准提案，成功案例包括后来被正式标准化的Portals API和Web Bundles等。标准化对于此类安全技术至关重要——如果只有单一浏览器支持，网站缺乏动力部署；只有形成跨浏览器共识，才能产生足够的生态推动力。历史上，类似的跨厂商协作案例包括WebAuthn标准的推广（从提案到主流浏览器全面支持历时约三年）以及HTTPS的普及（得益于Let's Encrypt和浏览器厂商的联合推动，HTTPS覆盖率从2014年的约30%提升到2024年的超过95%）。

DBSC的安全价值与现实局限

对Web安全生态的深远影响

如果DBSC能够被广泛采用，将带来多重安全收益：

• Cookie窃取失效：信息窃取软件即便成功入侵设备，窃取到的Cookie也无法在别处使用。更准确地说，窃取到的短期Cookie会在数分钟内过期，且攻击者无法在自己的设备上完成续期所需的密码学证明
• 黑产经济模型瓦解：被盗Cookie的商业价值大打折扣，相关产业链难以为继。当前信息窃取软件的商业模式建立在"偷一次，用很久"的基础上——一个被盗的长期会话Cookie可能在数天甚至数周内有效。DBSC将这个窗口压缩到分钟级别，使得批量交易被盗凭证的商业逻辑不再成立
• 整体安全提升：个人用户、企业以及依赖会话认证的各类在线服务均可获益

企业安全场景的应用前景

DBSC对企业安全架构的潜在影响尤为值得关注。在零信任（Zero Trust）安全模型中，"永不信任，始终验证"是核心原则。Google自身的BeyondCorp企业安全框架就率先实践了这一理念——取消传统VPN，对每一次资源访问都进行设备状态评估和身份验证。DBSC可以天然地融入这类架构：设备绑定的会话凭证本身就是一种持续的设备证明，服务器每次验证Cookie续期签名时，实际上也在确认请求来自已注册的可信设备。

对于部署了ZTNA（零信任网络访问）解决方案的企业而言，DBSC提供了一种标准化的、浏览器原生的设备绑定能力，可以减少对专有客户端代理的依赖。未来，企业的SaaS应用（如Google Workspace、Microsoft 365、Salesforce等）如果广泛采用DBSC，员工即使在未安装企业MDM管理软件的设备上，也能通过DBSC获得硬件级别的会话保护。这对于BYOD（自带设备办公）场景尤其有价值。

当前面临的挑战

不过，DBSC也并非万能方案：

• 硬件依赖：它依赖设备的可信硬件支持，对于缺乏TPM等安全模块的老旧设备可能无法完全启用。根据Google的设计文档，对于没有硬件安全模块的设备，DBSC可能回退到软件隔离方案（如操作系统级别的密钥库），但安全性会相应降低
• 本地攻击风险：如果恶意软件已在设备上获得足够高的权限，理论上仍可能在本地实时利用私钥进行签名操作——尽管这比简单导出Cookie到远程设备困难得多。这种攻击方式要求恶意软件在受害设备上保持持续运行，并实时代理每一次服务器的验证请求，大幅增加了攻击复杂度和被检测的概率。安全专家将此称为"从离线攻击升级为在线攻击"——攻击者不能再"偷了就跑"，必须维持对受害设备的持续控制，这给端点检测与响应（EDR）系统提供了更多的检测机会
• 推广周期：标准的推广需要网站和浏览器的双向配合，短期内难以覆盖所有服务。服务器端需要实现DBSC的注册、挑战和验证逻辑，这意味着现有的认证基础设施需要升级。对于使用第三方身份提供商（如Auth0、Okta）的网站，可能需要等待这些服务商集成DBSC支持
• 隐私考量：设备绑定的密钥对在理论上可能被用于跨站追踪（如果多个网站共享相同的设备标识）。为此，DBSC的设计要求每个网站使用独立的密钥对，确保不同站点之间无法通过DBSC进行用户关联
• 多设备使用场景：DBSC的设备绑定特性天然与用户的多设备使用习惯产生张力。现代用户通常在手机、平板、笔记本和台式机等多个设备上访问同一账户，而传统Cookie可以通过浏览器的同步功能在设备间共享。DBSC要求每个设备独立注册密钥对，这意味着用户在新设备上首次访问时需要重新完成完整的登录流程。这实际上是一种有意为之的安全设计——它确保了会话无法被"同步"到攻击者的设备上。对用户而言，这与当前首次在新设备登录时的体验差异不大，因为主流服务本来就要求新设备登录时进行额外验证

从承载令牌到设备绑定：会话安全的范式转变

DBSC代表了会话安全领域的一次重要范式转变：从"谁持有令牌谁就是用户"转向"谁拥有绑定设备谁才是用户"。这种将凭证与硬件深度绑定的思路，与近年来兴起的Passkey（通行密钥）等无密码认证技术一脉相承，共同指向一个更安全的身份验证未来。

Passkey是基于FIDO2/WebAuthn标准的无密码认证技术，由FIDO联盟推动，Apple、Google、Microsoft三大平台厂商于2022年联合宣布支持。Passkey同样使用公私钥对进行身份验证，私钥存储在设备的安全硬件中，用户通过生物识别（指纹、面部）或设备PIN解锁使用。与传统密码相比，Passkey从根本上消除了钓鱼攻击的可能性——因为私钥永远不会被发送到服务器，认证过程中也不存在可被截获的共享秘密。截至2024年，GitHub、Amazon、PayPal、各大银行等主流服务已支持Passkey登录，Google账户更是将Passkey设为默认登录方式。

Passkey针对的是登录环节的密码替代，而DBSC针对的是登录后的会话保护，两者形成互补：Passkey确保登录过程不被钓鱼攻击，DBSC确保登录后的会话不被劫持，共同构建了从认证到会话的全链路硬件绑定安全体系。可以将其类比为一套完整的门禁系统——Passkey是"进门时的身份核验"，DBSC则是"进门后持续确认你仍然是本人"。在这两项技术的共同作用下，攻击者面对的不再是单一的防线突破问题，而是需要同时攻克硬件安全模块才能完成的端到端攻击，这从根本上改变了攻防的经济学等式。

从更宏观的视角来看，DBSC和Passkey代表了Web安全从"基于知识的认证"（你知道什么——密码）到"基于持有的认证"（你拥有什么——绑定设备）的根本性转型。这一转型的驱动力不仅来自技术进步，更来自威胁环境的根本变化：在AI驱动的自动化攻击时代，任何可以被远程复制的凭证都注定是脆弱的。只有将安全锚点固定在物理硬件上，才能建立起对抗大规模自动化攻击的可持续防线。

对于普通用户而言，这项技术几乎无感知，却可能在背后默默阻挡最危险的一类攻击。随着Chrome的率先落地，值得关注其他浏览器厂商是否会跟进，从而让设备绑定会话真正成为Web安全的新基石。

核心要点

• 传统会话Cookie作为承载令牌，一旦被窃取就能被任意设备使用，双因素认证无法提供保护
• 信息窃取软件已形成成熟产业链，批量窃取并交易会话Cookie
• DBSC通过TPM等硬件安全模块生成不可导出的私钥，将会话凭证与物理设备绑定
• DBSC采用短期Cookie加密码学轮换机制，窃取的Cookie在分钟级别内失效
• 该技术将攻击模式从简单的"离线Cookie窃取"提升为复杂的"在线实时代理"，大幅提高攻击门槛
• DBSC与Passkey互补，共同构建从登录到会话的全链路硬件绑定安全体系
• 作为开放标准提案，DBSC的广泛采用需要浏览器厂商和网站服务商的共同推进