不用 DBSC
普通会话主要依赖 Cookie。攻击者复制到未过期的 Cookie 后，就可能在另一台设备或另一个浏览器上下文里直接重放。
- 刷新条件：通常只看 Cookie 或传统刷新凭据是否还有效。
- 重放窗口：Cookie 没过期前都可能被利用。
- 演示含义：这里展示的是短 Cookie 有效期内的可利用窗口。
当前演示状态
DBSC 绑定状态
DBSC 绑定状态：未绑定
DBSC 启用
尚未观察到 DBSC 注册
短 Cookie 有效期
尚未签发短 Cookie。
Chrome 处理注册响应并回调 /StartSession 后才算真正启用；浏览器版本和安全上下文只作为提示信号。
使用 DBSC
DBSC 不会让已经偷到且未过期的短 Cookie 立刻失效；它把 Cookie 有效期做短，并把自动续期绑定到原 Mac Chrome 的设备私钥。
- 刷新条件：过期后必须通过刷新端点，用原浏览器私钥签名证明。
- 重放窗口：未过期的短 Cookie 仍可能被利用；短 TTL 缩小被盗 Cookie 的可利用窗口，原设备上的 Chrome 可以自动续期，过期后偷来的 Cookie 不能在另一台设备续期。
- 演示含义：重点看短 Cookie 过期后的重放阻断和刷新证明事件。
Chrome / DBSC 支持检测
- 安全上下文检测中
等待浏览器脚本检测 HTTPS 和 isSecureContext。
- Chrome 版本检测中
等待浏览器脚本读取 Mac Chrome 品牌和主版本。
- DBSC 启用未确认
尚未观察到 DBSC 注册
没有稳定公开的前端 DBSC 开关可直接读取，所以最终结论以服务端是否观察到 DBSC 注册为准。如果事件只停在 registration-started，说明服务端已发出注册挑战，但 Chrome 没有成功回调 /StartSession；Mac Chrome 148+ 只是实验提示阈值，还需要当前构建、flag 或灰度真正启用 DBSC。
服务端观察到的事件
- --:--:--等待info
还没有服务端观察到的 DBSC 事件。
服务端接入要点
- 登录后返回
Secure-Session-Registration。 - 保存会话公钥和一次性刷新挑战。
- 签发短期 host-only Cookie，并验证刷新证明。
威胁模型
DBSC 可以降低离开本机后的 Cookie 重放风险，也能减少长期被盗 Cookie 的价值。