利用Script Gadget进行CSP绕过

作为现代社会的核心技术之一，Web深刻地改变了人与人和数据交互的方式。 Web上最严重的攻击之一是跨站点脚本（XSS），攻击者可以在该脚本中将其恶意JavaScript代码注入Web应用程序，从而使该代码可以完全访问受害站点。为了减轻造成XSS的标记注入缺陷的影响，现在所有浏览器中都提供了对内容安全策略（CSP）的支持。部署这种策略使Web开发人员可以将可从其加载脚本代码的白名单列入白名单，从而实质上限制了攻击者仅能够执行从所述白名单中注入的代码的能力。在存在所谓的脚本小工具（script gadget）的情况下，注入脚本标记并不是成功攻击的必要先决条件。这些小的JavaScript代码片段将页面中包含的非脚本标记转换为可执行的JavaScript，从而为绕过部署的CSP打开了大门。特别是结合CSP处理重定向资源的逻辑，脚本小工具使攻击者可以绕过否则会采取的安全策略。

在本文中提出一个问题：在没有先验知识的情况下，即使没有部分信任的源托管的所有文件也可以安全地部署CSP吗？为了回答这个问题进行了调查，显示了真实的网站即使在存在CSP且开发人员未添加包含此类小工具的代码的情况下，攻击者也可以将已知脚本小工具加载到库中 ，只要托管站点已在CSP中列入白名单。结合用于重定向的CSP匹配逻辑，能够绕过10％的其他原本安全的策略。为了进一步回答研究问题，进行了假设的what-if分析。通过这样，可以自动为所有前10,000个站点生成明智的CSP，并表明由于严重依赖同样托管此类库的第三方，因此仍有大约三分之一的站点仍然容易受到脚本小工具旁加载的影响。

0x01 Introduction

在当今社会，网络已成为日常生活的重要组成部分。它不仅已发展成为一个能够通过社交媒体与朋友保持联系的平台，而且更重要的是，它已转变为一个成熟的应用程序生态系统，甚至可以托管复杂的应用程序。鉴于这种日益增长的重要性，任何特定于Web的威胁都在威胁精巧数据的安全性。最严重的威胁之一就是所谓的跨站点脚本（XSS）漏洞。这些漏洞使攻击者可以在有漏洞的网站的上下文中执行JS代码，从而从根本上使攻击者的代码可以执行站点自己的JS可以执行的任何操作。这使攻击者能够窃取受害者的凭据，泄露敏感信息或代表受害者执行操作。因此，XSS可能会造成严重损坏，尤其是在安全性至关重要的应用程序中。为了减轻此漏洞的影响，开发人员可以使用内容安全策略（CSP）。由于XSS意味着开发人员不需要的代码在其应用程序中执行，CSP遵循了开发人员预代码的白名单方法。特别是，开发人员可以提供允许在Web应用程序的上下文中加载并因此执行的脚本资源的白名单。

值得注意的是，尽管有几篇论文显示了站点运营商无法以安全的方式部署CSP ，但仍存在一个新的威胁：Script Gadget。将脚本小工具配成JS代码片段，这些片段会将非脚本数据转换为执行代码。因此，这些片段（通常包含在AngularJS等广泛使用的库中）使攻击者能够利用应用程序中的注入漏洞，而无需注入实际的脚本有效载荷。由于非脚本数据不受CSP控制，因此这使攻击者可以在存在脚本小工具的情况下成功利用注入漏洞。为了利用脚本小工具，需要将包含库加载到站点中，或者将包含此类库的主机列入白名单。在野发现的56％不同策略可能会通过白名单中的小工具托管网站被如绕过，仅存在包含标记为AngularJS的库的主机不足以成功利用漏洞。

由于CSP是针对XSS注入的最后一道防线，因此假设部署CSP的站点可能容易受到XSS的攻击。因此模拟了一个注入漏洞，并将小工具库与非脚本有效负载组合在一起，将其旁加载到目标应用程序中。仅在可以触发利用之后，才将站点标记为易于通过脚本小工具旁加载进行绕过。这样一来发现只有248个使用合理CSP的站点，而29个站点包含指向AngularJS托管站点的白名单条目，只有24个（9.6％）可以通过脚本小工具旁加载来绕过。重要的是，尽管以有意义的安全方式部署CSP的站点集很小，但是从一开始，通过脚本小工具来绕过其策略的过程就凸显了依靠第三方来建立策略的沉重负担。

先前的工作提出了根据站点功能所需的脚本通过自动化工具部署CSP的功能。为了了解脚本小工具严重损害此类工具生成功能性且安全的CSP的能力，从第二个角度研究了脚本小工具的问题：对前10,000个网站的假设what-if分析。为此，基于这些站点所使用的JS源生成了CSP，并表明仅由于它们依赖第三方主机才能通过旁加载的脚本小工具成功攻击这些应用程序的三分之一以上。更糟的是，为避免路径信息跨源泄露，如果加载的资源是重定向的结果，则CSP的匹配算法将忽略源表达式的路径成分。因此，即使开发人员没有将整个源域列入白名单，而只是将特定脚本列入白名单，但如果至少有一个列入白名单的源遭受了开放重定向，仍然可以加载选择的库。值得注意的是，属于10,000个最常用网站的一部分或这些网站加载的资源的114个不同域都受到此漏洞的影响。

0x02 Technical Background

本节描述了这项工作中使用的各种技术。特别是概述了跨站点脚本，CSP作为缓解攻击的手段，以及脚本小工具和开放式重定向的概念。

A.跨站脚本

