客户端CSRF是一种新型的CSRF漏洞，攻击者可以通过修改程序的输入参数，欺骗客户端JavaScript程序将伪造的HTTP请求发送到易受攻击的目标站点。现有研究对这个新漏洞几乎一无所知，而基于JavaScript的Web应用程序的探索性安全性评估由于缺乏可靠且可扩展的测试技术而受到阻碍。本文介绍了工具JAW（https://github.com/SoheilKhodayari/JAW ），该工具可利用混合属性图上的声明式遍历（针对JavaScript程序的标准混合模型），针对客户端CSRF来分析现代Web应用程序。

本研究使用JAW评估了Bitnami目录中所有（即106个）Web应用程序中客户端CSRF漏洞的普遍性，涵盖了超过2.28亿行JavaScript代码。本文工具发现了12,701个可伪造的客户端请求，总共影响了87个Web应用程序。对于203个可伪造的请求，针对七个Web应用程序成功创建了客户端CSRF攻击，这些Web应用程序可以执行任意服务器端状态更改操作或启用跨站点脚本和SQL注入，而这是传统攻击向量无法实现的。最后分析了可伪造的请求并确定了25个请求模板，突出显示了可以操纵的字段和操纵的类型。

0x01 简介

客户端跨站点请求伪造（客户端CSRF）是影响现代Web应用程序的新型CSRF漏洞。与更传统的CSRF一样，攻击者可以短暂访问恶意URL，从而诱骗受害者的浏览器以用户的名义向目标网站发送经过身份验证的，对安全性敏感的HTTP请求，而无需用户的同意或意识到。在传统的CSRF中，易受攻击的组件是服务器端程序，该程序无法区分传入的身份验证请求是否是有意执行的，也称为混淆代理问题。通常通过添加伪随机不可预测的请求参数，防止伪造或更改默认浏览器的行为并避免在跨站点请求中包含HTTP cookie。在客户端CSRF中，易受攻击的组件是JavaScript程序，它使攻击者可以通过修改JavaScript程序的输入参数来生成任意请求。与传统的CSRF相反，现有的反CSRF对策不足以保护Web应用程序免受客户端CSRF攻击。

客户端CSRF非常新，它在2018年首次影响了Facebook ，而且研究者几乎不了解易受攻击的行为，新漏洞的严重性以及利用情况。研究新漏洞不是一件容易的事，因为它需要每个真实的Web应用程序收集和分析数百个网页。不幸的是，此类分析主要由于缺乏适用于检测和分析易受攻击的JavaScript行为的可靠且可扩展的工具而受到阻碍。

通常，研究基于JavaScript的Web应用程序中的客户端CSRF漏洞并非易事。首先，没有JavaScript代码的规范表示。其次，JavaScript程序是事件驱动的，需要模型来捕获这方面并将其纳入规范表示中。第三，由于JavaScript程序及其执行环境的动态特性，纯静态分析通常不够准确，因此需要混合静态+动态分析技术。最后，JavaScript库构成了跨网页的代码中值得注意的一部分，并且反复分析它们会导致效率低下的模型，不适合检测漏洞。

在本文中，通过提出混合属性图（HPG）来解决这些挑战，该属性图是客户端JavaScript程序的一种基于图的一致表示形式，可以捕获静态和动态程序行为。受先前工作的启发，使用属性图进行模型表示和声明式图遍历，以识别对安全敏感的HTTP请求，这些请求消耗来自攻击者可控源的数据值。另外介绍了JAW，这是一个用于检测客户端CSRF的工具，该框架从种子URL开始，通过自动收集Web资源并监视程序执行来实例化HPG。

0x02 背景

A.客户端CSRF

客户端CSRF是一类新的CSRF漏洞，攻击者可以通过操纵该程序的输入参数来欺骗客户端JavaScript程序，以将伪造的HTTP请求发送到易受攻击的目标站点。在客户端CSRF攻击中，攻击者诱使受害者单击属于攻击者控制的网页或诚实但易受攻击的网站的恶意URL，从而导致目标网站的与安全性相关的状态更改。

影响：与经典CSRF相似，可以利用客户端CSRF在服务器端执行对安全敏感的操作并损害数据库完整性。成功的CSRF攻击可能导致远程执行代码，非法汇款或假冒和身份欺诈等等。

根本原因：当JavaScript程序使用攻击者控制的输入（例如URL）来生成传出的HTTP请求时，就会产生客户端CSRF漏洞。下面将讨论操作不同的JavaScript输入源所需的功能。

威胁模型：攻击者的总体目标是通过操纵各种JavaScript输入源来伪造客户端HTTP请求。在本文中考虑URL，窗口名称，文档引荐来源网址，postMessages，Web存储，HTML属性和cookie，它们各自需要不同的攻击者功能。操纵URL，窗口名称，引荐来源网址和postMessages要求攻击者能够伪造URL或控制恶意网页。例如，网络攻击者可以制作一个恶意URL，该URL属于诚实但易受攻击的网站的来源，当受害者访问该URL时，目标站点的JavaScript程序会自动提交HTTP请求。

网络攻击者可以控制恶意页面，并使用浏览器API欺骗目标页面的易受攻击的JavaScript，以发送HTTP请求。例如，网络攻击者可以使用window.open( )在新窗口中打开目标URL，将postMessages发送到打开的窗口，或通过window.name API设置窗口名称。此外，Web攻击者可以利用攻击者控制的网页的URL来操纵document.referrer。

对于Web存储和HTML属性，攻击者需要在Web存储或DOM树中添加临时数据项。 Web攻击者可以假设Web应用程序提供了这样的功能（例如，通过HTTP请求）来实现。同样，了解XSS漏洞的Web攻击者可以操纵Web存储或DOM树。最后，修改Cookie可能需要强大的攻击者，例如网络攻击者。攻击者可以通过修改可能处于休眠状态的cookie将永久的客户端CSRF有效载荷植入受害者的浏览器中，然后利用该cookie攻击受害者。注意到，网络攻击者也可以执行网络攻击者执行的所有攻击。

漏洞：Listing 1展示了一个易受攻击的脚本，该脚本基于本研究在SuiteCRM中发现的真实漏洞，该脚本在页面加载期间通过HTTP请求获取购物发票。首先，程序获取一个具有id输入的HTML输入字段（第1行），然后定义一个事件处理程序h，该事件处理程序h负责通过异步请求获取发票的价格，并使用价格填充输入（第2-9行）。对于异步请求，函数h使用YUI库，该库为低级XMLHttpRequest浏览器API提供了包装asyncRequest。然后，将函数h注册为名为loadInvoice的自定义事件的处理程序。此事件由函数showInvoicePrice分派（第14-16行）。当JavaScript程序使用URL片段存储HTTP请求的服务器端终结点时，就会发生此漏洞（第3-5行），攻击者可以修改该输入。

