本文来源于ACM CCS 2022；
https://dl.acm.org/doi/10.1145/3548606.3560685

摘要

• “浏览器扩展”是轻量级的浏览器附加组件，使用各个浏览器特定的功能丰富的JavaScript api，为用户提供了额外的Web客户端功能，如改进网站外观和与第三方集成服务，比常规的Web应用程序更有效。
• 然而，使用浏览器扩展也有可能带来安全问题：读取和修改DOM内容（数据窃取）、在应用程序上下文中执行不受信任的脚本（可能导致广告注入）、拦截和控制客户机-服务器交换信息（嗅探）、篡改各种攻击预防措施的HTTP报头（如CSP、X-Frame-Options）从而使安全机制失效，将应用程序暴露给相关类型的攻击（例如点击劫持）。
• 本文提出“自动分析框架”，通过利用静态识别和动态分析技术来检测篡改HTTP报头的扩展。我们静态地识别具有修改报头权限的扩展，然后检测api在运行时修改头文件的危险行为。

前提

所有与安全相关的HTTP响应头：

1. 内容安全策略(Content-Security Policy, CSP):

   CSP最早是为了解决XSS问题而引入，指示浏览器只能从哪些源加载资源（如block-all-mixed-content）；也可指示在不安全连接上强制TLS，防止任何中间人攻击（upgrade-insecure-requests）。**frame-ancestors指定可以嵌入页面的父源，而frame-src**允许指定页面中 iframe 的加载位置。

   举例：

   网站管理员希望允许 Web 应用程序的用户在他们自己的内容中包含来自任何来源的图像，但将音频或视频媒体限制为受信任的提供者，并且所有脚本仅供托管受信任代码的特定服务器使用。

   Content-Security-Policy: default-src 'self'; img-src *; media-src example.org example.net; script-src userscripts.example.com

   CSP 设计为完全向后兼容，不支持它的浏览器会忽略它，照常运行，不提供 CSP 头部的站点，浏览器同样会使用标准的同源策略。

2. http严格传输安全协议(HTTP Strict-Transport-Security,HSTS):

HSTS 是对首次使用机制的信任，它试图做的是确保：一旦你访问过网站，浏览器就知道后续交互必须使用 **HTTPS，从而减轻服务器每次转换的压力。**更改此报头可能使客户端容易受到协议降级攻击和cookie泄漏等。

3. X-Frame-Options (XFO):

用于防御客户端的点击劫持攻击，指示浏览器是否应该加载一个iframe中的页面。如果服务器响应头信息中没有X-Frame-Options，则该网站存在点击劫持攻击的可能。

4. X-Content-Type-Options:

阻止客户端MIME类型嗅探漏洞。设置其属性为nosniff，服务器指示浏览器不要嗅探任何资源的MIME类型。相反，删除报头会使应用程序容易受到内容嗅探的攻击。

1. 跨源资源共享(Cross-Origin Resource Sharing, CORS):

   CORS机制指示浏览器应认可其加载资源的源（域、方案或端口）以外的任何源，可以与access - control - allow - credentials结合使用。

2. Set-Cookie:

   Set-Cookie将要设置的Cookie项发送给客户端。下次客户端访问时，会带上该Cookie。

3. 额外的安全机制: 减轻类似于spectree和XS-Leaks等攻击。

   referrer - policy(用于控制何时发送referrer报头)，

   PermissionsPolicy (用于选择性地禁用浏览器功能，如地理位置)，

   Cross-Origin-Resource-Policy,

   cross - origin-open - policy

   Cross-Origin-Embedder-Policy

所有与安全相关的HTTP请求头：

1. Referer和Origin:

   只要浏览器能获取到请求源都会携带Referer。Referer将发送访问请求的源URL；

   只有跨域请求，或者同域时发送post请求，才会携带Origin请求头。Origin 指示了请求来自于哪个站点。该字段仅指示服务器名称，并不包含任何路径信息。