在Web上，包含来自第三方页面的内容很常见：从广告到地图服务，各种各样的内容都是通过框架加载到应用程序中的。如果没有分离机制，那么包含来自不同源的内容将带来严重的安全后果。因此，同源策略（简称“ SOP”）是Web上最基本的安全性机制，可确保只有来自同一Web源的文档才能相互访问。这意味着在给定文档中运行的所有JavaScript仅在其协议，主机名和端口匹配时才能访问其他文档的内容。因此，要获得对另一个文档内容的访问权限，攻击者的代码必须运行相同的源。例如，通过目标应用程序中的代码注入漏洞。这种攻击称为跨站点脚本（XSS），因为攻击者可以将代码注入另一个站点。因此，恶意代码可以执行合法代码可以执行的任何操作，例如根据攻击者的喜好修改页面，泄露敏感信息（例如会话cookie）或以受害用户的名义执行任何操作。

B.内容安全策略

如前所述，XSS可能会对Web应用程序造成巨大破坏。为了减轻这种意外的JavaScript代码执行的影响，引入了内容安全策略（简称CSP）。可以通过HTTP标头或元元素来部署这种策略，该HTTP标头或元元素由以分号分隔的多个指令组成。每个指令名称后面都有源表达式的列表。这些表达式表示可以包含指令名称定义的类型的资源的源。例如，要仅允许Google Analytics（分析）和自托管（即源于同一源）的代码作为允许的脚本源，并限制其他任何资源（例如，对象，框架，媒体）的加载，可以使用以下策略：

无论何时指定script-src或default-src（作为后备），CSP都禁止使用内联脚本，事件处理程序和执行字符串到代码转换的函数。但是，可以通过在指令中添加“ insafe-inline”或“unsafe-eval”来放宽这些限制。在2012年的原始候选推荐中，CSP仅支持将主机名和URL列入白名单。后来，在CSP Level 2中，解决了Level 1的这种灵活性，尤其是在内联脚本和事件处理程序方面。为了使它们更容易列入白名单，该标准在白名单脚本中增加了对哈希和随机数的支持。通过使用哈希，开发人员可以通过将脚本代码的SHA哈希添加到script-src指令来显式地将内联脚本列入白名单。或者，当出现随机数时，会将带有该随机数作为属性的所有脚本（内联脚本和外部脚本）都列入白名单。

使用仅包含哈希的白名单将使那些列入白名单的脚本无法添加额外的脚本资源。对于随机数，理论上脚本可以读取其自己的随机数，并且在添加新脚本时，将所述随机数附加到它们上。不过，值得注意的是，当前的W3C工作草案（CSP Level 3）添加了一项功能来解决此问题，尤其是“strict-dynamic”。部署此表达式后，通过nonce或hash列入白名单的任何脚本都可以以编程方式（即使用createElement和append Child，而不是document.write）添加其他脚本。这使列入白名单的脚本能够传播放入其中的信任。

此外，“strict-dynamic”会禁用所有基于主机的白名单。由于只能使用散列或随机数进行部署，因此“strict-dynamic”也意味着“不安全的内联”无效，因为在存在散列或随机数的情况下将忽略此操作。不过，值得注意的是，对“strict-dynamic”的支持是有限的，Safari或Microsoft Edge目前尚不支持。CSP可以在重定向资源时利用其泄露敏感路径信息，CSP 2级采用了宽松的路径匹配方案。特别是，假定以下CSP：

在这种情况下，该策略仅将cdn.com中的单个脚本列入白名单。但是，假设redirect.com包含一个URL，而不是传递实际内容，而只是向浏览器发送了30倍的重定向，CSP的匹配算法将忽略白名单中任何条目的路径部分，以及从至少一个资源被列入白名单的任何源中包含的低级脚本。在此示例中，这将使攻击者可以包含来自https://redir.com?target=https://cdn.com/vulnerable.js 的脚本。因此，如果列入白名单的元素包含重定向，而目标在攻击者的控制之下，则CSP的限制功能会部分削弱。

C.脚本小工具

没有必要将带有JS代码的恶意标记直接注入网站以执行XSS攻击。取而代之的是，可以使用合法的JS代码片段（称为脚本小工具）来注入或执行恶意有效负载。上图显示了这样一个脚本小工具的示例。代码遍历所有按钮（第1行和第2行），提取属性数据文本，并设置相应按钮的innerHTML属性。因此，攻击者可以仅添加下图中所示的按钮，而不必注入脚本标签。如果将其注入页面本身，则由于data-text属性没有特殊含义，因此不能将其作为JavaScript执行，这需要评估作为HTML标记。但是，当脚本小工具访问该属性并设置innerHTML属性时，将执行攻击者的代码。

对于本文工作而言，重要的是脚本小工具能够绕过现有的CSP限制。在简化示例中，攻击者的代码（由小工具编写）包含在事件处理程序中，如果在没有“不安全内联”的情况下部署CSP，则不会执行该代码。而且编写脚本标签也无济于事，因为根据HTML规范，分配innerHTML不会执行任何脚本标签。

为了了解此类小工具对CSP的影响，如上图所示是一个使用jQuery的稍微复杂一点的示例。假设脚本是通过随机数列入白名单的，并且使用了strict-dynamic。值得注意的是，jQuery中的html函数实际上不仅仅是innerHTML的包装。特别是，如果在传递给函数的HTML中检测到脚本元素，则这些脚本元素将传递给eval（对于内联脚本而言），或者导致以编程方式添加到文档中（对于外部脚本）。因此，尽管CSP将阻止浏览器直接加载攻击者的注入脚本，但脚本小工具将解析该脚本，然后通过createElement和appendChild将其添加到DOM中。由于此脚本是随机的，并且使用了““strict-dynamic”脚本，因此浏览器现在将加载并执行攻击者的代码。

