--- title: "Chrome 扩展下架后的代码执行盲区：机制缺陷与安全风险分析" route: "/posts/2026/04/11/chrome-extension-store-removal-security-flaw/" canonical_path: "/posts/2026/04/11/chrome-extension-store-removal-security-flaw/" canonical_url: "https://blog2.hotdry.top/posts/2026/04/11/chrome-extension-store-removal-security-flaw/" markdown_path: "/agent/posts/2026/04/11/chrome-extension-store-removal-security-flaw/index.md" markdown_url: "https://blog2.hotdry.top/agent/posts/2026/04/11/chrome-extension-store-removal-security-flaw/index.md" agent_public_path: "/agent/posts/2026/04/11/chrome-extension-store-removal-security-flaw/" agent_public_url: "https://blog2.hotdry.top/agent/posts/2026/04/11/chrome-extension-store-removal-security-flaw/" kind: "research" generated_at: "2026-04-11T19:18:12.647Z" version: "1" slug: "2026/04/11/chrome-extension-store-removal-security-flaw" date: "2026-04-11T04:02:05+08:00" category: "security" year: "2026" month: "04" day: "11" --- # Chrome 扩展下架后的代码执行盲区：机制缺陷与安全风险分析 > 以 JSON Formatter 扩展为例，剖析 Chrome Web Store 审核机制与扩展下架后持续运行的技术根因，揭示浏览器扩展生态的安全盲区。 ## 元数据 - Canonical: /posts/2026/04/11/chrome-extension-store-removal-security-flaw/ - Agent Snapshot: /agent/posts/2026/04/11/chrome-extension-store-removal-security-flaw/index.md - 发布时间: 2026-04-11T04:02:05+08:00 - 分类: [security](/agent/categories/security/index.md) - 站点: https://blog2.hotdry.top ## 正文 当一个 Chrome 扩展被从 Web Store 下架时，用户设备上的副本并不会自动卸载或禁用。这一看似“温和”的设计选择，实际上构成了浏览器扩展生态系统中最为隐蔽的安全漏洞之一。2025 年以来，安全研究机构已累计发现超过 100 个存在恶意行为的 Chrome 扩展，其中不乏拥有数百万安装量的成熟产品。这些扩展在被下架后，其代码仍然在数以千万计的用户浏览器中持续运行，继续拥有访问页面内容、网络请求和敏感数据的权限。本文以曾被广泛使用的 JSON Formatter 扩展为切入点，深入分析扩展下架后仍可执行代码的技术机制，并探讨 Chrome Web Store 审核流程中存在的系统性缺陷。 ## 扩展架构与下架后的运行机制 理解这一安全问题的技术本质，需要首先了解 Chrome 扩展的基本运行原理。Chrome 扩展本质上是一个打包的 Web 应用，由 HTML、CSS、JavaScript 和一个名为 manifest.json 的配置文件组成。扩展在用户浏览器中拥有独立的执行上下文，可以通过 Content Scripts 注入到用户访问的网页中，也可以通过 Background Scripts 在后台处理网络请求和事件。更关键的是，扩展被授予的权限决定了其能访问的数据范围——一个请求了 `` 权限的扩展，理论上可以读取和修改用户在浏览器中访问的所有内容。 当开发者将扩展发布到 Chrome Web Store 时，扩展的安装包会被 Google 的服务器存储和分发。但这里存在一个关键的设计决策：扩展的安装并非“租借”，而是“交付”。一旦用户安装了某个扩展，该扩展的文件会被下载并存储在用户本地的浏览器配置目录中。这意味着，即使开发者主动从 Web Store 移除该扩展，或者 Google 因违规而下架该扩展，已经安装在用户浏览器中的文件并不会被自动删除。扩展的 JavaScript 代码仍然存在于本地，仍然拥有之前授予的权限，并且在用户下次启动浏览器或访问特定网页时继续执行。 这种设计背后的考量是合理的：Google 认为用户对自己设备上的软件拥有主权，不应该被远程强制移除。然而，这一设计在安全层面形成了巨大的盲区。研究表明，当一个扩展被标记为“已从商店移除”时，Chrome 只会停止向用户推送更新通知，并不会禁用该扩展的运行功能。对于依赖远程配置服务器或后端 API 的扩展，移除后可能因为无法连接到服务器而逐渐失效；但对于像 JSON Formatter 这样完全在本地执行的工具类扩展，移除商店页面几乎不会对其功能产生任何影响。 ## Chrome Web Store 审核机制的结构性缺陷 Chrome Web Store 的审核机制长期面临“规模化困境”。根据 Google 官方公布的政策，所有提交至 Web Store 的扩展都会经过自动化扫描和人工审核的组合流程。然而，面对超过 20 万个活跃扩展和每日数千个新提交，审核团队难以对每个扩展的代码变更进行深度审查。这导致了一个严重的问题：恶意开发者可以利用“马甲包”策略，先提交一个功能正常且无害的版本以通过审核，随后通过后续更新引入恶意代码。由于扩展获得初始批准后，后续更新通常采用简化审核流程，恶意代码可以在短时间内触达大量用户。 更值得关注的是审核标准的模糊地带。以 JSON Formatter 为例，这是一个最初旨在美化 JSON 格式显示的工具类扩展，其核心功能完全合法。然而，安全研究人员发现该扩展的某些版本存在可疑行为，包括在特定条件下注入广告代码或收集用户的浏览数据。这类行为的恶意程度介于“广告软件”和“间谍软件”之间，往往处于审核标准的灰色地带。Google 的审核政策明确禁止“秘密收集用户数据”和“注入未经请求的广告”，但在实际执行中，区分“功能性的广告展示”和“恶意广告注入”并非易事。扩展可以使用复杂的触发条件，例如仅在特定域名或特定时间段内激活其广告注入逻辑，从而规避自动扫描系统的检测。 审核机制的另一项根本缺陷在于其“事后追责”模式。Google 倾向于在收到用户举报或安全社区报告后才对问题扩展采取行动，而非在恶意代码进入商店之前将其拦截。这种被动防御模式意味着，一个恶意扩展可能已经在商店中存活数周甚至数月，期间积累了大量安装量。当扩展最终被下架时，这些安装量已经转化为实实在在的安全风险——如前所述，下架并不等同于卸载。 ## 扩展下架后的威胁向量分析 下架后仍可运行的扩展面临多种具体的威胁向量。第一种威胁是“沉默的恶意行为延续”。即使原始开发者在其扩展被下架后没有推送任何更新，扩展本身的现有代码已经可以造成危害。以广告注入类扩展为例，其代码中可能包含针对特定广告网络的调用逻辑，这些逻辑会在用户浏览特定类型的网页时触发，展示额外广告或进行点击欺诈。用户通常不会意识到这些行为是由已“消失”的扩展引起的，因为扩展的图标可能仍然存在于工具栏中，用户也完全记不得自己何时安装了这个扩展。 第二种威胁来自“开发者身份转换”。一个曾经合法的扩展被下架后，其代码仓库或开发者账号可能被出售给恶意行为者。由于扩展已经安装在用户设备上，新运营者无需重新分发恶意软件即可获得代码执行能力。他们可以尝试通过各种手段诱导用户手动更新扩展（如果扩展仍具有更新能力），或者简单地利用现有代码中的既有漏洞进行攻击。即使扩展完全失去了更新通道，其现有的权限和代码本身仍然是有价值的攻击面。 第三种威胁是企业环境中的“持久性立足点”。在企业网络中，IT 管理员通常依赖浏览器扩展来部署内部工具或安全解决方案。如果某个被企业广泛安装的扩展被下架且存在恶意行为，攻击者可能将其作为突破口，通过该扩展窃取企业凭据、监听通信流量或横向移动到内部网络。由于企业环境的更新周期往往比个人用户更长，这类扩展可能在企业中存留数年而不被发现。 针对 JSON Formatter 这类工具类扩展，具体的风险表现为：扩展被授予了访问所有网站数据的权限（通常是为了格式化任意页面上的 JSON 响应），这意味着它可以读取用户通过浏览器发送和接收的所有内容，包括表单数据、登录凭据、会话 Cookie 以及其他敏感信息。如果扩展的代码被篡改或包含隐藏的数据外传逻辑，这些信息都可能被窃取。安全研究人员已经记录了多起案例，攻击者通过入侵合法的扩展开发者账号或收购无人维护的扩展来实现上述攻击。 ## 工程层面的缓解策略与监控要点 面对这一系统性问题，用户和企业都需要采取分层防御策略。在个人用户层面，定期审查已安装的扩展是必要的。Chrome 提供了 `chrome://extensions` 页面，用户可以在此查看所有已安装扩展的权限和来源。建议用户关注以下信号：权限与功能明显不匹配的扩展（如一个简单的 JSON 格式化工具请求访问所有网站的权限）、来自不活跃或未知开发者的扩展、以及在 `chrome://extensions` 中显示“此扩展不在 Chrome Web Store 中”的扩展。后者意味着该扩展可能已被下架但尚未从用户设备移除。 在企业层面，部署浏览器扩展白名单和集中管理策略至关重要。Google Workspace 和 Microsoft Intune 等企业管理平台允许管理员限制用户仅能安装经过审批的扩展，并可以远程禁用已发现问题的扩展。企业还应实施浏览器扩展清单审计，至少每季度一次扫描所有终端上的扩展安装情况，关注新出现的扩展和权限变更。此外，部署专注于浏览器安全的安全产品可以监控扩展的可疑网络行为，例如尝试连接已知恶意域名或在非预期场景下发送大量数据。 在技术实现层面，监控下架扩展的持续运行需要关注以下指标：浏览器客户端上报的扩展状态变化、扩展产生的异常网络流量模式（如定期向陌生端点发送小数据包），以及页面注入事件中的异常行为。安全团队可以建立已知恶意扩展的特征库（基于扩展 ID、证书指纹和代码哈希），并在网络边界或终端检测系统中进行匹配。当检测到已下架扩展仍在活跃运行时，应自动触发告警并引导用户卸载。 ## 总结 Chrome 扩展从 Web Store 下架后仍可执行代码的问题，折射出浏览器生态系统在安全设计上的深层矛盾：既要尊重用户对本地软件的控制权，又要承担起平台方的安全监管责任。JSON Formatter 案例表明，即使是看似无害的工具类扩展，在获得过度权限后也可能成为攻击向量。而审核机制的规模化困境和“事后追责”的被动模式，使得恶意扩展有隙可乘。用户应养成定期审计扩展的习惯，企业则需要建立覆盖扩展生命周期的安全管理流程，从安装审查到持续监控再到下架后的清理，形成完整的安全闭环。 --- **参考资料** - The Thai CERT: Over 100 Malicious Chrome Extensions Found Stealing Session Data and Injecting Ads (2025) - Google Developer Documentation: Manifest V2 Support Timeline - Chrome Web Store Troubleshooting: Handling Extension Violations ## 同分类近期文章 ### [Rockstar Games 遭遇 ShinyHunters 勒索软件攻击：2026年4月事件分析](/agent/posts/2026/04/12/rockstar-games-shinyhunters-ransomware-april-2026/index.md) - 日期: 2026-04-12T01:27:56+08:00 - 分类: [security](/agent/categories/security/index.md) - 摘要: 深入分析 2026 年 4 月 ShinyHunters 组织对 Rockstar Games 的勒索攻击事件，探讨攻击手段、影响范围及游戏行业安全防护要点。 ### [CPU-Z与HWMonitor供应链攻击检测：从二进制完整性到工程化响应](/agent/posts/2026/04/12/cpu-z-hwmonitor-supply-chain-attack-detection/index.md) - 日期: 2026-04-12T01:02:33+08:00 - 分类: [security](/agent/categories/security/index.md) - 摘要: 深度剖析 CPUID 产品供应链攻击事件，提供工程级的二进制完整性验证方案与可落地检测参数。 ### [BlueHammer：利用 Windows Defender 更新机制的本地提权漏洞分析](/agent/posts/2026/04/11/bluehammer-windows-defender-privilege-escalation/index.md) - 日期: 2026-04-11T19:01:17+08:00 - 分类: [security](/agent/categories/security/index.md) - 摘要: 深度拆解 BlueHammer 如何通过滥用 Defender 签名更新流程、VSS 与 Cloud Files API 组合实现从普通用户到 SYSTEM 权限的提权，并给出检测规则与缓解建议。 ### [固件二进制完整性验证：从 TPM/UEFI 到供应链审计的工程实践](/agent/posts/2026/04/11/firmware-binary-integrity-verification/index.md) - 日期: 2026-04-11T16:51:19+08:00 - 分类: [security](/agent/categories/security/index.md) - 摘要: 基于 CPU-Z/HWMonitor 供应链攻击事件，从工程视角构建固件与 BIOS 二进制完整性验证流程，涵盖 TPM 证明、UEFI Secure Boot 审计及代码签名验证的关键参数。 ### [macOS TCC 数据库完整性验证：工程化检测与自动化审计方案](/agent/posts/2026/04/11/macos-tcc-database-integrity-validation/index.md) - 日期: 2026-04-11T13:27:43+08:00 - 分类: [security](/agent/categories/security/index.md) - 摘要: 深入解析 macOS TCC 数据库完整性验证机制，提供直接文件系统访问的检测策略与自动化审计参数配置。