攻击：上图显示了利用Listing 1的客户端CSRF漏洞进行攻击的示例。首先，攻击者通过将目标站点的URL作为URL片段插入来准备易受攻击站点的URL（步骤1）。然后，诱使受害者访问易受攻击的URL（步骤2），因为它属于用户信任的应用程序。页面加载完成后（步骤3），JavaScript代码将从URL片段中提取URL，并向目标站点发送异步HTTP请求，这又会导致目标服务器上与安全性相关的状态更改。

现有防御措施无效：在过去的几年中，社区提出了针对CSRF的几种防御措施。最近，浏览器供应商提议通过将所有cookie都默认标记为SameSite = Lax来引入更严格的相同站点cookie策略。不幸的是，现有机制无法提供针对客户端CSRF攻击的完整保护，例如，当使用同步Token或自定义HTTP标头时，JavaScript程序会将它们包括在外发请求中，如图所示Listing 1的第7行中。此外，如果浏览器或网站对cookie使用同一站点策略，则JavaScript网页一旦加载，便可以执行初步的同一站点请求，以确定是否存在预先建立的用户会话绕过同一个网站政策。

B.挑战

在这项工作中，打算在Web应用程序的客户端JavaScript代码中研究新的客户端CSRF漏洞。在提出解决方案之前，将展示实现目标所需要解决的挑战。

（C1）静态表示模型：通过静态分析来分析JavaScript程序具有极大的挑战性。例如，先前的工作提出了过程间控制流程图，数据流相关性图表，类型分析器和指向分析。不幸的是，这些方法提供了程序的临时表示，每个方法都集中在一个单独的方面，而这不足以研究客户端CSRF。最近看到了一些新的想法，它们将静态表示与代码属性图（CPG）统一在一起。但是，这些新想法并不是针对JavaScript的细微差别而定制的，例如异步事件或执行环境。迄今为止，还没有用于JavaScript的模型可以提供规范的表示形式来进行代码的检测和探索性分析。

（C2）特定于漏洞的分析工具：在过去的几年中，已经有很多方法可以检测客户端JavaScript程序中的漏洞。迄今为止，这些方法已主要应用于XSS或逻辑和验证漏洞，这些工具与漏洞的具体分析紧密结合在一起。因此，试图研究新的客户端漏洞（如客户端CSRF）的研究人员被迫重新实施那些重新发现调整和陷阱的方法。

（C3）基于事件的控制权转移：现有的统一表示形式（例如CPG）假设控制权的转移仅通过函数调用发生，而这一假设不再适用于JavaScript。在JavaScript中，控制转移也通过事件发生，这些事件要么源于环境，例如鼠标事件，要么是用户定义的，如清单1所示。当分派一个事件时，将执行一个或多个注册函数，这些事件将被执行。可以更改程序的状态，注册新的处理程序并触发新事件。表示通过事件处理程序进行的控制转移是分析JavaScript程序的基础。

（C4）动态Web执行环境： JavaScript程序依赖于许多动态行为，因此很难通过纯静态分析来研究它们。一个典型的例子是动态代码加载。本质上，就像其他资源一样，JavaScript程序可以流式传输到用户的Web浏览器。因此，与大多数静态分析方法中的假设相反，整个JavaScript代码可能无法用于分析。另一个示例是JavaScript与DOM树之间的交互。例如，考虑两个包含相同DOM树节点的变量；但是，一个变量的内容是通过document.querySelector（“ input”）获取的，而另一个是通过document.form [0] .input获取的。在这种情况下，确定两个变量是否指向同一个对象（即指向分析）通常很重要。但是，通过查看源代码很难确定这一点，因为DOM树通常是由同一程序生成的。

（C5）共享的第三方代码：大多数现代的Web应用程序至少包括一个第三方JavaScript库，例如jQuery，以从其对低级浏览器API的强大抽象中受益。客户端CSRF的检测需要能够确定程序何时执行HTTP请求，以及程序何时将低级网络操作委托给库。同样，库函数可以是程序数据流的一部分。

迄今为止，现有方法的效率非常低，因为它们在分析中包括了库的源代码。观察到外部库占每个网页的JavaScript代码行总数的60.55％，因此即使在访问同一Web应用程序的新页面时，也需要使用现有技术来重新处理相同的代码。一种替代方法包括创建手工制作的库模型。尽管这种方法在对低级浏览器API进行建模时很有效，但无法很好地扩展到外部库。首先，外部库的更新频率要高于浏览器API，其次，JavaScript程序可以使用许多替代库。

C.方法概述

为了克服挑战，本研究提出了混合属性图（以下简称HPG），这是JavaScript程序的基于图的规范模型。此外，提出了JAW，这是一个从种子URL开始构建HPG的工具，并利用声明式性图遍历来检测客户端CSRF。本文方法解决了以下挑战：

（C1）HPG为JavaScript源代码提供统一的规范表示，类似于C / C ++ [91]和PHP [33]的代码属性图。

（C2）定义HPG并开发JAW，以能够执行各种安全任务，即对客户端CSRF漏洞的检测和探索性分析。将代码表示形式（图）与分析（遍历）解耦可能会使JAW更适合重用（就像其他基于CPG的方法一样）。但是，由于研究目标是研究客户端CSRF，因此在本文中，既不针对HPG，也不主张HPG可重用性。

（C3）HPG通过提出事件注册，调度和依赖关系图（ERDDG）来捕获JavaScript的细微差别，例如基于事件的控制转移。

（C4）HPG通过Web环境的快照（例如DOM树）和JavaScript事件的痕迹捕获客户端JavaScript程序的Web执行环境的动态。

（C5）JAW可以生成外部库的可重用符号模型，这些模型将在HPG中用作代理。

JAW输入输入要测试的应用程序的种子URL。然后，它使用网络爬虫来访问目标。在访问期间，JAW存储JavaScript和HTML代码，并监视执行情况，以捕获DOM树，HTTP请求，注册的处理程序和触发事件的快照。通过使用用于公共库的已知签名的数据库，JAW可以识别外部库并为每个库生成一个符号模型。符号模型由库的元素（例如函数名称）和一组表征其行为的语义类型之间的映射组成。然后，JAW为每个存储的页面构建HPG，并将HPG与预先生成的语义模型链接。最后，JAW可以查询HPG，以检测或交互式探索客户端CSRF漏洞。

0x03 混合属性图

本节介绍混合属性图（HPG）。 HPG由代码表示形式和状态值组成。代码表示统一了JavaScript程序的多个表示，而状态值是在程序执行期间观察到的具体值的集合。使用标记的属性图对二者进行建模，其中节点和边可以具有标签和一组键值属性。以下示例显示了一个图形，其中li是节点标签，rj是关系标签。节点和边可以通过使用属性（键值映射）存储数据。

