刘济舟：《基于IAST交互式安全测试实践的初步探索》

3月13日，「金融业企业安全建设实践群·华南分会」在深圳举办了2021年第一场线下活动——IAST实践分享研讨会。

本文内容整理自现场刘济舟的发言，已脱敏，已获原作者授权发布。

以下为发言实录：

大家好，我是刘济舟，今天给大家分享基于 IAST 交互式安全测试实践的初步探索，包括以下四个方面：

一，SDL 体系的的建设考虑

从需求的角度，我们的需求一般是由业务部门进行整理和提出的，通常业务部门更侧重于业务功能的实现，也没有足够的能力去顾及安全，导致在需求分析阶段缺乏足够的安全需求分析和设计。从开发的角度，我们的开发人员侧重于开发编码的能力，信息安全能力比较薄弱，导致他们很难从攻击者的角度去审视开发的软件。整体来看，由于我们以前的安全投入比较靠后，导致项目风险较大而且是在后期才进行安全测试和漏洞修复，所以需要投入的成本也比较大，消耗了较多的人力和时间。

安全测试主要由安全人员参与，我们在做安全测试的时候经常会遇到一些问题：

1、在做白盒测试的时候，还有代码审计的时候，发现我们的执行效率较低，误报率很高，但是安全人员人数又少，就造成我们的运营成本很高。

2、在做 web 扫描的时候，发现扫描器的执行效率也低，覆盖面也不够广，造成很多脏数据，影响到了后续的功能测试。漏洞报告对研发不够友好，没有办法实现功能测试和安全测试的同步进行。

3、为了不导致脏数据影响测试，所以一般情况下是在测试完成后，业务上线前漏洞扫描和人工渗透同步进行。由于渗透测试人员专业能力的局限性，会造成测试结果水平参差不一。同时应用较多，没有办法满足产品快速迭代的需求。所以我们一直在寻找一些新的技术、新的商业化产品来提升现有的安全测试体系。

基于以上困扰，我们在去年启动了开发安全能力建设项目，与项目管理平台结合，包含各阶段流程的梳理、评审机制的建立、相关开发资源库的建设，引进业内先进的安全工具，将通过数据接口收集各阶段安全数据、开发数据及漏洞样本。构建我联社自身研发组织特点的软件安全开发生命周期体系。

大家可以看到，有启动立项，需求设计，编码测试，发布验收这样一个生命周期，我们在生命周期内不同阶段设置了一些控制点，由不同的人员去执行。

首先是可行性分析立项之后，项目人员会对项目进行风险定级，然后提出安全要求，这时候我们安全人员就在这里设置一个控制点，对立项材料进行安全评审，通过之后再到下一步形成需求文档，项目人员就会进行安全需求分析，我们安全人员就会对他提出的安全需求分析进行评审。

接下来在系统设计报告形成的时候，项目人员就会对系统设计报告提出安全设计的内容，然后安全人员进行安全设计的评审，最后在编码完成测试之后，由测试人员编写安全测试开发人员编写安全测试用例，然后再由安全人员对测试用例进行评审。

最后在准生产环境上线之后发布之前，也会由项目人员进行等保合规检查，还有代码审计，然后再由安全人员进行系统配置的审核，漏扫，渗透，还有安全需求符合度，形成一个闭环。

控制对象有四个，一总体的安全需求，二详细的安全需求分析，三安全设计材料，四安全测试，最后保证系统的安全质量。这个过程也需要一些工具来支撑，安全组件库，安全解决方案库，源代码扫描的工具，配置检查工具，测试工具，搭建安全需求分析平台，还有漏洞扫描工具。

我们是把整个 SDL 体系和项目管理平台结合来做，目标是以企业开发生命周期为主线，针对每个环节嵌入安全活动，通过工具链的支撑，最终达到优化整体 SDL 体系的目的。

二、SDL 建设中安全测试的需求和厂商选型的考虑。

1、随着新技术和新架构的不断推陈出新，安全测试也提出更高的技术需求，要适应新架构，解决传统 web漏扫没法实现的功能，比如api微服务等等。

2、提高安全测试的覆盖率。传统的安全测试没法应用某些场景，比如加密一次性资源防重放，签名验签等。

3、我们想要实现安全左移。以前的安全测试是比较靠后的，现在需要把安全测试前置，在开发测试阶段去提升软件的安全性。通过功能操作即可自动化输出精确的安全结果，无需专业的安全人员和投入额外时间。

4、我们需要安全能力透明集成。既要解决应用安全问题，又要保障工作效率，让工具链自动化集成到开发测试环境里，原则就是不能麻烦别人，不能因为安全的增强而影响应用的迭代或者降低工作效率，这样开发人员才会接受安全，我们的工作才能更好推进。

