💡 如何在流水线中集成与应用 DAST ？

近日，在「DevSecOps 软件安全开发实践」课程上，极狐(GitLab) 前端工程师钱堃、极狐(GitLab) 高级后端工程师张林杰，展开了关于 DAST 的概念、必要性、优缺点的内容分享，并结合实操演示，帮助大家进一步掌握 DAST 技术。

以下内容整理自本次直播，你也可以点击👉观看视频回放或下载 PPT。Enjoy～

DevSecOps 在 DevOps 的基础上增加了 Sec（Security，安全）的概念，是指通过与 Sec （安全团队）+ Dev（研发团队） + Ops（运营团队） 合作，在标准 DevOps 周期中建立关键的安全原则。

DevSecOps 提倡 “安全左移” 的理念，即在软件生命周期（SDLC）的早期阶段就注重安全问题，从而防止缺陷产生以及尽早找出漏洞。

在软件开发生命周期不同阶段发现漏洞，其修复成本（人力、财力等）不一样。如下图所示，如果说需求阶段发现一个漏洞，其修复成本是 1，在编码阶段就变成了 5，而在生产阶段变成了惊人的 30，这意味着：生产阶段漏洞修复成本 = 需求阶段漏洞修复成本 x 30。

可见通过安全左移，能够大幅降低安全漏洞修复成本。

图片来源：NIST

不同开发阶段有不同风险漏洞，借助各种安全扫描工具，层层递进，才能实现整体，例如：

• SAST - 静态应用安全测试；

• DAST - 动态应用安全测试；

• IAST - 交互式应用安全测试；

• RASP - 运行时应用自我保护；

• Dependency-Scanning - 依赖项安全扫描；

• Secrets Detection - 机密信息检测。

图片来源：Freebuf

DAST 和 SAST

今天，我们主要分享安全扫描工具之一——DAST（Dynamic Application Security Testing，动态应用程序安全测试）。

提到 DAST，就绕不开通常与其成对出现的 SAST（Static Application Security Testing，静态应用程序安全测试）。首先，先厘清概念：

➤ SAST

通常在编码阶段，对源代码进行安全测试发现安全漏洞的测试方案。

SAST 是对应用程序源代码执行直接的白盒分析，分析是在代码的静态视图上运行的，这意味着代码在审查时没有运行。

➤ DAST

在测试或运行阶段，分析应用程序的动态运行状态。它模拟黑客行为对应用程序进行动态攻击，分析应用程序的反应，从而确定该 Web 应用是否易受攻击。

DAST 是一种黑盒测试技术，它们不能访问代码或实现细节，只检查系统对潜在漏洞测试的请求和响应。换言之，DAST 是外部的漏洞扫描程序。

另外，从扫描准备、扫描速度、开发语言等方面进行比较，两者之间还有以下差别：

为什么需要 DAST ？

从上文的内容中可以看到 SAST 具有其局限性，包括：

• SAST 应用于代码未运行时，无法覆盖运行问题或配置问题；

• SAST 对于访问控制，无法覆盖身份验证或加密等场景；

• 主流 SAST 工具均基于污点传播模型实现，在代码分支多、调用层级很深的情况下，信息网络庞大（特别是考虑了调用顺序和全局变量的情况下），耗时成倍增长；

• 为降低复杂度，检查器丢失上下文信息，从而无法准确定位到某些标识符正确指向对象，最终导致误报或漏报。

举一个 SAST 误报的例子。如下图，这是一段 JS 代码，定义了一个 test 函数，变量 b = 11 * 10，如果 b > 100 ，那么返回一个普通字符串 safe；如果 b < 100 ，则将函数传进来的实参去进行 eval。

我们肉眼来看，可以算出 b = 110 ，永远都是大于 100，返回 safe 字符串，后面的 eval 永远不会执行，所以这个函数在我们预想的运行情况下，它是一个安全函数。

但如果在极狐 GitLab 上开启 SAST 检查，就可以扫到这个漏洞，如下图，发现使用了 eval，认为有可能会导致危险的注入，进行警告，但实际上这个函数是安全的，因此产生误报（在极狐 GitLab 中，用户可以 dismiss）。

这个例子说明了 SAST 的局限性。鱼和熊掌不可兼得，因此需要 DAST 弥补一些 SAST 的不足。

DAST 的工作流程

以 Web 部署为例，DAST 的工作流程是：

Step 1 ：通过爬虫扫描整个 Web 应用结构，爬虫会发现被测 Web 程序的目录数量、页面数量、页面参数；