2. Fetch Metadata:

   跨站泄露攻击与跨站请求伪造(CSRF)攻击类似，是因为服务器在不知道谁发出请求(用户或脚本)、请求的来源、资源包含什么的情况下将内容传递给浏览器。为了解决“跨站泄露”的问题，W3C提出了获取“元数据请求标头”（Fetch Metadata），它包含了一组 Sec-Fetch-*
   格式的请求头，包含请求的目标对象、请求的模式等。

   Sec-Fetch-Site表明请求是否来自同一个源(same-origin)、相同的站点(不同的源，相同的站点)、完全不同的站点(跨站点)，或者由用户在地址栏中输入URL触发(none)。

   Sec-Fetch-Dest用于通知服务器所请求的资源类型。这个报头有助于服务器决定是否应该返回某个文档。

   Sec-Fetch-Mode用于特定请求的模式，例如导航通知服务器某个请求是顶级导航的结果。

   Sec-Fetch-User用于告知服务器用户操作是否导致了请求，服务器可以使用它来检测潜在的CSRF攻击。

3. upgrade-insecure-requests:

   使用加密安全连接。

浏览器扩展的安全策略、运行流程：

在使用浏览器扩展的过程中，不同身份对于安全策略的遵循结果：

• 只有开发人员少数扩展遵循“目标功能请求的最小特权原则”、“细粒度特权分离“策略。
• 一旦用户在安装时向这些扩展授予了所需的特权，就无法控制扩展如何、何时、在什么上下文中利用特权执行功能。
• 因此，具有更高权限的扩展可能对应用程序的安全性和客户端处理的敏感数据有害。

浏览器扩展的运行流程：

1. 编写：开发人员在每个扩展的清单（manifest）中定义应用程序的元数据，如他们打算在组件中使用的任何扩展API权限、浏览器API权限、Web站点的内容、目标主机配置权限等，并编写包含核心逻辑的不同后台脚本组件（称为扩展核心）。
2. 安装：在用户安装扩展程序时，用户必须授予启用扩展程序所需的所有权限。
3. 运行：扩展向允许的主机发出经过身份验证的获取请求，并在Web应用程序中执行JavaScript脚本。它作为一个单独的组件运行在一个单独的进程中。它可以访问高度特权的、功能丰富的浏览器扩展api，以执行多种功能：访问浏览器历史记录、管理已安装的扩展列表，以及根据需要启动或卸载它们，被动地拦截或主动地删除、发送或修改针对任何给定Web站点的请求（如发出跨源请求(SOP)）、直接与页面交互，修改其内容，并在后台（网页上下文中）执行脚本，除非通过CSP等安全机制禁止。

例子：

     该扩展拥有在后台拦截客户机-服务器间交换的信息的特权，它将`X-Frame-Options`报头的值从DENY更改为ALLOWALL，修改服务器不允许Framing的安全约束。

相关工作

攻击情况：

1. 由于恶意浏览器扩展程序拥有很多特权，所以它们成为了攻击的重要载体。
2. 有两种情况：①本就是带有恶意的浏览器扩展/②由于代码中的漏洞（如不安全的消息处理）而被利用，导致SOP绕过、cookie窃取或历史嗅探，由于扩展代码中的设计选择和编码错误威胁到报头完整性，无意间降低使用浏览器扩展的访问者的访问个别站点的安全性。

攻击效果：

1. 以赚钱为目的，将广告从非法来源注入到网页中。
2. 观察用户在Web上的活动，窃取敏感信息并将其发送到第三方域以创建唯一的用户配置文件。
3. 在客户端安装恶意软件，成为互联网上僵尸网络框架的一部分。

检测手段：

1. 使用动态分析和honeyypages，将改变安全相关的报头作为识别恶意浏览器扩展的特征。

   bad：修改csp通常对于实现适当的扩展功能有时是必要的，如将其代码注入到页面中。

2. 使用一种细粒度筛选过程，结合静态和动态分析技术来区分恶意扩展和良性扩展。

   bad：最初是良性的扩展，后来通过接收更新可能变成恶意的扩展，从而绕过了最初的筛选。

3. 使用污染传播技术，识别出其中2.13%的浏览器扩展泄露了私人数据。

4. 使用一种自动审查工具，在将其提交到商店之前，静态分析Firefox浏览器扩展的源代码，检测可能构成的潜在漏洞。