接下来分享我们对 IAST 交互式技术实现的两种方式：

1、基于流量交互式的安全测试通过代理还有探针，在业务流量中把参数替换成攻击向量，然后发送给被测服务器，通过服务器的回报对测试结果进行判断。不再单一利用 DAST 爬虫技术来获取WEB应用的 URL，而是通过各种流量收集方式解决了获取应用 URL 的问题，这种 IAST 交互技术其实也是一种优化的 DAST 被动扫描器。深层次原理还是篡改原始报文，将输入点的值替换成 Payload，并重放数据报文。然而 DAST不能提前预知 URL 的输入点会存在什么类型的安全漏洞，因此只能将所有不同漏洞类型的 Payload 全数依次替换后重放数据报文。所以我们更关注基于插桩的交互式安全检测技术。

2、基于插桩流量的交互式安全监测技术。插桩模式分为两种，一是主动型，二是被动型。

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

被动型 IAST 是用自解码插桩技术，在无需改造应用代码的情况下，采集函数调用链数据流。根据之前配好的规则，分析函数的调用链数据发现安全漏洞。被动型 IAST 在漏洞检测过程中始终保护静默监听，不会主动去重放报文。被动型 IAST 可以比 SAST、DAST 检测更多的通用漏洞，因为 agent 可以查看应用的所有代码、应用程序运行时控制流、应用程序数据流信息、环境配置信息、HTTP 请求和响应、使用的框架和其他组件、后端连接信息、数据库连接等，所以是我们更加重点关注的产品。

三、IAST产品测试对比

分成两个环节，一是通过漏洞靶场，对 IAST 产品进行交叉验证；二是把 IAST 产品部署在真实的测试环境里面进行测试。为了验证产品成熟度，我们重点关注了以下能力：

1、漏洞检出率

2、漏洞误报率

3、漏洞检测的覆盖率

4、场景的覆盖率

5、威胁发现的能力

6、 Agent 的兼容性

漏洞把场是我们自己搭的Java环境，针对一个已知漏洞去进行验证。漏洞靶场主要是已知漏洞的情况下去检测漏洞，企业测试环境就是在未知漏洞的情况下去检测产品的漏洞发现能力。

漏洞靶场我们基本覆盖了OWASP Top10 的重要威胁漏洞类型。

因为被动插装模式下去分析代码，会hook底层函数，所以我们在同一种漏洞下用造成该漏洞的不同类函数去编写漏洞来检测产品的能力，比如 SQL 注入就是用了5个函数， SSRF HttpURLConnection类、URLConnection类，恶意软件访问类型，XXE命令执行，还有其他的反射型XXS，存储型 XXS等，这些是基础测试的内容，然后我们还对特殊场景——一般测试没有办法检测到的场景——比如加密情景、编码情景等进行测试。

这是我们部分测试结果的分享。

SQL注入，我们就用了5个函数，产品A均能检测出来并告警。产品C只检测出 mysql，mybatis，其余三个函数没有检测出来。

这是目录遍历测试的结果。

我们使用了 File.listfiles 函数去执行，有路径拼接，做了4个，1个是正常调用，第2第3个是Linux的不正常调用，第4个是windows的不正常调用。结果产品A和产品C都可以检测出目录遍历的告警。

还有任意文件下载结果的分享。

同样采用路径拼接的形式，使用了一个正常调用，两个不正常调用，这里可以看到一些读取内容的测试用例，结果就是产品A和产品C都可以检测出这种漏洞类型。

接下来是 IAST 漏洞展示。

首先是污点输入，展示应用处理污染源出现的详细位置，接下来是污点传播，展示出应用处理污染源进行转/解码的详细过程和应用中污染源传播途径,如应用处理字符操作的详细过程等，这就是污点传播。最后是污点执行，比如展示出应用处理SQL操作完整调用栈数据，同时把用户代码突出展示。通过污点输入、污点传播 、污点执行的清晰展示能更好帮助开发人员定位代码，帮助安全人员复现和利用。

接下来是前面给大家提到的，我们做了4个特殊场景的靶场测试：

我们最关注的就是特殊场景的IAST检测率，因为在加密加签这些特殊场景下，自动化工具很难发现漏洞，如想发现漏洞，也需要安全人员花费时间去编写相应的加解密工具对接。

1、加密场景。普通的安全测试在加密场景下无法对一些漏洞进行告警，那么 IAST 产品到底能不能在加密场景下正确地告警？加密场景一般出现在前后端传递敏感信息时，前端加密，然后把敏感信息传到后端进行解密。