A.代码表示

代码表示对JavaScript源代码进行建模，并建立在代码属性图（CPG）概念的基础上，该概念结合了C程序的三种表示形式，即抽象语法树，控制流图和程序依赖图。后来，同样的想法被改用于研究PHP程序，用调用图扩展了CPG。 HPG通过事件注册，分派和依赖关系图以及语义类型进一步扩展了CPG。

抽象语法树（AST）：AST是对程序进行分层分解以对其句法构造进行编码的有序树。在AST中，终端节点代表发送的操作数（例如，标识符），并且非终端节点对应于运算符（例如，分配）。在下图中，AST节点用舍入框表示。终端节点以粗体斜体表示，而非终端节点全为大写字母。 AST边按照语言语法的产生规则将AST节点彼此连接，例如，在Lisitng 1的第10行中，i.addEventListener（'loadInvoice'，h）是具有三个子代的调用表达式（CALL_EXP），成员表达式（MMBR_EXP）i.addEventListener，文字'loadInvoice'和标识符h。 AST节点是代码表示的核心节点，为其余模型提供了构建块。

控制流程图（CFG）：CFG描述了程序指令的执行顺序以及将控制流转移到特定执行路径所需的条件。在上图使用非终端AST节点之间的边（绿色）对CFG进行了建模。 CFG边有两种类型：有条件的（来自谓词，并用true或false标记）和无条件的（用ε标记）。函数的CFG以入口节点开始，以出口节点结束，标记了函数作用域的边界。这些分散的过程内流通过过程间调用边相互连接，如下所述。

过程间调用图（IPCG）： IPCG允许对JavaScript程序进行过程间静态分析。它与程序中的每个调用站点关联可以从该站点调用的功能集。例如，Lisitng 1中第16行的表达式showInvoicePrice（'input'）要求执行第14行的函数showInvoicePrice。将IPCG集成到代码表示中，并带有定向调用边，例如，请参见上图C_EXP AST节点和F_DECL AST节点。

程序依赖图（PDG）：变量的值取决于一系列语句和谓词，PDG对这些依赖关系进行建模。 PDG的节点是非终端AST节点，边表示数据或控件相关性。数据相关性边指定在源节点上定义的变量x以后将在目标节点上使用，标记为Dx。例如，在上图变量uri在第3行中（由VAR_DECL声明），并在第4行中（在IF_STMT中）使用，因此PDG边（蓝色）将它们连接在一起。控制依赖项边反映了目标语句的执行取决于谓词，并由Ct或Cf标记，该条件对应于真或假条件，例如，第7行中CALL_EXP的执行取决于中的IF_STMT谓词第4行。

事件注册、调度和依赖性图（ERDDG）：ERDDG打算对JavaScript程序的事件驱动执行范例以及事件处理程序之间的细微依赖关系进行建模。在ERDDG中，节点是非终端AST节点，使用三种类型的边对执行和依赖关系进行建模。第一个边对事件的注册进行建模，例如Lisitng 1中的第10行将h注册为自定义事件loadInvoice的处理程序。用节点C_EXP（即addEventListener的调用站点）和节点F_DECL（即定义函数h的语句）之间类型注册的边来表示事件的注册。第二个边模拟事件的分发。例如，Lisitng 1中的第15行调用浏览器API dispatchEvent来调度loadInvoice事件类型的处理程序的执行。使用类型调度的边对控制转移进行建模。例如，参见上图15行的C_EXP节点与注册处理程序的C_EXP之间的边（红色）。最后一个边对语句和事件之间的依赖关系进行建模。通过处理程序声明的AST节点与处理程序声明的AST节点之间的边实现依赖关系。上图显示了第2行的F_DECL节点和函数主体的边。

语义类型：客户端CSRF的检测需要标识语句，这些语句发送HTTP请求，并使用来自预定义源的数据值。 通过语义类型对语句的属性进行建模，语义类型是分配给程序元素的预定义字符串。 然后，在计算程序之后，将类型传播到整个代码中，例如，可以将类型WIN.LOC分配给window.location，然后将其传播到PDG，CFG，IPCG和ERDDG边之后的其他节点。 在上图中，对于WIN.LOC类型，使用了一个蓝色填充圆，该圆在Duri PDG边之后传播，即第3、4和5行的uri。语义类型也可以分配给函数以指定其语义行为抽象。 例如，可以对所有允许JavaScript程序发送HTTP请求（例如fetch或XMLHttpRequest）的浏览器API使用字符串REQ。 HPG将语义类型建模为AST节点的属性。

符号建模：在分析程序的源代码时，需要考虑第三方库的行为。从每个库中提取一个符号模型，并将其用作分析应用程序代码的代理。在这项工作中，符号模型是将语义类型分配给库的函数和对象属性。例如，在上图中，可以为asyncRequest术语使用语义类型REQ（用橙色实心圆表示），并提取其实际代码。同样，为了重构使用库函数的程序的数据流，定义了两种语义类型，它们对库函数的过程内输入输出依存关系进行建模。对于输入数据值流向返回值的函数，使用语义类型o←i;对于输出取决于输入值（例如，通过IF_STMT）的函数，使用o〜i类型。库的符号建模由JAW自动执行，JAW在库元素和语义类型列表之间创建映射。

B.状态值

JavaScript程序具有动态行为，这些行为很难通过静态分析进行分析。因此增强了HPG，以包括在运行时收集的具体数据值，并将它们链接到对应的代码表示形式。

事件跟踪：为了捕获由于静态分析或自动触发事件的局限性而无法建模的一组激发事件，使用事件的动态跟踪来扩充静态模型。事件跟踪是在执行网页期间观察到的一系列具体事件。例如，用于HTTP请求响应的负载事件或网络事件。在可能的情况下，使用在页面加载时触发的事件跟踪来激活ERDDG图中的其他注册边。如上图所示，事件跟踪图的节点表示在运行时观察到的具体事件，而边表示其顺序。

环境属性：环境属性是全局窗口和文档对象的属性。 JavaScript程序的执行路径和变量的值可能会根据环境属性的值而有所不同。通过为动态观察到的特性创建具体值图来丰富HPG，还存储HTML DOM树的快照。如果变量的值是从DOM API获得的，则可以从树中解析实际值。使用DOM树来定位DOM API所引用的对象，例如，要确定事件分发是否以处理程序为目标，可以检查分发和注册是否在同一DOM对象上完成。为每个环境属性创建一个节点，并将具体值存储为该节点的属性。如上图所示，通过代表所有权或父子关系的边来连接这些节点。

C.带有HPG的客户端CSRF分析

给定前文描述的HPG，现在使用它来检测和研究客户端CSRF。说当（i）从攻击者控制的输入到输出HTTP请求req的参数存在数据流，并且（ii）在页面加载时提交req时，JavaScript程序容易受到客户端CSRF的攻击。

