链锯：基于链接的自动化工作流漏洞生成

摘要

我们解决了web应用程序的自动漏洞生成问题。在这方面，我们提出了一种方法，该方法显著提高了web注入漏洞识别和漏洞生成的技术水平。我们的漏洞生成方法解决了与典型web应用程序特征相关的各种挑战：它们的多模块特性、插入式用户输入和使用数据库后端的多层体系结构。我们的方法开发应用程序工作流、数据库模式和本机功能的精确模型，以实现高质量的漏洞生成。我们在一个叫做链锯的工具中实现了我们的方法。Chainsaw被用于分析9个开源应用程序，并生成了199个一阶和二阶注入漏洞，大大优于几种相关方法。

关键词

漏洞生成；网络安全；注入漏洞

1.简介

Web应用程序是推动现代电子商务和银行应用程序的引擎。因此，这些应用程序的安全性是一个重要问题。这些应用程序中任何可利用的漏洞都可能给在线企业带来巨大的经济损失，也可能给消费者带来隐私损失。漏洞分析研究工作试图在攻击者利用漏洞之前主动暴露这些应用程序中的缺陷，因此从防御角度来看，这是至关重要的。

注入脆弱性分析工作大致分为两类：渗透测试方法和基于程序分析的方法。其中，渗透测试工具通过在应用程序中注入输入（类似于常见的漏洞字符串）来检查是否存在漏洞数量。虽然它们易于部署，但它们缺乏对应用程序的广泛覆盖，因此漏掉了漏洞。事实上，最近的研究表明，这些工具的覆盖率很低。

静态分析方法不存在覆盖问题，而是基于对应用程序代码的更直接的探索。特别是，他们专注于识别应用程序中某些敏感汇的属性。有大量工作（例如，[17]、[20]、[28]、[26]、[9]）用于识别SQL注入（SQLI）和跨站点脚本（XSS）等web应用程序漏洞。然而，由于在建模复杂语言特性时需要考虑技术和工程方面的因素，静态分析工具经常会出现误报。

近年来，一个备受关注的方向是自动漏洞生成：将静态分析工具产生的潜在漏洞转化为具体漏洞的方法。由于漏洞利用是对应用程序的实际输入，可以进行验证，并且在大多数情况下是自动的，因此漏洞利用查找有可能消除静态工具中的错误警报。

在本文中，我们在web应用程序设置中寻求一种自动漏洞生成方法。也就是说，给定一个应用程序，目标是自动构造一系列恶意HTTP请求输入，将应用程序的执行指向易受攻击的接收器。考虑到web应用程序的多模块和多层特性，自动利用漏洞生成的问题与[1，15]中研究的二进制应用程序的问题截然不同。

我们在本文中的主要贡献是一种漏洞生成技术，它能够“链接”一系列HTTP请求，当按顺序发出时，这些请求会将应用程序的执行指向易受攻击的接收器。请注意，接收器可能深入嵌套在应用程序的模块结构中，只有通过提供从公共可访问模块开始的输入序列才能访问该应用程序，并且此类路径可能经常查阅存储在持久存储中的数据。

我们的方法的出发点是静态分析：基于符号执行沿着web应用程序的路径创建web应用程序行为的模型。从这里开始，必须克服两个可扩展性挑战，才能成功发现利用漏洞。第一个涉及路径选择：我们必须探索哪些路径才能使机会主义剥削产生成功？我们的方法可以观察到，通过使用路径的约束解决成本，可以对路径的遍历进行优先排序，这样我们就可以有效地识别导致成功利用的路径。

第二个问题是关于持久性数据库状态：如何处理沿着所探索的路径可能存在的数据库查询。在二阶攻击创建的背景下，这个问题变得尤为重要，例如，一个易受攻击的查询被用来存储一些随后从（第二个）漏洞接收器读取的数据。我们的方法使用静态和动态技术来处理持久数据库状态。

我们的方法是在一个名为Chainsaw的工具中实现的，据我们所知，它是第一个生成跨多个HTTP请求的注入攻击的工具。链锯是为PHP语言构建的，但其背后的概念是通用的，适用于其他web平台。Chainsaw利用应用程序工作流结构、数据库模式和PHP本机函数的精确建模来实现成功的漏洞检测，并能够检测二级漏洞。Chainsaw在9个不同复杂性的PHP web应用程序上进行了测试，产生了199次漏洞利用，包括30次二阶漏洞利用，并且从设计上看没有误报。对相关工具结果的详细比较表明，链锯可与其他最先进的方法相比，并且在大多数情况下表现显著优于其他最先进的方法。

本文组织如下：第2节提供了漏洞检测的背景、运行示例和相关挑战。我们在第3节对我们的方法进行了高层次的概述，并在第4节对其实现进行了讨论。我们将在第5节讨论我们的实验和结果。相关工作在第6节中介绍，我们在第7节中总结。

2.背景和挑战

假设和目标：我们假设分析系统可以完全访问web应用程序的源代码。为了测试漏洞利用，我们假设分析系统也有一个正常的安装，并具有适当的登录凭据。它可以通过向应用程序发送请求并观察结果来测试应用程序上生成的任何输入。目标是构造一系列恶意HTTP请求，将应用程序导航到易受攻击的接收器，以执行SQLI或XSS攻击。这些攻击的目的是从数据库中过滤信息、在数据库中注入恶意内容或获取窃取客户端内容（如cookie）的能力。

