1、背景

我在闲谈自动化应用安全测试工具中提到这么句话“如果能将安全融到DevOps里,又不影响现有的状态,那当然是最好不过了”,这个时候你可能就有疑问了,现有的安全测试模式是怎样的,为啥要做改变呢?为啥非要融到DevOps里面呢?我们来盘盘安全测试几大经典痛点。

DevOps的终极目标:提升软件交付的质量內建以加速流程。那么问题来了,这里的质量侧重点在功能,在于功能能用,好用。那么交付物的安全要如何保证呢?以前基本都是在程序/软件上线后,对其进行渗透、漏扫等待工作,来排除一部分安全风险。在快速持续交付的DevOps下,以下几个问题就凸显出来了。

  1. 代码中使用的组件本身安全性无法得到保障
  2. 开发周期短,版本迭代频繁,难以实现每个版本都完成安全测试
  3. 目前以代码审计为基地的安全审计误报和漏报率过高,需要人工复合,人力资源耗费较大
  4. 开发人员和测试人员安全相关知识体系薄弱,安全人员开发知识体系薄弱,三方沟通有一定屏障
  5. 多数公司安全测试主流为渗透测试,对于代码和功能本身逻辑缺陷无法在研发过程中发现,后期改动对整体架构可能影响很大

说完上面几个痛点,这个时候就希望能有那么一个或几个工具,能在应用上线前实现以下几点:1、在提交代码阶段就能自动检测代码组件安全性、代码的逻辑漏洞;2、在提测阶段功能测试进行的同时进行安全测试,且不增加测试人员工作量;3、预发布环境模拟黑客的攻击手段,对应用进行安全测试。于是乎,就有了今天我要讲的三板斧:SAST、IAST、DAST。

(当然,安全测试左移更合适的是从产品立项开始就介入,此方向后续有空再更新,本文着重从代码开发到上线前夕的安全测试。)

2、DAST

2.1、DAST简介

DAST全称是动态应用程序安全测试(Dynamic Application Security Testing),是一种黑盒测试,也是目前业界用的最多的,使用相对而言最简单的一种安全测试方法。在程序运行阶段进行分析,模拟黑客攻击,并捕获程序反应,从而确定该应用是否会受到攻击。就像在上了锁的房子外看屋内,通过各种方法,一次次的去试探,看有没有可以利用的漏洞,

2.2、DAST原理

  1. 通过爬虫爬取web应用结构;
  2. 根据爬虫结果分析,对发现的页面使用准备好的poc进行攻击尝试;
  3. 对返回的结果进行分析,确认是否存在漏洞;

2.3、DAST优势

安全测试人员无需具备开发能力,无需了解程序内部架构,对程序语言、框架无限制,能发现大部分高分析问题。

2.4、DAST劣势

1、对于爬虫无法发现的url束手无策;

2、随着技术的发展和新漏洞的披露,厂商需要不断的更新漏洞扫描插件;

3、针对需要需要提交某些特殊参数的场景,DAST同样显得捉襟见肘;

4、主战场在web应用程序,来到app战场上也有点力不从心;

5、发现漏洞定位层级在url止步,无法更深层次的探索漏洞原因,需要花费大量时间进行定位和分析,这对于持续交付理念的DevOps就显得很不友好了。

3、SAST

3.1、SAST简介

SAST全称是静态应用程序安全测试(Static Application Security Testing),顾名思义对没有跑起来的静态代码进行安全测试。目前而言,多数开发人员对于代码开发的侧重点在业务功能的实现,对于安全开发的意识不够甚至可以说薄弱, 于是乎,在代码开发这个阶段积累了大量的安全风险。SAST就提供了对源代码进行安全测试分析安全漏洞的能力。