使用图遍历对两个条件进行建模，即查询以从HPG中检索信息。在本研究工作中，使用声明性Cypher查询语言定义图遍历，但是在本文中，在保留声明性方法的同时，以集合符号和谓词逻辑来举例说明Cypher语法。查询Q包含HPG的所有节点n，其谓词p（图模式）为true，即Q = {n：p（n）}。使用谓词定义节点的属性。例如，使用谓词hasChild（n，c）来表示节点n具有AST子项c。谓词的另一个示例是hasSemType（n，t），它表示语义类型为t的节点n。可以例如通过逻辑运算符来组合谓词以定义更复杂的查询。

检测客户端CSRF：客户端CSRF漏洞的第一个条件是存在传出请求的攻击控制的输入参数。上图显示了来自真实示例的易受攻击代码的不同实例，其中通过构造，将WIN.LOC和REQ语义类型分配给AST节点，分别显示为蓝色和橙色框。对于上图的所有三种情况，目标是识别同时具有橙色和蓝色标签（标有红色箭头）的代码行。在较高的层次上，一行代码是JavaScript语句或声明（例如EXP_STMT，VAR_DECL）的非终端AST节点，用谓词isDeclOrStmt（n）表示。 然后，一旦确定了这样的AST节点n，就需要研究该节点是否具有两个子c1和c2，其中一个子节点为REQ类型，另一个子节点为WIN.LOC类型。 按照查询符号，可以编写：

查询1不足以确定是否存在客户端CSRF漏洞，因为返回的节点可能对应于页面加载时未执行的代码行。通过额外的可达性检查来完善它。通常，从isDeclOrStmt（n）这样的节点n开始，可以跟踪CFG的后向边（ε，true和false），以确定是否到达CFG入口节点。然后，每当到达函数定义（例如F_DECL）时，都会在IPCG调用边之后跳转到其所有调用位置。但这还不够，因为可以在触发特定事件时执行功能。因此，需要向后访问ERDDG边，即依赖关系边，然后是注册和调度边。分别处理特殊情况，在这些情况下，浏览器会在加载页面时自动触发事件。继续跟踪CFG，ERDDG和IPCG的后向边，直到到达CFG入口节点或不再有匹配任何先前条件的节点为止。如果CFG条目节点位于查询结果集中，则节点n是可访问的。

脆弱行为分析：先前的查询可以识别客户端CSRF的一般易受攻击行为，即使用攻击者选择的数据值提交HTTP请求的程序。但是，程序可能会对输入进行各种检查，最终可能会影响开发环境。例如，在上图程序1显示了一个易受攻击的脚本，其脚本的第1行的域验证限制了攻击者操纵整个请求URL。但是，程序2显示了攻击者可以选择完整的URL字符串（包括路径和查询字符串）的情况。打算研究的客户端CSRF漏洞的一个方面是确定攻击者可以操纵传出请求的程度。例如，如果window.location属性流至请求参数而没有进行任何清理。查询2捕获了以下方面：

查询2检查由查询1返回的节点n1是否通过PDG边连接到赋值语句，该赋值语句的右侧子级是window.location的属性。谓词hasPDGPath（n2，n1）指定在PDG边之后存在从n2到n1的路径，并且isAssignment（n2）标记n2为VAR_DECL或ASSIGN_EXP节点。

要考虑的另一个方面是请求中攻击者可控项目的数量。例如，上图的程序3显示了一个更复杂的示例，其中，攻击者还可以控制请求正文的内容，从而增加了为易受攻击的行为创建利用漏洞的灵活性。为此，查询可以利用属于同一请求的元素之间的PDG依赖性，将属于同一HTTP请求的易受攻击的代码行聚类。然后，查询可以计算攻击者可控制的注入点的数量（例如，参见程序3第6行中的两个注入点以及第4行中的注入点）。

0x04 JAW

在本节中将介绍JAW，这是一个使用HPG研究客户端CSRF漏洞的框架。 JAW从网站的原始URL开始，使用启用JavaScript的网络搜寻器访问网页以收集Web资源。在访问期间，JAW还收集运行时状态值。然后，给定用户定义的语义类型及其对JavaScript语言标记的映射的列表，JAW构造HPG。建设分为两个阶段。首先，JAW识别程序所使用的外部JavaScript，并对其进行独立处理以提取符号模型。然后，它构造其余JavaScript代码的图，并将JavaScript程序的元素链接到状态值。最后，JAW通过在HPG上执行查询来分析客户端CSRF。下图概述了JAW的体系结构。

A.数据收集

数据收集模块执行两项任务：爬取以发现来自不同用户状态的URL，以及为找到的每个网页收集JavaScript代码和状态值输入。数据收集模块的输入是被测Web应用程序的种子URL，以及可选的测试用例，以通过用户登录，例如，作为脚本化的Selenium任务或通过跟踪记录。

爬虫：开发了一种爬虫，它使用通过Selenium控制的无头Chrome实例。从种子URL开始，爬虫访问Web应用程序以收集Web资源和运行时执行数据。它遵循迭代加深深度优先搜索策略，并在未找到其他URL或分配的时间预算用完时终止（默认值为24h）。如果作为输入提供，它将在爬网会话之前执行测试用例。

JavaScript代码和状态值：当访问每个页面时，爬虫程序每ti = 10秒存储一次Web资源和状态值，其中m = 2次（可配置参数）。爬虫针对每个ti间隔收集HTML页面，JavaScript程序，HTTP请求和响应以及明确显示的JavaScript属性。通过Selenium接口提取JavaScript属性时，为爬虫开发了一个Chrome扩展程序，该扩展程序使用函数hook来拦截对addEventListener的调用以收集事件，并调用chrome.webRequest API来拦截网络流量。

B.图构造

收集到的JavaScript代码和状态值来构建HPG。生成的图形被导入Neo4j数据库中，以便进行细粒度的声明式路径遍历，以检测和研究客户端CSRF，本节描述了构建HPG的技术细节。

规范化JavaScript代码：第一步，JAW通过在脚本标签和HTML属性（即内联JavaScript代码）内串联代码段来创建规范化的JavaScript程序，并保留程序段的执行顺序。组合内联代码时，JAW用addEventListener API替换内联事件处理程序注册。

库检测：为了识别库，使用库检测器，该工具可在执行环境中搜索已知的库签名（例如，全局变量）。

HPG构造：JAW构造HPG的方法如下。首先，为每个检测到的库的符号建模创建图。如果该库的符号模型已经存在，则跳过此步骤。然后，它为正在分析的程序创建一个图。不管使用该图如何，构建HPG的规则都不会改变，如下所示。