D.开放式重定向

HTTP重定向是一个URL到另一个URL的自动重定向，通常由3xx HTTP状态代码指示。如果原始服务器正在维护中，URL的这种重定向可以例如用于将请求临时重定向到另一台服务器。为了创建一种更动态的重定向到其他页面的方式，目标URL可以通过如下所示的HTTP参数来指定：

但是，如果未在服务器端正确验证重定向的目标，则攻击者可以使用它来导致重定向到任意目标。一般来说，这可以用来诱使用户隐藏实际的内容源。例如，攻击者可能在网络钓鱼活动中使用开放重定向，因为用户只能在单击URL（指向看似良性的网站）之前检查URL，而不能在重定向发生之后（指向攻击者的页面）检查URL。在用例中，与CSP结合使用时，这种开放式重定向尤其成问题，因为CSP的白名单源匹配算法会在重定向加载资源时忽略任何路径。

0x03 Attacker Model & Research Questions

A.威胁模型

在这项工作中，研究可以通过在旁加载来自白名单各方的脚本小工具的库来在多大程度上绕过CSP。因此，假设一个网站使用的CSP不能轻易绕过，以减轻标记注入的影响。在此CSP中，script-src指令已将该网站的所有必需JavaScript源列入白名单，其中包括一个脚本丰富的第三方域（例如CDN），该域还托管一个包含脚本小工具的库,不认为网站本身必须使用此库。但是，确实假定此站点遭受了标记注入漏洞，从而使攻击者可以在应用程序中插入任意标记。绕过CSP的实际攻击分为以下步骤，如下图所示：

（1）攻击者利用标记注入将攻击者有效负载添加到网站。此有效负载包括两部分：首先，一个脚本标签指向一个包含由白名单方（例如AngularJS）托管的脚本小工具的库。其次，一段本身不会被执行的标记（例如，前面讨论过的按钮）。

（2）注入的脚本标签将包含小工具的库加载到网站中。 CSP不会进行干预，因为托管脚本的第三方被列入了受信任的脚本源白名单，这意味着该库已添加到站点的执行上下文中。

（3）现在网站上已经存在脚本小工具，注入的有效负载的第二部分触发了该小工具来执行攻击者的恶意JavaScript代码。

除了直接从列入白名单的主机中加载此类小工具库之外，还考虑开放重定向的情况。如前所述，当发生重定向时，CSP的匹配规则不再考虑资源的路径。因此，假设一个站点需要一个站点的某些资源，该站点也承载带有小工具的库，但是通过其完整URL明确地将这些脚本列入白名单，则具有开放重定向的单个列入白名单的主机就可以绕过。在这种情况下，攻击者将注入指向打开的重定向站点的脚本标签，将重定向目标指向小工具库。然后，CSP会检查该库的主机是否包含在任何白名单条目中，并加载脚本。

因此，如果任何列入白名单的源都存在开放重定向重定向漏洞，尽管只有来自该小工具源的另一个脚本被列入了白名单，但仍可以通过此重定向来加载该小工具。

B.研究问题与目标

该工作重点的主要研究问题是：脚本小工具如何严重削弱站点运营商部署安全CSP的能力？如果所有网站都将部署限制脚本源的CSP，那么这个问题可以分为现实应用程序中绕过的有效性以及理论上的可利用性。为了回答这个问题，需要达成一些中间目标。为了使用脚本小工具实际绕过策略，必须知道托管相应库的源，以便可以将它们旁加载到目标网站中。通过收集这些资源，可以确定有多少个不同的站点托管带有脚本小工具的库。为了进一步提高攻击的效率，需要学习开放式重定向URL。有了这些漏洞，可以利用基于重定向的路径松弛攻击来仍然加载脚本小工具，尽管该源仅被白名单作为指向同一域中其他脚本的URL。实际应用程序中开放重定向的集合能够确定这些重定向可用于多大程度的旁路。

将研究重点放在那些不能轻易绕过的CSP上，这使本研究能够理解脚本小工具和开放重定向如何仍然会破坏Web上的许多安全策略。因此，首先需要定义如何设计旨在限制脚本内容的策略，以使其有效运行。通过收集现代Web应用程序中存在的CSP并根据有效性定义进行分析，可以看到有多少个网站正在使用CSP有效缓解XSS攻击。最后，假设使用合理的CSP的站点数量很少，基于从前10,000个Web站点的使用脚本源生成的CSP进行了假设分析。

0x04 Bypass Preparations

分析易受攻击的站点对旁加载脚本小工具的敏感程度的第一步是收集两个重要信息。这需要检测托管了已知脚本小工具库的URL。为此，使用自动搜寻器来调查前10,000个网站经常使用的脚本，并对每个脚本进行分类，以确定是否已知其中包含脚本小工具。除此之外，鉴于CSP标准的作者决定在重定向的情况下放宽主机匹配，因此们还需要创建一个具有开放重定向的URL列表。因此，作为爬虫设置的一部分，记录了所有网络请求，尤其着重于重定向到另一个URL的资源。随后，应用两种匹配算法来确定重定向目标是否包含在原始请求的URL中，如果是，则将该URL标记为开放重定向。

A.数据集管理