问题定义：当恶意内容通过查询注入到数据库（SQLI）或到达将内容（即代码）发送到客户端（XSS）的类echo语句时，利用此漏洞的攻击就会成功。要触发此类行为，恶意内容必须沿着从输入开始的某个路径到达或影响一个或多个敏感接收器的执行。在web应用程序中，这些指向接收器的路径可能跨越多个模块（PHP中的服务器端脚本，类似于Java中的servlet），攻击者可能需要向所有这些模块发送恶意输入。

漏洞生成问题可以正式表述如下：给定一个web应用程序，找到一系列对（（M1，IE1），（M2，IE2），。。。，（MN，IEN）），其中每个IEi是必须通过HTTP请求发送到相应模块Mi的输入，以利用MN中易受攻击的接收器。

2.1运行实例

我们将介绍一个聊天室应用程序的示例，本文将使用该示例来说明我们的方法（清单1-4）。该示例包含来自应用程序不同模块的代码片段，包括几个SQLI和XSS漏洞来说明该方法。特别是room.php首先包含一个带有函数定义的文件（第1行）。接下来，它检索用户输入（第4-11行），并使用两个内置函数（第5、12行）清理这些输入。接下来，它将使用经过清理的用户输入版本构建一个SQL查询（第15行）。根据查询结果，将设置超全局 $_SESSION[‘room_name’]（第17行），并执行到dashboard.php，通过调用header函数（第18行）。Superglobals是PHP中的内置结构，可以从所有模块访问。该模块还包含通过HTML表单的自重定向（第21-22行）。

dashboard.php充当web应用程序若干功能的调度程序，例如添加或删除类别、创建聊天室等。清单3显示了addcat.php，它在添加类别之前检查类别是否存在。代码执行第一个查询以检索房间名称和访问级别（第5-6行），如果第一个查询检索到的$accesslevel值等于1，则执行第二个查询以检索第13行。

请注意，清单3第13行的SQL查询有一个SQLI漏洞，因为htmlspecialchars没有转义单引号，这使得查询容易受到任何具有单引号的攻击模式的攻击，例如1’或“1”='1。其他select查询（清单1中的第15行，清单3中的第5行）不包含此类漏洞，因为它们的输入由一个更强大的清理功能（清单1中的第12行）清理。最后一个代码段包含一个insert查询，它在ROOM\u表中插入不同聊天室的值。请注意，此查询的输入也没有得到充分的清理。

2.2漏洞利用生成难题

复杂的工作流：通常，易受攻击查询的执行取决于应用程序工作流，即访问模块的顺序以及这些模块之间的共享状态。通常，web应用程序中可以有多个导航序列。其中一些可能代表预期的工作流，其中模块执行的顺序遵循开发人员设想的工作流，而另一些可能是非预期的工作流，攻击者可能会发出任意请求，并从预期的顺序跳过某些模块的执行。请注意，通过在重定向期间更改每个模块在输入中期望的值，也可以利用预期的工作流。例如，在我们正在运行的示例中，在模块addcat中执行易受攻击的查询。php依赖于模块室的执行。php，它设置变量$_SESSION[‘room_name’]的值，该变量在addcat中被选中addcat.php（第1行）。为了能够产生非平凡的漏洞利用，一种方法必须考虑各种可能的工作流，包括预期的和非预期的。

数据清理和路径敏感度：要生成有效的利用漏洞，必须精确建模用户输入沿不同路径到接收器的转换和清理。例如，尽管示例包含多个查询，但由于对指向它们的某些路径的清理不足，其中只有两个查询易受攻击。例如，清单4中通过第6行的路径不易受攻击，而通过第4行的路径易受攻击。因此，我们的做法必须考虑到沿着敏感接收器的路径进行清理，并生成这些清理无法阻止的漏洞利用。

持久存储效果：数据库状态是自动构建有效利用漏洞的另一个重要方面。事实上，存储在数据库中的值是应用程序的额外输入，在执行期间会影响其控制和数据路径。例如，在正在运行的示例中，清单3第13行中易受攻击查询的执行取决于$accesslevel的值，该值由以前的查询从数据库中检索。因此，我们必须能够考虑从应用程序到数据库的控制流和数据流，反之亦然。

在下一节中，我们将详细介绍解决这些挑战的方法。

3.方法

为了成功地生成漏洞，我们需要应对规模的挑战：为了使机会主义漏洞生成成功，我们必须探索哪些途径？我们的方法观察到，可以根据路径的约束求解成本对路径进行排序，并从那些需要最少分析和求解复杂性的路径开始构建漏洞利用。

如图1所示，我们的总体方法是在最初的分析步骤中获得更大的覆盖率，并在随后的三个步骤中构建工作利用率。第一步称为种子生成，将每个模块单独考虑，并根据其输入建立精确的计算模型。具体而言，该方法生成利用种子，这是一组经过验证的输入，将执行定向到模块内易受攻击的接收器。种子生成是模块的局部生成，在方法的后续阶段（即工作流推理和工作流细化）受详细的攻击规范和数据库模式规范的指导，我们使用受限的探索策略，重点是派生一系列HTTP请求，引导攻击者沿着一系列模块到达上一步生成的一个漏洞种子。这是通过有选择地探索应用程序路径子集的方法来实现的，以便生成漏洞利用。在接下来的小节中，我们将提供这些步骤的详细视图。

3.1种子生成

此阶段的目标是确定可用于漏洞利用的汇，并删减不易受攻击的敏感汇。具体而言，利用种子是一对（S，I），其中S表示易受攻击的敏感接收器，I={（i1，v1），…（in，vn）}是必须发送到包含S的模块的输入中的变量值对集，以便利用S。此阶段的输出是应用程序各个模块中存在的利用种子列表。由于这一阶段只是我们方法的起点，我们将其讨论保持简短。