1.AST：JAW使用Esprima（一种符合标准的ECMAScript解析器）生成标准化源代码的AST。 Esprima的输出是AST的JSON表示形式。在此表示中，节点是具有类型属性（例如VAR_DECL）的键值字典，并且边用临时字典键表示。将JSON输出映射到图形的AST节点和AST边。

2.CFG ：本研究广泛审查了开源CFG生成器，例如escontrol，styx或ast-flow-graph，并选择了Esgraph，因为它很受欢迎并且符合Esprima 。从AST开始，Esgraph生成CFG，其中节点是用于语句或声明的AST节点，对于条件分支，边标记为true或false，对于同一基本块的节点标记为ε。

3. PDG：JAW使用dujs，这是一个基于Esgraph的def-use分析库。修改了dujs以增加对全局变量，闭包和匿名函数调用的支持。 dujs的输出是AST边之间每个变量v的定义使用关系的列表，该JAW导入为HPG中的数据依赖边Dv。对于控制相关性边，JAW根据CFG计算后支配树，每条语句s一个。然后，JAW将树的每个边分别映射到True或false分支的Ct或Cf。

4.IPCG：JAW生成IPCG的方法如下。在AST和CFG的构建过程中，JAW会跟踪所有函数定义和调用站点。然后，它将调用站点与其可能调用的函数定义相关联。 JavaScript中有五种类型的调用表达式：全局对象上的函数调用（例如foo( )），属性调用（例如a.foo( )或a['foo']( )），构造函数调用（例如，新的Foo( )），通过call( )和apply( )方法的调用。在所有情况下，实际的函数定义名称都可以使用别名。使用PDG解析指针，并相应地连接调用边。如果指针的值是有条件的，将边连接到每个相应的函数定义。

5.ERDDG：为了生成ERDDG，JAW会在创建AST和CFG期间跟踪事件调度和处理程序注册。对于发现的每个事件处理程序，JAW都会创建一个将顶级AST节点（即CFG节点）连接到处理程序功能的注册边，以及一个将处理程序功能连接到主体语句的依存关系。为了将每个事件调度关联到注册站点，检查它们是否针对相同的DOM元素。为此利用PDG解析在其上调度了事件的指针以及在其上注册了处理程序的指针，并检查它们是否引用相同的变量声明或具有逐字或语义上相同值的不同变量。使用DOM快照来检查两个不同的DOM查询是否可以在语义上针对同一元素。例如，可以使用元素的id或名称属性来查询元素。一旦确定指针引用了相同的元素，就可以在分发站点和注册站点之间连接一条边。

6.语义类型和传播：此步骤的输入是语义类型t和AST节点σ的签名之间的映射T，例如，将WIN.LOC类型映射到JavaScript属性window.location。对于每对（t，σ）∈T，JAW将每种类型t存储到与签名σ匹配的AST节点。然后，JAW通过HPG传播类型t。

算法1将类型t从节点n传播到其他节点。首先，函数propagateLeft将类型t分配给左侧的变量v（例如，分配的变量）（如果有的话），然后将其返回。然后，函数propagateByPDG在PDG边之后传播t，并返回访问路径P。然后，对于路径pi∈P末端的每个节点nt，区分了三种情况。第一种情况是nt是一个函数调用，通过在符号建模过程中分配的特殊语义类型进行建模。如果是这样，将污染输出变量o，然后递归调用o的propertyForward。其次，nt是具有IPCG边的调用表达式。在这种情况下，在函数定义上对参数c进行了污染，该参数与调用站点上污染的参数相对应，并为c调用propertyForward。然后，调查函数定义上下文中的最后一个污染节点是否是污染的return语句。如果是这样，在保存返回结果的调用站点上为变量vle ft调用propertyForward。第三，nt是传递受污染数据的事件分发表达式。在这种情况下，跳过分派和注册边，污染相应的事件变量，然后为该变量调用propertyForward。当以上条件均不成立时，此过程终止。

在创建用于库的符号建模的HPG和其余代码的HPG时，JAW都会执行语义类型传播。在为其余代码创建HPG时，语义类型映射T包括在符号建模期间创建的映射。

符号建模：此步骤的输出是语义类型和AST节点的映射，该映射在为正在分析的程序构建HPG时使用。符号建模始于从库源代码构建HPG。然后，在传播了语义类型之后，JAW搜索具有过程内输入输出关系的函数定义。更具体地说，JAW通过至少一个输入参数来识别所有非匿名函数表达式，并通过向后程序切片方法来跟踪其返回语句（如果有）的值。在较高的层次上，利用PDG，CFG，IPCG和ERDDG图从返回值的起点开始，一直到修改该值的地方，再到生成该值的地方结束。如果返回的变量（例如o）对函数输入（例如i）具有PDG控件依赖性，则将类型o〜i分配给该函数。如果建立PDG数据依赖关系，则将其标记为o←i。最后，JAW选择具有至少一种语义类型的所有函数表达式和对象属性节点，这些节点将在JavaScript代码的HPG构造中使用。

0x05 评估

评估的总体目标是研究客户端CSRF漏洞并评估JAW的有效性和实用性。在4,836个网页上运行JAW，这些网页从106个流行的Web应用程序中爬取，并为228,763,028 LoC生成了HPG。在此过程中，发现在87个应用程序中分配了12,701个可伪造的客户端请求。发现七个应用程序遭受至少一个0 day客户端CSRF漏洞的攻击，可以利用该漏洞执行状态更改操作并破坏服务器的完整性。下图描述了为了构建和分析HPG的每个工具组件的平均处理时间。

A.实验设置和方法

测试平台：从Bitnami目录中选择Web应用程序，该目录提供了可随时部署的预配置Web应用程序的容器。选择Bitnami应用是由于其受欢迎程度，多样性和先前工作的使用。在评估时，Bitnami包含211个容器。丢弃了105个没有Web应用程序且没有重复项的容器，例如，使用不同Web服务器的相同Web应用程序。其余的106个Web应用程序是：内容管理系统（23个），分析（15个），客户关系管理（11个），开发人员工具和错误跟踪（10个），电子商务（8个），论坛和聊天（8个），电子邮件和营销自动化（5个），电子学习（4个），媒体共享（3个），项目管理（2个），会计和投票管理（2个）以及其他（15个）。 Web应用程序的完整列表中包括WordPress，Drupal，GitLab，phpMyAdmin和ownCloud。然后，对于每个Web应用程序，为每个受支持的特权级别创建一个用户帐户，并创建一个Selenium测试用例来执行登录。总共创建了136个测试脚本，每个应用程序包含1到5个测试用例。

JAW输入：JAW的输入是种子URL，Selenium测试用例和语义类型映射。种子URL包含用于用户登录的URL（总共113个登录URL），而测试用例是在配置测试平台时准备的。然后，对于所有Web应用程序，使用下表列出的语义类型。

