Help us learn about your current experience with the documentation. Take the survey.

Web API 模糊测试

  • 版本：Ultimate
  • 提供方式：GitLab.com、GitLab 自托管、GitLab Dedicated

Web API 模糊测试对 API 操作参数执行模糊测试。模糊测试将操作参数设置为意外值，旨在导致 API 后端出现意外行为和错误。这有助于您发现其他 QA 流程可能遗漏的错误和潜在安全问题。

除了 GitLab Secure 中的其他安全扫描仪和您自己的测试流程外，您还应该使用模糊测试。如果您使用的是 GitLab CI/CD，可以将模糊测试作为 CI/CD 工作流程的一部分运行。

有关概述，请参见 WebAPI 模糊测试 - 高级安全测试。

入门指南

通过编辑您的 CI/CD 配置开始使用 API 模糊测试。

先决条件：

要启用 API 模糊测试：

  • 使用 Web API 模糊测试配置表单。

    该表单让您可以选择最常见的 API 模糊测试选项的值，并生成一个 YAML 代码片段，您可以将其粘贴到 GitLab CI/CD 配置中。

理解结果

要查看安全扫描的输出：

  1. 在左侧边栏，选择 Search or go to 并找到您的项目。
  2. 在左侧边栏，选择 Build > Pipelines。
  3. 选择管道。
  4. 选择 Security 标签页。
  5. 选择一个漏洞以查看其详细信息，包括：
    • 状态：指示漏洞是否已被分类或解决。
    • 描述：解释漏洞的原因、其潜在影响和推荐的修复步骤。
    • 严重性：根据影响分为六个级别。更多信息，请参见 严重性级别。
    • 扫描器：标识检测到漏洞的分析器。
    • 方法：确定易受攻击的服务器交互类型。
    • URL：显示漏洞的位置。
    • 证据：描述用于证明给定漏洞存在的测试用例
    • 标识符：用于分类漏洞的引用列表，例如 CWE 标识符。

您也可以下载安全扫描结果：

  • 在管道的 Security 标签页中，选择 Download results。

更多详情，请参见 管道安全报告。

在功能分支上生成发现项。当它们合并到默认分支时，它们会变成漏洞。在评估您的安全状况时，这种区别很重要。

优化

要充分利用 API 模糊测试，请遵循以下建议：

  • 配置运行器使用 always pull policy 来运行最新版本的分析器。

  • 默认情况下，API 模糊测试会下载管道中先前作业定义的所有工件。如果您的 API 模糊测试作业不依赖于 environment_url.txt 来定义被测试的 URL 或任何其他先前作业创建的文件，则不应下载工件。

    为了避免下载工件，扩展分析器 CI/CD 作业以指定无依赖项。例如，对于 API 模糊测试分析器，将以下内容添加到您的 .gitlab-ci.yml 文件中：

    apifuzzer_fuzz:
  dependencies: []

应用程序部署选项

API 模糊测试需要一个已部署的应用程序可供扫描。

根据目标应用程序的复杂性，有几种部署和配置 API 模糊测试模板的方法。

审阅应用程序

审阅应用程序是部署您的 API 模糊测试目标应用程序的最复杂方法。为了协助此过程，GitLab 创建了一个使用 Google Kubernetes Engine (GKE) 的审阅应用程序部署。此示例可以在 Review apps - GKE 项目中找到，以及在 README 中配置 DAST 审阅应用程序的详细说明。

Docker 服务

如果您的应用程序使用 Docker 容器，您有另一种使用 API 模糊测试进行部署和扫描的选项。在您的 Docker 构建作业完成后，您的镜像被添加到容器注册表中，您可以将该镜像用作 service。

通过在您的 .gitlab-ci.yml 中使用服务定义，您可以使用 DAST 分析器扫描服务。

当向作业添加 services 部分时，alias 用于定义可用于访问服务的主机名。在以下示例中，dast 作业定义中的 alias: yourapp 部分意味着已部署应用程序的 URL 使用 yourapp 作为主机名（https://yourapp/）。

