什么样的请求适合做模糊测试（REST-ler）

随着Amazon Web Services和Microsoft Azure的出现，云服务在最近的几年中增长迅速。大多数云服务，不管是SaaS，PaaS还是IaaS，都是通过REST API访问的，而Swagger可以说是最受欢迎的REST API描述语言。

通过REST API自动测试云服务并检查这些服务是否可靠和安全的工具仍处于起步阶段。本文介绍了一个自动化智能REST API安全测试工具REST-ler，它分析Swagger规格说明并生成通过REST API执行的相应服务的测试。与其他REST API测试工具不同，REST-ler对整个Swagger规格说明执行轻量级静态分析，然后生成并执行通过其REST API执行相应云服务的测试。REST-ler生成测试的智能化体现在两个方面：（1）推断Swagger规格说明中声明的请求类型之间的依赖关系（例如，由于请求B要将请求A返回的一个资源ID x作为输入，因此推断请求B应该在请求A后面执行）；（2）分析在先前测试执行期间观察到的响应的动态反馈，生成新的测试（例如，发现请求C在请求A之后执行，请求B被服务拒绝，因此在后续的测试中避免把二者组合起来）。我们发现这两种技术对于在缩小搜索空间的同时执行更全面的测试是必要的。通过REST-ler工具测试GitLab，我们还发现了新的bug。

Fuzzing意味着自动测试的生成和执行，其目的是找到安全漏洞。本文中的研究对象是那些有Swagger规格说明的REST API的云服务。REST-ler的主要算法工作流程如图所示：

图1 REST-ler测试生成算法流程图

Swagger规格说明描述了如何通过REST API去访问一个云服务。客户端程序发送请求到服务端，并接收来自服务端的响应。请求和响应都是通过HTTP协议发送和接收的。对于给定的Swagger规格说明，REST-ler会首选进行解析处理，根据规格说明中对于请求接口的描述，通过python代码去构成该HTTP请求。在这个过程中，能够被fuzzing的基础数据类型的请求参数将会被标注出来。

该算法通过循环遍历的方式计算请求序列的集合。首先，所有的长度为n-1的有效请求序列构成的集合会通过广度优先的搜索方式，在最后添加一个新的依赖条件满足的请求，形成新的长度为n的请求序列。然后，对于集合中的每一个新的请，所有的被标注为fuzzing的参数被具象化，其所使用的数值是从一个有限的集合中选取的。接着， REST-ler将执行该请求并检查这个请求的响应信息。如果HTTP请求的响应代码正常，则这个新的请求被认为是有效的，否则它将被记录下来用于后续的分析和调试。

对于每一个可以被fuzzing的参数，在具象化的过程中，算法会基于一个属于该数据类型的数值集合，从中挑选一个数值出来。举例来说，如果被fuzzing的参数是整形的，那么REST-ler可能会使用一个包含{0, 1, -10}的集合，集合中的具体的数值是由用户定义的。

图2 REST-ler模块图

整个REST-ler可以被分为四个模块：主应用入口、解析和编译模块、核心fuzzing引擎和日志模块。主应用入口负责根据配置参数启动fuzzing测试会话。解析和编译模块负责解析Swagger规格说明并生成用于对目标服务进行模糊测试的RESTler语法。核心fuzzing引擎模块实现了REST-ler的测试生成算法。最后，日志模块负责监控客户端与服务的交互并记录了所有的消息内容。

方案评估：

(1) 对于有效地自动化REST API模糊测试来说，在请求类型之间推断依赖关系和分析请求响应的动态反馈这两种方式是否都是必要的？

图3 代码覆盖和HTTP状态码随时间走势图

对于这个研究问题，我们对于一个博客发布服务进行了测试，实验中对代码覆盖率和HTTP状态码进行分别进行了观察，左侧的图是忽略了对于类型之间的依赖关系的实验结果，中间的图忽略了请求响应的动态反馈的实验结果，右侧的图则是综合考虑两者的实验结果。实验说明了请求类型之间推断依赖关系和分析请求响应的动态反馈这两种方式的互补性，并表明在REST API模糊测试中，这两者都是需要的。

(2) 当请求序列增长时，REST-ler生成的测试是否能够执行到服务端更多的逻辑处理？

表1 REST-ler测试GitLab结果表

对于这个研究问题，实验数据表明随着请求序列长度的增长，服务端的代码覆盖率也在增长。同时，为了达到更高的代码覆盖率，请求序列集合的大小、根据中间的响应结果创建的动态对象数量也迅速增长。

(3) 在REST-ler中应该应用何种搜索策略？

为了找到更高效的搜索策略，出了前面使用的BFS策略外，我们还使用了Random Walk和BFS-Fast这两种策略进行实验，实验结果表明BFS比RandomWalk的效果更佳，而BFS-Fast和BFS效果比肩，但是BFS-Fast所生成的请求序列集合的大小要更小，因此BFS-Fast是REST-ler默认采用的搜索策略。

表2 BFS和RandomWalk搜索策略下的代码覆盖率

表2 BFS和BFS-Fast搜索策略下的代码覆盖率

1. 我们介绍了REST-ler，REST API的第一个自动化智能模糊测试工具，它分析Swagger规格说明，自动推断请求类型之间的依赖关系，生成满足这些依赖关系的请求顺序的测试，并通过动态分析服务对这些测试的响应，学习到哪些请求序列有效或无效的。
2. 我们提供了详细的实验证据，表明REST-ler中使用的技术对于有效的自动REST API模糊测试是必要的。
3. 我们还提供了用三通不同策略获得的实验结果，这些策略被分别用于搜索由所有可能的请求序列定义的大搜索空间，并讨论了它们的优缺点。
4. 我们提供了一个详细的案例研究，研究的对象是GitLab这个大型流行的开源自托管Git服务。我们讨论了到目前为止通过REST-ler发现的几个新bug及其严重性。

此文由南京大学软件学院2018级硕士章许凡翻译转述。