目次
一、概述
二、安全工具链在平台中的定位
2.1 概述
2.2 分层定位
2.2.1 不同阶段的安全工具
2.2.2 安全工具金字塔
2.3 安全流水线集成概览
2.3.1 概述
2.3.2 尺度流水线集成安全工具链概览图
三、安全工具链分类
3.1 概述
3.2 威胁建模类
3.2.1 威胁建模的概念
3.2.2 威胁建模起到的作用
3.2.3 威胁建模的流程
3.2.3.1 威胁建模流程图
3.2.3.2 威胁建模流程内容
3.2.3.2.1 绘制数据流图
3.2.3.2.2 威胁识别与分析
3.2.3.2.2.1 STRIDE威胁分析方法论
3.2.3.2.3 制定消减步伐
3.2.3.2.3.1 消减步伐表
3.2.3.2.3.2 DREAD 威胁评级模型
3.2.3.2.4 验证消减步伐
3.3 静态安全检测类
3.3.1 静态检测原理
3.3.1.1 静态检测原理图
3.3.1.2 静态检测技能发展阶段
3.3.1.2.1 基于正则匹配代码分析
3.3.1.2.2 基于AST代码分析
3.3.1.2.3 基于IR和CFG代码分析
3.3.1.2.4 基于CodeQL代码分析
3.3.2 SAST产品列举与横向对比
3.3.3 总结
3.4 动态安全检测类
3.4.1 DAST根本原理
3.4.1.1 动态检测原理图
3.4.2 DAST的缺点
3.4.2.1 覆盖范围有限
3.4.2.2 限定HTTP/S测试对象
3.4.2.3 无法定位漏洞代码
3.4.2.4 产生脏数据
3.4.2.5 特定场景不支持
3.4.3 总结
3.5 交互式安全检测类
3.5.1 IAST根本原理
3.5.1.1 主动式IAST
3.5.1.1.1 主动式IAST根本原理
3.5.1.1.2 被动式IAST根本原理
3.5.1.1.2.1 IAST探针作用
3.5.2 SAST、DAST和IAST优劣势对比
3.6 运行时应用自我保护类
3.6.1 运行时保护界说
3.6.2 运行时保护根本原理
3.6.2.1 原理形貌
3.6.2.2 原理图
3.6.2.3 Java插桩技能分类及优缺点
3.6.2.3.1 基于ByteBuddy字节码转换的原理
3.6.3 RASP的缺点
3.6.4 总结
一、概述
本文将重点先容安全工具链子系统和周边生态子系统。通过这些内容的先容，为各人打下DevSecOps平台技能框架的基础，为后续章节的安全专项本事与DevOps融合做前提铺垫。
安全工具链是指企业安全建设者站在整个软件开发生命周期的角度，去选择不同的安全工具在软件研发过程不同阶段解决安全风险，从而实现平台级的安全主动化。周边生态系统是指除了安全工具之外，在软件开发生命周期或DevOps流程中还涉及其他的系统，如项目管理、组件仓库和镜像仓库等，这些典范的周边生态系统都会影响到安全工具链的建设与实行方案。
二、安全工具链在平台中的定位
2.1 概述
建设DevSecOps平台的目标之一就是降低线上安全漏洞的数量和修复成本，围绕这一目标，其核心是构建和利用好各种主动化安全漏洞检测工具，并将其与CI/CD流水线进行主动化集成，在不影响研发效率的同时，确保安全漏洞能够及时、准确地发现。
作为建设者，需要根据工具的特性和所适合嵌入的研发阶段，对安全工具进行分类，以明确安全工具在整个平台中的定位，构建安全发现本事的纵深，让各种安全工具各司其职，终极形成完备的安全工具链。
2.2 分层定位
2.2.1 不同阶段的安全工具
在DevSecOps中，安全左移的表现情势是将安全工作前置到目标规划、需求分析、软件设计、编码开发、构建部署等阶段，并由CI/CD平台推动整个开发和运营流程主动化，在不同阶段采用不同的安全工具。
下图列举了各阶段的一些典范安全工具，这些安全工具主要特点是高度主动化及可集成性。
从上图中可以看到，在软件开发生命周期的不同阶段都对应了不同的安全工具及工具的主动化程度，在某个阶段的主动化程度越高就越适合在该阶段做工具集成。
例如，SAST（静态安全检测）和SCA（软件成分分析）适合在开发和构建阶段集成至CI/CD流水线，而DAST（动态安全检测）和IAST（交互式安全检测）适合在测试阶段集成至CI/CD流水线。终极在DevSecOps模式下，安全工具链覆盖软件开发生命周期的所有阶段。
2.2.2 安全工具金字塔
除上述根本安全工具外，有时还需要一些更前瞻性的安全工具，这些安全本事井井有条、相互作用、本事叠加、共同协作来保障应用安全。在《2020 DevSecOps行业洞察陈诉》中，初次提出了安全工具金字塔概念，如下图所示：
《2020 DevSecOps行业洞察陈诉》参考地址：
《2020 DevSecOps行业洞察陈诉》正式发布了 - FreeBuf网络安全行业门户
该金字塔涵盖了传统建设层、应用实践层和杰出层，并从技能前瞻性、落地难度和市场遍及时间三个维度思考未来DevSecOps演进的工具链，目前已发展到2.0版本。
图中从安全的角度，自下而上地显示了不同阶段、不同条理的安全检测工具。陈诉中指出，工具的分层与该工具的普适性、侵入性和易用性相干，一般认为普适性强、侵入性低、易用性高的工具适合金字塔底层并优先集成，相反普适性弱、侵入性高、易用性低的工具更适合在不停的实践深化过程中逐渐引入。别的，陈诉中还指出，金字塔中的安全工具分层与DevSecOps成熟度分级没有直接关系，仅使用低条理的安全工具也可以完成高等级的DevSecOps实践成熟度。
2.3 安全流水线集成概览
2.3.1 概述
在安全主动化落地阶段，需要由安全职员去构建这些安全本事，并将安全本事原子化，放到DevSecOps流水线的编排模板中。通常是根据企业的业务形态去构建各个不同的原子化本事，然后将这些本事集成至对应的作业模板。通过安全原子化本事与作业模板编排后的融合，当业务真正去使用的时候，只需在流水线中选择一个模板即可完成安全操纵。
2.3.2 尺度流水线集成安全工具链概览图
下图展示了一个尺度流水线集成安全工具链的概览。
从上图中可以看到，当DevSecOps流水线构建完之后，安全原子化本事可以根据流水线作业模板做不同的编排，例如，代码提交完之后主动触发代码安全检测，构建完之后触发软件成分分析，部署完之后触发安全扫描。当流水线作业模板充足丰富的时候，整个安全主动化工作就逐渐做起来了，这是一个慢慢迭代的过程，一般来说是从研测向运维推进建设，大概研测和运维同时建设，并向中间合拢，最后达成一体化的安全主动化。主动化之后，DevSecOps平台里会出现许多过程数据，如项目管理数据、任务数据、漏洞数据等，基于这些汇总数据，可以持续地去做度量分析和运营改进。
三、安全工具链分类
3.1 概述
在谈安全工具链时，看到最多的就是各种安全检测工具，如SAST、DAST、IAST等。前文已经讨论了这些安全检测工具在DevSecOps平台各阶段的主动化程度和分层定位，同时列举了尺度流水线的集成概览，本节将继承探讨这些典范工具的技能原理、优缺点及使用场景。
3.2 威胁建模类
3.2.1 威胁建模的概念
威胁建模(Threat Modeling)是分析应用程序安全性的一种结构化方法，通过识别威胁明白信息系统存在的安全风险，发现系统设计中存在的安全题目，制定风险消减步伐，将消减步伐落入系统设计中。
3.2.2 威胁建模起到的作用
威胁建模可以在产品设计阶段、架构评审阶段大概产品运行时开展，强迫我们站在攻击者的角度去评估产品的安全性，分析产品中每个组件是否大概被篡改、仿冒，是否大概会造成信息泄露、拒绝攻击等。
3.2.3 威胁建模的流程
3.2.3.1 威胁建模流程图
在微软的软件开发生命周期中，一直将威胁建模当作最核心的一部分，并通过威胁建模消除绝大部分的安全风险。下图展示了微软威胁建模的流程。
从上图图中可以看到，威胁建模包含绘制数据流图、威胁识别与分析、制定消减步伐、验证消减步伐4个流程。
3.2.3.2 威胁建模流程内容
3.2.3.2.1 绘制数据流图
数据流图一般是根据业务的系统上下文、逻辑架构图、网络界限、服务或组件调用关系，由安全职员与业务方一起绘制。绘制数据流图的过程可以帮助安全职员更好地明白业务、确保安全视角没有遗漏。可以使用一些威胁建模工具绘制数据流图，典范的有微软提供的威胁建模工具Microsoft Threat Modeling Tool和OWASP安全组织提供的OWASP Threat Dragon。
微软微软提供的威胁建模工具官网地址：
Microsoft Threat Modeling Tool 概述 - Azure | Microsoft Learn
OWASP Threat Dragon官网地址：
OWASP Threat Dragon | OWASP Foundation
下图为微软威胁建模工具绘制的某业务数据流图。
数据流图主要由外部实体、处置惩罚过程、数据存储、数据流及信托界限构成，在上图的数据流图中，矩形表现外部实体，圆形表现处置惩罚过程，中间带标签的两条平行线表现数据存储，带箭头的曲线表现数据流，蓝色虚线表现信托界限。
下图详细列举了构成数据流图的5个部分。
3.2.3.2.2 威胁识别与分析
通过数据流图和信托界限的划分，我们对容易产生威胁的地方也有了一定的明白。要识别威胁，首先需要知道攻击者的目标，明确需要保护的重点资产，如代码、服务器、敏感数据等；其次界说大概的攻击者，如内部员工、竞争对手、外部的攻击团队等，并找出这些潜在的攻击者大概的攻击路径，如利用安全漏洞、弱口令、垂纶邮件等，可以看到攻击路径的确定会影响到终极的信托界限划分；最后需要对这些识别到的威胁进行分析，剖析大概会出现的详细威胁。
3.2.3.2.2.1 STRIDE威胁分析方法论
STRIDE方法是微软提供的用于威胁分析的方法论，它从攻击者的角度把威胁划分成六个种别，分别是Spooling（仿冒）、Tampering（篡改）、Repudiation（狡辩）、Information Disclosure（信息泄露）、Dos（拒绝服务）和Elevation of Privilege（权限提拔），几乎能够覆盖目前绝大部分安全题目。但随着近年来隐私保护的题目越来越严重，隐私安全也成了业务一个重要威胁，因此STRIDE新增了一项Privacy（隐私），演变成现在的ASTRIDE(Advanced STRIDE)。下图列举了ASTRIDE的7类威胁与信息安全三要素、三属性的对应关系。
接下来可以结合数据流图的根本元素，使用ASTRIDE威胁分析方法来对根本元素进行威胁分析，可以得出下图的对应关系。
上表直观地表现了数据流图根本元素碰面临哪些种别的威胁。外部实体可以被伪造，如发起中间人攻击、认证信息伪造等；处置惩罚过程碰面临上述所有的威胁，如业务系统的Web服务面临爬虫攻击、DDOS攻击等；数据存储往往面临数据被篡改、敏感数据泄露等威胁，如数据库被脱库，敏感数据未加密等。对所有元素进行威胁分析后，就会获得该系统的威胁清单，后面就可以依据威胁清单来制定消减步伐。
3.2.3.2.3 制定消减步伐
3.2.3.2.3.1 消减步伐表
可以根据不同的数据流图元素和威胁界说消减步伐，固然不同的威胁对应的消减步伐一般也不一样。例如，在绘制数据流图小节中的业务数据图中，用户登录Web应用程序这一行为会存在仿冒威胁，消减步伐可以是强的身份认证、防止登陆口令暴力破解等，详细方案就是账号、密码、证书认证，增加验证码机制，密码实验次数限制，账号黑名单机制等。下表列出了ASTRIDE威胁对应的消减步伐。
通常在提出消减步伐时，要综合思量业务的实际情况，不能因制定的消减步伐导致业务性能、易用性等大打折扣，有时安全和业务之间要做一个均衡，一般有4种应对步伐：
- 缓解。采取一定的步伐增加攻击时间和攻击成本。
- 解决。彻底消除风险，例如，可以是代码和组件方式实现，或安全认证方案等。
- 转移。将威胁转移至第三方或其他系统，例如，购买第三方安全服务，签署用户协议和免责声明等。
- 担当。担当风险是基于成本和安全的一个综合考量，例如，有的风险受到战役、自然灾难等不可抗力因素限制，出于成本思量，选择担当此类风险。
实际上也并不是所有的威胁都必须及时修复，例如，有些威胁大概风险不大，但如果消减步伐会导致整个架构调解就可以思量临时不修复。
3.2.3.2.3.2 DREAD 威胁评级模型
因此需要对威胁进行评级，界说严重程度和优先级，可以使用DREAD威胁评级模型。
DREAD威胁评级模型分别对应5个指标：破坏程度(Damage)、可复现性(Reproducibility)、可利用性(Exploitability)、受影响的用户(Affected users)、可发现性(Discoverability)，下表详细列出了这5个指标的等级划分。
从表中可以看到，这5个指标中每个指标的评级分为高、中、低三等，终极威胁的危险评级由这5个指标的加权均匀算出。
DREAD威胁评级模型官网地址：
Advanced Threat Modelling Knowledge Session (owasp.org)
3.2.3.2.4 验证消减步伐
在完成威胁建模后，需要回顾整个过程，验证威胁是否已经完成闭环，数据流图表是否符合设计，代码实现是否符合预期设计，是否列举所有威胁，以及威胁是否都采取消减步伐。验证过程不是一次性工作，过程中需要和业务经常保持沟通，反复实行整个威胁建模的运动识别安全风险，同时确保每个风险都在及时跟进处置惩罚。最后整理所有的威胁建模材料并归档，作为后面业务威胁建模的参考材料。
3.3 静态安全检测类
3.3.1 静态检测原理
3.3.1.1 静态检测原理图
静态应用安全测试(Static Application Security Testing，SAST)是一种在编码阶段对源代码进行安全扫描发现安全漏洞的测试技能，又称为白盒测试。SAST是在软件安全开发生命周期(S-SDLC)较早阶段引入的安全检测工具，合理使用可以在最早阶段发现安全风险，SAST技能的根本原理如下图所示：
3.3.1.2 静态检测技能发展阶段
上图形貌了SAST的根本原理，同时也是SAST类产品技能发展的几个阶段：基于正则匹配代码分析、基于AST（Abstract Syntax Tree，抽象语法树）代码分析、基于IR（Intermediate Representation，中间代码）和CFG（Control Flow Graph，控制流图）代码分析、基于CodeQL代码分析。
3.3.1.2.1 基于正则匹配代码分析
根据一些漏洞的特征，通过关键字匹配去发现漏洞，但由于无法猜测开发职员的编程习惯，匹配规则难以适配多数场景，导致误报率、漏报率非常高。现在纯基于正则匹配的SAST已经不存在了，只是作为一种辅助分析技能。
3.3.1.2.2 基于AST代码分析
通过词法分析和语法分析，将高级代码语言转化为AST语法树，如许就不需要直接去分析高级语言，转而分析AST语法树，解决了正则匹配关键字的最大题目。基于语法树预置大概造成漏洞的函数，通过算法分析这些漏洞函数的入参是否可控来判断是否存在漏洞，这种算法称为污点分析技能。基于AST代码分析最大难点是无法完备处置惩罚AST语法树，因此这类SAST都碰面临同样的题目。
3.3.1.2.3 基于IR和CFG代码分析
使用编译器大概解释器将高级语言转换成IR中间代码，IR保存了源代码之间的调用关系、上下文分析等，根据IR可以绘制出CFG，它代表了整个代码的控制流程图，后续漏洞挖掘仍是采用污点分析技能对CFG进行分析，并通过符号实行忽略程序中不可达的代码路径。目前主流的SAST产品大多采用这类技能。
3.3.1.2.4 基于CodeQL代码分析
通过统一多种语言的AST剖析器，在实行完并解释后将代码的AST剖析结果按照预设好的数据模型存储到CodeDB中，使用QL语言界说污点追踪漏洞模型实行QL查询，进而通过高效的搜索算法对CodeDB的AST元数据进行查询，在代码中搜索出漏洞结果。CodeQL技能大概是未来SAST的方向。
开发职员在编码过程中，采用IDE安全插件的方式进行当地源代码安全扫描，可以快速发现安全漏洞并修复。IDE插件扫描的原理就是污点跟踪技能，下图展示了集成IDE插件后发现安全漏洞的示例。
从上图中可以看到，编写存在漏洞的代码时，IDE就会产生告警，在可以检察告警内容的同时，插件也提供了修复方案，单击就可以完成漏洞修复，速率非常快。
IDE集成安全插件固然很重要，但强迫开发职员使用特定的插件非常困难（实际上几乎是不大概的），更不用说强迫他们使用特定的IDE。因此在IDE中使用安全插件并不是唯一的方案，在DevSecOps平台中还可以将SAST作为CI/CD流水线的一部分。如许，可以确保纵然开发职员未在IDE中使用安全插件，在构建运行过程中，仍旧会进行安全扫描。
3.3.2 SAST产品列举与横向对比
下表列举了Fortify、Chechmarx、奇安信代码卫士、SonarQube（开源版）、腾讯云代码分析（开源版）等5款典范SAST产品的横向对比分析，在不思量检测规则优化的情况下，结果如下。
3.3.3 总结
SAST通太过析应用程序的源代码来发现安全漏洞，它的优点是支持多种语言和架构，对漏洞类型的覆盖率较高。但从上表中可以看出，SAST的使用还是有一定门槛的，尤其是在静态检测规则的优化方面，默认规则无法完全匹配业务代码解决误报率和漏报率题目。
一般商业级的SAST工具默认情况下误报率广泛在30%以上，这将导致在DevSecOps落地时需要花费更多精力在规则优化和消除误报上。
另外，传统的SAST扫描耗时较长，尤其是对于大型的代码仓库，往往需花费数小时乃至数天才能完成，这不符合DevOps的研发效能理念，需要结合DevSecOps平台架构和安全流程去思量并发设计和异步设计。
3.4 动态安全检测类
3.4.1 DAST根本原理
3.4.1.1 动态检测原理图
动态应用安全测试(Dynamic Application Security Testing，DAST)是一种在应用运行时模仿恶意攻击者发起主动攻击，并根据应用的详细反应确定该应用是否存在漏洞的技能，又称为黑盒测试。DAST技能的根本原理如图所示：
在上图中，DAST首先通过爬虫探测整个被测系统的结构，遍历Web的目次层级，页面信息、参数等，用户设置完目标URL后，开始模仿Web用户单机链接操纵爬取应用程序；接着对爬取的信息进行分析，并发起攻击实验，即数据重放，如在哀求的表单中添加攻击特征数据；最后DAST会分析这些来自业务系统的返回，根据返回结果判定是否存在漏洞。
可以看出使用DAST这种测试方法，操纵职员不需要了解应用的内部逻辑、业务的实现方式，乃至无需具备编程本事，其完全站在攻击者的视角，采用攻击特征库验证并发现漏洞，误报率低。同时DAST的这种高度主动化的测试方法也非常容易集成至CI/CD流水线。
3.4.2 DAST的缺点
DAST的优点许多，但缺点同样明显，主要缺点集中在以下几个方面：
3.4.2.1 覆盖范围有限
严重依靠爬虫获取到的信息，如果爬虫遍历不全或不准确，会影响终极的扫描结果，导致漏报。例如，AJAX页面、动态JS拼接的链接、输入手机号或短信认证页面等，这些传统的爬虫都无法或难以应对。
3.4.2.2 限定HTTP/S测试对象
DAST的测试对象为HTTP/S的Web应用，对于其他应用无法进行安全测试，例如，iOS/Android上的客户端应用无法进行安全测试。
3.4.2.3 无法定位漏洞代码
DAST发现漏洞后会定位漏洞的URL，无法定位产生漏洞的代码位置及产生漏洞的原因，因此需要业务去进一步分析，通常需要花费较长的时间来进行漏洞定位和修复。
3.4.2.4 产生脏数据
DAST必须发送攻击特征数据来进行探测，会产生大量的安全测试脏数据，污染业务测试的数据，因此会对功能测试造成一定的影响，在安全测试过程中需要和功能测试职员保持沟通和协调。
3.4.2.5 特定场景不支持
不支持的场景主要表现在业务逻辑漏洞、某些无回显漏洞，接口经过加密和认证，大量验证码等场景。
3.4.3 总结
针对上述缺点，一些安全厂商经过不停地验证迭代，目前有的DAST工具可以制止以上若干缺点。即便如此，优秀的DAST产品检出率也只有30%，但DAST误报率极低，使用简朴，因此仍旧是业界安全测试非常广泛的一种方案。
3.5 交互式安全检测类
3.5.1 IAST根本原理
3.5.1.1 主动式IAST
交互式应用安全测试(Interactive Application Security Testing，IAST)是近来几年比较流行的应用安全测试技能，曾多次被Gartner列为安全领域的Top 10技能之一，又称为灰盒测试。IAST理念是让开发职员和测试职员在实行功能测试的同时，无感知地完成安全测试，极大提高安全测试效率。
IAST实现的方式主要有主动式和被动式两种模式。
3.5.1.1.1 主动式IAST根本原理
下图为主动式IAST的原理：
从上图中可以看到，功能测试职员在欣赏器大概移动端设置署理，接着发起功能测试，测试流量经过署理，署理将流量复制一份，添加攻击特征数据，IAST扫描器利用改造后的流量对被测业务系统发起安全测试，根据返回的数据包判断是否存在漏洞，后续的操纵和DAST的原理一样，这里不再赘述。这种署理模式的IAST不依靠爬虫，解决了DAST覆盖范围有限的题目，别的测试对象无论是基于HTTP/HTTPS的应用，还是基于iOS/Android上的客户端应用，主动式IAST都支持检测。
3.5.1.1.2 被动式IAST根本原理
下面重点先容被动式IAST，它是一种基于插桩(Instrumented)模式的IAST，插桩模式的核心是在被测业务系统中部署Agent，使用动态Hook和污点跟踪算法挖掘漏洞。
可以看到被动式IAST检测漏洞的底层逻辑和SAST一样，都是基于控制流和污点跟踪技能判断漏洞，最大的区别是被动式IAST省去了构建AST/IR这一过程，由于通过插桩，在应用运行时已经可以绘制出控制流图。下图展示了这一过程。
从上图中可以看到，功能测试职员发起的哀求到达被测业务系统的时候，IAST Agent可以追踪哀求中的参数流动情况。例如，某个哀求体此中一个过程是实行SQL查询语句，哀求体如下：
IAST首选会将外部输入的参数zhangsan标为污染数据，接下来会一直跟踪这个污染数据，如果污染数据在转达过程中被处置惩罚了，如加密、哈希等操纵，那么该标志就被清除（图中灰色圆形块），如果一直到实行SQL查询语句的时候该参数都未经过处置惩罚（图中蓝色圆形块），那么IAST就认为实行SQL语句的时候，来自外部输入的参数不可控，会产生SQL注入漏洞。以是污点分析简朴明白就是追踪毗连绿色块的过程（图中蓝色块的毗连线）。
目前主流的IAST技能根本都采用插桩技能来实现污点跟踪，进而发现漏洞，而DAST需要进行数据重放，根据返回信息确认是否存在漏洞。因此DAST的缺点在IAST中根本都不存在。
3.5.1.1.2.1 IAST探针作用
应用启动前Agent在应用的特定位置插入探针，探针不会影响应用的原有逻辑，探针最主要作用如下：
- 获取流量。探针可以获取所有被测业务系统的哀求和响应，等于是替代了DAST的爬虫功能，只要被测业务系统功能测试全面，就可以获取到完备的流量。
- 代码分析，探针会对应用中每一行代码进行静态分析，即SAST技能，因此可以定位产生漏洞的代码位置。
- 控制流跟踪。探针可以在应用运行时，通过Hook的方式记录当前应用的上下文信息，及时分析数据流动过程并回溯调用栈，可以得到特定哀求的控制流信息。
- 污点跟踪。基于控制流信息，采用污点跟踪算法，追踪不信托输入数据的流动过程，判定是否存在漏洞。
3.5.2 SAST、DAST和IAST优劣势对比
下表横向对比了SAST、DAST和IAST的优劣势。
从表中可以看出，IAST的优势较明显，它结合了DAST和SAST的优势，但最大的缺点是部署探针的成本和对业务性能的影响，尤其是在复杂场景下大概会引起业务部分的反感。因此IAST只有集成进DevOps或DevSecOps平台，在流水线中完成主动部署，最大限度发挥其安全测试效率才会有意义，最合适的场景是应用上线前的测试阶段。DAST是完全站在攻击者的视角进行资产探测，发现资产暴露面及应用的漏洞，从而保障线上运营环境的安全，最合适的场景是应用运营阶段。而SAST针对的是源码漏洞检测，能够在最早期发现安全题目，最合适的场景是应用的编码和构建阶段。
3.6 运行时应用自我保护类
3.6.1 运行时保护界说
运行时应用自我保护(Runtime Application Self-Protection，RASP)是Gartner在2012年初次提出并将其界说：运行时应用自我保护是一种植入到应用程序内部或其运行时环境的安全技能。它能够控制应用程序的实行流程，而且可以及时检测和阻止攻击行为。
3.6.2 运行时保护根本原理
3.6.2.1 原理形貌
通过界说我们发现，RASP其实也是一种插桩和Hook技能，这和上文提到的IAST Agent采用的是同样的技能手段，实际上IAST Agent就是基于RASP的理念去实现的，区别是IAST Agent负责挖掘漏洞，RASP负责拦截攻击行为。
3.6.2.2 原理图
下图展示了Java语言插桩技能的根本原理。
以Java语言为例，JVM提供Instrument机制，运行了Instrumentation署理的Java程序，字节码的加载会经过我们自界说的Agent Transformer，在这里可以过滤出我们关注的类和方法，并对其字节码进行相干的修改，实现Hook埋点，最后重新加载Hook后的字节码文件完成整个插桩过程。Java应用的插桩主要分静态和动态两类，而每一类又可以使用不同的技能实现。
3.6.2.3 Java插桩技能分类及优缺点
从表的对比可以看出，无论是基于JDK动态署理机制，还是基于Cglib+ASM实现的动态字节码生成机制，大概基于Javassist实现的自界说类加载器修改运行期字节码，都没有基于ByteBuddy的字节码转换技能的效果好。
3.6.2.3.1 基于ByteBuddy字节码转换的原理
从上图可以看到，在对感爱好的方法进行字节码转换后，就可以在before ( )和after ( )方法之间进行Hook埋点，处置惩罚插桩相干的业务逻辑。要想进入到Hook点，必须处置惩罚Hook相干的逻辑，如许就可以根据上下文和参数来实现对攻击行为的检测和拦截。
例如，SSRF漏洞（服务端哀求伪造漏洞）RASP的检测逻辑为遍历每个request哀求的用户输入参数，与Hook到的URL比较，如果相同，则用户输入的URL到达了底层网络哀求的API，此时再检测URL对应的IP是否是内网地址，如果是，则判定为SSRF攻击，触发拦截机制。
3.6.3 RASP的缺点
RASP的缺点也很明显，一是插桩和Hook机制对应用的耦合较深，会对服务器性能有影响，实际推广难度大；二是方案不通用，需要为不同的语言适配不同的RASP，目前只在Java、PHP和.Net语言中具备成熟的产品；三是部署难度，需要研发配合，在每台服务器的应用上都需要实行RASP插桩命令，增加部署成本。
3.6.4 总结
综上所述，RASP在定位上是应用层自顺应的安全解决方案，目标是在不改变应用架构或应用代码的前提下，达到快速检测并阻止攻击的目的。只需要在重点关注的节点进行插桩和Hook，就可以检测到OGNL表达式、会话、哀求、SQL语句等信息，如果Hook节点充足充实，可以有效地防御XSS、SSRF、RCE和SQL注入等Web攻击。
好了，本次内容就分享到这，欢迎各人关注《DevSecOps》专栏，后续会继承输出相干内容文章。如果有帮助到各人，欢迎各人点赞+关注+收藏，有疑问也欢迎各人评论留言！
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