首要目标是评估有多少个站点托管着承载脚本小工具的库，并确定哪些站点允许开放式重定向。为了解决这些问题，从Tranco Top 10,000个网站列表的主页以及所有相同站点子页面中抓取了数据，该列表于2019年5月10日创建，每个站点最多具有1,000个不同的URL。要访问这些页面，利用Google的浏览器工具框架puppeteer对Chromium Web浏览器进行工具化。在每次访问页面期间，爬虫都会拦截每个HTTP响应，而与内容类型无关。如果这样的响应是重定向的结果，将检查触发重定向的URL是否在参数之一中提到了其目标。在这里不仅考虑了完整的URL，还考虑了存在的域，路径或它们的base64编码等效项。一旦其中之一出现在网址中，就会将其替换为GoogleAPIs托管的脚本的网址。然后请求带有新目标的URL，并检查响应是否与此脚本匹配。如果是这样，认为此重定向是开放的，因此攻击者可控。

在此过程中还将捕获重定向的整个链，因为每个重定向都会导致发出额外的请求。另外，如果内容类型与JavaScript有关，并且响应中包含请求的脚本的实际源代码，则使用Retire.js来调查此JavaScript代码是否包含已知的框架或库。决定使用Retire.js，因为与其他用于分析JS库的应用程序（例如Wappalyzer）相比，它是免费的，可以在不依赖（可能受速率限制的）API的情况下在本地进行检测，并且易于嵌入在爬虫的基础架构中。使用此信息，在主机和公共可用的库或框架之间创建映射，这些映射包含主机提供的脚本小工具以及在其执行上下文中使用这些库的域。可以看到这些库的用法和托管在野有多么普遍。稍后，可以在旁路生成中重用此数据集，以从旁加载包含列入白名单源的库的脚本小工具。

使用收集的重定向，然后研究重定向URL中的哪些查询参数确定了重定向的目标。因此，在触发重定向的URL的查询参数中搜索目标URL或其等效的base64编码。如果匹配，则将该URL的对应部分更改为选择的脚本源。为了验证找到的重定向是否确实是一个开放的重定向，将每个重定向URL加载到选择的新目标中。如果通过此链接成功加载了新目标，会将重定向URL存储为开放重定向。

B.脚本小工具

使用数据集，能够检测到从9,909个不同站点加载的28个不同的库。为了调查脚本小工具的普遍性，将这些库与已知包含脚本小工具的库相交。此外，研究了多少个主机包含多少个不同URL的这些库。值得注意的是，只要查询参数发生变化，就将其视为新的URL。这项调查的结果显示在下表中。考虑到包含对象通常来自前10,000个站点之外的站点，因此不同主机的数量远远高于实际爬网数据集的大小。

可以将其归因于以下事实：不仅考虑爬取的网站本身，而且还考虑这些网站使用的所有第三方。 jQuery库是迄今为止最常用的库，其中包含特定版本的脚本小工具。但是，来自jQuery的小工具只能使攻击者绕过CSP中的strict-dynamic，并且绕过多个XSS筛选器，而不能绕过基于主机的CSP白名单。此外，如果没有使用攻击者控制的输入显示调用jQuery函数，就无法触发jQuery中的脚本小工具。第二个最常用的小工具库Bootstrap也仅包含用于绕过strict-dynamic过滤器和XSS过滤器的小工具。但是，第三个条目AngularJS托管在947个不同站点上，其脚本小工具能够绕过基于CSP主机的白名单并执行有效负载，而无需其他先决条件。其他能够绕过基于主机的白名单的脚本小工具库是AureliaJS和PolymerJS。但是，在数据集中未发现它们的任何出现。缺少这些库的原因是因为仅对第一级子页面进行了爬取，或者因为在某些情况下Retire.js未能正确地对库进行分类，因为Web开发人员已自定义了它们的版本。

除了以这种方式发现的库之外，还用AngularJS的3个公共已知资源列表扩充了数据集。检查了此列表，以确保所有列出的URL仍托管有问题的库，以确保它们是可利用的可行目标。值得注意的是，这将gstatic.com添加到了可行的主机列表中，事实证明这是最成功的旁路启动器之一。在爬取中未发现此消息，因为似乎没有任何站点使用它（根据PublicWWW上的搜索）。

C.开放式重定向

发现来自114个不同域的4,902个URL可用作开放重定向。如上表所示，在某些域上，可以使用近500个不同的URL来执行开放式重定向。请注意，这些域不一定是前10,000 Top Tranco列表的一部分，而是这些站点用来加载资源的域。开放重定向URL数量最多的大多数顶级域是广告或分析提供商。对于CSP生成绕过来说，这一事实尤其重要，因为广告和分析脚本经常在真实的CSP中列入白名单。还调查了哪个查询参数是用于定义重定向目标的频率。因此，分析了每个经过验证的开放重定向URL，以提取占位符为值的查询参数。如上表所示，用于重定向的最主要参数是redir（1,612个不同的URL）。而且，许多URL（314）直接将目标用作参数，而不是指定用于定义目标值的关键字。使用此常用查询参数列表，可以使用自定义搜索查询（例如Google Dorks）来查找开放的重定向漏洞，而无需爬网数千个网站。

0x05 Real-World Impact

在通过指向已知脚本小工具库的两个URL以及打开的重定向列表收集了真实数据之后，现在转向主要研究问题，即脚本小工具旁加载对CSP的影响的严重性。为了实现这一目标，首先将Web应用程序发送的CSP收集到了前10,000个列表中。基于针对脚本内容限制的有意义的安全策略的概念，然后评估了由于存在白名单的主机和已知脚本小工具而可能导致旁加载脚本小工具成为受害者的站点的情况。不只是简单地假设这种匹配就足够了，而是通过模拟注入缺陷建立一种在实践中确认可利用性的方法。

A.方法