对于模块内的每个接收器，链锯以符号方式探索从源（即该模块的用户输入）到该接收器（即mysql query（）和类echo函数）的所有执行路径，并为每个接收器构建符号接收器表达式和符号公式FP。在符号接收器表达式中，数据参数表示为程序常量或符号值，这些值是通过对接收器中使用的变量执行的操作计算出来的。换句话说，符号执行为静态（数据参数为常量）和动态接收器（数据参数为变量）。
复杂的工作流公式FP表示（1）路径条件，（2）沿接收器路径的输入转换，以及（3）接收器上下文产生的约束。最后，将每个符号公式FP与攻击规范FA连接，该规范包含对汇处变量值的约束。例如，与清单3第13行的接收器相关的符号公式FP和可能的攻击规范FA如下所示：

我们对符号汇和公式的分析是基于我们过去的工作[6]。基于对系统依赖关系图（SDG）执行过程间切片，它是过程间的、路径敏感的以及上下文敏感的。对于每个接收器，相应的SDG捕获所有构建查询（数据依赖）的程序语句，并控制这些语句之间的流。然后，我们计算汇的反向切片，以便每个切片表示从源到汇的唯一控制路径以及路径条件。当此路径包含静态单一赋值（SSA）形式的语句（这是我们分析的第一步）时，构建符号公式的上述组件（1）和（2）是很简单的（第4.1节中讨论了上述组件（3））。

在这一点上需要提到的一个重要细节是，模块中存在的任何PHP超全局在这一阶段都是不受约束的，从而使分析成为模块的局部分析。这些超全局变量可以在此模块中进行约束，但也可以在其他模块中进行赋值。例如，在模块室中。php超级全局$\u会话[‘username’]受到约束，但在登录中设置。php。要成功利用利用利用种子，链锯必须找到一系列模块执行，这些模块执行会产生对超全局的适当分配，以便将执行定向到种子接收器。我们将在下一节中解释此过程。

3.2导航问题

这个问题可以表述如下：给定模块MN中的一个利用种子，是否有沿着模块导航序列（M1，…，MN）的执行路径满足利用种子的约束？在本文的其余部分中，我们将这种执行路径称为跨越导航序列（M1，…，MN）全局执行路径的执行路径。全局执行路径基本上由属于每个模块Mi的本地执行路径的串联组成。例如，在addcat的第13行中触发漏洞攻击。php，一种本地执行房间的路径。必须首先执行php，然后是来自仪表板的本地执行路径。php，最后是addcat中的本地执行路径。php。
这个问题的主要挑战之一，实际上也是链锯的主要瓶颈，是每个利用种子需要考虑的全局执行路径的数量。该数目取决于指向包含该漏洞种子的模块的导航序列的数目以及每个模块内的本地执行路径的数目。更具体地说，给定模块MN内的漏洞利用种子，每个导航序列（M1，…，MN）包含的全局执行路径数量等于每个模块中本地执行路径数量的乘积。在最坏的情况下，必须在搜索过程中计算和处理这些全局路径。因此，为了优化可行路径的搜索，链锯根据可能的导航序列的全局执行路径数以递增的顺序对其进行有效排序，并基于此顺序选择下一个可能的导航序列。这种选择背后的直觉是能够在每单位时间内处理尽可能多的导航序列。

具体来说，链锯首先构建一个称为通用工作流图（GWFG）的导航图，该图表示所有可能的导航序列，并从该图中导出导航序列的排名。接下来，对于每个导航序列，Chainsaw构建一个优化的工作流图（R WFG），其目标是允许搜索满足利用种子的全局执行路径。我们将在下面解释这两个步骤。

3.2.1工作流推理

通用工作流图（GWFG）是一个加权有向图G=（V，E），其中每个顶点V∈ V表示web应用程序的一个模块，每个边缘e=（vi，vk）∈ E表示从vi到vk的导航。每条边上的权重e=（vi，vk）表示链锯在导航序列中探索该边时产生的成本（随着全局执行路径数量的增加）。具体而言，为了构建按全局执行路径数量排序的导航序列列表，我们在GWFG上使用k最短路径算法[11]，该算法在给定加权有向图的情况下，找到按路径成本排序的两个节点之间的k条最短路径。为了将k条最短路径算法的成本定义作为沿边的权重之和与链锯的成本定义作为沿边执行路径的乘积相协调，在GWFG中，我们为每条边指定了一个等于log2（nk）的权重，其中nk是vk中的执行路径数。

例如，在图2中，它代表了我们的示例（还有一个附加模块：check.php），房间之间有两个导航序列。php和创建。php，一个通过仪表板。php，总成本为10（=210=1024全局执行路径），一个通过检查。php，总成本为12（212=4096个全局执行路径）。因此，链锯首先处理前者，因为它的全局执行路径较少。

GWFG是通过识别负责导航的代码中的语句（例如HTML表单、链接、PHP重定向等）及其目标，并相应地向图中添加顶点和边来构建的。简而言之，GWFG表示应用程序中所有可能的导航序列。

工作流推理模块的输出是一组按可能的全局执行路径总数排序的导航序列。下一阶段处理每个序列，以找到满足利用种子约束的全局执行路径。

3.2.2细化的工作流图

一旦选择了导航序列（M1，…，MN），链锯的下一个任务就是在该序列内找到一个全局执行路径，该路径将导致利用漏洞种子。我们注意到，这个全局执行路径是由导航序列中每个模块内部的执行路径串联而成的。