5. 使用基于网络的方法对安全头进行分析，其中需要进行两个请求。

   bad：可能会导致给定随机服务器响应的假阳性。

方法论

本文实现了一个自动化框架，用于检测修改请求头或响应头的浏览器扩展。

(1)有多少浏览器扩展拥有拦截或修改Web请求和响应的特权?

(2)有多少浏览器扩展有在运行时修改HTTP头的能力?

(3)它们中有多少在各自的目标主机上主动地注入、删除或覆盖与安全相关的报头?

(4)哪些安全报头最常被这些扩展改变?这些修改是否降低了Web应用程序的客户端安全性?

(5)这种安全报头拦截的趋势和扩展之间的变化会随着时间而变化吗?

**静态分析期间：**精确地识别可能拦截客户端-服务器交换的扩展。

Part 1

1. 首先，解析所有扩展的清单（Manifest），并确认该扩展是否拥有更改HTTP报头所需的权限。例如：一个运行时同步地拦截和修改请求和响应标头的浏览器扩展，必将同时拥有webRequest和webRequestBlocking权限。如果浏览器扩展未请求这样的权限，则丢弃。
2. 然后，解析后台脚本（Scripts），以定位在源代码级别拦截报头的api，识别触发浏览器扩展的核心逻辑的主机，从每个选定的扩展中收集浏览器扩展所拥有的主机权限。

💡 如何得知扩展所拥有的主机权限：

（1） 从扩展的Manifest中所有目标主机入手，如列出具体url：http://www.example.org，或包含通配符的url：http://*.example.org （*example.com的所有子域）。*由于我们的静态分析器是轻量级的，它只从webRequest api的参数中提取URL字面量，而不解析指针。

（2） 但是，大多数扩展会列出http:////或https:///，表示域不可知。这种情况下，框架无法从扩展程序清单(Manifest)或后台脚本代码(Scripts)这两个来源中提取出目标主机，则会进一步查找 Tranco Top 100 域名列表，以确保能够获取足够的主机列表来进行头部分析。

（3） 还有一部分扩展虽然在Manifest中声明的是<all_urls>，但是会通过在webRequest API定义中指定拦截具体主机的报头；或在Manifest中指定额外的主机；或在代码执行操作中执行域检查。这种例外情况可以见下表。

💡 静态分析器的优势：
动态分析方法通常只能捕获在测试期间生成的 HTTP 请求流量，而不能捕获到所有与浏览器相关的网络流量。因此，如果我们发现某个扩展程序包含特定api的定义，但是动态分析方法未能捕获该扩展程序正在拦截的 HTTP 请求流量，那么我们可以在后续的分析中再次检查该扩展程序，以确保它不会对用户的隐私和安全造成威胁。

Part 2 扩展程序核心重写

• 处理提取的主机：

  框架用有效的通配符替换通配符，并存储它们以进行动态分析。例如：

  

  被转换成http://www.sub.foo.com。但在某些情况下，这种转换可能出错，例如，
  不会产生有效的URL。

• 重写浏览器扩展核心脚本：

  这一步，自动化框架会对识别出来的所有具有足够特权来修改HTTP头的扩展程序进行**插装。**即：通过修改扩展程序的核心逻辑代码，覆盖扩展程序使用到的相应webRequest API的本地定义，在保留原始功能的同时，添加一个额外的头捕获机制（“钩子”功能）。最后，自动化框架运行扩展程序，以收集扩展程序的行为信息，包括拦截和记录webRequest API调用的信息，检测浏览器扩展程序对HTTP请求头的修改，并评估这些修改的安全性。

• 优点：

  1. 在一次运行中记录api的扩展执行前后的头信息，不会因为服务器端的随机性或竞争条件而出现误报。
  2. 可以避免代码混淆的影响，因为我们钩子会修改HTTP头的本地api。

• 例子：onHeadersReceived的插装

  下面这段代码的作用是在浏览器扩展中对特定的API（webRequest）进行修改，以便收集HTTP请求和响应标头的信息。

  