为了生成可以绕过CSP的攻击，需要有关目标所使用的CSP的信息，执行有效负载的HTML标记注入，包含脚本小工具的库的URL以及可以触发脚本小工具。在某些情况下，还可以使用发现的开放重定向漏洞之一来旁加载脚本小工具库。还收集了所有CSP HTTP标头以及在目标站点上作为HTML元标记部署的所有策略。根据CSP 3级标准的解析说明来解析每个收集的策略。给定攻击者模型，该模型旨在绕过通过旁加载小工具来限制脚本内容的策略，仅考虑具有有意义的安全CSP进行内容限制的网站。特别是，认为网站具有以下政策：

（1）它使用script-src指令或default-src指令作为后备

（2）它不使用*作为通配符，它会将所有可能的脚本源列入白名单，

（3）不会将整个计划列入白名单，例如data：或https:，

（4）它不包含“ unsafe-inline”，后者允许使用内联JavaScript。

作为对基于主机的CSP脚本白名单的实际绕过，使用了存在于AngularJS库中的脚本小工具。上图显示了一个示例标记，该标记使用AngularJS中存在的脚本小工具来调用JavaScript window.alert函数，而无需注入任何脚本标签或事件处理程序。 AngularJS中的脚本小工具是允许任意代码执行的最严格的小工具之一，根据数据，AngularJS具有最佳的分布。此外，与其他小工具相比，除了存在小工具外，它没有任何先决条件。 仅将AngularJS用作脚本小工具的限制不会对可绕过性结果产生严重影响。大多数库提供程序都是CDN，如果攻击者能够从这些CDN之一中加载脚本，则将哪个可用脚本小工具库用于绕过没有区别。

使用数据集来创建托管AngularJS库的源列表。根据定义，对于每个具有安全CSP的网站，都会生成一个利用该漏洞的方法，该方法可模拟标记注入以注入脚本标签，该脚本标签从各个CSP中白名单的源之一加载AngularJS。如果网站仅将CDN中的一个特定脚本列入白名单，则利用程序生成器将使用前文所述的过程中发现的一个开放重定向漏洞，将其列入白名单中的源之一，从而使该利用程序仍然能够从以下位置加载AngularJS库： CDN。

既然网站上存在易受攻击的库，将滥用脚本小工具来执行自己的JavaScript代码。生成器模拟了标记注入，以验证绕过策略是否在野有效。为了模拟标记注入，利用puppeteer的page.evaluate函数将标记添加到网站上。重要的是，在没有AngularJS库的情况下，此标记不会导致代码执行。

B.结果

总共，能够成功访问998,712个URL。在该数据集中，从2,076个不同的网站收集了CSP。这些域中只有965个实际上使用了script-src或default-src指令。其中有248个已根据5.1节中的定义安全地完成了此操作。对于248个使用安全策略的网站，为其中29个网站生成了漏洞，利用攻击可以成功绕过其中的24个。尽管与最初抓取的数据集相比，这个数字非常低，但绕过率大约为10％，首先是针对具有紧密CSP的网站。因此，尽管该述的攻击不会影响大量网站，但确实即使是备受关注的网站也可能易于通过脚本小工具和开放重定向来绕过，这表明了不完全了解托管在第三方网站上的代码的危险派对网站。

为了了解为什么无法验证某些生成的漏洞利用程序，手动调查了这些情况。发现这可能归因于retire.js的错误分类，当仅存在Angular模块（例如angular-sanitize）时，retire.js会错误地检测到AngularJS。用于漏洞利用的大多数Angular源仅成功地绕过了一个网站。这是因为这些CDN不是公开使用的CDN，而是由特定网站（例如alicdn.com）用于aliexpress.com的CDN。但是如上表所示，某些站点由于多次将多个角度源列入白名单而易受多次旁路的影响。因此，此表中显示的数字是相交的。

AngularJS的源www.gstatic.com 能够绕过20个不同域的CSP。在为数据集中发现证据表明，至少有四个被利用的网站使用了源自www.gstatic.com 的JavaScript。在所有情况下，似乎它们仅使用gstatic来加载reCaptcha API或Chrome Cast应用程序框架。因此只能将那些特定的URL列入白名单，这样攻击者将需要另一个列入白名单的源中的开放重定向漏洞，才能真正绕过其CSP。由于直接对脚本小工具进行旁加载，在野发现的绕行都是有可能的。尽管如此，通过基于重定向的开放式旁加载（仅能禁用CSP的路径匹配），这些可利用的旁路中只有两个是可能的。因此，即使将reCaptcha与整个URL一起列入白名单，这些漏洞也将很容易受到攻击。

C.案例研究

为了更好地理解这些绕过的方式，将仔细研究两个示例，这些示例部署了看似安全的CSP，但在脚本小工具被旁加载时仍然可以被利用。在撰写本文时已通过其script-src指令通知了双方有关此问题的信息。

（1）Snapchat

首先关注snapchat.com，该服务器使用上图所示的script-src指令部署了CSP。乍一看，此脚本限制指令似乎是严格而安全的策略。该政策本身不包含“ unsafe-inline”之类的危险表达。而且，只有来自站点本身和另一方（即Google）的资源才被视为第三方脚本。但是，列入白名单的源之一是www.gstatic.com ，它使攻击者可以旁加载https://www.gstatic.com/fsn/angular_js-bundle1.js 并随后滥用AngularJS的脚本小工具来执行任意恶意有效载荷。 尽管此策略足以抵御常规类型的XSS（重要的是，列入白名单的主机不包含可用于执行代码的JSONP端点），但是Snapchat对www.gstatic.com 的信任使它们容易受到攻击;有效地使通过CSP的缓解对XSS攻击者无效。在数据收集过程中，没有发现Snapchat实际使用了gstatic.com。这可能源于以下事实：自动对网站进行了爬取，而没有将爬虫程序登录到Web应用程序中。因此，实际上只访问了可用于现实世界用户的功能的一小部分。

