Web Push 通知暗藏杀机？别让它变身隐形后门

你可能没注意到的无声威胁

Web Push 推送通知现在几乎成了网页应用的标配。协作工具用它来实时提醒，报警系统靠它来及时送达。但如果这个本该让用户知情的机制，反而成了攻击者悄无声息的入侵通道呢？

这就引出了“Sleeping Agent”漏洞。它利用了浏览器在执行 Web Push API 安全规则时的一个时间差，把推送功能变成了持久化的隐蔽攻击工具。

漏洞是怎么产生的

Web Push API 原本有一条安全规定：userVisibleOnly: true。意思是，网站必须保证每条推送都会显示通知给用户看到。这算是一种“君子协定”——浏览器相信你会遵守。

理论上没问题，但实际执行却有漏洞。

攻击者可以让恶意 Service Worker 在收到推送后，迅速执行两个操作：

1. 先调用 showNotification() 显示通知
2. 马上再用 notification.close() 把通知关掉

通知只在浏览器内部数据库里短暂存在，然后就被删除了。等浏览器去检查“通知是否真的显示”时，它查的不是屏幕上有没有通知，而是数据库里的记录。这就形成了一个时间差：数据库有记录，屏幕上却什么都没有。浏览器认为合规了，用户却完全没察觉。攻击者因此获得了一条隐蔽的命令通道。

为什么这个问题值得关注

这个漏洞不只是绕过了一个设置，它直接动摇了 Web Push 整个信任体系：

持久隐蔽：攻击者能建立长期通信通道，而用户完全不知道。传统恶意软件需要安装和运行，Web Push 只需用户访问一次被植入恶意代码的页面。

合规失效：很多安全框架把“显示通知”作为信任边界。现在这个边界被绕过了。

影响范围广：Chrome、Edge 甚至 Safari 26.5 之前的版本都受影响。这个漏洞在当前主流浏览器里都能稳定复现。

门槛低：不需要复杂工具，五分钟就能在稳定版本浏览器里完成攻击。

技术细节

漏洞的核心在于，浏览器检查通知是否显示的时间点，在 Service Worker 完成所有操作之后。具体流程是：

1. 推送事件到达
2. Service Worker 快速执行 showNotification() 和 notification.close()
3. Service Worker 执行完毕
4. 浏览器开始检查：“通知显示了吗？”
5. 它查询的是数据库（里面有记录），而不是实际屏幕
6. 检查通过
7. 推送事件被视为合法

这个时间窗口很窄，但足够稳定地被利用。

对开发者的建议

如果你在开发使用 Web Push 的应用，这些问题值得注意：

你的 Service Worker 有没有被检查过异常通知行为？ 如果第三方脚本控制了你的 Service Worker，这个漏洞就会变成你的安全问题。

你有没有监控通知的生命周期？ 可以对 showNotification() 和 close() 调用设置监控或记录，来发现异常行为。

你有没有验证推送消息的来源？ 用加密方式确认推送来自你的合法服务器，而不是攻击者的命令通道。

更广泛的影响

这个漏洞揭示了网页平台安全的一个根本问题：规范意图和实际执行之间的差距。W3C 规范要求浏览器必须保证通知可见，但实际检查的却是数据库记录，而不是屏幕上的内容。

这说明，安全要求只有执行机制真正有效时才算可靠。光靠“君子协定”是不够的。

如何应对

浏览器厂商已经知道这个漏洞，正在修复中。如果你正在运行生产系统，建议：

1. 监控 Service Worker 的通知行为，注意异常关闭通知的模式
2. 对推送消息来源做服务端验证
3. 保持浏览器更新，及时获得厂商的修复
4. 在敏感应用中使用 Web Push 时，考虑潜在的威胁模型

Web Push 本身是个很有用的功能，但像所有强大的平台特性一样，需要我们同时关注它的好处和风险。

“Sleeping Agent”这个漏洞提醒我们，即使设计良好的安全机制，也可能存在被利用的漏洞。只有保持警惕、实施纵深防御，才能更好地保护应用和用户。