3.2、SAST原理

  1. 首先通过调用语言的编译器或者解释器把前端的语言代码(如JAVA,C/C++源代码)转换成一种中间代码,将其源代码之间的调用关系、执行环境、上下文等分析清楚。
  2. 语义分析:分析程序中不安全的函数,方法的使用的安全问题。
  3. 数据流分析:跟踪,记录并分析程序中的数据传递过程所产生的安全问题。
  4. 控制流分析:分析程序特定时间,状态下执行操作指令的安全问题。
  5. 配置分析:分析项目配置文件中的敏感信息和配置缺失的安全问题。
  6. 结构分析:分析程序上下文环境,结构中的安全问题。
  7. 结合2)-6)的结果,匹配所有规则库中的漏洞特征,一旦发现漏洞就抓取出来。
  8. 最后形成包含详细漏洞信息的漏洞检测报告,包括漏洞的具体代码行数以及漏洞修复的建议。

3.3、SAST优势

SAST从语义、依赖关系、配置文件进行分析,从代码源头发现问题,比从被锁的房子外去发现问题的DAST的检测对象要丰富的多,甚至不需要代码跑起来就能发现问题。

从效率上而言,在代码开发阶段就能发现问题,能及时的进行修正调整,避免后续出现问题需要修改框架的可能性,修复成本更低。

3.4、SAST劣势

看了上面的过程,是不是感觉从源码下手的SAST就能彻底解决安全问题了呢?人无完人,更何况它只是一个工具呢。

支持的语言方面,SAST对于需要进行测试的语言和框架是有一定限制的,如果遇到不适配的语言,就只有无可奈何了。

扫描时间方面,对于源码的分析并没有我们想象的那么快速,扫描一次需要数小时或者更久。

关于误报,目前商业级别的工具误报率至少是30%,误报会导致我们对工具的实用性产生怀疑,同样需要时间来进行漏洞真实性的判断。

4、IAST

4.1、IAST简介

IAST全称是交互式应用程序安全测试(Interactive Application Security Testing),综合了DAST和SAST的优势,曾被Gartner咨询公司列为网络安全领域的Top 10技术之一,具有误报率极低、可以定位漏洞所属api及代码片段等优势。

4.2、IAST原理

目前IAST实现的原理有代理、VPN、流量镜像、插桩四种模式,本文着重介绍插桩模式。

插桩模式:一般是在代码运行的中间件上进行插入探针,常见的有tomcat、spring boot等,通过探针获取程序运行时的请求、代码数据流、代码控制流等,结合请求、代码、数据流、控制流综合分析进行漏洞的判断。插桩模式又分为主动模式和被动模式。(由于此处篇幅过大,简略带过,后面将针对IAST单独出文,敬请期待......)

4.3、IAST优势

插桩模式的IAST所处的地理位置优势,漏洞测试准确性高,误报率极低。发现的安全漏洞既可定位到代码行,还可以得到完整的请求和响应信息,完整的数据流和堆栈信息,便于定位、修复和验证安全漏洞。支持测试AJAX页面、CSRF Token页面、验证码页面、API孤链、POST表单请求等环境。能发现代码中使用的第三方组件的版本和包含的公开漏洞。

插桩模式还可以在完成功能测试的同时完成安全测试,无需额外投入时间完成安全测试,不会影响破坏开发流程,适合持续交付理念的DevOps模式。

4.4、IAST劣势

不支持C、C++、Golang等无需虚拟环境运行的语言,插桩模式是agent-server模式,agent的每次更新都需要重启sever端,部署工作量大。在业务逻辑面前,IAST同样无能为力。

5、总结

总的看来,在开发阶段适合使用SAST,提测阶段适合使用IAST,在预发布/线上适合使用DAST。三个技术各有各的好,也同样有各自的毛病,使用得当,就能在各自所在的阶段能扬长避短的发现更多的安全风险,将安全问题扼杀在摇篮之中。

