关于webapi:GitLab-Dogfooding-实践Web-API-模糊测试

本文起源：about.gitlab.com
作者：Eugene Lim，Mike Eddington
译者：极狐 (GitLab) 市场部内容团队

在极狐 GitLab/GitLab 外部，咱们用 Dogfooding 文化来帮忙更好地了解产品、解决痛点以及配置谬误，构建一个更高效、性能更丰盛、用户体验更好的平台。本文将聚焦在「API 含糊测试」的 Dogfooding 实际上。

什么是 Web API 含糊测试

Web API 含糊测试（Web API Fuzz Testing）次要通过生成大量随机但合乎肯定语法规定的输出，来对 Web API 进行测试。这种“随机输出”可能会触发 API 的一些意料之外的执行门路或谬误，从而发现 API 设计或实现中的某些破绽或谬误。

通过剖析这些谬误，能够发现缺点和潜在平安问题，而这些问题可能是聚焦特定破绽的平安扫描工具所脱漏的。极狐 GitLab/GitLab Web API 测试是其余平安伎俩，如动态应用程序平安测试（SAST）、动静应用程序平安测试（DAST）等的无效补充。

主动生成 OpenAPI 标准

运行 Web API 含糊测试分析器，需具备以下条件之一：

• OpenAPI 标准 – v2 或 v3；
• GraphQL 模式；
• HTTP 存档 (HAR)；
• Postman Collection – v2.0 或 v2.1。

在 API 含糊测试项目初始阶段，API Vision 工作组也在钻研 「如何在 OpenAPI 标准中主动生成 GitLab REST API endpoint」。因为 GitLab 应用 Grape API 框架，咱们曾经辨认并测试了 grape-swagger gem，它能够基于既有 grape 正文主动生成 OpenAPI v2 标准。

例如，以下 API 端点代码：

 Class.new(Grape::API) do
   format :json
   desc 'This gets something.'
   get '/something' do
     {bla: 'something'}
   end
   add_swagger_documentation
 end

会被 grape-swagger 解析为：

{
  // rest of OpenAPI v2 specification
  …
  "paths": {
    "/something": {
      "get": {
        "description": "This gets something.",
        "produces": ["application/json"],
        "operationId": "getSomething",
        "responses": {
          "200": {"description": "This gets something."}
        }
      }
    }
  }
}

然而，因为有 2000 多个不同的需要和格局的 API 操作，须要做大量额定工作来解决不满足 grape-swagger 需要或 OpenAPI 格局的边缘例子。一个最简略的例子就是承受文件参数的 API 端点，比方上传指标图片端点（metric image endpoint）。 极狐 GitLab/GitLab 应用 Workhorse 智能反向代理来解决“大型”HTTP 申请，如文件上传 。

在这种状况下，文件参数必须是 WorkhorseFile 类型：

namespace ':id/issues/:issue_iid/metric_images' do
            …
            desc 'Upload a metric image for an issue' do
              success Entities::IssuableMetricImage
            end
            params do
              requires :file, type: ::API::Validations::Types::WorkhorseFile, desc: 'The image file to be uploaded'
              optional :url, type: String, desc: 'The url to view more metric info'
              optional :url_text, type: String, desc: 'A description of the image or URL'
            end
            post do
              require_gitlab_workhorse!

因为 grape-swagger 并不能辨认 WorkhorseFile 对应的 OpenAPI 类型，它会将该参数从输入中排除。咱们通过在生成过程中增加特定的 grape-swagger 文档来修复该问题：

requires :file, type: ::API::Validations::Types::WorkhorseFile, desc: \
'The image file to be uploaded', documentation: {type: 'file'}