为了提取全局执行路径，Chainsaw为每个导航序列构建了一个优化的工作流图（RWFG）。RWFG是一个有向图G=（V，E），其中每个顶点表示序列中一个模块的局部执行路径，每个边E=（vi，vj）∈ E表示从一个本地执行路径到另一个本地执行路径的转换，即执行路径vj（在模块Mj中）遵循执行路径vi（在模块Mi中）。因此，全局执行路径对应于R WFG上的路径。

图3的左半部分显示了R WFG的一个实例，它表示导航序列（room.php、dashboard.php、addcat.php）。在此图中，每个模块由一组节点表示，其中每个节点表示一个本地执行路径（对于空间约束，我们不显示所有本地执行路径）。该序列的全局执行路径由R WFG路径（L2、A3、D2）表示。

如前所述，每个利用种子需要考虑的全局执行路径的数量是链锯的主要瓶颈。通过从RWFG中删除那些明显不可行的边，我们可以显著减少此数量。换句话说，如果我们可以证明一个模块中的本地执行路径Ai不能遵循另一个模块中的另一个本地执行路径Li，那么我们可以从R WFG中删除相应的边。为此，链锯首先为R WFG的每个顶点vi构建路径摘要。此摘要包括对vi表示的路径中的超全局变量的赋值。接下来，链锯为每个顶点vj收集一组先决条件。此集合包含沿vj表示的路径检查的条件。如果vi的路径摘要与vj的前提条件不一致，则使用这两个集合，链锯不会连接vi和vj。当我们无法确定任何不一致时，我们连接两个顶点。作为一个示例，图3中的表显示了一个可能的全局执行路径的摘要和前提条件，该路径导致addcat中存在漏洞的接收器。php。

对于每个指向漏洞接收器的全局执行路径，链锯都会创建一个符号公式，表示沿该全局路径的计算和条件。接下来，它使用漏洞利用种子的上下文将攻击规范的约束添加到此符号公式中（有关上下文感知的详细信息，请参见第4.1节），并使用解算器寻找解决方案。解算器解决方案（如果找到）包含所有局部和超全局变量的值，这些变量需要发送到导航序列中的每个模块，以便到达利用种子。

3.3二级漏洞利用

web应用程序的后端数据库是一个重要组件，它包含了该应用程序状态的很大一部分。这种状态通常会驱动应用程序内部的控制和数据流。创建符号公式时，链锯通过添加表示数据库值的约束来包括数据库的状态。处理数据库状态的主要挑战是它总是在不断发展，因此利用它可能变得可行或不可行。

此外，数据库还可以用作二阶攻击的通道，例如二阶SQLI和存储XSS。在这些攻击中，使用SQL敏感接收器在数据库中输入特定内容，目的是在从数据库中检索后到达第二个敏感接收器。第二个接收器可以是另一个SQL查询接收器或XSS接收器。

链锯的主要优点之一是它能够精确地建模数据库状态。此功能可以更精确地生成一阶和二阶漏洞。接下来，我们将介绍链锯使用的技术。

静态输入生成：通常，在敏感接收器上利用漏洞的可行性取决于指向该接收器的路径上的条件，该条件取决于数据库状态。例如，清单3第13行中的查询的执行取决于PHP变量$accesslevel的值，这反过来又由第5行中的查询从数据库中检索。显然，如果数据库中房间级别的值不等于1，则执行将不会继续。

为了确保生成的漏洞利用是可行的，链锯会在需要时为数据库生成新的值。更具体地说，链锯首先（在分析过程中）在对数据库的写入（插入和更新查询）和从同一个表读取的select查询之间构建映射。使用此映射，Chainsaw标识可用于在数据库中插入所需值的write语句。例如，插入列级别值的插入查询如清单4所示。

作为下一步，链锯构造输入，这些输入将使应用程序在数据库中插入所需的值。更具体地说：（i）它将该写操作设置为接收器，并导出相对于该接收器的公式FP，（ii）表示要插入的所需值的约束公式FD，以及（iii）发送公式FP∧ FD到解算器。在我们的例子中，我们要求解算器提供所需的输入值，以便在清单4的第10行的插入查询中为变量$level指定值1。

对于生成二阶漏洞，过程类似。请注意，对于二阶攻击，通常有两个感兴趣的敏感接收器。第一个接收器是写查询，它在数据库中插入有效负载。第二个接收器是另一个查询或语句，它使用有效负载数据而不进行适当的清理（例如，在二阶SQLI或存储的XSS中）。对于二阶漏洞生成，上述过程中的一个小补充是，Chainsaw使用适合在第二个接收器生成漏洞的攻击规范FA。

动态审核：除了在数据库中插入数据的静态输入生成之外，链锯还能够通过在符号执行中包含its状态产生的约束来使用活动系统的现有数据库数据。我们称这种能力为动态审计。更具体地说，Chainsaw在三个步骤中扩充了符号公式：（1）DB-PHP映射：通过分析符号查询，在PHP变量和相应表的列名之间创建映射。在某些情况下，这些映射可以直接从WHERE子句构造中推断出来，WHERE子句构造将数据库列名与PHP变量名连接在一起（例如，WHERE room\u name='room.PHP中的KaTeX parse error: Can't use function '\u' in math mode at position 5: room\̲u̲ ̲name'），而在其他情况下，…room\u row[‘level’]映射到addcat.PHP中的数据库列级别）。（2） 数据检索：创建映射后，通过删除WHERE子句并在同一个表上运行（Select*）查询来修改查询。这可以确保从数据库中检索到所有可能的值。（3） 约束创建：在当前路径公式FP中添加一个新术语TD，表示对从数据库派生的PHP变量值的约束。

