随着网络应用的普及，人们越来越关注软件安全性、稳定性和软件质量问题。而软件系统也越来越复杂，即使经过仔细测试的软件也时有 Bug 逃逸。为了解决这一问题，模糊测试作为一种高效测试方法，被广泛关注和研究。

什么是模糊测试？

概念：

模糊测试（Fuzzing Test）一种黑盒/灰盒软件测试技术，通过提供随机输入来检测程序中的错误、漏洞等，帮助发现程序中的边界条件错误、内存泄漏、缓冲区溢出等潜在问题，验证软件功能的正确性、稳定性与健壮性，进而提高系统安全性。

API 模糊测试是模糊测试的典型应用。在 API 成为现代软件架构的基础与关键的背景下，作为评估 API 安全性有力手段的 API 模糊测试的重要性不言而喻。

常见测试方法论

这里延展分享软件测试中常用的测试方法论：一般分为有黑盒测试、白盒测试和灰盒测试。它们的区别在于测试人员对系统内部结构的了解程度：

• 黑盒测试：只依据需求与功能进行测试，测试人员不需要了解内部结构与实现；
• 白盒测试：依据结构与代码进行测试，测试人员需要完全了解或控制内部结构；
• 灰盒测试：介于黑白盒测试之间，测试人员对部分内部结构有所了解，测试既考虑输出与功能，也关注测试覆盖率。

而模糊测试的测试用例与数据是随机生成的，不依赖于软件内部结构与实现，测试人员无需完全了解软件内部逻辑。因此，模糊测试属于黑盒或者灰盒测试，且即使不熟悉代码本身的测试人员也可以承担相应工作。

不同角色的人进行模糊测试时有何不同？

不同角色的人进行模糊测试时，视角和关注点也不同，举个例子：

开发同学更关注代码逻辑，通常根据软件内部的实现逻辑及其可能的漏洞与问题点来设计模糊测试方案。如下图，开发同学有可能直接针对代码或接口进行测试，而忽略外部依赖或上下文。

测试同学更关注业务逻辑，通常根据软件的业务逻辑、外部接口与用户场景来设计模糊测试方案。如下图，测试同学会生成真实仓库，设置多个参数值，提交包含文件变更的 commit 等，尽量更贴近实际用户操作。

安全工程师则更关注风险，通常会设计模糊测试方案来发现各种潜在的安全漏洞，更关注危害严重的问题。

理解各个测试角色的优势与局限，通过沟通协作来弥补各自的不足，精心设计全面而有针对性的测试方案，是发挥模糊测试甚至任何测试技术最大效用的要素之一。

模糊测试 VS 传统测试

模糊测试主要可以分为以下 6 个步骤：

1. 识别目标系统；
2. 识别输入；
3. 生成模糊数据；
4. 使用模糊数据执行测试；
5. 监控系统行为；
6. 结果记录与分析。

其中 1-5 步与传统测试工作流程高度相似度，在步骤 6：结果记录与分析上，传统测试和模糊测试是完全不同的：

• 传统测试的结果分析，关注预期结果，确认是否实现需求。例如测试能否正常登录系统，得到的结果是正常登录或不能正常登录。
• 模糊测试的结果分析，更关注意外结果与异常行为，侧重发现未知漏洞。在上述例子中，模糊测试则是寻找和分析让登录系统崩溃的原因。换句话说，模糊测试更关注被测系统的稳定性和健壮性，不在意系统的业务行为正确性。

另外一个不同之处在于，模糊测试难以用人工介入。主要因为：

• 模糊测试产生海量随机测试用例，使得人工判断与介入每个用例变得不现实；
• 模糊测试产生的大量测试结果需要判断预期与异常，人工难以完成，需要依靠高度自动化的算法来分析分类。

为什么要做 API 模糊测试？

API 已成为基础架构

现代软件系统基于微服务架构，大量使用 API 进行服务调用与集成。API 的安全性直接决定整体系统的安全性，所以 API 模糊测试是评估系统安全性的关键一环。

快速发布需求提高

很多企业都在使用敏捷开发，要求更短的更新周期和更高的发布频率。这增加了由于疏忽或考虑不周导致安全漏洞的概率。

而敏捷标准下，每一个迭代都是一个可用的产品，必须关注安全性；同时，无论是安全性缺陷抑或可用性缺陷，越早修复，成本越低。

因此，应用 API 模糊测试进行持续监测是一个很好的选择，确保快速迭代不会引入高危漏洞。

人工不能够完全覆盖 API 输入

如前文所言，模糊测试通过提供随机输入来检测程序中的错误、漏洞等。而 API 输入域往往过于庞大，人工很难考虑每一种输入的安全性。

API 模糊测试可以随机产生海量测试数据来尽可能覆盖所有输入场景，检验 API 的健壮性。

API 模糊测试在极狐GitLab 上的实践

在开发过程中应用模糊测试的益处显而易见，可以在 QA同学进行测试之前，极早发现问题并解决问题，减少双方沟通成本和时间。

支持格式

