Hotdry Blog

Article

浏览器扩展读取 LinkedIn 数据的隐私风险与权限模型评估

以 LinkedIn 扫描用户浏览器扩展的隐私争议为切入点,分析浏览器扩展的权限模型与敏感 API 调用链,给出用户与开发者的可操作安全指南。

2026-04-03security

当用户登录 LinkedIn 平台时,一次静默的数据扫描正在后台进行。2026 年初,Fairlinked e.V. 协会发布的 BrowserGate 调查报告揭示了微软旗下 LinkedIn 平台的大规模用户数据扫描行为:每當用户访问 linkedin.com,隐藏脚本会自动检测用户浏览器中安装的扩展程序,并将结果回传至 LinkedIn 服务器及第三方安全公司 HUMAN Security(原 PerimensionX)[1]。这一行为涉及超过 6000 种扩展程序的识别,包括 509 种求职工具、200 余种商业竞品以及大量涉及用户宗教信仰、政治倾向和健康状况的敏感扩展。欧盟监管机构已将此行为列为潜在违法,因为整个过程未获取用户同意,亦未在隐私政策中披露。

这一事件的本质并非简单的数据收集,而是暴露了现代浏览器扩展生态中权限模型的系统性风险。当用户授权一个扩展访问其浏览器数据时,实际上授予了该扩展对特定 API 的调用权,而这些 API 在缺乏严格约束的情况下,可以被滥用于用户画像构建、行为追踪乃至企业情报收集。本文将从浏览器扩展的权限模型出发,结合 LinkedIn 扫描事件的技术细节,剖析敏感 API 的调用链风险,并为用户和开发者提供可落地的防护建议。

浏览器扩展权限模型的核心机制

现代浏览器扩展基于 WebExtensions 标准构建,Chrome、Firefox、Edge 等主流浏览器均遵循这一架构。扩展的权限体系主要由两部分构成:主机权限(Host Permissions)和 API 权限(API Permissions)。主机权限决定了扩展可以访问哪些网站的数据,通过在 manifest.json 中声明 <all_urls> 或特定的域名模式实现;API 权限则指定了扩展可以调用的浏览器内部接口,如操作 cookies、读取浏览历史、管理标签页等。

以 Chrome 扩展为例,Manifest V3(当前最新版本)对权限模型进行了多项安全强化。传统 Manifest V2 允许扩展在安装时一次性获取全部声明的权限,这种 “全有或全无” 的模式导致用户在安装时面对冗长的权限列表难以做出准确判断。Manifest V3 引入了可选权限(Optional Permissions)和运行时权限请求(Runtime Permissions)机制,开发者可以将敏感权限的获取延迟到用户实际需要使用该功能时再弹出提示。Chrome 还会对声明了主机权限 <all_urls> 的扩展进行额外审查,因为这种权限等同于授予扩展读取和修改所有网站内容的权力。

然而,权限模型的安全性高度依赖于开发者的自律和用户的安全意识。LinkedIn 扫描事件的特别之处在于,问题并非来自第三方恶意扩展,而是平台本身利用了浏览器扩展检测技术来识别用户环境。根据 BrowserGate 的调查,LinkedIn 的脚本通过枚举 navigator.plugins 和 navigator.mimeTypes 等浏览器 API,判断用户是否安装了特定扩展 [1]。这是一种被动检测方式,无需用户授权,但结合 LinkedIn 本身已获取的用户身份信息(姓名、雇主、职位),即可构建出精确的用户画像。

高风险敏感 API 解析

浏览器扩展的权限体系中,存在若干被安全研究人员标记为高风险的 API,理解这些 API 的能力边界是评估扩展隐私风险的前提。cookies API 允许扩展读取、修改和删除与特定域名关联的 cookies,攻击者可以利用此接口窃取会话令牌,从而劫持用户账户。tabs API 提供对浏览器标签页的完整访问权限,包括标签页的 URL、标题、 favicon 以及在某些情况下的页面内容摘要,这对隐私的威胁在于可以完整记录用户的浏览行为轨迹。

webRequest API 是功能最为强大的网络请求监控接口之一,它允许扩展拦截、修改甚至阻止浏览器发出的所有 HTTP 请求。在 Manifest V3 中,webRequest 被替换为 declarativeNetRequest,后者通过预定义的规则集对网络请求进行过滤,理论上降低了权限被滥用的风险,但仍然可以用于实现内容过滤、广告拦截等合法功能。history API 和 bookmarks API 分别暴露用户的浏览历史和收藏夹信息,这些数据对于构建用户兴趣图谱具有重要价值。此外,storage API 虽然用于本地数据持久化,但如果扩展存在跨站脚本漏洞,攻击者可能通过注入恶意代码读取存储的用户数据。

