RESTler——面向RESTful API的自动化模糊测试工具
CS杂货铺2021-01-14 23:07
引言
模糊测试（Fuzz Test）可以帮助我们揭示程序中的重要缺陷，可以识别真实世界中的故障模式，并发出信号，指出在你的软件发布之前应该堵住的潜在攻击途径。
RESTler是第一个有状态的针对REST API的模糊测试工具，用于自动化的测试云服务并找到云服务中存在的安全性和可靠性问题。
本篇文章将会主要介绍一下RESTler的产生背景、其优点、测试原理以及面向HTTP协议的请求构造过程。
图1RESTler的产生场景
传统开发模式下，用于本地程序安全性的静态分析或者模糊测试工具可能非常多。然而，随着云成为新的关键基础架构，云服务的数量每天都在增长，人们现在需要负责不断提供实时服务的新功能，同时维护其安全性和可用性。当前，大多数的云和Web服务都是通过REST（REpresentational State Transfer）API的方式来提供接口，但是针对这些Web 服务的静态分析和模糊测试工具却不是很多。开发人员亟待一套自动化方案来帮助其尽可能发现API接口中存在的问题，以避免用户有意或无意的导致系统崩溃。
为了满足开发人员对REST API接口进行自动化测试，Microsoft研究人员开发了RESTler 工具，通过该工具可以帮助开发人员在云服务中查找安全性和可靠性问题。
图2 RESTler产生及应用场景RESTler的优点
与其他的模糊测试工具相比，RESTler具有如下优点：
RESTler能够会对整个Swagger规范执行轻量级的静态分析，从Swagger规范中智能地推断出不同请求之间的生产者-消费者关系，进而生成并执行测试用例。RESTler是有状态的，它能够从前序的响应中学习到该服务的行为，进而能够发现一些只有在特定请求序列下才能有可能导致的服务状态，进而找到该服务所存在的Bugs，所以说RESTler是有状态的。如何产生测试用例
RESTler主要包含如下两个大的步骤来生成测试用例
依据Swagger规范，从中推断出不同请求类型之间的依赖关系，例如，A请求的响应是B请求的一个必要条件，那么此时A应该在B之前执行。动态的分析前序测试执行期间得到的响应信息，以便生成新的测试用例。例如，学习到请求若C在A请求之后，那么B就会被拒绝，这样就能够防止后续的测试序列的合并。举个例子来说，针对如下图3所示的一个RESTful API接口，其描述了博客的增删改查请求，当我们在Swagger中点击任意一个Item时候，我们其实都可以看到该请求的详细的信息。
图3 RESTful API接口用YAML格式描述一下上述图片中的第二个Item中的内容可能如下图左侧所示，确切描述了针对该接口的请求和响应信息。例如，definition部分表示一个类型为String，name为body的对象为必须传入的参数，而类型为Integer，name为id的对象为可选参数，path部分描述了HTTP协议的POST请求的语法格式以及可能的响应值。
针对这样的一个API接口规范，RESTler会自动的构造一个HTTP POST请求，流程如下图右侧所示，在构造过程中，每一个reslter_static后追加的参数都不会被更改，而restler_fuzzable后追加的参数，我们在测试过程中不断修改其值，我们可能需要去维护一个字典，每次过程中都可以去根据字典的值来对该参数进行替换。由于篇幅的关系，在下一篇文章中介绍如何去构造字典。
图4 RESTler分析Swagger规范的流程同样的，RESTler也会去分析每次请求的响应信息，本例中，我们可以使用parse_posts来分析其响应信息。本例中，POST请求会返回一个ID信息，此时，RESTler就会根据对响应值的分析来推断出POST请求是执行图3中后面的DELETE、PUT、GET三个请求的依赖，因为这三个请求都需要使用id来作为参数。
总结
篇幅的关系，本篇文章主要是介绍一下面向RESTful API的模糊测试工具RESTler，介绍了其产生背景、特点以及其分析Swagger文档并构造HTTP请求的步骤，后续文章在详细介绍一下其如何生成用例，如何去自动化的评估前后测试序列间的状态信息。
举报/反馈
0
0
收藏
分享