• 一些细节问题：

  1. 过滤掉“use strict”和非ascii字符，因为它们可能会干扰本文“API钩子”的执行；

  2. 修改了由浏览器扩展定义的CSP，使得自动化框架所需的XMLHttpRequest能够收集报头数据(附录A)。这样可以克服目标域名不可达、某些扩展程序只对特定的通配符主机进行修改等问题。

  3. 在运行初始实验时，发现自动化框架并没有按照预想捕获被挂钩事件侦听器的调用，经过进一步调查，他们发现了以下几类原因：

     (i) 许多目标域名从某些地理位置无法到达。
     (ii) 有些目标域（或客户端）在HTTP请求中并不总是返回完整的报头集，甚至可能在每次请求时都返回不同的一组报头。这可能导致自动化框架无法捕获所有请求所包含的报头。因此，在这种情况下，我们需要在实现中考虑这种不确定性，并且不能依赖于任何特定的报头集。
     (iii) 有的扩展使用了作者框架无法解析的通配符主机（如*😕///*.pdf）

     (iv)有一些浏览器扩展程序请求使用activeTab特权，它可以允许扩展修改当前浏览器中的任何活动选项卡上的标题，甚至绕过扩展程序在Manifest文件中声明的主机。这相当于all_urls，但使用activeTab需要在运行时进行用户干预，即用户必须允许扩展程序在当前活动选项卡上加载并操作任何主机。一旦允许，扩展程序将继续操作，直到页面关闭或用户导航到任何不同的原点。我们需要依赖于扩展程序的重写来自动分析此类扩展。因此，我们会标记这些扩展程序，单独安排修改后的扩展在我们的测试域中运行。

动态分析期间：

Part 3 动态分析&报头收集

1. 我们使用自动化框架puppeteer，为每个扩展启动浏览器实例，并访问每个目标主机(URL)。
2. 它在页面加载后停留在页面上6秒，以记录客户机-服务器通信，将在运行时捕获的原始和修改的报头集合存储到日志服务器上。
3. 然后，分析扩展程序所做的修改，并进一步将这些修改标记为良性修改或具有潜在危险性的修改。
4. 在每次访问页面之后、访问其他URL之前，清除缓存，避免让缓存中更改的头文件影响对下一个扩展程序的分析。

Part 4 检测潜在的有害扩展

• 在捕获了扩展在运行时的行为之后，我们使用自动化框架分析原始的头文件和修改后的对应文件之间的差异。如果服务器在一个响应中发送了同一个报头的多个实例，或者一个报头包含多个逗号分隔的值，框架将给定报头的所有不同值分组在一个序列化结构中，并相应地进行比较。框架检测到被修改、注入和删除的内容后，根据下述规则，报告扩展进行修改是良性或可疑的。

  （1）如果扩展修改X-Frame-Options报头以强制执行服务器发送策略的宽松版本时，（如将DENY替换为ALLOWALL），框架会识别该更改并将扩展标记为modifiedHeader。

  （2）如果一个扩展添加了任何不存在ground truth头的安全头，分析器将该扩展标记为injectedHeader。

  （3）如果任何ground-truth安全头被删除或替换为空字符串，则标记为strippedHeader。

实验 - 对chrome浏览器扩展程序的分析

本文进行了一项大规模的分析。

**数据源：**2020年6月（186,434个）、2021年2月（174,355个）、2022年1月（180,361个）可下载的CHROME扩展。

**注：**有109,311个重复的扩展，其中92,441个扩展在三次快照里无更新。

自动化框架的流程：

1. 提取CRX包→186434，过滤掉其中无效的CRX包。→166932
2. 检查请求webRequest特权的扩展程序→17536，及进一步请求webRequestBlocking特权的扩展程序→14821。
3. 过滤不存在的扩展/不存在有意义脚本和页面的扩展，剩下的扩展拥有在运行时同步拦截和修改HTTP报头的特权。→14052
4. 向扩展程序核心脚本注入覆盖webRequest api的钩子，从中提取主机url，并在源代码级别确定相关api的使用情况。→3049 根据静态分析，这些扩展程序进行了报头拦截。
5. 更进一步，基于它们的目标主机分类，（即它们是在所有主机上操作还是在特定的一组主机上操作），发现大多数扩展都可以对all_urls进行操作。

钩子注入