闲谈安全测试左移三板斧相关推荐

  1. mysqls压力测试怎么用_阿里研究员:测试稳定性三板斧,我怎么用?

    阿里妹导读:如何治理测试稳定性问题?很多人会说:环境.流程管控.监控.工具化.加机器.专人负责.等等.这些都是对的.不过这些都是解决方案层面的,而不是方法论和理论体系层面的.今天,阿里研究员郑子颖来说 ...

  2. 阿里测试左移和开发赋能分享

    此文章为转载,部分内容修改,请知悉.原文地址:https://mp.weixin.qq.com/s/DBcIXCij-BU8PVg6NswUpA --------------------------- ...

  3. 都在说测试左移和右移,只有这篇文章说明白了

    大家熟悉的测试工作(也是传统的瀑布式),是接到项目后参与需求评审,然后根据需求文档写写用例和准备脚本,等开发提测之后正式开始测试.提bug.回归,测试通过后就结束了,项目交给运维上线,之后投入下一个项 ...

  4. 一文搞懂测试左移和测试右移

    软件测试技术应当贯穿整个软件开发生命周期.对软件产品(包括阶段性产品)进行验证和确认的活动过程,其核心目标是尽快尽早地发现软件产品中所存在的各种问题 bug-- 与用户需求.预先定义的不一致性. 然而 ...

  5. 阿里10年测试大佬带你搞懂测试左移和右移

    看到我们论坛一个测试开发知识体系,对于测试左移和右移, 有点不太懂,看了2篇文章,强行提笔总结了下,还有部分内容是直接翻译的.关于测试左移和右移.测试左移中提到了尽早的发现问题.以及持续集成.尽可能的 ...

  6. 【软件测试】敏捷方法与测试左移

    文章目录 敏捷方法 测试左移 测试左移与DevOps 敏捷方法 当敏捷开发方法(Agile Development Methods)出现时,人们认为它们"最适合约 50 人或更小的团队,这些 ...

  7. 敏捷测试的“三板斧“

    什么是三板斧 可灰度:任何变更,都必须是可以灰度的,即控制变更的生效范围.先做小范围变更,验证通过之后才扩大范围 可监控:在灰度的过程中,必须能做到可监控,能了解到变更之后对系统的应用 可回滚:当通过 ...

  8. 阿里研究员:测试稳定性三板斧,赶紧来学习一下

           前言        1. 测试稳定性问题 理想情况下,我们希望每一个失败的测试用例都是由真正的缺陷引起的.实际情况中,用例失败的原因大多是一些其他的原因: ·某个服务的版本部署的不对 · ...

  9. 测试稳定性三板斧,你了解多少?

    一.测试稳定性问题 理想情况下,我们希望每一个失败的测试用例都是由真正的缺陷引起的.实际情况中,用例失败的原因大多是一些其他的原因: a.某个服务的版本部署的不对 b.测试执行机的硬盘满了,因为上次运 ...

最新文章

  1. 《小程序个人信息保护研究报告》解读
  2. 大话移动开发之QT-Quick
  3. 匿名内部类的使用总结
  4. 移动设备页面高度不足时min-height 的尴尬处理
  5. mysql中基本的DML语句
  6. linux6.5dns装什么,CentOS6.5安装DNS服务
  7. 验证文件路径的正则表达式(支持网络路径)
  8. data Mining with Weka: Trailer More Data Mining with Weka 用weka 进行数据挖掘 Weka 用weka 进行更多数据挖掘...
  9. js Dom对象的属性与方法
  10. openCV 中值滤波算法解析
  11. FEC(前向纠错码)
  12. 图片批量压缩工具免费版-免费的批量图片压缩工具
  13. Excel如何实现数据排列组合
  14. 数据科学和人工智能技术笔记 十八、Keras
  15. 一文读懂|什么是dToF激光雷达技术?
  16. WorkManager
  17. Android界面编程之简单的图片浏览器
  18. 实验二 CPU 部件实现之 ALU 和寄存器堆
  19. 怎样把经纬度坐标转换为空间直角坐标
  20. 计算机用老毛桃u盘备份系统,如何使用老毛桃winpe系统进行Ghost备份

热门文章

  1. ARM芯片tops的计算方法
  2. PTA R7-5 Jack cheng的烦恼3
  3. 小米手机ADB删除系统应用去广告
  4. 2016风云杯大学生信安大赛 WriteUp
  5. 50 岁开发者如何绝地求生
  6. base64转图片+图片转base64
  7. 【理解springboot自动装配原理】
  8. VS+QT——二维码生成(使用nayuki第三方库):从建工程开始
  9. 计算机三级网络技术知识点大全(二)
  10. 广电在5G时代的发展和应对策略