Step 2 ：根据爬虫的分析结果，对发现的页面和参数发送修改的 HTTP Request 进行攻击尝试（扫描规则库）；

Step 3 ：通过分析 Response ，验证是否存在安全漏洞。

上述步骤涉及到两种扫描方式，即：

• 被动扫描（default）：不主动攻击，搜索 HTTP 消息、Cookie、存储事件、控制台事件和 DOM 以查找漏洞，包括搜索暴露的信用卡、暴露的机密令牌、缺少的内容安全策略以及重定向到不受信任的位置。

• 主动扫描（full）：主动攻击，分析每个 HTTP 请求以获取注入位置，例如查询值、标头值、cookie 值、表单和 JSON 字符串值，将攻击内容注入到对应注入位置，形成新的请求， 将请求发送到目标应用程序，并检查 HTTP 响应来确定攻击是否成功。

DAST 的优缺点探析

DAST 优点

1. 不受语言和框架限制

DAST 测试不要求具备编程语言知识；无论使用何种框架，DAST 工具都会根据输入和输出，评估应用程序行为。

2. 低误报率

DAST 工具对应用程序环境执行端到端扫描，使安全研究人员能够检测和识别安全漏洞。

3. 无需访问源代码

DAST 扫描通过应用程序前端发送恶意有效负载来测试，因此企业可以利用第三方安全服务来执行，而不暴露应用程序代码。

DAST 缺点

虽然 DAST 工具评估应用程序代码中的各种漏洞，但它们无法定位代码库中安全问题的确切位置；也无法嗅探应用程序堆栈中未执行部分中的漏洞。

常见的 DAST 工具

下图所示是常见的 DAST 工具：

极狐 GitLab 中 DAST 流水线的流程

Step 1：因为 DAST 是黑盒测试，需要依赖于一个运行中的真实应用程序才能工作。因此，先准备一个已部署的应用网站（测试网站）；

Step 2：在仓库 CI Yaml 文件配置对应 DAST 脚本

Step 3：把相应配置提交到对应极狐 GitLab 仓库，触发流水线，通过 CI runner 运行扫描程序，模拟用户访问请求；

Step 4：获得响应结果，分支器会针对响应返回结果做具体分析，如果输出有漏洞，则输出到对应的漏洞报告中，该报告在 CI runner 运行完之后，统一输出到 CI 产物中；

Step 5：根据漏洞报告展示的漏洞具体信息，开发者可以着手进行漏洞修复。

极狐 GitLab DAST 配置指南

Web Analyzer

两种类型的 Web Analyzer 

实际开发中，以 Web 应用为主。极狐 GitLab 针对 Web 应用提供两种类型的 Analyzer ：Proxy-based analyzer 和 Browser-based analyzer。接下来分别介绍：

➤ Proxy-based analyzer: 用于扫描传统的简单 HTML 应用

在极狐 GitLab 中配置 DAST 的 Proxy-based analyzer 非常简单：声明 DAST stages，通过引入一个模板文件，就可以开箱即用了。

在实际运行的过程中，调用 ZAP 代理程序，对应用程序进行一个扫描过程：

➤ Browser-based analyzer: 用于扫描重度使用了 JavaScript 的应用，包括单页应用

Browser-based analyzer 使用浏览器模拟访问：配置对应参数 DAST_BROWSER_SCAN，设置为 true，就可以启用了。

它的原理是在 ZAP 前端设置了一层浏览器代理，模拟用户进行行为分析，通过 ZAP 代理，访问到具体的 Web Application。这样的好处是所有请求和返回结果实际上都是经过 ZAP，这样可以利用 ZAP 的请求分析功能，对具体响应就做具体分析，看是否存在漏洞。

上图配置中引用了一个模版配置文件：DAST.gitlab-ci.yml，它具体是做了哪些事情？如下图：

• 声明了需要引用的镜像版本号：13；

• 声明了一个新的 DAST 任务，使用极狐 GitLab 官方提供的 DAST 镜像，进行扫描处理；

• 可以看到具体的 script 参数里面，先通过提取对应的环境变量 DAST_WEBSITE（如下图方式 1）或者把对应的地址放到根目录下 enviroment_url.txt 文件（如下图方式 2），两种方式取其一；

• 执行脚本，分析完之后他通过 artifacts，也就是对应浏览 Pipeline 产物；

• 最后将漏洞报告输入到文件中去。

方式 1：适合静态地址

