被动型IAST是DevSecOps实现自动化安全测试的最佳工具

　　把Sec塞进DevOps不只是技术与工具变更那么简单，更重要的是思维方式和内部流程的转变，推进DevSecOps的关键原则是：别给人添麻烦。

　　《Gartner 2017研究报告：DevSecOps应当做好的十件事》和《Gartner 2019研究报告：DevSecOps应当做好的十二件事》两篇研究报告中都对成功实施DevSecOps进行了研究。两篇报告一致认为实施DevSecOps的关键挑战和第一要素是：“安全测试工具和安全控制过程能够很好的适应开发人员，而不是背道而驰”。安全团队想要将安全测试或安全控制成功的融入在DevOps中的前提是：

　　不要试图改变程序员和测试人员的工作方法，也不要去增加他们额外的工作负担。

　　否则你将破坏DevOps的协作性和敏捷性，注定会成为众矢之的，最终无法落地。由于破坏DevOps的协作性和敏捷性而失败的惨痛案例笔者身边就有好几个。

　　应用安全测试在CI/CD软件开发周期中的集成点

　　WEB应用安全测试目前在市场上有众多的解决方案，其中最老牌、应用最为广泛的应属SAST和DAST这两类的测试工具，通过在源代码 (SAST) 或公开对外接口 (DAST) 上运行安全扫描，可以在应用上线之前识别并纠正许多漏洞。

　　然而随着 DevSecOps 被广泛接纳，Gartner 在 2017 年的研究报告中明确提倡用 Interactive Application Security Testing (IAST) 替换 SAST 和 DAST，原文如下：

　　考虑交互式应用安全测试 (IAST) 替代传统的静态应用安全测试（SAST）和动态应用安全测试 (DAST) 是可行的，我们建议这么做。IAST 是在DAST基础上的一种改进形式，测试过程更加可视化，包括内部和外部的。IAST 综合了 DAST 和 SAST 的优势，在确保测试代码覆盖率的基础上尽可能的做到了减少误报。

　　接下来笔者分析一下 Gartner 为何如此推崇在 DevSecOps 中采用 IAST 来替换 SAST 和 DAST。

　　1、SAST 因效率差、误报率高无法敏捷的融入到 DevOps 中

　　首先我们对 SAST 实现原理进行简单分析，SAST 一般实现都是在不运行代码的情况下通过词法分析、语法分析、控制流、数据流分析等技术对源代码进行扫描，并利用复杂的检查规则匹配发现与定位缺陷，最后生成结果。

　　虽然 SAST 目前可以集成到开发者IDE环境并融入到 DevOps 中，但 SAST 往往需要比较长的扫描分析时间，实时性比较差，同时误报率也比较高，需要投入大量的安全团队的资源来去除这些误报。

　　除此之外，SAST 针对应用程序引用的第三方开源组件、开源框架也无法有效识别已知存在安全风险。

　　总之，SAST 实际应用在 DevSecOps 环境中并不轻松，除非你拥有非常充裕并且经验丰富的安全团队对其进行不断的优化、开发与维护。

　　2、DAST因适应场景有限及严重影响正常业务功能测试而无法融入到DevOps中

　　DAST 是目前应用最为广泛的 WEB 应用安全测试工具，市面上有些厂商把 DAST 经过改造偷换概念自称 IAST。IAST 产品鱼龙混杂，笔者身边就有因为选用了此类产品导致无法无缝融入 DevOps 的情况，为大家避免再次踩坑本文会花较大篇幅用于讨论 DAST 相关技术。

　　DAST 的原理相对比较简单，一般分为以下几个阶段：首先 DAST 利用爬虫技术获取尽可能全的应用URL后进行去重，然后分析和提取外部可能的输入点；其次针对每个URL中的输入点替换成不同漏洞类型的 Payload，实质上是篡改原始数据报文轮番地毯式向WEB应用重放 HTTP/HTTPS 报文，最终 DAST 收到WEB应用的响应报文对其分析来判断漏洞是否存在。