• 动态分析期间，钩子成功地注入到99%的扩展中，并无错误地执行功能。另外1%的（26个）扩展在运行时无法加载的原因是扩展中本来就有语法错误。
• 2020-2022年，分别有9,842、5,172和5,031个扩展为不同的webRequest api注册了至少一个事件监听器。但是，我们只关注webRequest、webRequestBlock两个相关api。我们发现分别有2735、2785和2713个扩展为上面提到的两个api中的任何一个注册了一个事件监听器。这个数字远低于表1中静态分析的数字。我们手动采样了JavaScript代码中包含调用的扩展，但是我们的分析并没有触发这些扩展，发现差异主要来自于只在特定条件下（如用户配置）注册这些事件处理程序的扩展。

实验结果

• 在对安全头（security headers）的研究中，三个数据集中共有1,129个扩展程序修改了≥1个安全头，发其中867个扩展程序会篡改服务器发出的安全头，315个扩展程序会篡改客户端发出的安全头，而53个扩展程序则同时修改了服务器和客户端发送的安全头。此外，还发现有94个扩展程序仅在测试域名上修改安全头，这表明了第3.3节中讨论的重写（rewriting）的必要性。94个扩展程序中，10个扩展程序使用了activeTab权限，其余扩展程序由于在测试过程中无法访问目标主机而无法确定其具体影响。这段数据的后续内容会对最常见的安全头及其修改进行概述。

4.3.1 响应头

（1）XFO和CSP是每个组受影响最大的服务器发送的安全头。

因为扩展经常尝试在框架中加载内容或将脚本注入页面，这两种操作分别通过XFO和CSP变得更加复杂(或不可能)，所以经常被更改。

• XFO（X-Frame-Options）:绝大多数网站仍然依赖XFO实现帧控制（而非通过CSP）。

  Chrome只支持XFO的SAMEORIGIN和DENY 两种值。删除报头或设置为不支持的值并不会带来影响。

  Dark Mode for Chrome (50万+安装量)对所有域名都删除XFO报头。

  Eno® from Capital One(60万+安装量)对amazon.com删除XFO报头。

  WhatsApp Web的Notifier(40万+安装量)在whatsapp.com上删除XFO报头。

  虽然这可能是扩展顺利运行所必需的，但排名靠前的扩展的描述都没有提到对点击劫持攻击的防护护。

  我们进一步分析了2022年在不同域上修改XFO的17个扩展，发现它们都放松了原来的策略，要么设置为“ALLOWALL”，要么设置为基本上被浏览器丢弃的值。3/17还将“DENY”替换为“sameorigin”。6/17的扩展在所有域上显示此行为。安装删除了XFO的扩展的次数为5,372,019+。

• CSP：

  表4为3个数据集中前10个注入、删除和修改最多的10个CSP相关指令。

• 注：本文假定如果一个扩展（如NoScript）删除整个CSP头部，则会将原始CSP中的每个指令都视为隐含删除，因为删除整个头部会破坏原始策略中每个指令的控制。
• 重要研究发现：
  • 共计205个扩展删除整个CSP头，其中68个扩展在三个数据集都有。
  • 几乎所有的CSP指令都被（≥1个扩展程序）注入过。
  • 与XSS缓解相关的指令（即script-src和default-src）被至少274和263个扩展在至少一个域上删除。
  • 一般的扩展程序改变/注入/删除对于各个网站都是无差别的，但有的script-src指令根据Web服务器发送的内容修改值。
  • 超过80个扩展只是将原始指令的值替换为空字符串。
  • 放弃CSP的扩展总共至少有1 3279,417个安装量，而那些只修改CSP的扩展总共有3,202,903个安装量。
  • 2020年版本的Fair AdBlocker（安装量超过100万）将谷歌、eBay和许多其他公司的CSP头全部删除，2021年版本已经不再删除CSP标头；
  • HIRETUAL(安装量3万+)，它在Twitter、Facebook、谷歌和其他平台上发布csp。这个工具旨在帮助招聘人员获取联系信息，它还会删除X-Frame-Options报头，破坏所有目标站点的安全性。

（2）CORS的 access - control - allow - origin（跨域资源共享）