方式 2：适合动态地址

配置目标应用程序

如果想启用 DAST，必须要一个 Runtime。如果每次都要预先手动去部署 Runtime 的话，是比较麻烦的，有没有自动部署方式？答案是有的，并且有两种方式：

➤ 通过 docker service 配置 Runtime

提前编译好目标镜像文件，通过 docker service 方式在 Pipeline 中将 Runtime 运行起来。

如下图，定义了两个 job，第一个是 deploy 的 job，第二个是 DAST 的一个运行任务。

在 deploy 里面，通过 docker build 的方式把目标的镜像文件构建出来，并推送到了极狐 GitLab 的一个镜像仓库中。

在启用 DAST 的时候，定义了一个 services 的依赖项，即需要先把对应的镜像运行起来后，得到了一个实际运行地址，把这个地址填到 DAST_WEBSITE 环境变量中，这样就可以实现在 Pipeline 里运行 Runtime 的效果。

这种方式适合简单的镜像程序，因为如果有很多依赖项，就需要把对应依赖项的 Service 也一并定义，比较麻烦。

➤ 和 Review apps 搭配使用

极狐 GitLab 推荐 Review apps 功能，它可以针对某个合并请求来自动部署，用于 QA 验证或自动化测试。

Review apps 提供了这样一种机制：把对应的 MR 部署到某个相对临时的环境中去，就可以通过这个临时环境去看到这个变更的实际影响效果。这样一个临时 runtime 环境，正好可以搭配 DAST 来使用，做对应的 DAST 检测（如下图）。

身份认证：多种登录方式

因为爬虫并不能够自动对未登录的页面进行爬取，所以先要在爬虫里面做一些设置，让爬虫自动登录，Web Analyzer 支持多种登录方式，包括：

• HTTP authentication；

• Single-step login form；

• Multi-step login form。

需要注意的几点：

• 爬虫不具备人机校验能力，登录认证时需要关闭 CAPTCHA；

• 爬虫会遍历网站上的所有链接，如果不对它进行限制，有可能不小心扫到了一个登出链接，然后又会跳到一个重新登录的状态。因此要去除扫描登出链接。

扫描检查项与扫描时间控制

极狐 GitLab 的漏洞扫描检查项，包含高等级、低等级，超过 150 种。

有些部署网站可能比较大，涉及的页面数量和链接数量很多，执行 DAST 可能会出现执行时间过长或超时的情况。

此时就要手动控制对应的爬虫处理数量，DAST 提供了一些对应参数去限制，包括浏览器的数量、最大执行数、最大页面检查深度、总超时时间、具体操作的操作超时时间等，根据具体应用场景去调整。

API Analyzer

API Analyzer 与 Web Analyzer 的区别是，API Analyzer 不支持爬取，需要手动给到 API 文档，让它知道哪些端点需要检测。

支持的 API 格式包括 REST  API、 SOAP、 GraphQL、From bodies, JSON or XML。

如下图，常见的 OpenAPI 需要在 ci.yml 文件中去配置，引入 DAST_API 的样本文件，设置对应的 API 端点即对应的文档地址。

模板配置文件

DAST-API.gitlab-ci.yml 文件引入了另外一个仓库叫做 api-security 镜像，实际执行时也调用了不同的扫描分析脚本去执行输出。

下图是另外一种格式的 API 的配置方式：Postman collection，可以看到的对应的环境变量名称变了。

接着是 GraphQL API 配置方式，通过直接配置 API 端点即可，如果其支持类型，可以通过 API 本身的到详尽文档，不需要指出文档地址，否则需要手动指出。

Analyzer 拿到文档后，首先进行扫描操作，之后针对不同 API 进行实际检测和攻击。

GraphQL Schema with introspection

GraphQL Schema with schema file

身份认证：多种方式

➤ HTTP Basic Auth：直接提供一个账号密码

➤ Bearer token，分为两种：

• token 的过期时间比较长，可以在 CI 脚本 Yaml 文件名配置一个相对固定的 token，这样在整个分析过程中，只需要用到这一个 token 就可以了。

• token 时效性比较短的情况下，需要在爬取过程中定期去做更新处理，可以去指定更新 token 的脚本、更新时间，做到自动更新。

以上，就是关于 DAST 的基础知识和操作分享。同时，我们提供了极狐 GitLab 旗舰版 30 天免费体验机会，欢迎到极狐 GitLab 官网申请试用，结合产品实操，将更加有助于你进一步掌握 DAST 。