💡 如何在流水线中集成与应用 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 。
今天的文章流水线方式执行指令_与流水线的形式相对的叫什么分享到此就结束了,感谢您的阅读。
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
如需转载请保留出处:https://bianchenghao.cn/82635.html