刘济舟：《基于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 测试，我们也可以看到甲方提供数据和平台，乙方提供产品并且提供能力支持，甲方在测试过程中会反馈很多痛点给乙方，乙方就可以针对收集到的这些痛点不断优化他们的产品，最终是双赢，甲方可以用到更符合需求的产品，而乙方可以持续提升自己的技术服务水平，扩大市场占有率。
以上就是我今天的分享，谢谢大家。
本文转载自公众号“君哥的体力”，已获得授权。
刘济舟：《基于IAST交互式安全测试实践的初步探索》相关推荐
- 基于功能安全的测试实践：ESCL功能安全测试
概述 整车电子电器软硬件复杂性越来越高,电子系统失效可能导致的安全风险也随之提高,车辆的安全性受到了更大的挑战.本文依据ISO 26262从功能安全测试的角度出发,以ESCL为测试对应,阐述符合功能安 ...
- 基于Vue源码中e2e测试实践
您好,如果喜欢我的文章,可以关注我的公众号「量子前端」,将不定期关注推送前端好文~ 基于Vue源码中e2e测试实践 前言 技术选型&对Vue的参考 Puppeteer测试流程 在Concis中 ...
- 软件测试智能化 优势,陈耿-软件测试的智能化之路-基于模型的测试实践.pdf
国际软件质量工程峰会 International Software Quality Engineering Forum 软件测试的智能化之路 -基于模型的测试实践 目录 • 自我介绍 • 什么是基于模 ...
- 陆金所测试专家金玲谈《基于容器的自动化环境管理实践》
金玲:大家下午好,我是来自陆金所测试部金玲,大家知道陆金所是做什么的吗?请举手示意一下.有在陆金所投资过的举手示意一下?陆金所是针对用户的个人投资理财平台,开始的时候是针对P2P起家,后来整个业务进行 ...
- 基于 MaxCompute 的实时数据处理实践
简介: MaxCompute 通过流式数据高性能写入和秒级别查询能力(查询加速),提供EB级云原生数仓近实时分析能力:高效的实现对变化中的数据进行快速分析及决策辅助.当前Demo基于近实时交互式BI分 ...
- 初探团队基于session的探索性测试
如果你是一名测试人员,那么不管你对探索性测试的了解是多是少,我肯定你一定用过探索性测试的方法.想想看,你是否曾经这样测试过?不仅仅按照测试案例或者脚本上写什么,就完全使用那一套相同的数据.一模一样的流 ...
- soapui工具_基于开源的API测试工具！不再为web服务负载测试而发愁
通过一个可视化.拖拽式的界面,LoadUI允许您实时.交互式地创建.配置和重分配负载测试.在单一测试环境下,LoadUI提供完整的测试覆盖,支持所有标准的协议和技术.它功能强大,能从任意数量的本地和远 ...
- Docker与自动化测试及其测试实践
Docker 与自动化测试 对于重复枯燥的手动测试任务,可以考虑将其进行自动化改造.自动化的成本在于自动化程序的编写和维护,而收益在于节省了手动执行用例的时间.简而言之,如果收益大于成本,测试任务就有 ...
- Maven实战（四）——基于Maven的持续集成实践
相信很多读者和我一样,最早接触到持续集成的概念是来自Martin的著名文章<持续集成>,该文最早发布于2000年9月,之后在2006年进行了一次修订,它清晰地解释了持续集成的概念,并总结了 ...
- 智能测试实践之路-UI缺陷检测
背景 随着业务与技术的发展,软件架构从最初单体结构逐步演变成AI赋能的分布式体系,基础框架技术能力不断成熟,数据.控制.服务等能力的深化为业务的快速建立与扩展提供了强大的支撑能力.与此同时,测试技术由 ...
最新文章
- 一文了解迁移学习经典算法
- SpringBoot 2.0 编程方式配置，不使用默认配置方式
- Java并发程序设计（十一）设计模式与并发之生产者-消费者模式
- web安全攻防从入门到放弃-记录
- [机器学习]AutoML --- TOPT
- 输入法问题_「图」KB4515384再爆新问题：OOBE时中文输入法阻止创建本地账户
- Python函数(1)
- MachineLearning Exercise 7 ： K-means Clustering and Principle Component Analysis
- nyoj461 Fibonacci数列（4）解通项公式
- 洛谷P1338 末日的传说
- H.264流媒体协议格式中的Annex B格式和AVCC格式深度解析
- 「 论文投稿 」《IEEE ACCESS》录用经历
- 【G4基础08】GPS-2-Macro Commands宏命令
- IC芯片设计项目管理002：标准化流程的应用
- QT显示中文 连接上文
- [python作业]给定字符串“site sea suede sweet see kase sse ssee loses“，匹配出所有s开头，e结尾的单词。
- 数据科普：定价模型与平价关系式（投资必知必会）
- Ubuntu系统多屏显示
- (转)Dundas Chart for .NET
- ABViewer Crack,功能丰富的软件支持 60 多种流行格式