• CORS是一种浏览器机制，允许Web页面从不同的域（例如，协议、主机和端口）请求资源。为了保护用户的数据安全，CORS要求在允许跨域请求的同时，必须设置正确的Access-Control-Allow-Credentials和Access-Control-Allow-Origin标头。
• 然而，如果Access-Control-Allow-Origin标头被设置为通配符*，而Access-Control-Allow-Credentials被设置为true，则CORS不再安全，因为攻击者可以利用这个漏洞访问用户本地网络中的设备，如路由器。这是因为：许多浏览器插件在每个响应中都会注入一个带有*的Access-Control-Allow-Origin标头，从而打开了这个漏洞。
• 其中最受欢迎的插件之一是Video Downloader Plus，其安装量超过800K。Flexible Access Helper插件则是唯一正确设置Access-Control-Allow-Credentials和Access-Control-Allow-Origin标头的插件。

（3）X-CTO和HSTS在所有组中分别只受到13个和15个扩展的干扰。

（4）**Referrer-Policy：**只有8个扩展的变更。

（5）Permissions-Policy、COOP、COEP、CORP都不是特别受欢迎的篡改目标，因为它们在实践中很少使用。

（6）Set-Cookie: 有31个浏览器插件修改了Cookie的安全属性。

• SameSite标志是用于保护用户免受CSRF（跨站请求伪造）攻击的一种cookie安全属性。许多浏览器插件修改SameSite标志的值，其中一些插件甚至移除了所有cookie的CSP和XFO安全标志，并将所有cookie的SameSite标志设置为None，这实际上禁用了SameSite的保护机制。
• 一个例子是HiFrame插件，它允许任何页面在iframe中加载。该插件只有大约500个用户使用，但它会将所有cookie的SameSite标志设置为None，并添加了Secure标志，禁用了SameSite保护机制。但它在简介中声称自己“即插即用，风险极小”。
• 另一个例子是DuckDuckGo Privacy Essentials插件，该插件阻止所有尝试设置cookie，而Multi Chat - Messenger for Whatsapp插件则将SameSite标志设置为None。总共，至少有5,120,425个用户使用了这些浏览器插件。这些插件的行为可能会影响用户的安全和隐私。

（7）Strict-Transport-Security（STS）

Strict-Transport-Security头用于防止中间人攻击（Man-in-the-Middle，MITM）和SSL剥离攻击（SSL Stripping）。15个浏览器插件会修改HSTS头，其中Multi Chat - Messenger for Whatsapp插件是其中之一。这些插件中的大部分都会在所有页面加载时随意地移除HSTS头。

总体来说，HSTS并不是一个受欢迎的目标，这并不令人感到意外，因为强制使用HTTPS连接通常不会妨碍扩展程序的必需品（如加载跨域资源，在iframe中呈现页面或向页面注入CSP脚本）。然而，目前可用的扩展程序的用户基数仍然相当大，超过153,199个安装。

4.3.2 请求头

共有315个扩展干扰了任何给定的安全头。大多数更改分别发生在Origin和Referer头上。这在最近的扩展(即2020年之后)中更为明显，其中25%的扩展篡改了这些头文件。

• Origin/Referrer

  • Pure motion插件在请求向受支持的视频平台（如Dailymotion）发送请求时，会注入伪造的Origin和Referer头部，从而使得这些平台易受到攻击。
  • Dictionary all over with Synonyms插件则会删除Referer，但由于服务端检查可以基于Origin做出安全决策，所以对安全性影响不大。
  • CyDec Platform Anti-Fingerprinting插件则会随机化Referer，这可能会影响基于Referer进行安全检查的功能。

• Fetch Metadata

  Fetch Metadata规范相对较新，因此没有预期会有很多扩展程序对其进行修改。然而，一些较新的扩展程序会更加积极地修改这些头部信息，例如在2021和2022年期间发现了15个扩展程序修改了Sec-Fetch-Dest。其中，安装量最高的是Find website used fonts插件（7000+），该插件不仅将将dest从iframe设置为main，从而伪造一个实际框架页面的顶级加载，而且还修改了Sec-Fetch-Site报头，将其设置为none(用户通过输入新URL调用顶级导航时使用的值)。这显然破坏了Fetch Metadata的安全目标，因为它假装发出用户调用的请求。