为了演示上述过程，让我们考虑清单3中的查询：从room\u表中选择room\u name，level，其中room\u name=“$room\u name”。假设ROOM\u表具有以下属性记录（level，ROOM name）：（1，room1）和（2，room2）。在这种情况下，我们获得以下条款：
虽然静态输入生成是一种通用技术，但它可能会产生很大的开销。例如，考虑为插入查询Q1生成输入的常见问题，以便为集中的每个查询Qi生成一个可行的漏洞，每个都依赖于Q1。对于静态输入生成，Q1的输入生成过程（即路径探索、符号评估和约束求解）必须重复QI的次数，而对于动态审计，则不需要这样的输入生成，因为数据可以直接从数据库中检索。隐喻地说，动态审计类似于记忆，以前计算的结果在需要时被缓存和重用。然而，动态审计的缺点是，所获得的漏洞利用仅适用于特定的数据库实例。

对于数据库最初是从代码（例如，一系列插入查询）而不是从外部数据输入过程填充的应用程序，静态输入生成可以看到插入的元组，并可以生成相应的约束。因此，对于这些应用程序，从动态审计中获得的结果与从静态输入生成中获得的结果等效，具有开销较小的优点。

4.实现

我们的实现是在Pixy[18]和TAPS[6]的基础上编写的，用于源代码分析，Z3[10]用于约束求解。链锯的输入是web应用程序源、数据库模式和攻击规范。输出是一组HTTP请求，这些请求将利用易受攻击的接收器进行攻击。

4.1上下文感知

符号解析器：链锯以符号方式计算从源到敏感接收器（SQL或XSS）的每条路径，并通过将接收器参数表示为符号值来生成符号表达式。当遇到循环时，链锯会象征性地执行0、1或2次。

为了能够派生这些符号表达式中用户输入的上下文，我们在SQL和HTML解析器之上实现了两个额外的（符号）解析器。我们的两个解析器能够创建符号表达式的抽象语法树，并使用这些树来派生用户输入的上下文。例如，分析通过确定每个变量是单引号、双引号还是无引号来识别接收器中使用的变量的上下文。作为另一个示例，如果符号接收器是一个select查询，并且在WHERE子句中使用了用户输入，那么解析器可以派生用户输入的解析上下文。随后，该上下文用于指导公式FA的扩展，例如，使用表示重言式SQLI的约束。此外，值得指出的是，由于链锯在创建符号公式时自动包含清理函数的语义，因此它具有清理意识。

上下文感知示例。为了查看上下文感知的相关性，让我们考虑清单5中的XSS攻击场景。

对于清单5中的第1行，变量KaTeX parse error: Undefined control sequence: \/ at position 55: …t>alert（'xss'）<\̲/̲script>”都会触发攻击。…color是一个属性的值。因此，在攻击字符串中，必须首先关闭引号和标记包围字符（>），然后再关闭XSS负载（例如“><脚本>警报（'XSS”）</脚本>”）。链锯中使用的符号解析器能够推断这些不同的上下文，并指导构造发送给解算器的最终公式。

4.2通航结构分析

通用工作流图构造。为了构建应用程序的GWFG，我们的方法使用HTML解析器以及为每个模块生成的CFG来提取工作流推理功能：HTTP链接、表单、元标记、IFrame和PHP重定向函数。提取后，链锯创建两个节点，分别表示工作流功能的源模块和目标模块。由于我们的分析是过程间的、上下文敏感的数据和控制流分析，因此可以通过查阅为每个工作流函数生成的数据依赖图来解析工作流函数参数中的变量。虽然GWFG是从HTML和PHP特性构建的，但我们的提取技术可以应用于具有类似函数的语言。

GWFG的知情遍历。遍历R WFG的主要挑战是智能地决定要走哪条路径。在我们的实现中，我们使用了摘要历史的概念，这是一种“记住”遍历历史的机制，并将其用作搜索下一个兼容节点（执行路径）的指南。特别是，对于从节点vi到节点vj的每条边遍历，vi的摘要被添加到摘要历史中（最初为空）。直观地说，RFWG上路径的摘要历史记录是该路径节点的所有摘要的集合。

我们使用此类总结的一个具体示例基于图3。易受攻击的查询位于两条执行路径D1和D2中。如果搜索从L2开始，那么接下来可能要遍历两个节点：A2和A3。我们的搜索技术选择A3而不是A2，因为L2的汇总历史满足A3的前提条件。接下来，搜索将L2和A3的摘要添加到摘要历史记录中，以进一步指导下一个节点的搜索。到达A3后，搜索将检查A3的所有传出边（D1和D2），并重复相同的启发式操作，直到它到达D2中易受攻击的接收器。

这种搜索技术通过只保留可行路径，显著减少了RWFG中的边数过渡。反过来，这提高了在全局执行路径中为深度定位的利用种子生成工作利用的效率。

4.3数据库模式分析

在静态分析中，由于源代码中没有数据库约束，跨持久性存储的数据流建模并不简单。为此，Chainsaw分析数据库模式以捕获数据库施加的其他约束。具体来说，将检索表名和列定义，例如它们的名称、类型和值约束（例如，NOT NULL和length）。