　　由于爬虫技术的天生缺陷，DAST 面临着诸多的挑战。首当其冲的是爬虫无法爬取应用完整 URL 的问题。如：当应用具有 AJAX、Token、验证码、独立 API 等情况，或者应用执行必须依赖上步执行结果逻辑的场景，比如在面对密码重置、交易支付等场景应用时均无法进行有效的覆盖。为了解决 DAST 爬虫技术的缺陷开始对其进行改造，通常将 WEB/APP 客户端访问应用时的流量进行代理，方法有通过浏览器配置代理、VPN 流量代理等方式。对于非**环境还可以通过交换机流量镜像、应用访问日志导入、在应用服务器上部署客户端获取流量等几种弥补方案，通过以上补救方案后 DAST 就可以规避一些爬虫技术的缺陷。

　　分析完 DAST 爬虫缺陷我们再来分析查找输入点和 Payload 替换阶段的缺陷。

　　如今在互联网上的交易类 WEB/APP 应用为了保证数据的保密性和完整性必须在传输过程中对数据采用**、加签的方法，然而这对 DAST 这类安全测试工具几乎是毁灭性打击。

　　根本原因在于 DAST 无法得知其测试应用所采用的**算法与密钥，不能还原成明文，只看到一堆乱码密文无从获取有效的输入点，替换 Payload 就更无从谈起了。对于应用只有加签的场景对于 DAST 来说即使获取了有效的输入点，篡改原始报文替换 Payload 重放数据报文也不会被应用接受或处理。

　　那么假设 DAST 在面对没有采用**、加签等场景的 WEB 应用时，是否可以无缝融入 DevOps 实现 DevSecOps 测试阶段的自动化安全测试呢？各位看官,且听我慢慢道来。

　　首先我们假设 DAST 已经通过了良好的改造不再利用 DAST 爬虫技术来获取WEB应用的 URL（改良后有些厂商自称IAST~_~，且称之为伪 IAST），而是通过各种流量收集方式解决了获取应用 URL 的问题。那么接着 DAST 开始进入篡改原始报文，将输入点的值替换成 Payload，并重放数据报文的过程，然而 DAST 不能提前预知 URL 的输入点会存在什么类型的安全漏洞因此只能将所有不同漏洞类型的 Payload 全数依次替换后重放数据报文。

　　这会造成什么后果？服务器流量被放大 20 倍，加资源勉强解决了，但扫描速度变得巨慢，我等也敢怒不敢言。因重放数据导致重复提交数据，使得自动化功能测试失败（产生了脏数据、功能异常等问题），测试小姐姐跳脚了，这下忍无可忍了。情急之下灵光一现：采用延时检测或定时计划检测功能，把漏洞检测时间放在小姐姐测试结束后进行，不就 OK 了？！于是，嘴角一上扬微微一笑开始配置晚上 12 点后开始检测。

　　第二天早上迫不及待登录 DAST（伪IAST）系统查看扫描结果，显示屏和大脑一片空白，漏洞呢？原来应用系统登录会话超时、有些功能需要一次性Token，有些需要短信验证，有些接口只能特定的IP才能访问，有些需要回答一个随机问题后才能进入下个阶段……，这些都无解啊！！！

　　看形式只能使出必杀技，剑走偏锋。喊上研发部门开会，为能使 DAST（伪IAST）正常工作，提出让研发同步维护两个版本，除正常功能外还需要再增加一个版本。这个版本要求不能有**、会话不过期、没有验证码、没有一次性 Token、没有签名、没有……话还没说完研发老大拍案而起怒怼：老子 996 为了赶项目进度，你 MMP 还要来添堵，想让我们 120 吗？

　　最终结局可想而知，领导叫停 DAST（伪IAST）在功能测试阶段的应用，美好的安全测试向左移，安全无缝融入到 DevOps，DevSecOps 测试阶段的自动化安全测试梦想就这样被破灭了。当然并不能说 DAST（伪IAST）一无是处，DAST（伪IAST）只是不太适用在DevSecOps测试阶段的自动化安全测试或一些**、加签的一些复杂应用而已。

　　3、被动型IAST是DevSecOps测试阶段实现自动化安全测试的最佳工具

　　首先让我们来看一下Gartner对IAST的定义：

　　交互式应用程序安全测试（IAST）结合了静态应用程序安全测试（SAST）和动态应用程序安全测试（DAST）技术。这旨在通过SAST和DAST技术的交互，提高应用程序安全测试的准确性。IAST 将 SAST 和 DAST 中优势部分集成到了一个解决方案中。这种方法可以非常容易确认漏洞是否真实存在，并确定其在应用程序代码中的漏洞代码位置。

