摘要：

本文研究了Web应用漏洞利用脚本的自动化生成问题。针对复杂的Web应用，本文提出了一种高效的注入漏洞监测方法。成果为在9个开源应用中，找了199个一次或二次注入。该工具称之为CHAINSAW。

关键字：

1.介绍

本文中提出的方法大概如下。首先从静态分析开始，创建整个Web应用的行为模型，这里有两个问题：第一，哪条路径可以触发漏洞？这或可通过给路径赋权重来解决。第二，如何处理数据库查询的问题？二次攻击如何利用？这或可通过动静态分析相结合的方式来解决数据库状态的问题。

本文在CHAINSAW工具中实现了针对问题提出的想法，是第一个通过多个HTTP请求来实现Exp自动生成的工具。

2.背景与挑战

假定与目标：

Web应用项目代码完全开源，有运行实例与登录权限，可以测试任意输入并观察反应。实验的目标是能构造一系列的HTTP恶意请求来实施攻击。

问题定义：

成功注入一个SQL查询（SQLi）或者向一个client发送了信息（XSS），即被定义为攻击利用成功。即触发至少一个漏洞点。

这个攻击链的数学表示：((M1,IE1),(M2,IE2),(M3,IE3),.....,(MN,IEN))  M:模块 I:I输入 E:执行的HTTP请求

2.1运行实例

介绍了一个PHP编写的聊天室应用，存在几个未过滤导致的SQL注入点和XSS点，其主要代码如下。

room.php中主要实现了聊天室的选择，注意到有三个输入参数，$_GET['mode']与$_POST['category']均未进行有效的过滤，其中$_POST['category']传入到了dashboard.php中。

dashboard.php中对不同的$mode进行分别处理，将room.php传来的$cat_desc传到了addcat.php中。

在$accesslevel为1的情况下，$_GET['cat_desc']被拼接到了SQL语句中，在此触发了SQL注入漏洞。

create.php,创建新的聊天室，可以看到也存在SQL注入漏洞，这里并没有给出该php文件的上下文。

2.2Exp生成的挑战

复杂的工作流程

漏洞触发过程中，可能会使用到多个模块，有些工作流程可能按照开发者的预期来实现，有些则可能跳过了某些模块，或中间修改了某些数据。对于漏洞的触发需要考虑预期与非预期两种情况。

数据过滤与路径依赖

对于用户输入可能经过的各种路径，需要提前构建模型，考虑路径上出现的过滤与转换。

持久化存储的影响

数据库中存储的数据也是重要的输入，对代码执行有重要影响。比如某些数据被存储到了数据库中，在另一模块中又被提取出来拼接到了SQL查询语句中。

3.方法

为了成功的生成Exp，我们需要首先确定挑战的范围，即为了成功触发漏洞，哪些路径是我们必须要探索的？本文提出根据路径约束求解的消耗来排名，从那些分析需求和求解复杂度较低的路径入手。

整体方法如图所示：

首先是种子生成，建立前期模型预估可能的输入，同时也产生Exp种子，即在各个模块中触发漏洞点的输入。然后是推导工作流，找出导航序列，最后再优化工作流。通过全局路径的约束求解，得到解决问题的答案。下面会进行详细介绍

3.1 种子生成

这一阶段确定可能的漏洞触发点，并排除不存的漏洞的触发点。Exp种子的格式是（S,I）S是漏洞点，I是触发该漏洞点需要进行的操作，格式为{(i1,v1),...,(i2,v2)}，代表了在不同模块中一系列的操作。

在每一个模块里，CHAINSAW把从输入点到漏洞点的所有执行路径全部符号化，这样就获得了一个符号化公式Fp,这个公式符号化的表示了（1）路径状态（2）输入在不同模块之间的转移（3）来自漏洞出发点的上下文约束。比如说在上文提到的addcat.php中，该符号化公式FP与可能攻击输入FA如下：

该符号化公式的生成基于之前的工作，系统依赖图（SDGs）。有一个重要的细节需要被注意，全局变量（$_SESSION）可能在当前模块被赋值，也可能是其他模块。所以CHAINSAW需要找到给全局变量赋值的模块，而这个问题会在下面进行探讨。

3.2 导航问题

给定了一个模块内的漏洞触发路径（M1），是否存在一个连续的系列（M1,M2,...,M3）可以触发漏洞？下面我们称此序列为全局执行路径（global execute path）。