客户端CSRF检测方法：在本地部署了正在评估的Web应用程序，并针对每个目标实例化了JAW。在数据收集和创建HPG之后，运行一组查询以识别攻击者可控制的请求。然后，使用其他查询来确定攻击者控制下的请求字段和控制类型，通过人工验证来评估查询结果的准确性。对于每个可伪造的请求，将页面加载到检测到的浏览器中，并验证在客户端请求中是否观察到操纵的输入。例如，如果请求使用WIN.LOC类型的数据值，将标记插入易受攻击的页面URL中，并在传出请求中搜索该标记。确认请求的可伪性后，将其用于攻击中。首先，搜索执行安全性相关的状态更改操作（例如修改服务器端存储上的数据）的服务器端端点。然后构造一个字符串，当该字符串由易受攻击的页面处理时，它将导致向标识的端点的请求。最后将字符串打包到恶意URL中，并验证攻击是否针对具有有效会话的Web应用程序用户，该用户单击URL。

影响动态快照方法：进行了其他实验，以评估动态快照方法在（i）漏洞检测和（ii）HPG构建中的影响。首先准备了JAW的变体，以下称为JAW-static，它遵循纯静态方法进行HPG构建和分析。具体来说，JAW-static不考虑以下动态信息：触发事件，处理程序注册，HTTP消息，全局对象状态，针对DOM查询的指向分析，脚本标记的动态插入以及DOM树快照。用JAW-static重复了评估，并通过将其与JAW的评估结果进行比较，确定了JAW-static中漏报和误报漏洞的下限。此外比较了HPG节点，边和属性的差异。

然后记录了所有未触发的触发事件，并且JAW找不到用于HPG构建的代码行。此类情况表明JAW生成的HPG中存在漏报边。因此，手动检查所有情况以找出出现漏报边的原因。最后进行了另一个实验，以评估由于使用DOM树快照进行DOM查询的指向分析而导致的误报和漏报性边。对于所有网页，检测JavaScript代码以记录DOM查询所引用的实际元素，并将其与JAW解析的值进行比较。 JAW使用这些分辨率来创建ERDDG边，从而为误报边和漏报边打开了可能性。

B.收集数据分析

分析的大小：JAW从113个种子URL开始，提取了4,836个网页，每个Web应用程序从1到456个网页，每个应用程序大约46个网页。对这些URL的结构分析表明，它们中的865个具有散列片段，这表明这些URL带有客户端JavaScript程序的状态信息，这是单页Web应用程序的特征。总共有39个Web应用程序使用带有哈希片段的URL。
JAW从4,836页中提取了228,763,028个LoC，通过处理每页47,304个LoC来生成4,836个HPG。在查看代码的来源时，发现其中的大部分（即60.55％）来自共享库，例如jQuery（每页28,645个LoC，总共138,525,092个LoC），而其余部分是脚本中的应用程序代码标签（每页39.42％或18,649 LoC，总计超过90,188,256 LoC）和可忽略不计的金额是内联代码（每页0.02％或10 LoC，共超过49,680 LoC）。

最终在运行时，观察到总共有104,720个脚本标签被动态加载（即，通过以编程方式插入脚本标签）约2.63％的脚本标签。另外，JAW观察到有51,974个事件在加载页面时触发（每页大约11个事件），这些事件分布在46个事件类型中，其中38个是HTML5类型（例如，动画和DOM突变事件），其中8个是自定义事件。正如接下来将要展示的，即使运行时监视事件的数量可以忽略不计，它们在分析中的作用也是至关重要的。

符号建模的重要性：客户端程序的分析需要处理228,763,028个LoC，其中138,525,092个仅用于库，占总数的60％。分析表明，库在Web应用程序和页面之间都可以大量重用。首先，测试平台中的106个Web应用程序总共使用了31个不同的库。其次，每个页面包含从零到七个脚本库，平均每个页面有两个库。第三，这31个库的代码总量为412,575 LoC，比所有页面上的总138,525,092 LoC小335倍。因此，对库代码进行预处理以提取符号模型的过程将生成HPG所需的工作量减少了一半以上（-60.37％），从228,763,028 LoC变为90,650,511（即应用程序，内联JavaScript，和31个库）。

对于31个库中的每一个，JAW都会生成一个HPG并提取一个符号模型。上表概述了符号建模步骤的结果。 JAW在大约半小时内总共建模了11,977个函数，其中一半具有输入输出关系的语义类型（即5,923个函数），这是一种正确重构程序数据流的相关函数行为。

确定了64,854,097个事件边（即注册，依赖和分派），其中6,451,582是分派边，即为执行事件处理程序的意图建模的边。为了进行比较，将控件也转移到程序其他站点的调用边数为7,179,021，这意味着ERDDG表示能够识别+ 89.87％的将程序控件转移到边上。

C.可伪造请求

检测客户端CSRF的第一步是识别可以生成攻击者控制的请求的代码行。为此，准备了一组查询。根据威胁模型考虑了由攻击者控制的JavaScript程序的不同输入，这些输入可以由不同的攻击者伪造。

JAW在可发送HTTP请求的106个应用程序中识别出49,366行代码，并将其中36,665行标记为在页面加载期间无法访问或未使用攻击者控制的输入。其余的12,701个请求可以由攻击者控制。将这些请求按照对应于不同攻击者的输入源的语义类型进行了分组，如下表所示。注意到大多数应用程序（即87个）在页面加载时发送至少一个可伪造的请求。

误报：考虑到大量可伪造的请求，无法通过人工检查来验证所有请求。相反，首先选择所有组中的所有请求，但DOM.READ除外。然后，对于DOM.READ，集中于针对每个Web应用程序的一个请求（随机选择），即83个请求。总共检查了516个可伪造的请求。为了进行检查，在检测到的浏览器中加载了易受攻击的页面，以注入操纵的字符串，并观察传出的请求是否包括操纵的字符串。除了83个DOM.READ请求之一之外，所有请求都包含操纵的内容。经过仔细的调查，发现由于对上下文敏感的this关键字的指针分析不正确而导致误报，此关键字具有运行时绑定，并且对于函数的每次调用可能有所不同，具体取决于该函数的方式调用，例如，动态调用的函数，或使用调用和应用方法的层次结构的不同调用参数导致此操作的不同绑定。

利用：接下来为515个请求寻找了实际的利用方法。在这些实验中，假设所有输入源都为Web攻击者模型，但Cookie除外，假设其为网络攻击者模型。能够为影响七个Web应用程序的203个可伪造请求生成可利用的漏洞，它们全部使用WIN.LOC的数据值，任何网络攻击者都可以伪造该数据。对于其他组请求，无法找到漏洞利用程序。在手动寻找漏洞时很难达到完整性，因为这样的任务需要广泛的Web应用程序知识来识别目标URL和攻击者可以注入恶意负载的点，找不到漏洞利用程序这一事实并不意味着该漏洞利用程序不存在。对于这些情况，确认JavaScript代码通过无条件处理来自不同数据结构的数据值来发送HTTP请求。攻击者最终可能会找到一种在这些数据结构中注入恶意有效载荷并利用这些可伪造请求的方法。