　　看到这里大家终于明白为什么说改良后的DAST是伪IAST了吧。根据Gartner的定义，IAST需要结合SAST和DAST两者的技术优势，最终检测出的漏洞详情应非常容易确认是否真实存在，同时需要定位到存在安全风险的代码位置。

　　IAST 漏洞详情中都会包括漏洞形成的应用内部数据流的详细传播过程，以及漏洞存在的代码位置，这都是为了能让安全人员更方便的确认漏洞的真实性，让开发人员更容易理解漏洞的形成原因，同时使得开发人员自主的去修复漏洞更加容易。

　　目前市面上 IAST 根据实现原理不同可以两类，主动型 IAST 和被动型 IAST。这两类工具的共同点是对应用开发语言关联性非常紧密，均需要部署 Agent。Agent 会将可能引起安全风险的底层函数进行 hook。

　　主动型 IAST 结合了 DAST 的功能，篡改原始报文替换 Payload 进行数据报文重放，并在底层函数 hook 点实时监听，当监听到 Payload 进入函数 hook 点则判断漏洞存在。

　　主动型IAST的优势是几乎不存在误报，检测速度快于 DAST，但和 DAST一样没有办法适用于有**、加签、一次性 Token 等复杂应用场景，同时还存在产生脏数据、破坏功能测试结果等问题。因此主动型 IAST 也不能无缝融入到 DevOps，实现 DevSecOps 测试阶段自动化安全测试。

　　最后来看看被动型 IAST，被动型 IAST 在漏洞检测过程中始终保护静默监听，不会主动去重放报文。被动型 IAST 可以比 SAST、DAST 检测更多的通用漏洞，因为 Agent 可以查看应用的所有代码、应用程序运行时控制流、应用程序数据流信息、环境配置信息、HTTP 请求和响应、使用的框架和其他组件、后端连接信息、数据库连接等等。那么被动型 IAST 是如何检测漏洞的呢？

　　被动型 IAST 判断漏洞的主要原理实际上也并不复杂：被动型 IAST 认为外部传入的输入参数在没有经过安全过滤的前提下，又传播到了一个可能引起安全漏洞的风险函数，则会判定为漏洞存在，当然在实际商用产品中会加入很多其他逻辑。

　　原理

　　被动型IAST并不关心也不需要关心应用外部传入的输入参数是否**，天然支持具有**传输的场景。

　　其次我们可以看到：被动型 IAST 检测过程不需要重放数据报文，也就天然支持具有加签、一次性Token、短信验证、生物验证等等复杂应用场景，同时不会影响正常的业务功能测试。

　　被动型 IAST 另外一个特色是检测效率奇高，精准实时的漏洞检测，可与功能操作同步完成安全测试。

　　最后，被动型 IAST 不仅可以解决应用通用漏洞检测问题，还能对应用引入的开源组件进行风险管理，这一点对应用开发安全来说也特别的重要。

　　当然 IAST 并非没有缺陷，IAST 主要问题在于不同语言开发的 WEB 应用需要有不同类型的 Agent，特别是研发被动型 IAST 技术难度和投入都非常巨大，这也是为什么被动型 IAST 商用产品寥寥无几的重要原因。

　　另外 IAST 没有爬虫技术也不主动重放数据报文，因此无法检测没有安装 Agent 的 WEB 应用，对于需要进行远程漏洞扫描的场景 IAST 无法适用。

　　总结一下

　　被动型 IAST 可以适用于任何**、加签、一次性资源等复杂场景的应用，同时检测过程安全无危害，是 DevSecOps 测试阶段实现自动化安全测试的最佳工具。

　　最后让我们回顾一下Gartner报告中对DevSecOps的概述：

　　将安全性集成到 DevOps 中以交付 DevSecOps 需要改变思维方式，流程和技术。安全和风险管理领导者必须坚持 DevOps 的协作、敏捷性，以便安全测试在开发中实现无缝集成，从而使DevSecOps中的 ‘安全’ 透明。

　　所以在实际推进DevSecOps时应始终坚持“协作、敏捷、透明”，另外并不只是技术与工具变更，更重要的是思维方式和内部流程的转变才能真正达到预期。