其中存在的主要问题是，由于存在众多模块及模块内部的变量，全局执行路径的组合数量极为庞大，遍历尝试的代价太大。而本文提出解决方法是，根据全局执行路径的组合数量，对可能的导航序列进行排序。

CHAINSAW首先构造一个通用工作流图(GWFG)，用来展示所有导航序列并获取这些导航序列的评级。然后对于每一个导航序列，CHAINSAW再构造一个优化工作流图(RWFG)。

3.2.1工作流推断

通用工作流图是一个加权图 G = (V,E) V（顶点）是不同的模块，E（路径）是从一个模块转移到另一个模块的过程，路径权重是全局执行路径的增加量。通过K最短路径算法（KSP）按照两个节点之间的距离大小进行排序，并对数据进行归一化处理。上面实例中Web应用的工作流图表示如下：

通过识别PHP代码中有关跳转的行为（HTML表单，链接，PHP重定向等）来构建通用数据流表（GWFG）。简而言之，GWFG代表了所有可能的导航序列。

工作流推断模块将所有可能的导航序列（程序运行流程）按照全局执行路径的所有可能性数量进行排名，下一阶段的目标是找到能触发漏洞点的全局执行路径。

3.2.2 优化工作流图

为了减少计算量，优化工作流图（RWFG）对一些不必要的路径进行删除。为此，构造了前序-概要状态表格，将每个节点（功能模块）中需要的前序状态和该模块中对全局变量进行的赋值列到表中，如果前一个节点的摘要不能满足当前节点的前序状态，则这两个节点之间不会有联系，则可以删除该状态转移路径。

对于每一个可以触发漏洞点的全局执行路径，CHAINSAW构造了一个符号化公式，来表示这个全局路径上的估值计算与状态。然后结合Exp种子的上下文（4.1节中会介绍语义分析），向符号化公式添加攻击特征的约束，以得到问题的解答。如果找到了解答，意味着每个模块的输入及全局变量的值均已确定。

3.3 二次攻击利用

因为数据库的状态难以确定，所以难以判断一次攻击能否成功。另外数据库中的数据可用于二次注入和存储型XSS，这些数据的来源可能是另外的SQL注入漏洞点。CHAINSAW的优点是前期数据库状态的构建，可以更加准确的生成一次或二次利用的Exp。下面将讨论CHAINSAW中使用的技术。

静态输入生成

具体漏洞的触发依赖于一些特定的值，如在addcat.php中，$accesslevel的值需要为1，才能触发SQL注入点，而这个值是从数据库中获取的，如果数据库中对应的值不为1，则下面的漏洞点无法被触发。

为了保证生成的Exp是可行的，CHAINSAW建立了数据库输入(insert,update)与输出(select)的映射(map)，在输入点输入需要的数据，然后在输出点进行触发。如前面提到的addcat.php中的SQL注入漏洞，需要在插入数据库时即将$accesslevel的值赋为1（该触发点在List4 create.php中）。同样对于二次攻击，过程也是类似的，在前一个漏洞点插入需要的信息，在后一个触发点进行触发。

动态审计

CHAINSAW不仅可以插入需要的数据到数据库中，也可以直接从运行实例的数据库中获取信息。通过确定PHP代码与数据库查询的对应关系，来从数据库中提取符合需求的的数据。这样运算花费会比静态生成小，但是也会受限于数据库实例的状态。

4.实现

CHAINSAW基于Pixy,TAPS,Z3等既有工具 实现，输入Web应用的源码，数据库模式和攻击详述，即可输出攻击HTTP请求

4.1文本语义分析

符号化分析

对于从用户输入到触发漏洞这一路径，CHAINSAW会给出一个符号化的表述，并处理回环问题。该工具主要实现了SQL和HTML语句两个符号解析器，来分析输入的变量类型与传递路径，并且能识别过滤函数。

上下文语义

识别当前输入点的上下文语义，选择合适的攻击向量，如下表中两种情况，需要不同的Payload来触发XSS。前者可以直接插入攻击字符串"<script>alert(’xss’)</script>"，而后者需要先闭合前一个标签，攻击字符串就变成了 "’><script>alert(’xss’)</script>"。

4.2 导航结构的分析

构建通用工作流图