D.可伪造请求分析

在本节中将详细研究攻击者可以对上表伪造请求进行的操作程度。提取了发送可伪造请求的代码行的堆栈跟踪，并从三个方面描述了易受攻击的行为：请求字段，操作类型和请求模板。

请求字段：首先，可以操作的请求字段可以确定漏洞的严重性。例如，如果攻击者可以更改请求的域名，则可以使用客户端CSRF进行跨域攻击。根据被操纵的字段将Web应用程序分为四类，发现在9，34、41和41个Web应用程序中，攻击者可以操纵URL域，URL路径，URL查询字符串和body参数。 同样，根据可以在请求中处理的字段数将应用程序分组。总共有55、34和12个应用程序允许分别修改一个，一个以上和所有字段。

操作类型：影响严重性的另一个因素是在一个或多个字段中复制操作值的操作。发现28个应用程序允许攻击者更改一个或多个字段的值。同样，有38个和28个应用程序允许攻击者通过将攻击者控制的字符串分别添加和添加到最终字符串来添加一个或多个字段。

可伪造的请求模板：通过模板对HTTP请求进行特征化，在模板中对可以操作的字段的类型和数量以及操作的类型进行编码。上表列出了所有模板，对于每个模板，它显示了匹配请求和使用它们的Web应用程序的数量。总共确定了25个不同的模板。观察到，大多数Web应用程序在其所有网页上仅使用一个模板（即68个应用程序）或两个模板（即17个应用程序）。

E.利用和攻击

203个可利用的客户端CSRF影响七个目标，如下所示。 漏洞利用与传统CSRF相同的方式攻击Web应用程序，即通过执行与安全性相关的状态更改请求。 此外，发现利用客户端CSRF的XSS和SQLi攻击是无法通过经典攻击向量来利用的。

SuiteCRM和SugarCRM：总共在SuiteCRM和SugarCRM中发现了115和38个可伪造的请求，这些请求可被利用来破坏服务器的完整性。 在这两个应用程序中，JavaScript代码均读取哈希片段参数（例如ajaxUILoc），并将其逐字用作提交异步请求的端点。 攻击者可以向状态更改服务器端端点发出任何任意请求，以删除帐户，联系人，案例或任务。

203个可利用的客户端CSRF影响七个目标，如下所示。我们的漏洞利用与传统CSRF相同的方式攻击Web应用程序，即通过执行与安全性相关的状态更改请求。此外，我们发现了利用客户端CSRF进行XSS和SQLi攻击的方法，而传统的攻击向量无法利用此方法。

SuiteCRM和SugarCRM。总共，我们在SuiteCRM和SugarCRM中发现了115和38个可伪造的请求，这些请求可被利用来破坏服务器的完整性。在这两个应用程序中，JavaScript代码均读取哈希片段参数（例如ajaxUILoc），并将其逐字用作向其提交异步请求的端点。攻击者可以向状态更改服务器端端点发出任何任意请求，以删除帐户，联系人，案例或任务，仅举几个我们手动确认的实例。

Neos：在Neos中发现了8个可伪造的请求。在所有这些参数中，HTTP请求的每个参数p都源自页面的URL参数moduleArguments [@p]。例如，拥有后端服务器用来将请求路由到内部模块的action和controller参数。这种行为使攻击者可以将请求定向到任何有效的内部模块，包括实现状态更改操作的模块。例如，利用此行为从文件系统中删除资产。

Kibana：发现了一个由Timelion生成的可伪造请求，该请求是Kibana的一个组件，将独立的数据源组合并可视化。 Timelion允许使用自己的查询语法在数据源上运行查询。 JavaScript代码可以从页面的URL片段读取查询，并将查询传递给服务器端。结果，攻击者可以在未经受害者同意或不知情的情况下执行恶意查询。

Modx：在Modx中发现了20个可伪造的请求，可以通过两种不同的方式对其进行利用。首先，Modx的JavaScript从页面URL的查询参数中获取URL字符串，并逐字使用该字符串来提交带有有效反CSRF令牌的异步请求。与SuiteCRM和SugarCRM相似，攻击者可以向状态更改服务器端端点伪造请求。同样，在一个可伪造的请求中，Modx在客户端请求中复制页面的URL参数，该参数会在响应中反映出来并插入到DOM树中，从而使攻击者可以使用客户端CSRF来安装客户端XSS。根据手动评估，攻击者只能通过客户端CSRF来利用客户端XSS。

Odoo：发现了一个可伪造的请求，该请求使用URL片段的id参数加载数据库实体。发现服务器在未经正确验证的SQL查询中使用此参数，从而导致SQLi漏洞。注意到由于使用了反CSRF Token，如果不先利用客户端CSRF漏洞，就很难通过直接请求来利用SQLi漏洞。

Shopware：发现页面加载时Shopware发送了20个可伪造的请求。该代码将页面的URL哈希片段映射到传出请求的不同部分。首先，代码将哈希片段的第一个片段用作传出请求的URL路径。然后，它将剩余的片段用作传出请求正文的参数。例如，这使攻击者可以删除商店目录中的产品。

F.动态快照影响

本文设计并进行了其他实验，以显示动态快照对漏洞检测和HPG构建的影响。

（1）漏洞检测

使用JAW-static重复了评估，并将结果与JAW进行了比较。 JAW-static总共发现了48,543个请求，其中11,878个据报告是可伪造的。通过比较差异，观察到JAW-static已检测到840个较少的可伪造请求（即下限为+ 7.07％漏报性）。在840个漏报中，有161个是本研究发现了利用的漏洞，即，JAW-static未检测到JAW检测到的可利用客户端CSRF漏洞的79.3％。此外，JAW-static报告了另外17个不容易受到攻击的案例（即误报率下限为+ 0.15％）。手动检查了所有误报和漏报案例，以发现潜在原因。

误报（FP）：在17个FP中，有12个是由于不存在动态获取的代码（即，通过动态插入脚本标签）而导致，在动态代码中，污染变量的值发生了变化。 JAW中消除了此类FP，因为它利用DOM树和HTTP消息监视程序执行。然后，在这17种情况中，有3种是由于随后使用具有动态生成的字符串的动态代码评估构造删除了事件处理程序。最后，最后两个FP发生是由于从DOM树中删除了元素，因此隐式删除了它们的事件处理程序。同样，此类FP不会随JAW一起发生，因为它在运行时监视触发的事件及其处理程序。

