剪贴板即信道
摘要 异步剪贴板 API 为 Web 应用提供了读、写系统剪贴板的能力，但 navigator.clipboard.write() 的异步执行与用户 paste 事件的同步触发之间，存在一个容易被忽略的原子性缺陷。攻击者可利用同一用户手势先后调用 write() 和 read()，通过 Promise.race 构造竞态条件，在浏览器实际写入新内容之前读取到剪贴板中尚未被覆盖的残留数据——而这些数据可能来自另一个域，包含密码管理器自动填充的凭据、2FA 种子或私钥。更危险的是，结合密码管理器的“复制密码”功能和 WebAuthn 条件 UI 的自动填充行为，窃取甚至不需要用户额外的粘贴操作。 异步剪贴板 API 的安全模型 从 execCommand 到 navigator.clipboard 在 navigator.clipboard 出现之前，页面只能通过 document.execCommand(‘copy’) 和 document.execCommand(‘paste’) 操作剪贴板，且后者仅在浏览器扩展或用户主动粘贴时可用。异步剪贴板 API 允许页面使用 readText() 和 writeText() 直接读取和写入文本，前提是获得用户许可（对于 read，通常要求页面可见且由用户手势触发）并且传输数据遵循安全上下文（HTTPS）。 关键设计：write() 返回一个 Promise，在数据被系统剪贴板确认后解析；read() 同样返回一个 Promise，在读取到当前剪贴板内容时解析。二者都是在“任务队列”中异步执行的，但在一次用户手势（如 click 事件）中，可以同时调用两个方法而不相互阻塞。 同一个点击下的 write 与 read 考虑以下代码： button.addEventListener('click', async () => { navigator.clipboard.writeText('A'.repeat(100)); const data = await navigator.clipboard.readText(); console.log(data); }); 开发者预期 readText() 会返回刚才写入的 ‘AAA…’，但实际结果取决于 UA 的事件循环调度：如果 writeText() 的内部实现是“先调度写入任务，再解析 Promise”，而 readText() 在写入任务实际执行之前就已经从系统剪贴板读取了内容，那么 data 将是调用 writeText()之前 剪贴板中的旧数据。这个顺序差异构成了可被利用的竞态窗口。 竞态条件的微观时序 任务队列的调度间隙 浏览器主线程执行模型： 用户点击，click 事件处理开始。 调用 writeText()，UA 创建一个“写剪贴板”任务并将其排入任务队列，同时返回一个 Promise。 继续执行，调用 readText()，UA 创建一个“读剪贴板”任务排入队列，返回…
