如何在流水线中集成与应用 DAST ?
近日,在「DevSecOps 软件安全开发实践」课程上,极狐(GitLab) 前端工程师钱堃、极狐(GitLab) 高级后端工程师张林杰,展开了关于 DAST 的概念、必要性、优缺点的内容分享,并结合实操演示,帮助大家进一步掌握 DAST 技术。
以下内容整理自本次直播,Enjoy~
DevSecOps 在 DevOps 的基础上增加了 Sec(Security,安全)的概念,是指通过与 Sec (安全团队)+ Dev(研发团队) + Ops(运营团队) 合作,在标准 DevOps 周期中建立关键的安全原则。
DevSecOps 提倡 “安全左移” 的理念,即在软件生命周期(SDLC)的早期阶段就注重安全问题,从而防止缺陷产生以及尽早找出漏洞。
在软件开发生命周期不同阶段发现漏洞,其修复成本(人力、财力等)不一样。如下图所示,如果说需求阶段发现一个漏洞,其修复成本是 1,在编码阶段就变成了 5,而在生产阶段变成了惊人的 30,这意味着:生产阶段漏洞修复成本 = 需求阶段漏洞修复成本 x 30。
可见通过安全左移,能够大幅降低安全漏洞修复成本。
图片来源:NIST
不同开发阶段有不同风险漏洞,借助各种安全扫描工具,层层递进,才能实现整体,例如:
图片来源:Freebuf
今天,我们主要分享安全扫描工具之一——DAST(Dynamic Application Security Testing,动态应用程序安全测试)。
提到 DAST,就绕不开通常与其成对出现的 SAST(Static Application Security Testing,静态应用程序安全测试)。首先,先厘清概念:
➤ SAST
通常在编码阶段,对源代码进行安全测试发现安全漏洞的测试方案。
SAST 是对应用程序源代码执行直接的白盒分析,分析是在代码的静态视图上运行的,这意味着代码在审查时没有运行。
➤ DAST
在测试或运行阶段,分析应用程序的动态运行状态。它模拟黑客行为对应用程序进行动态攻击,分析应用程序的反应,从而确定该 Web 应用是否易受攻击。
DAST 是一种黑盒测试技术,它们不能访问代码或实现细节,只检查系统对潜在漏洞测试的请求和响应。换言之,DAST 是外部的漏洞扫描程序。
另外,从扫描准备、扫描速度、开发语言等方面进行比较,两者之间还有以下差别:
从上文的内容中可以看到 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 的不足。
以 Web 部署为例,DAST 的工作流程是:
Step 1 :通过爬虫扫描整个 Web 应用结构,爬虫会发现被测 Web 程序的目录数量、页面数量、页面参数;
Step 2 :根据爬虫的分析结果,对发现的页面和参数发送修改的 HTTP Request 进行攻击尝试(扫描规则库);
Step 3 :通过分析 Response ,验证是否存在安全漏洞。
上述步骤涉及到两种扫描方式,即:
1. 不受语言和框架限制
DAST 测试不要求具备编程语言知识;无论使用何种框架,DAST 工具都会根据输入和输出,评估应用程序行为。
2. 低误报率
DAST 工具对应用程序环境执行端到端扫描,使安全研究人员能够检测和识别安全漏洞。
3. 无需访问源代码
DAST 扫描通过应用程序前端发送恶意有效负载来测试,因此企业可以利用第三方安全服务来执行,而不暴露应用程序代码。
虽然 DAST 工具评估应用程序代码中的各种漏洞,但它们无法定位代码库中安全问题的确切位置;也无法嗅探应用程序堆栈中未执行部分中的漏洞。
下图所示是常见的 DAST 工具:
Step 1:因为 DAST 是黑盒测试,需要依赖于一个运行中的真实应用程序才能工作。因此,先准备一个已部署的应用网站(测试网站);
Step 2:在仓库 CI Yaml 文件配置对应 DAST 脚本
Step 3:把相应配置提交到对应极狐 GitLab 仓库,触发流水线,通过 CI runner 运行扫描程序,模拟用户访问请求;
Step 4:获得响应结果,分支器会针对响应返回结果做具体分析,如果输出有漏洞,则输出到对应的漏洞报告中,该报告在 CI runner 运行完之后,统一输出到 CI 产物中;
Step 5:根据漏洞报告展示的漏洞具体信息,开发者可以着手进行漏洞修复。
实际开发中,以 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,它具体是做了哪些事情?如下图:
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 支持多种登录方式,包括:
需要注意的几点:
极狐 GitLab 的漏洞扫描检查项,包含高等级、低等级,超过 150 种。
有些部署网站可能比较大,涉及的页面数量和链接数量很多,执行 DAST 可能会出现执行时间过长或超时的情况。
此时就要手动控制对应的爬虫处理数量,DAST 提供了一些对应参数去限制,包括浏览器的数量、最大执行数、最大页面检查深度、总超时时间、具体操作的操作超时时间等,根据具体应用场景去调整。
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,分为两种:
以上,就是关于 DAST 的基础知识和操作分享。同时,我们提供了极狐 GitLab 旗舰版 30 天免费体验机会,欢迎到极狐 GitLab 官网申请试用,结合产品实操,将更加有助于你进一步掌握 DAST 。