漏报（FN）：观察到几乎有一半的FN（即405）是由于漏洞位于动态加载的代码中而发生的。对于78个和7个FN，针对DOM查询的指向分析不准确，因为分别需要DOM树的状态和环境变量进行此类分析。剩下的350个FN源自JavaScript程序使用setTimeout和eval通过在运行时生成代码来触发事件。

（2）HPG的构造

总计，JAW静态生成了4,836个HPG的498,054,077个节点和639,323,601个边，比JAW（漏报）少10,756,335个节点（-2.11％）和13,338,972个边（-2.04％）。在所有丢失的边中，有1,048,172个是对建模事件至关重要的ERDDG边，其余的12,290,800个边是AST，CFG，PDG和IPCG边。此外，JAW-static错过了16,710个边属性（在ERDDG注册边上设置），这些边属性标记了是否在运行时触发了事件处理程序，而未使用静态分析进行标记。
进行了其他实验之后，记录了JAW无法映射到其代码行的触发事件。 JAW总共在运行时观察到了4,974个HPG中的51,974个事件，其中34,808个已经被静态分析标记并被动态触发。其余的17,166个事件在运行时触发，而未被纯静态分析捕获。在17,166个事件中，JAW无法在代码中找到456个事件的相应事件处理程序（0.88％），这表明HPG中的FN节点和边。手动分析显示，大多数情况（387个事件）的原因是使用eval和setTimeout函数以及动态构造的字符串来触发事件。由于代码的动态加载以及JAW不监视的方式（例如，从iframe内部加载代码），其余69个事件未映射。

最后，当执行DOM查询的指向分析时，评估DOM树快照的使用所引入的FP和FN边。 JAW总共在4,836个HPG中遇到了241,428个DOM查询选择器，其中127个选择器（0.05％）中JAW不精确地解析了查询所指向的DOM元素。为了确定ERDDG派发边，JAW将总共87,340对DOM查询选择器的指针相互比较（即，在一个DOM查询选择器上分派的事件链接到其事件处理程序，该事件处理程序使用另一个查询选择器进行事件注册）。评估表明，JAW在87,212个案例（决策准确度为99.85％）中准确地决定了连接分发站点与注册站点之间的分发边，其中有56,923个真阳性和30,289个真阴性。在其余的128种情况下，JAW决定是否创建边线是不准确的，有94 FN和34 FP边（决策不准确度为0.15％）。

观察到查询选择器可能会出现这样的FP和FN边，这些选择器在页面加载的53.7毫秒（平均）之内（最大）为92.5毫秒。比所有查询选择器的平均访问时间低十倍，即559.2毫秒。在本实验中，使用运行时程序工具获取了评估JAW在HPG施工中的准确性的基本事实。但是，这样的技术会带来性能上的损失，并且不适用于大型HPG（例如，在模型构建和漏洞检测中），DOM快照对JAW FP和FN边的影响可以忽略不计。

0x06 讨论

客户端可伪造请求的属性：在本文中表明82％的Web应用程序至少具有一个带有客户端可伪造请求的网页，可利用该网页发起CSRF攻击，这表明可伪造请求很普遍。还展示了客户端CSRF可用于发起其他攻击，例如XSS和SQLi，这些攻击无法通过传统的攻击媒介进行装载。然后，对可伪造请求的分析表明某些客户端CSRF模板比其他客户端更普遍，例如，在28.7％的易受攻击的应用程序中，攻击者可以覆盖请求正文中的参数。

脆弱应用程序的特性：发现测试平台上的106个目标中有39个是单页应用程序（SPA），即36.7％。手动检查了87个易受攻击的目标，发现其中有44.8％是SPA的目标。另外，在17.9％的经过测试的SPA中发现了漏洞利用（§5.5）。这揭示了客户端CSRF实例在SPA应用程序中更为普遍的事实。

控制权转移和运行监视：评估表明，动态信息使控制路径的传输增加了0.26％。尽管评估可以忽略不计，但评估显示，动态信息对于识别87个易受攻击的应用程序中的14个和7个可利用的应用程序中的3个的可伪造请求至关重要（分别增加了+ 19.1％和+ 75％）。

漏洞源自相同代码：对515个可伪造的HTTP请求的手动分析显示，每个漏洞都源自跨多个页面使用的同一代码的不同副本。每个应用程序的漏洞模板范围为一到四个，而大多数应用程序（即78.1％）只有一个模板。这些事实表明，开发人员倾向于在不同页面上重复相同的错误。

误报：观察到，将状态值与传统的静态分析一起使用将有助于消除虚假的执行轨迹。但是广泛的手动验证发现，由于动态调用函数中此语句的指针分析不准确，因此1/516请求是错误肯定的。观察到这样的请求正在使用源自DOM树的数据值，这意味着DOM-READ可伪请求类别的1/83请求可能是误报。计划在将来通过将this关键字的对call敏感的解析合并到JAW中来解决此缺点。

局限性：本文中发现的漏洞是本研究模型和遍历所捕获的漏洞。但是，由于模型的构建受到用于构建属性图的单个静态分析工具，例如CFG，PDG。由于JavaScript程序的流性质和JavaScript动态代码生成功能，通过静态分析准确地构建这些模型是一项具有挑战性的任务。与先前的工作类似，只要字符串参数可以静态重建，JAW就会提取由动态结构执行的代码，即eval，setTimeout和new Function( )。作为未来的工作，计划用改良的JavaScript引擎（例如VisibleV8）替换扩展，以更好地支持反射和这种动态构造，并最大程度地减少函数挂钩的潜在副作用，尤其是对于到事件处理程序。此外，本文中发现的漏洞会影响JAW通过爬虫到达的那些页面。但是，爬取是一项艰巨的任务，并且JAW可能丢失了带有易受攻击代码的页面。为了扩大覆盖范围，计划为其他爬网程序的平滑集成提供支持。

增量静态分析：JAW可以通过预先构建的符号模型将分析客户端JavaScript程序所需的工作减少60％。查看独特的应用程序代码时，发现页面之间也共享了很大一部分代码。例如，4,836个页面总共包含104,720个应用程序脚本，其中只有4,559个是唯一的，这表明不同网页的共享代码可以一次建模，并可以通过增量程序分析进行重用，这是计划在将来解决的问题。

0x07 总结

在本文中，JAW是用于检测和分析客户端CSRF漏洞的第一个工具。 JAW的核心是HPG的新概念，它是用于客户端JavaScript程序的规范，静态+动态模型。 对JAW的评估发现了12,701个可伪造的客户端请求，这些请求影响了87个Web应用程序。 对于其中的203个，针对七个应用程序创建了一个可利用的漏洞，可用于破坏数据库完整性。 本文分析了可伪造的请求，并确定了25种不同的请求模板。 这项工作已经成功地证明了范例检测客户端CSRF的功能。