CHAINSAW使用HTML解析器以及上下文无关文法来提取工作流转换的特征，主要包括：HTTP链接，表单，meta标签，iframe以及PHP重定向函数。提取这些跳转特征后，CHAINSAW便创建两个节点，用于表示这个工作流的起点与终点。

遍历工作流图

有效遍历整个工作流图的方法是智能的选择转移路径，为了实现这一点，本文提出了摘要历史（summary history）这一概念。即记录遍历的历史，用于指导下一个执行路径的选择。比如说，从节点Vi遍历到节点Vj，节点Vi的摘要需要添加到摘要历史中。

下面是一个简单的优化工作流图，展示了可能的漏洞触发路径，以此工作流图的遍历为例进行分析：

在addcat.php中有两个执行路径，如果从room.php的L2路径开始遍历，根据CHAINSAW的遍历规则，将首先选择A3而不是A2，因为L2的摘要历史满足A3的前序条件。下一步会把L2和A3的摘要都加入到摘要历史中，用于指导下一步的选择。会重复此启发式遍历的过程，直到到达漏洞点所在路径D2。

4.3数据库模式分析

因为应用中存在与数据库交互的操作，需要对数据库中的表名及每列的具体信息进行分析，记录其名称，变量类型和变量限制等。如下所示的插入语句，如果var1和var2是枚举类型，取值范围是{1,2},那么此处便不可以触发漏洞，因为其不接受其他值。CHAINSAW的数据库分析模块可以分析多种数据库，如MSSQL,MySQL,Oracle等。

4.4约束求解

CHAINSAW使用了Z3求解器及一个插件（Z3-str）来求解漏洞触发序列，并将源代码转换为三地址码来实现对路径信息的预处理，以加速求解过程。

处理过程记录。首先识别常用的70个PHP函数，当然这个过程还是较为粗糙的。如该语句：$cat_desc=htmlspecialchars($_GET[’cat_desc’])，在CHAINSAW的Z3处理中，使用了Z3-str的Replace函数，将字符串进行了替换，翻译后的代码如下所示：

5.评估

CHAINSAW对9个开源的PHP应用进行了测试，其代码复杂度不尽相同，SLOC(Single Line of Code)从323到63502不等，其中的SQL查询次数、数据表个数、XSS触发点个数如下表所示：

5.1 结果概览

如下表所示，在9个开源PHP语言的Web应用中，发现了199个一次、二次SQL注入、XSS漏洞。其中149个（75%）是SQL注入漏洞，50个（25%）是XSS漏洞，在所有的漏洞中，30个（15%）是二次注入漏洞。

5.2 一次漏洞示例

导航路径：

漏洞代码：

5.3 二次漏洞示例

5.4 数据库分析的效果

在前期进行数据库分析的情况下，减少了SQLI漏洞的误报率，下表是具体的数据比对。

5.5 分析复杂度及消耗

5.6 与相关工作的比对

由于CHAINSAW研究的角度在之前较为少见，本文从种子生成、Exp生成等角度与先前论文进行比较，发现各项指标具有较大提升。特别要指出的是，CHAINSAW的文本分析减少误报。比如如下的代码片段：

Ardilla工具认为第3行print函数处存在XSS漏洞，但CHAINSAW则会指出，如果$_POST['selectclass']输入XSS攻击字符串，则会导致前面SQL查询语句报错，并不会执行print语句。因此减少了一次误报行为。下表则展示了CHAINSAW与其他两种漏洞检测工具，在多个Web应用中漏洞（SQLI+XSS）发现的数量比对。

5.7 讨论

该工具还无法处理JavaScript语句的情况，导致难以判定由JavaScript处理过的变量，以及JavaScript引发的状态转移。此外还会遇见少部分超时问题，以及无法处理全部的PHP特性。

6.总结

该段为笔者读后感悟，并非原文总结。

该文中提出的方法角度新颖，在常见Web漏洞挖掘中，使用了符号执行，工作流转移，语义分析等方法，拓展了一般性FUZZ与漏洞静态分析的思路方法，此文在后面也有新的论文（NAVEX）给以改造升级，大家可以对比研究一下。当然也可以看到其分析的程序框架较为老旧，代码逻辑也较为简单，难以在前后端逻辑复杂的Web应用框架中使用。但这仍然是一个较好的开始，其中的思想很值得我们学习。

关于安全学术圈, 有兴趣加入学术圈的请联系[email protected]