例如，清单6显示了一个insert查询，它似乎很脆弱。但是，如果表TBL中的列var1和var2的类型为enum{1，2}，则该查询将不再可利用，因为数据库将不接受任何其他值。链锯捕获此类数据库约束（例如，（$v11∨ $v1==2）和（$v21）∨ $v2==2），并将它们添加到插入或更新查询中使用的PHP变量中。我们的数据库模式分析能够分析各种基于SQL的数据库模式（例如，MS SQL、MySQL、Oracle等）。

数据库约束的另一个来源是存储过程。要分析这些，我们需要静态分析存储过程以提取约束。我们的实现目前没有这种支持。然而，我们评估的应用程序中没有一个使用存储过程。

4.4约束求解

为了生成漏洞种子和最终工作漏洞，链锯使用Z3 SMT解算器及其插件Z3str。对于每个全局执行路径，链锯会预处理路径信息，以便于转换为解算器规范。为了做到这一点，我们在CFG构建过程中利用了源代码的生成三地址码（TAC）表示。然后将每个TAC语句编码为公式。

翻译注意事项我们的工具识别和翻译二进制和一元PHP表达式、内置PHP函数和条件语句。我们的方法对70个最常用的PHP内置函数的语义进行建模。Z3中对多个字符串操作的支持很粗糙，因此我们使用自己的Z3规范对这些操作进行了扩充，以对内置函数进行建模并推断数据类型。

例如，清单7显示了链锯在Z3中执行的PHP语句KaTeX parse error: Can't use function '\u' in math mode at position 4: cat\̲u̲ ̲desc=htmlspecia…\u GET[‘cat\u desc’））的翻译。此函数用HTML实体编码替换某些字符（例如，单引号、符号）。为了使用解算器语言对该函数建模，我们使用Z3 str Replace函数。由于此函数仅替换子字符串的第一个匹配项，因此链锯会为每个特殊字符的匹配项复制清单7中所示的代码。

5评估

主题应用程序。我们在表1所示的9个PHP应用程序上评估了链锯。这些应用程序的复杂性各不相同，SLOC从323到65302不等。我们的数据集涵盖了链锯两个近距离工作中使用的所有测试对象，即Ardilla【19】和CraxWeb【16】。此外，我们的数据集涵盖了来自多个相关研究的受试者（例如，[9]中的2人、[8]中的1人、[26]中的1人和[3]中的1人）。

设置。链锯部署在Ubuntu 12.04 LTS虚拟机上，每个虚拟机有2个2.4GHz的内核和40GB的RAM。对于每个应用程序，我们首先运行种子生成，然后运行漏洞利用生成步骤。我们自动验证每个漏洞种子和每个工作漏洞，以确保它们到达接收器，并手动确认每个漏洞，以确保漏洞达到预期效果。我们还测量了链锯的运行时间。对于这些应用程序，动态审计模式等效于静态输入生成模式，前者用于提高效率。

5.1结果概述

表2显示了我们的结果摘要。在9个主题应用程序中，Chainsaw共识别出181个漏洞种子和199个无误报的工作漏洞。149（75%）的工作漏洞是SQLI漏洞，50（25%）是XSS漏洞。在所有工作漏洞中，30（15%）是二级漏洞。30次二阶漏洞攻击中有13次是二阶SQLI漏洞攻击，其余17次/30次是存储XSS漏洞攻击。我们在漏洞检测的精度和覆盖率方面优于大多数相关方法（第5.6节）。

5.2选定的一阶漏洞利用

对于WebChes，Chainsaw生成了多个位于不同模块中的SQLI和XSS漏洞利用。其中之一是为viewmessage中易受攻击的查询生成的SQLI漏洞。php（参见清单8）。利用此漏洞，攻击者可以查看其他用户的通信消息。此漏洞的全局导航顺序如下：

生成的约束数为203，漏洞利用生成时间为156秒。该漏洞字符串如附录中的清单21所示。注意，出于演示目的，我们将所有漏洞利用表示为GET请求。

添加CAT2。在DNScript应用程序的php（见清单9）中，攻击者可以向数据库插入恶意域名。添加CAT2。在查询中使用用户输入之前，php不会对其应用清理。导航顺序如下：

链锯为此查询生成了2个漏洞。第一次攻击遵循预期的工作流，路径长度为4。从五个模块收集的约束数为27。由于登录时存在验证码。为了生成有效的漏洞，我们对源代码进行了非常小的更改，以便生成有效的CAPTCHA字符串。Chainsaw为同一查询生成的另一个漏洞遵循较短的程序员意外工作流路径，该路径会命中AddCat2。php（一个可公开访问的页面），漏洞路径长度等于1和3个约束。如前所述，虽然大多数利用路径遵循应用程序的预期工作流，但通过中断工作流可以生成同样可行的利用。在此特定上下文中，备用攻击路径需要访问1个模块（而不是4个模块）。

对于EVE，链锯在两个模块中生成了5个SQLI：案例1：在编辑中。Chainsaw生成了一个SQLI漏洞，路径长度为1（edit.php为public），约束数为40。利用此漏洞可以检索其他成员的信息。清单11（第2行）显示了易受攻击的查询和生成的漏洞（第3行）。

案例2：内部构件。php、Chainsaw生成了4个SQLI漏洞，都是基于更新的查询（见清单12中的示例），攻击者可以在$comment和$name中注入恶意负载。查询中使用的其他变量是安全的，因为MembersMain表中的其他列要么是整数，要么是日期数据类型。链锯将与查询中使用的每个变量相关联的列类型添加到为源代码提取的约束集合中，如第4.3节所述。所有4个漏洞都具有以下导航序列

5.3选择二阶漏洞利用