在极狐GitLab上，API 模糊测试目前支持以下几种格式:

1. OpenAPI 规范（版本 2 和 3）：这是 API 文档行业标准，极狐GitLab可以直接导入 OpenAPI 文件并自动生成模糊测试方案。
2. GraphQL Schema：图查询语言，近年流行的一种查询语句。极狐GitLab 支持导入 GraphQL Schema 来定义 API 接口，并基于此生成模糊测试方案与用例。
3. HTTP存档（HAR）：通 HAR 文件格式用来存储 HTTP 交易的定期快照，包含完整请求和响应数据。极狐GitLab 可以导入 HAR 文件，解析其中的请求与响应详情，并自动生成相应的 API 测试用例与模糊测试方案。
4. Postman 集合：知名 API 测试工具，其支持以合集格式导出 API 请求与环境等信息，文件可以直接在极狐GitLab 上导入，极狐GitLab 可自动解析其中的API 请求与环境参数详情。

接下来，以 OpenAPI 为例，分享 API 模糊测试在极狐GitLab 上的实践，主要有以下 6 个步骤：

1. 在极狐GitLab 新建项目，把相关 API 代码和文档填入项目；
2. 安装极狐GitLab 模糊测试工具，与相应依赖项和内容；
3. 编写相应测试用例，极狐GitLab 提供现成接口和内容来进行测试；
4. 运行测试；
5. 查看结果，如有问题，则及时定位和修复；
6. 集成到 CI/CD 中，后续每次提交新代码后，自动运行流水线，及时返回测试结果，从而尽早发现问题和解决问题。

在极狐GitLab 页面启用 API 模糊测试

模糊测试属于安全测试的一部分。

如下图，在极狐GitLab 新建项目 → 安全与合规→ 安全配置 → API 模糊测试 → 填写目标地址 + 选择扫描模式 + OpenAPI 规范文件路径 + 是否身份验证 + 扫描轮廓（例如，有一个接口，三个参数，示例中每个参数生成 20 个不同类型参数内容，来请求该接口，测试该接口是否稳定健壮。）→ 生成代码片段，即可放入 CI 运行测试。

API 模糊测试配置示例

如下图所示，极狐GitLab 项目中自带模板：API-Fuzzing·gitlab-ci.yml ，其主要作用是：

1. 配置模糊测试的环境变量；
2. 读取 OpenAPI. json 文件，抓取相应参数；
3. 根据 OpenAPI.json 中的接口定义，自动生成大量测试用例组合。如果每个请求有 3 个参数，每个参数有 20 种取值，则理论上可以生成 20 的 3 次方，即 8000 个测试用例进行组合。

Build 阶段构建测试环境与准备测试数据；

Fuzz 阶段则专门执行模糊测试。

API 模糊测试配置内容

如下图展示了一个很典型的 CRUD（增删改查） 接口组合，包含 GET 和 PUT 两个接口：

• GET 接口：用于获取用户信息，返回 UserID、名字、密码等多个字段；
• PUT 接口：用于更新用户信息，可以更新名称、密码等字段。

下图是极狐GitLab API 模糊测试基于接口的定义自动生成相应的测试内容，主要包括：

• 接口URL与请求方法；
• 接口所需的参数、请求体与认证信息；
• 接口响应的验证断言或脚本；
• 接口的模糊测试方案与大量随机测试用例；
• 其他相关测试数据如 headers、cookies、身份信息等。

API 模糊测试执行过程

如下图，极狐GitLab API 模糊测试的执行流程大致如下：

1. 构建测试镜像：编排 API 模糊测试所需要的环境容器，构建测试执行的 Docker 镜像；
2. 部署被测试系统：将需要测试的系统或服务部署到环境中，运行并监听在配置的端口（如下图是777端口）上；
3. 认证信息配置：如果被测试系统需要认证，则需在环境中配置相应的认证信息，以访问系统接口；
4. 检出测试代码：从代码仓库中检出 API 模糊测试所要脚本、工具与用例等相关代码；
5. 运行被测试系统：使其正常启动并监听在配置的端口上；
6. 解析 OpenAPI 文件：使用 Pitchalizer 工具解析传入的 OpenAPI 文件，抓取其中的接口定义信息，包括 URL、方法、请求参数、headers 等内容；
7. 生成测试用例：根据解析出的接口信息，自动生成大量的随机测试用例，包含各接口的测试数据；
8. 执行接口请求：使用生成的测试用例对被测试系统的接口进行大规模的随机请求，同时监控系统响应与运行状况；
9. 检查接口响应：检查结果是否符合预期，判断接口功能是否正确以及系统稳定性等。

API 模糊测试执行结果

最终总共是执行 259 个 API 请求。

如下图，示例一共是写 4 个接口，最终总共是执行 259 个 API 请求，平均每个接口大超过 60 个请求。可见模糊测试可以通过大量自动化测试来检测 API 接口健壮性，大幅提升测试效率，尽早解决问题。

以上就是关于 API 模糊测试的内容与实践，希望今天的分享对大家有帮助！