（2）Spotify

考虑的第二个示例是spotify.com（请参见下图）。在这里再次发现www.gstatic.com 被列入白名单，这使它更容易受到先前的攻击。假设Spotify意识到旁加载的小工具存在的问题，他们可以选择在必要的脚本（即reCaptcha API）上明确将白名单列入白名单。但是，这不足以确保这一方面免受基于脚本小工具的攻击。原因是sb.scorecardresearch.com被列入白名单。

分析表明，此主机具有开放重定向。因此，攻击者可以使用它来添加指向开放重定向的脚本资源，并确保重定向目标是gstatic.com上的Angu larJS。如前所述，如果重定向导致加载资源，CSP将禁用路径匹配，这意味着将允许gstatic.com提供任何脚本。该示例着重说明了开放重定向可能会对CSP的安全性产生的潜在影响。因此，为了确保一个人的应用程序免受旁加载脚本的危害，除了要确保没有主机名可以被载入Angular或其他库之外，网站管理员还必须确保其他主机名都不会被列入白名单。条目包含一个开放的重定向。

0x06 Hypothetical Impact

到目前为止，本文发现已经显示出许多重要的见解：首先，数据集中所有站点中只有大约10％甚至部署了CSP。应用合理安全策略概念，可以认为其中只有四分之一的站点可以防止常规脚本注入。不过，值得注意的是，尽管分析表明其中大约有10％的人容易遭到绕过，包括Snapchat和Spotify等主要组织。鉴于这些知名网站已经只信任少数几个实体（例如Snapchat仅将其自己的网站和Google属性列入白名单），不能假设普通网站可以部署类似的严格政策。通过扩展研究问题，使其也涵盖了一个假设的案例：如果今天排名前10,000的站点中的每个站点都将部署合理的CSP，该怎么办？为了了解脚本小工具对CSP部署这一理想未来的影响的严重性，首先讨论如何为Tranco排名前10,000个站点生成此类策略。然后对脚本小工具可以绕过多少个这些策略进行了分析。

A.方法

为了进一步研究基于第三方的CSP绕过的影响，假设所有站点都将部署明智的CSP，并以此为准。为此，依赖于已收集的有关分析站点包含的脚本的信息。尽管有更多的生成CSP的方法，还是以轻量级的方式生成CSP。尤其是，尽管许多站点由于依赖于内联脚本而无法部署CSP，但专注于仅管理基于主机的白名单，因为这是攻击的主要目标。尽管在许多站点上删除内联事件处理程序是不可行的，并且是导致CSP缺乏成功的主要因素，但假设实验旨在了解脚本小工具对CSP减轻脚本注入能力的影响。因此，假设每个站点都可以摆脱内联处理程序，并随机化所有内联脚本，即生成的CSP仅是基于主机的白名单。

CSP脚本源生成算法首先会根据爬网站点中的主机对脚本源进行聚类。这提供了主机名到所述主机上的脚本URL的映射。如果给定的主机仅托管一个脚本，则将完整的URL添加到CSP。对于所有具有多个URL的主机，将实现与在野观察到的结果保持一致：将完整的主机名添加到CSP中。

值得注意的是，根据发现的脚本用法自动生成script-src指令的过程只是CSP的下限。由于自动爬取的这种自然局限性，可能会错过前文中提到的允许进行探究的库的使用。因此，关于前10,000个Tranco网站假想生成的CSP的可利用性的结果也只是一个下限。

算法的代码示例生成了合理的脚本内容限制指令，如上图所示。使用此算法，自动生成了脚本指令中相对于定义而言安全的script-src指令。将重复使用漏洞利用程序生成和验证，以调查它们是否容易受到绕过攻击。在初步测试中，发现并不是所有被检测为AngularJS的库实际上都包含一个脚本小工具。特别是，模块cookie和Angular的清理都被检测为AngularJS。为了确保分析不会产生误报，构建了一个简单的测试页面，该页面托管在本地。该页面包含小工具要消耗的有效负载。

接下来，对于每个指向被标识为AngularJS的URL，将其作为脚本包含在内，并确定是否执行了注入的有效负载。如果不是，将URL标记为AngularJS的无效版本。通过这样做，发现2349个带角度标记的库中有1399个可用于攻击。根据此列表，确定生成的CSP是否将允许包含1,399个脚本中的至少一个；从本质上讲，这将使攻击者可以旁加载AngularJS的工作版本。

B.结果

对于其余站点，要么被重定向到异地（例如，转到数据保护法规嵌入式广告），要么它们没有响应HTTP请求。一个这样的示例是samsungcloud.com，它不能解析为IP地址（带有或不带有www），但是可以用于support.samsungcloud.com（根据Google的检查）。

平均而言，其余页面所生成的script-src指令包含9.82个源表达式。最受欢迎的外部源表达式是https://www.google-analytics.com/analytics.js ，需要将5,216个不同的网站列入白名单。白名单条目数最多的网站（226）是www2.deloitte.com 。但是，这个数字之所以高，是因为CSP生成仅使用不同的主机名工作，并且如果将父主main列入白名单会被忽略，则会被忽略。因此，将sp \