对于myBloggie，Chainsaw生成了7个二阶SQLI漏洞。清单14和15展示了其中一个漏洞。第一步利用adduser中易受攻击的插入查询。php（清单14），其中KaTeX parse error: Can't use function '\u' in math mode at position 25: …SQLI漏洞。第二步从user\̲u̲ ̲TBL检索用户数据，而不进行清…titolo变量进行足够的清理。第二步发生在leggi。php，其中检索存储在geccBB\u forum表中的所有消息，并将其呈现给用户，而无需进行清理，如清单17所示。此漏洞的导航长度为2（rispondi.php和leggi.php）。生成的约束数为40，漏洞生成时间为13秒。附录中的清单24显示了相应的漏洞字符串。

在Schoolmate上，我们的工具生成了2个存储的XSS漏洞。清单18和19显示了这些漏洞之一。在第一步中，攻击者可以在没有任何身份验证或授权的情况下执行更新查询。应用程序接收攻击者的输入并将其存储在schoolinfo表中，其中schoolname和sitetext两列的类型为varchar（即，如果源代码中未应用清理，则允许使用恶意字符）。在第二步中，当站点的任何用户访问登录时，将执行恶意负载。php。此漏洞的导航长度为2（header.php和login.php）。生成的约束数为150，漏洞生成时间为98秒。该漏洞字符串如附录中的清单25所示。

5.4数据库模式分析的效果

表3显示了我们在链锯中实现的数据库模式分析的贡献。总的来说，链锯在我们的数据集中的9个应用程序中的8个应用程序上，每个应用程序的利用种子生成的误报率平均降低了16%。对于WeBid，Chainsaw的DB模式分析将SQLI种子生成的误报率降低了近60%。请注意，对于Scarf，条目为零，因为我们没有找到它的SQLI种子。

5.5开销和分析复杂性

表4总结了链锯生成漏洞的运行时开销。分析时间从10分钟到600分钟不等。对于geccbblite这样的小型应用程序，解决最终的漏洞利用公式只需不到一分钟，而对于WeBid这样的大型应用程序，则需要大约42分钟。通常，每个模块中可能的执行路径数量和每个应用程序中模块数量的增加会增加分析时间。生成的漏洞所穿越的导航序列的最大长度为2到5个模块。请注意，对于Webid、schoolmate和WebChes，分析时间和求解时间异常长，因为链锯必须分别遍历109万条、193万条和150万条执行路径。对于每个执行路径，我们的系统必须计算符号公式并调用解算器，从而增加分析和求解的开销。

表4：链锯的运行时摘要。分析时间：调用解算器之前的总时间。求解时间：求解所有SMT公式（包括不可满足的公式）的总时间。解释。生成时间：解决表示漏洞利用的可满足SMT公式的总时间。最大长度。导航的。序号：利用漏洞的导航序列的最大长度。

5.6与相关工作的比较

请注意，链锯与之前工作的一对一比较并不容易，因为（i）某些人没有工作工具之前的工作（ii）过时的受试者和（iii）缺乏对结果计算的明确性。尽管如此，只要我们能找到共同点（例如，共同的主题应用程序，相同的攻击类型），我们就会将链锯与之前的工作进行比较。

关于种子生成，我们将链锯生成的种子与[8]、[9]和[26]中报告的漏洞进行比较。在漏洞生成方面，我们将链锯与[19]和[16]进行比较，因为它们的两个数据集都包含在链锯中的测试对象中。表5和表6显示了链锯与这些工程的比较总结。请注意，与其中一些工作不同，我们根据非每条路径的唯一汇的数量来计算种子的数量。例如，对于指向接收器的n条易受攻击的路径，链锯只报告此接收器的一个种子。

种子生成：Wassermann和Su【26】在EVE中发现了5个SQLI漏洞，而Chainsaw生成了7个SQLI漏洞种子，所有这些都已转化为工作漏洞。RIPS[8]在myBloggie中发现了8个SQLI漏洞，而Chainsaw生成了24个SQLI漏洞种子（比RIPS多3倍），因为它执行路径敏感分析，而在RIPS中不可用。

漏洞生成：Ardilla[19]在5个应用程序的数据集上生成了60次攻击（23次SQLI和37次XSS）（见表5）。在同一个数据集上，Chainsaw生成了116个（56个以上）工作漏洞，这表明Chainsaw具有更好的覆盖率。对于XSS漏洞，Chainsaw生成了36个工作漏洞，而Ardilla生成了37个。在SQLI漏洞生成方面，Chainsaw比Ardilla多出47个漏洞，它生成了80个漏洞，而Ardilla只有33个漏洞。关于Ardilla，链锯中XSS漏洞减少1次的原因可追溯到该同学的一个案例。

对于清单20中来自schoolmate的代码片段，Ardilla生成了一个打印接收器漏洞，而Chainsaw将其标记为不可行，因为第1行存在查询。此查询需要返回一些满足where子句的记录，或者模块的执行被终止并且从未到达print语句。但是，Ardilla对$\u POST[选择类]的输入不会使查询返回任何记录，因为courseid列是整数，并且不会接受提供的字符串输入。

在myBloggie上，Chainsaw生成了7个漏洞，而[9]生成了5个二级漏洞。在Scarf上，[9]和Chainsaw分别生成了1个漏洞和工作漏洞。CraxWeb[16]报告了4个应用程序（Schoolmate、Webchess、faqforge和EVE）上共54次漏洞利用（24个SQLI和30个XSS）。在这组应用程序中，Chainsaw生成了106个漏洞利用（74个SQLI和32个XS）。链锯的SQLI漏洞利用率是CraxWeb的3倍，XSS漏洞利用率是CraxWeb的30倍。