然而，并不是所有边缘例子都可能在 grape 正文中通过简略匹配替换来解决。比方，Ruby on Rails 次要反对通配符片段参数，像路由 books/*section/:title 会匹配到 books/some/section/last-words-a-memoir。

此外，URL 将会被解析，以便成 section 门路参数的值为 some/section 且 title 门路参数的值为 last-words-a-memoir。

以后，grape-swagger 不能将这些通配片段辨认为门路参数，上述路由会生成：

"paths": {"/api/v2/books/*section/{title}": {
    "get": {
    ...
      "parameters": [
         {
           "in": "query", "name": "*section"
           ...
  }
}

而不是冀望的：

"paths": {"/api/v2/books/{section}/{title}": {
    "get": {
    ...
      "parameters": [
         {
           "in": "path", "name": "section"
           ...
  }
}

因而，咱们仍旧须要为 grape-swagger 打几次补丁。 目前，曾经能够实现为绝大多数端点主动生成 OpenAPI 标准 。

性能调优

有了 OpenAPI 标准，当初能够开始 API 含糊测试了。 极狐 GitLab/GitLab 应用 Review App 性能为某些个性变更生成测试环境，提供可用的含糊测试指标 。

但对于大量给定端点，不能冀望一个规范共享 Runner 能在单个 Job 中实现含糊测试。Web API 含糊测试文档蕴含了性能调优局部，举荐以下操作：

➤  应用多 CPU Runner

通过应用一个专用含糊测试 Runner 来实现。例如大型打算中的含糊测试工作流，特地是抉择了 Long-100 含糊测试配置文件。

➤  排除慢操作

通过查看 Job 日志中每个操作所破费的工夫，借此排除慢操作。在这个过程中，还能够辨认其余须要排除的端点，例如过早完结含糊测试会话的撤销令牌端点。

➤  将测试宰割为多个 Job

因为 OpenAPI 格局要求，将测试拆分为多个 Job 破费了最多的精力。

每个 OpenAPI 文档都蕴含了一系列必填对象和字段，因而不仅仅是依据固定行数进行简略拆分，每个操作还对定义对象中的条目有依赖，须要确保在拆分 OpenAPI 标准时，须要蕴含端点所需条目。因而，咱们编写了一个疾速脚本，用来将自测试环境中的理论数据填入示例参数数据，比方我的项目 ID。

➤  排除个性分支而非默认分支中的操作

尽管能够在本地运行这些脚本，将拆分作业和 OpenAPI 标准推送到存储库，但每次更新原始 OpenAPI 标准时都会产生大量更改。因而，咱们调整了工作流以应用动静生成的子管道，这些管道将在 CI 作业中拆分 OpenAPI 文档，而后为每个拆分文档生成一个蕴含作业的子管道。这使得迭代变得容易许多而且更加麻利。咱们曾经将脚本和流水线配置进行了上传，欢送参阅。

通过调整并行作业的数量和含糊测试配置， 最终咱们在可承受的工夫范畴内，实现了相当全面的含糊测试会话 。

对 API 含糊测试后果进行分级解决

实现含糊测试后，当初须要面对数百个发现后果。不同于检测特定破绽的 DAST 分析器，Web API 含糊测试找寻测试非冀望的行为和谬误，它们不肯定是破绽。这也就是为什么由 API 含糊测试分析器发现的谬误，重大等级会被标记为 ”Unknow”，期待更深刻的分级解决。

侥幸的是，Web API 含糊测试会在破绽页面中将 Postman 汇合以制品模式输入。这些汇合容许用户疾速反复在含糊测试期间触发故障的申请。在含糊测试工作流阶段，倡议设置一个应用程序本地实例，以便轻松查看日志和调试特定故障。

很多故障的产生都是因为不足对意外输出的解决。咱们能够从破绽报告界面间接创立 Issue，并且如果发现特定故障和之前解决过的故障有雷同根因时，能够将此破绽间接链接到原始 Issue 上。

咱们学到了什么

API 含糊测试 Dogfooding 我的项目被证实是一项富有成效的实际：

• 使极狐 GitLab/GitLab 其余工作流程受害，诸如 API 文档我的项目；
• 调优和分级解决，帮忙辨认和改良了流程痛点；
• 即便有 OpenAPI，主动地生成 API 文档也是艰难的，特地是针对一个存在工夫很长的代码库。极狐 GitLab/GitLab 的既有正文及测试通过跨多个团队之间的分布式、异步合作减速了文档编制速度；
• 很多极狐 GitLab/GitLab 性能个性，诸如 Review App、破绽报告以及动静生成子流水线帮忙构建起了一个强壮的含糊测试工作流。

针对工作流仍旧还有能够改良的中央。迁徙到 OpenAPI v3 能够进步 endpoint 的覆盖率；平安团队也在写一个 HAR Recorder 的工具来帮忙实时生成 HAR 文件，而不仅仅依赖动态文档等。

对于曾经施行多层动态和动静查看并心愿采取进一步措施来减少覆盖率的团队，倡议尝试将 Web API 含糊测试，以此来验证假如并发现代码中的“unknow unkonw”。