.guided.ss-omtrdc.net列入白名单的是159次，而不是一次。与数量如此之多相反，有2,024个站点在其CSP中仅需要一个源表达式，在大多数情况下，仅是“self”表达式。注意到分析未考虑内联脚本，即，即使达到这种相对安全的状态，这些站点也必须避免使用内联脚本或部署现时或散列。

在CSP为其生成脚本src的8,330个网站中，发现3,441个网站的策略实际上可以通过旁加载来绕过。上表显示了漏洞利用代最常选择的主机，其中包括AngularJS。值得注意的是，与实际的可利用性相反，www.gstatic.com 并不是影响最大的主机。这是由于以下事实：如果给定主机中仅包含单个脚本，则CSP生成会将完整URL列入白名单。特别是，发现尽管www.gstatic.com 的资源得到了广泛使用，但在大多数情况下，唯一使用的库是reCaptcha API。取而代之的是，作为假设的利用的直接旁加载目标的最佳AngularJS源是Google的CDN（ajax.googleapis.com），该源有931个受影响的网站。这种CDN或通常说CDN表现良好的一个原因是，开发人员倾向于对多个库使用相同的CDN，从而将CDN主机列入白名单。

与实际可利用性相比，另一个主要区别是，在假设的绕行情况下，仅开放式重定向会导致1,654个Tranco网站受到攻击。当需要来自主机的单个资源时，这又可以归因于CSP生成只将完整URL列入白名单。如上表所示，由于将securepubads.g.doubleclick.net列入了白名单，因此大多数开放式重定向（482）都是可能的。

能够为Tranco Top 10,000内超过3,441个站点的人工创建的CSP自动生成和验证旁路，这一事实表明了旁路的严重性。还注意到开放重定向的严重影响，尤其是在DoubleClick等受欢迎的网站上。旁加载的一种潜在解决方案是在CSP中使用哈希和随机数。但是，基于随机数的策略的问题在于，尤其是广告提供商倾向于向页面添加其他脚本，这将使它们不得不将随机数显式添加到新引入的脚本中，或者更有可能迫使第一方strict-dynamic。但是，如果存在strict-dynamic，则几乎所有具有Lekies等人发现的脚本小工具的库。

C.假设案例研究：reddit.com

为了进行健全性检查并了解为什么安全CSP脚本源指令容易受到绕过攻击的影响，手动研究了生成的策略以及生成的漏洞利用程序。

社交新闻聚合站点reddit.com并未在其实际应用中部署CSP，因此假设分析将其作为目标。生成的script-src指令如上图所示。它使用通过googleapis.com加载的jQuery，但此源中没有其他脚本，因此将其列为完整网址。在白名单中作为完整域存在的脚本源是securepubads.g.doubleclick.net，这是由于从该域加载的脚本在其路径中具有随机标识符或时间戳。鉴于此网站已被完全列入白名单，但重要的是还包含开放重定向。如前所述，如果由于重定向而加载了资源，则CSP会放宽路径匹配。因此可以从ajax.googleapis.com加载AngularJS库，尽管该库未明确存在于白名单中。

此代表性示例仅是由于开放重定向漏洞而可攻击的1,654个站点之一。为了从此漏洞中保护他们的网站，Reddit需要从基于主机的白名单转移到基于哈希和现时的白名单。

但是，由于通过编程方式触发了多个脚本加载，因此它们将需要使用strict-dynamic模式。但是，并非所有浏览器都普遍支持strict-dynamic表达式。因此Reddit将需要以编程方式传递随机数，或者将具有与某些浏览器不兼容的CSP。此外，脚本动态已显示可被多个脚本小工具绕过。因此，只有通过大规模将reddit.com更改为Web应用程序，才能消除该漏洞。

D.局限性和修改

为了验证CSP旁路，假设数据集中的每个网站上都存在一个标记注入漏洞。值得注意的是，本文工作目标不是要表明网站容易受到攻击，而是要表明在现代Web上生成基于主机的安全白名单有多么困难。 CSP最初旨在减轻XSS攻击的影响并研究现代Web中基于主机的白名单的有效性，仅对CSP进行单独调查。除此之外研究表明，不可忽略的一部分站点遭受了标记注入漏洞。

白名单生成中的一个基石是添加一个源而不是来自同一源的多个URL的阈值。自然，此阈值越高，将整个原点以及白名单小工具库列入白名单的机会就越小。尝试了更改将完整源列入白名单所需的URL数量。该分析的结果如下图所示。x轴显示阈值，即值2表示在添加原点之前，至少必须从相同的原点加载URL。这是用于测量的基准。自然，阈值越高，站点越安全。但是，必须注意，在抓取中并未对应用程序进行任何有意义的覆盖，即观察到的JavaScript包含量可能是一个下限。

0x07 Discussion

发现有几个因素导致脚本小工具的危险。首先，这些代码片段绕过了CSP的基本假设之一：鉴于不存在不安全因素，只能执行来自开发者白名单源的代码。特别是，脚本小工具可实现从字符串数据到代码的转换（类似于eval启用的功能），并且无法通过CSP进行控制。这将打开任何使用包含脚本小工具的库来进行攻击的站点。但是考虑到结果是即使存在正确的CSP时，三分之一的站点也容易受到攻击，这是另一个重要原因，即在同一源上托管用于各种目的的库。

相反，一项主要的安全优势来自内容的分离。例如，像Facebook或Twitter这样的社交网络不允许用户将任何内容上传到自己的源，而是分别上传到twimg.com和fbcdn.net。这背后的原因很简单：即使两个站点都可能使用机制来确保上传的图像不是HTML标记或Flash之类的活动对象（如果包含在其他站点中，则重要的是保留其源），但它们还是采用了纵深防御方法。因此，如果攻击者设法绕过上载过滤器以上载HTML，则它不会驻留在主页上，因此无法被利用来攻击站点。