stages:
  - build
  - fuzz

include:
  - template: API-Fuzzing.gitlab-ci.yml

# 将容器部署到 GitLab 容器注册表
deploy:
  services:
  - name: docker:dind
    alias: dind
  image: docker:20.10.16
  stage: build
  script:
    - docker login -u gitlab-ci-token -p $CI_JOB_TOKEN $CI_REGISTRY
    - docker pull $CI_REGISTRY_IMAGE:latest || true
    - docker build --tag $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA --tag $CI_REGISTRY_IMAGE:latest .
    - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
    - docker push $CI_REGISTRY_IMAGE:latest

apifuzzer_fuzz:
  services: # 使用服务将您的应用程序容器链接到 dast 作业
    - name: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
      alias: yourapp

variables:
  FUZZAPI_TARGET_URL: https://yourapp

大多数应用程序依赖于多个服务，如数据库或缓存服务。默认情况下，服务字段中定义的服务无法相互通信。要允许服务之间通信，请启用 FF_NETWORK_PER_BUILD feature flag。

variables:
  FF_NETWORK_PER_BUILD: "true" # 启用每个构建的网络，以便所有服务可以在同一网络上通信

services: # 使用服务将容器链接到 dast 作业
  - name: mongo:latest
    alias: mongo
  - name: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
    alias: yourapp

推出

Web API 模糊测试在 CI/CD 管道的 fuzz 阶段运行。为确保 API 模糊测试扫描最新代码，您的 CI/CD 管道应在 fuzz 阶段之前的某个阶段将更改部署到测试环境。

如果您的管道配置为每次运行都部署到同一个 Web 服务器，则在另一个管道仍在运行时运行管道可能会导致竞争条件，其中一个管道会覆盖另一个管道的代码。在模糊测试扫描期间，应排除对 API 的更改。对 API 的唯一更改应来自模糊测试扫描器。在扫描期间对 API 进行的任何更改（例如，由用户、计划任务、数据库更改、代码更改、其他管道或其他扫描器进行的更改）都可能导致不准确的结果。

您可以使用以下方法运行 Web API 模糊测试扫描：

API 模糊测试示例项目

获取支持或请求改进

要获取针对您特定问题的支持，请使用 getting help channels。

GitLab.com 上的 GitLab 问题跟踪器是报告 API 安全和 API 模糊测试相关错误和功能建议的正确位置。在打开有关 API 模糊测试的新问题时，请使用 ~"Category:API Security" 标签，以确保它被正确的人员快速审查。

在提交您自己的问题之前，搜索问题跟踪器查找类似条目，很有可能其他人遇到过相同的问题或功能建议。使用表情符号反应表示支持或加入讨论。

当遇到行为不符合预期的情况时，考虑提供上下文信息：

  • 如果使用 GitLab 自托管实例，请提供 GitLab 版本。
  • .gitlab-ci.yml 作业定义。
  • 完整的作业控制台输出。
  • 扫描器日志文件，作为名为 gl-api-security-scanner.log 的作业工件提供。

清理附加到支持问题的数据。删除敏感信息，包括：凭据、密码、令牌、密钥和密钥。

术语表

  • 断言：断言是检查用于触发故障的检测模块。许多断言具有配置。一个检查可以使用多个断言。例如，日志分析、响应分析和状态码是检查常用的共同断言。具有多个断言的检查允许它们被打开和关闭。
  • 检查：执行特定类型的测试，或对特定类型的漏洞执行检查。例如，JSON 模糊测试检查对 JSON 负载执行模糊测试。API 模糊测试器由多个检查组成。检查可以在配置文件中被打开和关闭。
  • 故障：在模糊测试期间，由断言识别的故障称为故障。故障被调查以确定它们是安全漏洞、非安全问题还是误报。在调查之前，故障没有已知的漏洞类型。示例漏洞类型包括 SQL 注入和拒绝服务。
  • 配置文件：配置文件具有一个或多个测试配置文件或子配置。您可能有一个用于功能分支的配置文件，另一个用于主分支的额外测试配置文件。