谷歌把会话劫持的命根子断了：Chrome 146让3亿条黑产 c

去年4月，谷歌悄悄扔出一项技术。14个月后，它终于上线 Windows 版 Chrome 146。微软安全团队内部测算：如果全网铺开，每年可减少数亿次账户接管。这不是补丁，是直接把黑产的一条财路掐了。

一条 cookie 在黑市能卖多少钱

会话劫持（Session Theft）的产业链成熟得惊人。用户电脑感染信息窃取木马后，Atomic、Lumma、Vidar Stealer 等家族会批量收割浏览器里的会话 cookie。这些令牌往往存活数月，攻击者无需知道密码，直接"借壳登录"。

被盗的 cookie 按平台标价。电商后台、企业邮箱、云服务控制台，单价从几美元到数百美元不等。2023年某暗市数据显示，单个有效的企业级 Microsoft 365 会话能卖到 80-150 美元。更讽刺的是，买家付款前还能验货——攻击者提供截图证明该 cookie 确实能登录目标账户。

谷歌 Chrome 与账户安全团队周四发文称："该项目代表我们在对抗会话劫持方面的重大进展，这一威胁在现代安全格局中依然普遍。"他们没说的是，这条财路已经跑了十几年，防御方一直在打补丁，从未真正治本。

传统方案的问题在于"治标"。双因素认证（2FA）能挡住密码泄露，但拦不住 cookie 被盗后的"合法"登录。设备指纹识别容易被虚拟机绕过。IP 地理位置检测对代理池无效。安全团队像是在跟攻击者玩打地鼠，每次升级都被快速绕过。

DBSC 的解法：把 cookie 焊死在设备上

设备绑定会话凭证（Device Bound Session Credentials，DBSC）的思路很朴素：让偷走的 cookie 变成废纸。

具体实现依赖硬件安全模块。Windows 平台用可信平台模块（Trusted Platform Module，TPM），macOS 用安全隔区（Secure Enclave）。浏览器生成一对公私钥，私钥永远不出设备。服务器每次发放短期会话 cookie 前，要求浏览器证明它持有对应的私钥。

谷歌解释："攻击者无法窃取这个密钥，因此任何被窃取的 cookie 都会迅速过期，对攻击者毫无用处。"

这里有个关键设计：回退机制。如果设备不支持安全密钥存储，DBSC 会优雅降级到标准行为，不会打断正常登录流程。产品经理的克制体现在这种"不折腾用户"的默认策略——安全增强不能牺牲可用性，否则用户会关掉它。

技术细节层面，DBSC 的密钥生命周期与设备绑定，而非用户账户。这意味着即使用户在同一台电脑上切换不同 Chrome 配置文件，每个配置文件的 DBSC 密钥也是独立的。企业环境常用的共享设备场景，因此不会意外串号。

从实验室到 Windows 全量：14 个月的测试链

2024 年 4 月，谷歌首次公开 DBSC 计划。当时它还是个实验性标志（experimental flag），需要手动开启。开发者的反馈集中在企业场景：证书管理、漫游配置文件、虚拟桌面基础设施（VDI）的兼容性。

谷歌与微软合作设计该标准，目标是将 DBSC 推进为开放 Web 标准。这种"先落地再标准化"的路径，与当年 HTTP/2 的推进节奏类似。浏览器厂商先跑通实现，再把经验反哺给 IETF。

2025 年初，DBSC 进入 Chrome Beta 渠道的开放测试。谷歌安全团队监控了数亿次会话的数据，重点观察两个指标：DBSC 会话的劫持尝试成功率，以及回退到标准行为的频率。前者决定安全收益，后者决定用户摩擦。

周四的正式发布意味着测试数据过关。谷歌称已观察到"会话劫持显著减少"，但未披露具体数字。macOS 版本计划在下一次 Chrome 更新中推出，Linux 和移动平台的优先级尚未公开。

企业环境的增强功能是下一阶段重点。谷歌提到"更好地集成企业环境"，暗示可能包括与现有身份提供商（IdP）的深度对接、组策略控制、以及审计日志的细化。这对需要合规留痕的金融、医疗行业尤为重要。

黑产的应对窗口：还有多久

任何防御机制的扩散都有时间差。Chrome 146 的 Windows 全量推送需要数周覆盖全球用户，macOS 版本尚未发布，其他浏览器厂商的跟进速度未知。

攻击者的应对选项有限。理论上，针对 TPM 的侧信道攻击存在，但成本远高于批量窃取 cookie。在受感染设备上直接操作（而非窃取凭证后异地登录）是另一条路，但这需要常驻木马，暴露风险更高，且无法像卖 cookie 那样规模化变现。

更现实的威胁是"降级攻击"：诱导用户或系统回退到标准 cookie 行为。谷歌的回退机制设计本意是兼容旧设备，但也可能成为被利用的缝隙。企业 IT 管理员需要权衡——强制启用 DBSC 可能拒绝部分合法用户，完全放开则留有空档。

信息窃取木马的开发者已经在调整。Lumma Stealer 的某版本更新日志中提到"DBSC 检测"，试图识别目标站点是否启用该机制，从而优先窃取非 DBSC 保护的会话。这种"挑软柿子捏"的策略，恰恰说明防御正在产生选择压力。

开放标准的博弈：谁将跟进

DBSC 要成为行业标准，需要跨浏览器共识。谷歌与微软的合作是起点，但苹果、Mozilla 的态度同样关键。

苹果的安全隔区（Secure Enclave）已在 macOS 版本中使用，技术路径与 Windows TPM 类似。但 Safari 是否会实现 DBSC，取决于苹果对开放 Web 标准的优先级判断。历史上，苹果对 WebKit 的改动相对保守，隐私保护功能（如智能防跟踪）往往优先于安全机制。

Mozilla 的立场更微妙。Firefox 的市场份额虽低，但在隐私敏感用户中仍有基本盘。Mozilla 曾推动多项安全标准（如 Certificate Transparency），但资源约束使其在硬件绑定机制上跟进较慢。

微软 Edge 基于 Chromium，理论上可直接继承 DBSC。但微软作为合作设计方，可能有更深度的集成计划，例如与 Windows Hello 或 Azure AD 的联动。这种"浏览器-操作系统-云服务"的垂直整合，是谷歌难以复制的优势。

企业身份提供商的适配是另一变量。Okta、Ping Identity、Microsoft Entra ID 等需要更新服务端逻辑，验证 DBSC 密钥证明。谷歌的文档提供了协议细节，但落地节奏取决于各家的优先级队列。

谷歌在发文中强调"这只是开始"。从 Windows 到全平台，从消费者到企业，从 Chrome 到行业标准——每一步都需要时间。会话劫持不会消失，但 DBSC 把攻击成本抬高了一个数量级。黑产被迫在"更贵的攻击"和"更窄的目标池"之间做选择，而防御方终于拿到了一点主动权。

一个值得玩味的细节：谷歌选择周四发布，而非常规的周二补丁日。安全团队的解释是"避免与微软 Patch Tuesday 撞车"，但也有人猜测是在等某个大型合作伙伴的同步公告。截至发稿，微软安全响应中心尚未发布相关博客。

Chrome 146 的更新日志里，DBSC 被埋在"安全修复"分类下，没有单独的功能入口。普通用户不会感知到它的存在——除非某天发现自己的账户突然不再被盗。这种"无感安全"是产品经理的理想状态，也是最难达到的境界。

下一个问题是：当 cookie 变得难以窃取，攻击者会把火力转向哪里？本地浏览器扩展的权限滥用、OAuth 流程的钓鱼、还是尚未普及的通行密钥（Passkey）实现缺陷？