可以说，如果CDN以相似的方式处理其不同内容，则许多易受攻击的站点将很容易受益。特别是，如果Google决定拆分包含reCaptcha片段和AngularJS的主机，则利用reCaptcha API的网站将不会受到脚本小工具的攻击。注意到本研究实际上并未检测到gstatic.com托管的AngularJS，而不得不依赖于已知的AngularJS源列表。这凸显了甚至没有必要在该特定站点上托管AngularJS。

虽然理论上可以通过将reCaptcha API的整个路径列入白名单来实现与分离库相同的保护级别，但是有关开放重定向的发现表明这还不够。因此，即使将完整的reCaptcha URL列入白名单，只要其他单个条目指向打开的重定向，也可以加载reCaptcha脚本主机上的任何脚本。

Web对脚本小工具的敏感性的另一个潜在改进是取消了开放重定向。正如分析所表明的那样，包含此类重定向缺陷的网站通常与广告和分析相关，这些广告和分析被频繁使用，因此受到大量网站的信任。可以说，这种开放重定向可以很好地达到目的，例如，广告提供商可以首先利用此URL来收集有关单击链接的统计信息，然后将用户重定向到目标站点。

值得注意的是，这遇到了在同一站点上托管各种库的相同问题：这些站点在同一站点下混合了不同的用例。解决此问题的一种简单方法是拥有特定的（子）域，这些域仅用于重定向。这样，网站仍可以将广告网络的整个域列入脚本内容的白名单，但是鉴于该域将不再具有开放重定向，因此将不再容易受到启用了重定向的脚本小工具的攻击。

即使在广泛部署CSP的理想世界中，第三方站点对他们的代码的依赖能够通过脚本小工具和开放式重定向的组合来绕开。鉴于CSP不太可能由于重定向后泄露敏感路径信息的严重威胁而被更改，因此呼吁CDN采取有意义的分离。特别是创建脚本小工具库列表，可以轻松地将它们与更有意义的内容分开。这样做的缺点是，如果某个站点想同时使用AngularJS和reCaptcha API，则CSP会变长，但它确实减少了旁加载脚本小工具的攻击面。

通过信任域，开发人员不仅可以信任它们直接加载的那些资源，还可以信任该域托管的每个资源。为了创建安全策略，开发人员需要确保没有任何受信任的域具有任何开放的重定向和/或未托管脚本小工具库。在实践中，这样的先验知识是可行的，因为即使彻底的爬取也无法找到仅包括在例如登录名之后的库。因此，开发人员可能会花费大量精力来加强其CSP，这可以通过白名单站点上的开放重定向和/或小工具库来绕过。此外，将白名单限制为不承载任何小工具库的网站会阻止该网站使用CDN。假设没有其他列入白名单的源遭受开放式重定向漏洞的影响，则开发人员只需将完整的URL列入白名单。但是，考虑到第三方经常添加更多脚本，URL可能会更改，这会违反CSP，可能会很脆弱。

0x08 Conclusion

这项工作中旨在了解当考虑脚本小工具和开放重定向时CSP的基础是如何动摇的。为了回答主要研究问题，首先展示了旁加载脚本小工具如何增加CSP保护的Web应用程序的攻击面。为此分析了Tranco排名前10,000位的公司，寻找托管脚本小工具的资源以及存在开放重定向问题的网站。基于所收集的见解对现实世界中的CSP进行了分析，以了解部署CSP的站点对旁加载小工具的威胁的敏感性。发现在少数几个甚至可以安全地使用CSP来限制内容的站点中，有10％的站点容易被列入白名单的脚本小工具绕过。有证据表明，即使来自所述源的资源已被其完整URL明确列入白名单，但列入白名单的开放重定向仍允许攻击者包括AngularJS。

除了对CSP在野部署情况进行描绘的真实分析之外，还进行了一项假设性实验，根据前10,000个站点使用的脚本编制了基于主机的白名单。总体而言，发现自动生成CSP的保守方法中，自动生成CSP的3,441 / 8,330个站点仍可能成为脚本小工具攻击的受害者。特别是，在那些可绕过的站点中，有1,654个受到白名单公开重定向的影响，再次突出表明了这种不安全的做法可能对其他网站造成的威胁。

为了减轻提出的CSP绕过，可以采用已经在整个Web上广泛使用的一种做法。托管上传的被动内容（如图像）的最佳做法是将它们托管在其他域下。如果CDN提供程序仅通过将已知危险的JavaScript库托管在与其其余代码分开的域中来利用这种做法，则将大大减少旁加载脚本小工具的攻击面。同样，尽管分析和广告提供商经常出于不同目的利用开放式重定向，但在设计上选择将此类重定向URL放在域上，因为提供商的主要功能需要CSP将其列入白名单，这也扩大了攻击面。在这里提出了分离概念，即将重定向托管在一个单独的域中，该域不需要在CSP中列入白名单。

总而言之，发现脚本小工具和开放重定向进一步削弱了CSP保护站点不受XSS攻击的能力。重要的是，这意味着第三方（没有任何恶意）可能会将信任它的网站置于托管良性功能的位置，这可能会意外破坏第一方的CSP。尤其是，尝试部署安全CSP的运营商必须充分了解托管此类库的任何站点，以及任何具有开放重定向的列入白名单的主机。

欢迎登录安全客 -有思想的安全新媒体www.anquanke.com/加入QQ交流群1015601496 获取更多最新资讯

原文链接：https://www.anquanke.com/post/id/239359