值得关注的是,扩展权限的授权是针对整个扩展而言的,这意味着一个扩展获取某项 API 权限后,可以在任何被授权的上下文中调用该 API,不区分具体的功能模块。这种 “一次授权,处处可用” 的特性要求用户在安装扩展时必须评估该扩展开发者的可信度,因为权限一旦授予,扩展代码的后续更新同样继承这些权限。如果开发者账户被攻击或扩展被恶意上架,用户的隐私数据将面临直接威胁。

实际攻击链路分析:从扩展检测到用户画像

LinkedIn 扫描事件展示了一种典型的隐私侵犯链路:平台利用浏览器 API 检测用户环境,结合已掌握的用户身份信息,实现精细化的数据采集。整个过程可以分为三个阶段:第一阶段是环境指纹构建,LinkedIn 的脚本通过检测约 6000 种已知扩展的特征标识(包括扩展的程序 ID、文件名、描述信息等),为每位用户生成独特的 “扩展指纹”[1]。第二阶段是身份关联,由于用户已登录 LinkedIn 平台,扫描结果可以直接与用户的真实姓名、雇主名称、职位头衔绑定,形成完整的个人档案。第三阶段是数据变现,扫描获取的信息被用于商业竞品分析、求职行为追踪,并向第三方公司共享。

从技术实现角度,LinkedIn 的扩展检测方法并不依赖任何敏感的扩展 API,而是利用了浏览器原生暴露的 navigator 对象属性。navigator.plugins 数组包含了浏览器中安装的所有插件信息,navigator.mimeTypes 列出了支持的 MIME 类型,扩展通常会在这些属性中注册自己的标识信息。通过比对预先构建的扩展特征数据库,平台可以以较高准确率判断用户是否安装了特定扩展。这种检测方式的隐蔽性在于它不需要任何用户授权,用户甚至无法感知自己的扩展列表正在被读取。

更值得警惕的是,LinkedIn 的扫描行为发生在用户明确授权登录的平台页面内,这意味着平台可以名正言顺地访问用户在该域名下的全部内容。浏览器扩展无法防御来自平台本身的这种检测,因为问题根源在于浏览器 API 的设计缺陷 —— 这些 API 本意是支持插件检测(如判断是否需要加载 Flash),但在商业利益的驱动下被滥用于用户追踪。目前的防御手段主要集中在浏览器层面,例如 Firefox 已开始限制 navigator.plugins 信息的可访问性,但 Chrome 等主流浏览器尚未采取类似措施。

用户与开发者的可操作安全指南

面对浏览器扩展生态的隐私风险,用户可以从三个层面构建防御体系。首先是安装前的评估,用户在安装扩展时应仔细审查权限声明,对于要求 <all_urls> 主机权限或敏感 API(如 cookies、webRequest、tabs)的扩展应保持警惕,优先选择功能明确、权限最小化的替代品。其次是运行时监控,用户可以定期访问浏览器的扩展管理页面,检查已安装扩展的权限是否发生异常变更,Manifest V3 允许扩展在更新时增减权限,这种动态变化是潜在的安全信号。最后是敏感场景的隔离,对于需要高隐私保护的操作(如使用竞品工具、访问求职平台),用户可以创建独立的浏览器配置文件或使用隐私模式,将敏感扩展与日常使用环境物理隔离。

对于扩展开发者而言,遵循最小权限原则是降低用户风险的根本策略。开发者应在 manifest.json 中精确声明实际需要的权限,避免为了功能便利而过度申请主机权限。Chrome 官方文档明确建议将权限划分为必需权限和可选权限两部分,必需权限在安装时请求,可选权限在运行时按需获取 [2]。此外,开发者应对扩展代码实施安全审计,防止跨站脚本漏洞导致权限被恶意利用。扩展发布后,应建立清晰的隐私政策,向用户说明数据收集的范围、用途和存储方式,这不仅是合规要求,也是建立用户信任的重要手段。

从平台治理角度,浏览器厂商需要重新审视 navigator 等原生 API 的设计哲学,平衡功能兼容性与隐私保护。BrowserGate 调查报告指出,LinkedIn 的扫描行为在欧盟法律框架下可能构成未经授权的数据处理 [1],这一案例应成为监管机构关注浏览器环境隐私风险的契机。随着 WebExtensions 生态持续扩展,扩展权限的滥用风险将日益突出,唯有通过技术改进、用户教育和法规完善的多方协同,才能有效遏制隐私侵犯行为的蔓延。


参考资料

security