2、防篡改场景。API 接口需要第三方服务调用，所以必须暴露到外网。为了防止别有用心的中间件攻击，我们会对每个请求的参数进行唯一的数据签名，避免中间人的攻击的场景。

3、防重放场景。主要用于避免用户多次点击形成脏数据，尤其是在有支付请求的时候容易产生多次点击，如果不做防重放，就会导致现金不一致的问题，我们采用一次性 token 和一次性验证码来模拟请求防重放的场景。

4、编码场景。主要适用于应用服务器不方便传输不可见字符，比如一个纯文本协议，二进制中可能会出现被当做控制字符处理的部分，这样就会引起传输失败。编码场景一般出现在需要在前后端传递信息的时候，比如采用 Base64 编码方式来执行一个ping命令，从而触发CMD漏洞攻击。

接下来展示两个场景的测试结果。

第一个是加密环境场景：

第二个是防篡改场景：

接下来用三种不同的模式进行测试——插桩模式IAST，黑盒测试，渗透测试——在这三种不同模式下我们发现它们彼此的不同点和互补的地方。

IAST 主要的优点在于无重放，没有脏数据，降低安全人员的工作量，但是它的覆盖面有一些欠缺。渗透测试的优势在于业务逻辑测试。接下来是IAST和渗透测试的对比：

用 IAST 进行测试的时候，我们发现了5个 SQL 注入、2个 XXE、1个任意 URL 跳转、6个 XSS，但人工渗透测试包含了漏扫，它是没有办法检测出这么多应用漏洞的，覆盖面没有 IAST 广。但是从业务逻辑漏洞来看，IAST 只检测出了水平越权，人工渗透测试 发现了敏感信息泄露、任意密码重置、接口未鉴全和水平越权。人工渗透测试在业务逻辑漏洞上还是有它的优势的。

四、IAST 产品测试总结和建议

插桩模式的 IAST 优点比较明显，支持 API、微服务、加密等等防重放的场景，漏洞检出率很高，误报率较低没有脏数据，检测效率较高，安全人员检测完成后漏洞就出来了，不需要安全人员再介入，降低了安全人员的工作量。IAST 还可以定位到具体的污染点，跟踪污染，但是 IAST 也有缺点：

1、无法有效识别安全过滤 。比如一些输入源添加了自定义的过滤函数，被动插装无法进行识别分析，造成“误报”；

2、 无法有效检测业务逻辑漏洞。虽然流量代理 和流量镜像模式下IAST有相应的功能进行检测，但是误报率还是特别高；

3、 污点分析能力无法有效识别一些为u照顾函数或者错误，丢失这些函数的污点传播链，从而无法检测；

4、无法检测没有插桩的 WEB 应用；

那么我们在使用了 IAST 之后，是不是就不需要 SAST，DAST了？

也不是。技术本身没有优劣之分，不同的技术可以解决不同场景的问题。

针对应用软件系统，IAST 插装模式下解决传统扫描技术高误报率、无法适应新应用架构等问题，同时也解决了人工渗透测试受人员专业能力的局限且费时费力，无法满足产品快速迭代等问题。且IAST能有效对 SQL 注入、命令注入、目录遍历、不安全的反序列、LDAP 注入、跨站请求伪造、表达式注入、NoSQL 注入等漏洞进行安全测试，覆盖了 OWASP 、CWE漏洞类型标准，相比传统漏洞扫描技术的测试覆盖率、精确度可提升 70-80%以上，那是不是就不需要 SAST 、DAST了？

思考这个问题前就首先需要思考他们各自原理和各自的优劣势，SAST 是白盒审计，处于开发过程中，并且有源码，优势非常明显。单从覆盖面来看，白盒的覆盖面非常大，如果人力比较充足的情况下可以接受通过工具化和人工筛查可以是企业最好的 bestway。目前主动型插桩和流量代理形式插桩已经集成 DAST 能力，DAST 已经慢慢融入到 IAST 。而 DAST 也融入到渗透测试中，形成自动化渗透的工具基础，需要通过工具和人结合，提升到一种新的高度，去发现一些更隐蔽的漏洞。

那么我们甲方也要因地制宜选择对应的技术去解决对应的问题，或者是把技术进行交叉测试。

通过 IAST 测试，我们也可以看到甲方提供数据和平台，乙方提供产品并且提供能力支持，甲方在测试过程中会反馈很多痛点给乙方，乙方就可以针对收集到的这些痛点不断优化他们的产品，最终是双赢，甲方可以用到更符合需求的产品，而乙方可以持续提升自己的技术服务水平，扩大市场占有率。

以上就是我今天的分享，谢谢大家。

本文转载自公众号“君哥的体力”，已获得授权。