5.7讨论

静态分析限制：我们的工具可以处理动态工作流构造，其中参数是沿执行路径定义的变量。但是，如果应用程序代码包含动态生成的工作流功能（例如，使用JavaScript生成的超链接），Chainsaw无法解析此类功能的动态参数。因此，在构建GWFG时，电锯可能无法推断出此类动态边的存在。因此，它可能会丢失模块之间的一些导航链接。然而，在我们的数据集中，我们在所有GWFG中最多遗漏了0.23%的边缘。此外，如果SQL查询或类echo语句的结构（即代码，而不是参数）无法静态构造（例如，由用户输入确定），则链锯无法构造符号接收器表达式。关于符号水槽结构及其局限性的详细讨论可以在我们之前的工作中找到【6】。

解算器失败：在少数情况下，链锯遇到超时或返回未知（即，无法确定公式是否可满足）。在我们的评估中，求解器在求解3463个seed SMT文件中的28个文件时遇到了不可判定性（不到seed SMT文件总数的1%）。此外，解算器在解算45个SMT文件时超时（约占整个seed SMT文件的1%）。

不支持的PHP功能：链锯使用Pixy[18]在PHP web应用程序中进行控制流分析。Pixy不支持某些PHP功能，如动态包含和某些面向对象的功能。因此，链锯无法处理此类特征。然而，在我们的评估中，这些并没有限制链锯对所使用的复杂数据集的适用性。注意，尽管链锯是为PHP实现的（PHP被广泛使用），但我们的方法也适用于其他web平台。

6.相关工作

利用二进制程序生成漏洞。Brumley等人【7】开发了一种自动漏洞生成技术，可识别修补的二进制文件与其未修补版本之间的差异，以生成触发差异的输入。Avgerinos等人【1】开发了AEG，以在二进制程序上生成控制流劫持漏洞。FlowStich[15]通过在二进制程序中连接数据流（假设控制流完整性完好无损）生成面向数据的攻击。所有这些工作都专注于为二进制文件生成漏洞，而我们的方法处理全局导航结构和web应用程序状态。

利用web应用程序生成漏洞。Ardilla【19】使用concolic执行和污染跟踪（包括数据库跟踪）来构建SQLI和XSS攻击向量。Ardilla有三个主要限制：代码覆盖率低（<50%）、简单的攻击库和通过内置函数进行的不精确的污染跟踪。由于使用静态分析、搜索策略和约束解决来分析应用程序导航状态和建模内置的清理功能，Chainsaw在生成的漏洞（二阶SQLI和深度定位漏洞）的数量和复杂性方面优于Ardilla。CraxWeb【16】采用混凝土和约束解算器支持bolic执行，以生成SQLI和XSS漏洞。CraxWeb的代码覆盖率低于链锯，并且不会产生难以构建的二级漏洞。尽管CraxWeb是独立于平台的，但链锯中实现的技术可以扩展并应用于非PHP web应用程序。QED[21]使用Java web应用程序的静态分析和模型检查生成一阶SQLI和XSS攻击。与链锯相反，QED不考虑二阶漏洞利用，它需要用特定语言编写攻击规范。【27】使用PHP应用程序的concolic执行生成暴露SQLI漏洞的输入。它只发现一阶SQLI错误，需要源代码插装，并且不执行数据库分析。EKHunter【12】将静态分析和约束求解相结合，以发现针对犯罪web应用程序的漏洞。与链锯不同，生成的漏洞不会跨越多个HTTP请求。W APTEC【5】针对参数篡改漏洞生成漏洞攻击，这些漏洞是逻辑漏洞，而不是链锯处理的注入漏洞。

脆弱性分析。有大量研究研究了注入漏洞检测。大体上，有静态分析相关的工作（如[17]、[18]、[26]、[20]和[29]）、动态分析方法（如[22]、[13]）和混合方法（如[2]）。其他方法侧重于发现和修复与卫生设施相关的错误，这是注射脆弱性的主要原因，如【23】和【24】。

MiMoSA[3]是一个系统，它跨web应用程序的模块进行推理，以发现数据和工作流攻击。我们的导航感知分析受到MiMoSA的启发，但它将分析推进到系统的工作流探索，以使用GWFG、R WFG、先决条件摘要和摘要历史等关键功能构建工作漏洞。Sun等人[25]提出了一种在web应用程序中发现访问控制漏洞的技术。他们的方法构建了一个类似于GWFG的图，但是，该图的用途与链锯生成的图不同。[26]是一种通过使用上下文无关语法对数据库查询建模来识别SQLI漏洞的方法。链锯更精确，因为它考虑了数据库模式分析和约束解算器，以生成对SQLI和XSS的具体利用。在RIPS【8】中，提出了一种污染分析系统来检测注入漏洞。[9] 开发一种静态分析技术，用于检测跨持久性存储的二阶漏洞。尽管RIPS和[9]可以检测SQLI和XSS以外的漏洞，但与链锯不同的是，它们实现了路径不敏感分析，这会导致较高的误报率，并且不会产生导航感知的工作漏洞。

7、结论

在本文中，我们介绍了Chainsaw，这是一个系统，它系统地分析导航结构，并使用web应用程序的数据库状态自动生成工作漏洞。链锯在我们的数据集上总共生成了199个工作漏洞，其中30个（15%）是二阶漏洞，没有误报。最后，我们还证明了链锯在漏洞检测和漏洞生成方面的性能明显优于以前的工作。