Chrome扩展的演变

• 对三个Chrome扩展程序数据集的研究：在19个月内的演变进行了调查。其中647个扩展程序在2020年干扰了任何安全标头，但有143个在2021年停止了这样做。其中，115个被从商店中删除，8个降低了权限，25个仍具有这些能力，但在自动化测试中没有使用。同样的趋势也出现在2021年的数据集中，其中177个扩展程序在2022年停止了干扰标头。在406个干扰所有三个数据集中标头的扩展程序中，55个完全没有改变。另外还涉及到一些扩展程序改变了他们修改标头的方式。同时，还有大量的扩展程序从商店中被删除或降低了权限。
• 他们从2021数据集中随机抽取了20个插件进行分析，发现其中大多数（17/20）是来自同一个供应商的壁纸插件，可能是导致Chrome插件安全问题的原因。另外，他们发现只有极少数（30/7,466）从被删除的插件中被列为恶意，大多数插件是良性的。此外，研究者还发现了一些在2021或2022数据集中开始修改安全头的插件，并对这些插件进行了分析。他们发现，14.4％和16.3％的新插件在2021和2022年时使用了修改安全头的权限，而在2020数据集中，只有4.6％的插件使用了这些能力。

……

后续反馈

披露+开发人员的回答：

最好的是-承认我们的报告和修改安全头文件的潜在威胁，并声称要么撤下扩展，要么修复问题

人工分析：

• 我们发现其中44个基于它们所提供的描述来实现功能，包括注入脚本和资源来突出显示文本，解决验证码，并为第三方域(如维基百科)提供其他基于文本的引用等。

• 一些更改也不一定会降低客户端安全性，就像NoScript, AdBlocker和其他隐私保护扩展一样。

• 实验发现，大多数扩展会修改这些头部，从而降低了安全限制，但有些扩展也会试图通过修改或注入相关头部来增强安全性。但是，如果安全策略配置不当，如CSP和CORS头，仍可能导致致命后果。总之，这些修改的实际影响可能因应用程序而异，取决于头部在请求处理中的作用以及其它指令和取代值的具体影响。

• 我们研究的是Google Chrome 浏览器，之后也研究了Firefox浏览器，以及其他的浏览器都是相似的结论。

• 即使安装量超过100万的流行扩展也存在此类问题，用户应该充分了解潜在风险。

• 自动化框架的局限性：

  1. 钩子不能注入后台脚本中包含的任何外部脚本。
  1. 本文没有创建honeyPage或模拟用户交互来捕获差异。

  我们的分析只揭示了那些在没有任何用户干预的情况下改变安全头的扩展，触发不了一些恶意扩展，因此我们的结果是破坏安全性的扩展问题严重性的下界。且当操作隐藏在触发条件后面时，我们的动态分析是有限的。

改进：

• 依旧是建议**“最小特权策略”**：虽然大多数这些扩展在某种意义上是出于良性的原因更改头文件，但这些更改通常是极端的，或者可以在不降低安全性的情况下避免。例如，打算从单个远程位置注入脚本的扩展不应该删除整个CSP报头(在许多情况下都是这样)，而是应该对原始策略进行最少的更改。类似地，如果一个扩展打算只在特定的主机上操作，比如社交媒体平台，它应该只限制其操作到这些主机，而不是all_urls。例如，Loop11用户测试在其描述中声明-“Loop11扩展将处于休眠状态，只有在您选择参加的可用性测试期间才会激活”。然而，情况并非如此，因为当激活时，它会改变所有页面的标题。
• 被破坏的安全性不会对开发人员产生不利影响，而会会对用户基础造成不利影响。例如，在所有域上安装了CSP的扩展的用户在使用Internet银行或其他重要Web站点时可能会面临严重的风险。因此，必须明确告知用户这些风险。这可以通过将我们的自动化框架合并到扩展审查过程中来实现，并在发现特定的更改时自动向扩展存储中的概述页面添加警告。这些建议给用户带来了负担，并要求他们了解一些技术。然而，这将激励开发人员进行最小的更改，探索替代方案，并防止用户出现“警告疲劳”。