徐州建站软件,兰州新区城乡建设局网站,建设企业网站一般多少钱,wordpress 导出表单目录 一、概述
二、安全工具链在平台中的定位
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 威胁建模的概念…目录 一、概述
二、安全工具链在平台中的定位
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 TestingSAST)是一种在编码阶段对源代码进行安全扫描发现安全漏洞的测试技术又称为白盒测试。SAST是在软件安全开发生命周期(S-SDLC)较早阶段引入的安全检测工具合理使用可以在最早阶段发现安全风险SAST技术的基本原理如下图所示 3.3.1.2 静态检测技术发展阶段
上图描述了SAST的基本原理同时也是SAST类产品技术发展的几个阶段基于正则匹配代码分析、基于ASTAbstract Syntax Tree抽象语法树代码分析、基于IRIntermediate Representation中间代码和CFGControl 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 TestingDAST)是一种在应用运行时模拟恶意攻击者发起自动攻击并根据应用的具体反应确定该应用是否存在漏洞的技术又称为黑盒测试。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 TestingIAST)是最近几年比较流行的应用安全测试技术曾多次被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-ProtectionRASP)是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动态代理机制还是基于CglibASM实现的动态字节码生成机制或者基于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》专栏后续会继续输出相关内容文章。如果有帮助到大家欢迎大家点赞关注收藏有疑问也欢迎大家评论留言
