云原生下的应用安全风险，不论是传统应用，还是拆分模块化后的应用，人为因素都是影响应用安全的重要一环，特别是当传统应用拆分为微服务后，可能导致各个模块被交给不同的开发组进行开发的情况，每个模块功能开发者的安全编码规范，安全意识并不统一。从安全团队的角度来讲，需要统一规范各个模块的安全编程质量。

云原生下企业应用安全现状

1. 安全人员配比：相对于开发人员，安全人员数量配比比较低，随着云原生应用的推进，安全人员的压力越发明显
2. 应用开发质量：企业内部和外包人员缺乏一定的安全开发意识，外包人员流动大，安全能力培养无法固定，安全开发水平参差不齐
3. 应用合规化：《网络安全法》《个人信息保护法》《关键信息基础设施安全保护条例》《数据安全法》等一系列相关法律法规的出台，对应用安全提出了更高的要求
4. 有效的安全工具：传统安全工具需要进化，契合云原生下微服务分布式的监测能力

安全风险普遍存在

97%被测目标存在某种形式的漏洞

• 28%的测试目标曾受过跨站脚本(XSS)攻击
• 76%的被测目标存在OWASP（开放式Web应用程序安全项目) 在2021年所披露的前十大漏洞
  • 应用程序和服务器配置错误占比21%[安全配置错误类别]
  • 19%的漏洞与[访问控制失效]类别有关
  • 18%的系统在使用易受攻击的第三方库，这一漏洞属于[易受攻击和过时的组件类别]（有时甚至没有清单来记录这些内容，现在很多企业都在同时使用数百个应用程序或软件系统，并拥有数百甚至数千个不同的第三方组件或开源组件，对企业来说，一份准确且实时更新的软件物料清单来有效追踪外部组件是非常有必要的）

数据泄露事件分析

• 78%的数据泄露事件是由网络攻击造成的，攻击者利用漏洞非法入侵，查看或下载系统数据
• 14%的事件是由系统不正确配置造成的，在数据传输或处理场景中，由于未对权限进行控制，未加密或未脱敏，导致用户隐私，组织的核心数据被窃取
• 8%的事件是由人为错误导致的，如内部人员利用职务便利非法越权查看，下载数据等。此类内部向外部泄露数据的安全事件极难防范，更多是管理，非技术发力杜绝可为。

移动应用程序安全风险

不安全的数据存储和通信漏洞

• 在移动设备安全测试中，有80%的漏洞与不安全的数据存储有关，攻击者既可以物理访问移动设备，也可以使用恶意软件进入设备
• 还有53%的漏洞与不安全的通信方式有关

漏洞复盘

复盘历史漏洞，按成因粗略可归为两类：

1. 代码漏洞，因不安全的API使用和逻辑编写产生的安全风险
2. 运维漏洞，指运行环境，配置和依赖等系统运维的安全风险，如软件供应链攻击，如公司内员工使用包管理软件拉取时，未配置公司镜像源，可能会拉取到攻击者抢注的恶意包

数据校验是几乎每份安全规范类文档会囊括的要点，可通过数据校验规避的漏洞约占历史web漏洞安全工单数量的70%~80%，但要落实好，最有效的解决办法还是自动生成代码来做此类事情。

DevSecOps

解释

从开发周期起始就引入安全流程，贯穿整个开发周期，对代码进行评审，审计，扫描和测试。尽早确定和实施防御技术，就可以降低安全问题的成本。

安全测试在整个发布和部署过程中持续进行，企业利用自动化工具（如SAST，DAST，IAST，SCA）及手工测试活动（如代码审查和渗透测试），综合达成安全加固的目标

将安全原则集成到开发和操作过程中的实践，创造简化安全性的新机会，换一种简单的概念，叫做安全左移。

措施策略

• 尽可能使用日志记录和监视工具，并建立实施事件响应流程，以便快速响应安全警报
• 部署自动化测试（如DAST），纵深防御解决方案（如RASP）及传统的的WAF技术以保护生产中的应用程序

立体问题，立体解决

从立体化上看，包括三个机制：

• 面向开发人员的代码安全指南+静态代码安全检查

  常见误区：重检查，轻提供解决方案。如果只聚焦于发现问题，但开发人员在解决问题时，如没有可操作的解决方案，修复工作往往难以推动

• 默认安全框架组件

• 嵌入基础设施的代码安全检查。

来自谷歌的实践建议

Google在内部安全左移的实践中，提出

1. 越早越好，软件设计初期就应考量安全，稳定性问题，否则越往后代价越高，过程会很痛苦
2. 安全意识教育很重要，但也不是银弹，安全工程师甚至都会犯错。在业务开发阶段，关注点往往是功能实现，要兼顾安全和稳定性设计方面的权衡，会很难。因此，应关注安全机制和工具的建设
3. 安全能力嵌入框架大有裨益，复用最佳实践，提供规范性与一致性，减少由业务各自实现产生的风险（不同业务重复在写安全校验逻辑，浪费人力还易出错），还能提升研效，降低修复成本和时间，框架虽不能保证预防解决所有问题，但出现问题时，只需要在一个点解决

Security By Design：写出漏洞不一定是开发者的问题，而可能是API设计得容易出错。如SQL注入为例，组件和框架都提供了参数绑定的功能，安全规范也有不断强调，但开发人员仍非常容易写出带SQL注入的代码。可以从API设计机制上禁用查询拼接，仅允许通过占位符替换进入查询语句。

数据校验各类安全规范都会囊括，但在实际过程中，落地并不理想。通过复盘数据统计，可通过数据校验规避的漏洞占历史web安全漏洞工单数量的70~80%。

组合采用校验和带默认安全机制的功能组件（融入Security By Design）两个方案是最优解。如你用IDL进行接口定义，可以定制规则请求消息体中的String类型字段必须限定格式/字符范围+长度，使得在保存IDL文件时，立即获得提示并修正存在的安全隐患。

数据校验本身是一项业务需求，降低开发门槛，让框架层提供组件让每个业务模块都能做到数据校验，是应该去实践的方向。

安全指南的难点

语言差异

每种语言面临的安全风险不同，如go和js相比，go就不存在原型链污染的风险。

同一门编程语言，用在不同的终端应用开发，面临的风险类型和数量有着天壤之别。

• 如JS应用于前端页面开发时，主要风险是DOM XSS
• 依托于Node.js进行后端接口开发，编码不当则存在命令注入，SQL注入风险。

场景关联

风险通常与业务场景高度相关，如

• SQL注入，一般发生在SQL查询场景，因为允许拼接SQL查询语句，且未做参数绑定和参数值校验，造成风险敞口
• SSRF漏洞，则发生在资源请求场景，未判断网络资源请求目标是否属于内网
• 命令注入，发生在命令执行场景，风险成因和SQL注入类似

代码安全指南，与场景关联，有利于受众人员降低认知学习成本，更容易想起注意事项，且要配套结合在线学习课程和考试，如此更能弱化开发人员不了解如何安全地开发的问题。

枚举的挑战

在代码安全指引中，要枚举API/Sink点。通常安全漏洞可归因为API的错误使用，sink点是编写安全策略组件重要的一部分，直接决定了SAST系统的扫描能力。

以google前端加固组件为例，通过对.innerHTML等容易被误用产生安全问题的API做了加固，封装为前端组件中心的函数对象，并设计了对应的编译时检查工具，使得DOM XSS由原来的20%降低到2%

这个例子中，最重要的是XSS Sink点的提取，也就是易误用产生安全漏洞的API，故Sink的提取是开展API加固极为重要的一步

确保所枚举的API的完善性是一个非常大的挑战，补充完善Sink点的工作长尾且任务量大，需随着内外部发现的漏洞，编程语言和框架的迭代而不断迭代。通过与社区携手一道维护是一条路。

静态安全扫描

代码安全指南只是安全左移建设的第一步，还需解决的挑战有：

• 开发人员有一定安全意识，但因为赶进度或疏忽遗漏安全措施落实，或是错误地实现安全校验逻辑
• 代码编写是否安全全凭开发人员自觉，缺乏提示、检查和卡点机制
  • 解决方式是：静态代码安全检查解决
  • 常规的源码表示方式以AST（抽象语法树）和IR（中间表达）为主。一般而言，IR是从AST经过层层转换而来，所以会比AST拥有更多信息。但相对的，每种语言一般会有自己不同的IR，处理起来会相对比较困难。而AST的形式则简单直观，操作起来也比较容易。
    • 第一种是在AST上做检查，既然源码被表示成了树的形式，我们就可以遍历AST，使用一些pattern去检查代码规范中的问题，如方法调用参数变量的检查。
    • 第二种就是污点分析，污点分析是更为常用的检查安全漏洞的方法，通过标记外部输入点，基于数据流观察能否达到危险函数（如SQL查询，命令执行函数）来检查安全漏洞。

源码、AST、IR

AST与污点分析的优缺对照

1
2
3
4
5
6

std::string cmdLine = "ls";
cmdLine += user_input; //source(输入)
if (cmdLine.find_first_not_of("1234567890.+-*/e ") == std::string::npos) //sanitizer(过滤点)
  system(cmdLine.c_str());//sink
else
  warning("xxxxx")

在写代码段不同阶段，开发人员对检查工具和结果的预期要求各不相同

1. 本地编写阶段

   要求速度快，此时往往代码还没写完，AST模式匹配就是个很好的检查方式，可考虑用semgrep等工具，封装为IDE插件。实践过程中，可尝试引入一些更激进的策略，如要求更改不安全的SQL查询拼接逻辑

2. 构建部署阶段：封装为流水线原子，并配套提供安全卡点机制，给出问题描述和解决指引

3. 日常检查阶段，代码仓库检查

   该阶段一般为旁路检查，可进行一系列复杂的分析。速度就不是第一考虑因素了。

白盒扫描战斗机CodeQL

行业产品对比^{<span class=“hint–top hint–error hint–medium hint–rounded hint–bounce” aria-label="58集团，白盒代码审计系统技术选型}

">[3]

在这个领域，是有成熟的商业善品和开源项目的，Coverity、Fortify、CheckMarx作为领头产品，有深厚的技术积累和专业的产品技术团队。优点就不用说了，缺点是定制化需求支持困难，引擎对用户不透明，需求提交给厂商响应时长为Month++；规则学习成本高，自定义规则困难；厂商以最大并发量授权license，弹性扩容能力差，存在成本浪费；融入企业自身的CI/CD流程困难，难以准确处理误报，漏洞修复复查等业务需求。

如Converity扫描脚本MacOS的版本适配一般都会delay2~3个月，这就会导致MacOS一更新，对C/C的安全扫描业务就会中断（C/C安全扫描依赖本地编译环境）。另外代码质量问题和安全漏洞并未明显区分，每个项目数千计的代码质量问题和安全漏洞难以修复落地。

开源产品SonarQube、FindBugs、Checkstyle等更偏向质量检查而非安全性检查，虽利于适配CI软件，但没有跨文件AST能力，无法分析跨文件数据流和控制流。

CodeQL

通过适配各个语言的AST解释器，并将代码的AST解析结果按预设好的数据模型将AST数据及其依赖关系存储到CodeDB里，通过QL语言定义污点追踪漏洞模型，执行QL时通过高效搜索算法对CodeGB的AST元数据进行高效查询，在代码中检索出漏洞结果^[4]。

• 支持除PHP外的常见语言类型
• 规则开源，无需依赖厂商支持；但AST分析引擎不开源，无法免费集成。
• 不支持软件成分分析，无法结合软件版本进行漏洞判断
• 它做得最棒的是通过不同语言的适配，把一些常用查询封装成QL语言，对AST数据进行一种类SQL的查询。结合AST元数据对DataFlow和ControlFlow进行更细致的判断，减少误报，漏报。
  • 悬赏开源社区完善规则
  • 通过GitHub庞大的开源代码及迭代数据，实现打标给神经网络学习提供学习样本

现代应用安全工具

静态应用安全测试（SAST）

• 也称为静态分析，是第一批发现源代码和字节码或二进制文件本身缺陷的AppSec工具之一。

• 能促成在软件研发生命周期的最初阶段收敛漏洞。

动态应用程序安全测试（DAST）

于运行状态下对应用程序进行爬行和分析。与SAST一样，它只能识别扫描引擎已知的漏洞和配置问题，传统的DAST扫描通常测试公开的HTML接口，更先进的DAST扫描器也可以测试REST API

SAST（白盒）vs DAST（黑盒）

一图胜十言，SAST和DAST联合起来才能彼此完整

软件组合分析（SCA）

由于开源组件带来的风险增加，SCA工具在过去几年变得越发流行。该工具能识别源代码，容器和注册表中的开源漏洞，大多数SCA工具还能检查开源许可合规性和归属要求。

交互式应用安全测试（IAST–灰盒）

关键技术：插桩检测模式+流量检测模式+实时web日志

传统黑盒扫描器依赖于页面响应检测漏洞，需要发送大量的请求，还有误报的可能。对于SSRF，文件上传等漏洞，在页面没有回显，主机无外网权限的情况下，还可能漏报。

机制解释

交互性

只会分析“交互”产生时所影响到相关代码的安全风险，而不是扫描所有代码、配置文件或遍历整个站点。

插桩检测

是在保证目标程序原有逻辑完整的情况下，在特定位置插入探针，在应用程序运行时，通过探针获取请求，代码数据流，代码控制流等。基于请求，代码，数据流，控制流等综合分析判断漏洞.

你可以说它部署在应用程序运行的代理或传感器上

由于该技术针对不同语言需要研发不同的插桩探针，因此对于厂商而来，其IAST工具每增加对一种语言的支持，即相当于开发一款新产品，也就意味着IAST工具支持的编程语言越多，厂商所需投入的人力成本和经济成本也就越大。

如果语言本身提供了插桩的接口，那么探针开发的难度将会大大降低。例如Java提供了一个instrumentation 接口。通过该接口，可以以一种标准的方式，在启动应用时添加javaagent参数来加载插桩探针，从而实现动态数据流污点追踪。

SAST&DAST混合

• 第一点是如何“理解”代码。根据不同语言来区分，需要关注哪些函数，这些函数里哪些是污点输入？哪些是污点传播、清洗、汇聚？根据不同的漏洞原理来做分析。
• 第二点，从各种语言底层做突破，捕获关键函数的调用情况？读取到关键函数何时被调用、传入了什么参数、数据传递给了谁。

工作模式

现在较先进的IAST是支持两种模式，主动相当于可以发起测试，被动相当于只判定漏洞

• 主动模式：接收到相应流量，在对流量进行初步筛查后，将流量发送到扫描控制端，扫描控制端会结合payload进行数据流重放，重放验证过程中根据请求和响应，及函数代码执行流，判断其中是否存在安全漏洞，主动模式支持漏洞复现。

• 被动模式：引入动态污点技术，当一个请求流量输入后，给变量打上污点标记，在整个函数内部流转时，当变量携带着污点标记在整个函数内部流转时，就可以观察它经历了哪些函数，整个过程就是一个污点传播过程。

  • 在被动模式下，仅会对触发的流量进行扫描分析，为保证测试效果，触发的流量越全面，扫描越安全。
  • 不需要数据重放，也就意味着不存在脏数据；对于签名和加密接口都有很好的处理效率。

漏洞发现后处理

经判断存在风险需处理的漏洞，进行漏洞修复并更新至测试环境后，需再次触发漏洞所在的url，此时IAST插桩会自动进行回归测试，如系统判断该漏洞已修复，则会自动关闭该漏洞。

一句话总结

IAST通过运行时插桩或流量分析的方法，借助于功能测试或自动化测试的交互式行为，实现透明、高效分析应用漏洞，防止应用带病上线。

污点分析实现三关键

实现污点分析，有三个核心关键点

1. source点：表示外部输入，如web输入，文件输入等
2. sink点：表示危险的函数调用或者变量赋值，如system等函数
3. sanitizer：表示过滤点，经过过滤点的数据将被取消标记

污点分析从user_input一路进行数据流追踪

污点追踪漏洞发现举例

以XXE实体注入漏洞为例

1. 通过RequestResponseBodyMethodProcessor.resolveArgument这个方法参数，引入了请求中postData的XML实体，将该实体标记为污点数据
2. 而后XML实体污点数据进入传播阶段，在传播阶段，探针会hook代码中String类型的方法（如String,StringReader,StringBuilder,subString等），这些String类型的方法称为传播函数，会对污点源进行String处理
3. 从污点数据可见，XML实体经过处理后，被封装到了一个对象内部（java.io.StringReader@20cca27a），此时java.io.StringReader@20cca27a也会被探针标记为污点数据，加入到污点集中继续进行污点追踪
4. 经过污点输入，传播两个阶段，污点数据会进入到污点汇聚过程。对于不同的漏洞而言，探针hook的汇聚函数有所不同，如针对SQL注入会hook语句执行的方法，针对XXE漏洞会hook解析XML实体的方法
5. 汇聚阶段被AbstractSAXParser.parse方法执行了解析操作，因为XXE漏洞最后阶段就是解析XML实体，所以污点追踪过程到此就结束了，探针此时会释放所有污点数据，不再继续追踪下去
6. 纵观整个污点数据流转过程，这个漏洞被上报的原因是：输入源XML实体在污点输入阶段，没有对请求包中的XML实体内容进行校验就进行了引入，在传播阶段，只进行了一次对象转换操作，没有对引入的XML实体做相应的无害化处理，直到对象在污点汇聚阶段被解析方法进行解析。整一个过程，探针没有识别到污点数据在三个阶段有任何的清洁函数，故此漏洞最终被上报。

OpenRASP-IAST

目前支持的漏洞检测

触发条件均为用户输入的参数直接拼接产生的漏洞，尚不支持非HTTP参数，参数编解码方式触发的漏洞

• 命令注入

• 目录遍历

• PHP eval代码执行

• 文件上传

• 文件包含

• 任务文件读取

• 任意文件写入

• SQL注入

• SSRF

  服务器请求伪造，对于远程url没有进行严格过滤的情况下，攻击者可通过该漏洞控制web网站作为代理服务器远程攻击服务器或该web的本地服务器。一般情况下，其攻击目标是外网无法访问的内部系统。其危害有，利用协议获取本地文件；可对内网、本地进行端口扫描，查看端口开闭状态；发现漏洞后攻击运行在内网或本地的应用程序；通过访问默认文件实现对内网web应用的指纹识别。其触发的场景，可能有转码服务，图片加载与下载，url获取内容收藏等。可通过限制请求端口，禁用不需要的协议，统一错误信息等来进行限制

• Java XXE

被动模式+fuzz测试

OpenRASP-IAST是被动扫描模式，不会使用爬虫技术去获取URL信息，当iast.js下发成功，Java/PHP内部的探针会自动在请求结束时，将本次请求的参数，hook点信息提交给openrasp-iast服务器进行分析，并选择性的fuzz目标

fuzz -模糊测试的代名词，所谓模糊测试，即为向应用提供非预期输入，从而检测程序逻辑漏洞。例如模拟用户面对输入框犯傻的时候总会出现一些“奇葩”的非预期初入，此外，模仿攻击者向应用、加密内容、操作系统指令或原始代码注入命令行函数，来检视程序会出现什么情况

将IAST部署至测试环境，并长期运行。在QA，RD做单元测试，功能测试时自动的进行漏洞检测。检测目标按照IP：PORT或者HOST进行分组，每个目标可以有不同的配置，若勾选 自动启动扫描 选项，则会在发现新目标时自动启动扫描任务。

运行时应用程序自我保护（RASP）

Runtime Application Self-Protection

集成到应用程序中分析用户流量和行为模式，以阻止和防止攻击。RASP部署在生产服务器上，工作模式更像传统的web应用程序防火墙（WAF），但RASP技术使用AI和机器学习来代替正则表达式匹配，将保护程序像“免疫血清”一样注入到应用程序中，与应用程序融为一体，能实时检测和阻断安全攻击，使应用程序具备自我保护能力。

RASP是一种基于服务器的技术，应用程序开始运行就会激活，每个RASP系统都有自己的一组安全规则列表，用于交叉检查事件和相关数据，确保只有允许的事情才能执行，每种RASP技术提供的保护级别取决于安全规则的深度及实现类型。

• 通过对请求调用的关键函数进行监听，拦截各种绕过流量检测的威胁攻击
• 几乎所有的攻击手段最终都可归纳成敏感命令执行，敏感文件读写，敏感数据库操作等异常行为
• 开源软件和第三方漏洞被利用时，执行到代码底层，通常聚焦到一些敏感函数上，如反序列化，数据库执行，命令执行，文件操作，响应返回等相关函数
• 支持动态下发热补丁修复风险，可在不中断业务同时为系统提供临时保护，争取宝贵时间，紧急上线的项目也可以利用此特性临时加固

除了执行代码检查，RASP还能做应用服务器启动时的安全配置规范检查，如进程启动账号检查，弱口令检查，重要cookie是否开启http-only配置等

通过RASP的改造应用，可提升应用内敏感数据流向的可见性。例如，记录应用对数据库的查询行为，明确应用和表，字段间的依赖关系；记录应用http response信息，发现应用将敏感信息返回给客户端的行为；还可为数据加解密提供支撑。

成熟RASP三构成

安全插件

实现RASP防御能力的执行模块，要求消耗低，能收集应用中间件/开发语言/语言版本/操作系统等信息，并通过与数据调度器的数据联动，实现资产信息传递，入侵防御，漏洞数据分析等功能

AI攻击检测引擎

判定攻击行为的决策中心：结合外部安全威胁情报中心，借助上下文情景分析能力，通过纵深流量学习算法，自主学习正常访问模型，防御未知的漏洞风险

不是说其它工具都是基于正则的，哪怕SAST也有不同层级的实现，解决不同难度的问题

概念解释：东西向流量

• 南北向流量：外部发起

• 东西向流量：内部产生

探针平等对这些进入应用程序的数据进行分析

管理平台

• 展示应用资产，安全检测，分析，防御结果
• 提供集中管控工具，统一下发配置和指令
• 可视化展示应用的状态，安全态势，为安全事件处理和能力优化提供数据决策支撑

工作流程简介

• 大部分安全检测逻辑都在插件中实现，当引擎检测到敏感行为时，会依次调用插件进行检测，支持对数据库，文件，网络行为等进行检测（插件以js语法写成）

• Java版在服务程序启动时，动态修改Java字节码，对敏感操作的函数进行挂钩，如数据库操作，文件读取写入操作，命令执行…当攻击发生，就会触发这些Hook点，此时RASP agent就可以获取到函数的参数，如要读取的文件名，要执行的命令等

• 基于启动时的插桩操作，当有类被ClassLoader加载时，该类的字节码先交给自定义的Transformer处理，判断是否为要Hook的类，如是则交给javassist字节码处理框架进行处理，类的字节码被按事件驱动模型逐步解析每个方法，当触发了需hook的方法，会在方法开头或结尾插入进行检测函数的字节码，然后把hook好的字节码返回给Transformer从而载入虚拟机

  字节码存储在.class文件中，每个.class文件包含一个java类或接口。

  javassist就是一个用来处理java字节码的类库，可在一个已编译好的类中添加新的方法，或修改已有方法，不要求你对字节码方面有深入的了解。它也可以去生成一个新的类对象，这点相较于反射方式不同，反射只能编辑一个对象，不能动态生成一个类

• 实际过程细节，比如上的介绍复杂一丢丢，进此传送门去搜索

• OpenRasp的agent端和IAST agent端在探针端有近似的任务，可IAST还要配一个扫描器，接收agent报上来的请求数据，识别要关注验证的活，开始自动做渗透测试任务

  • 换种说法，你可以说RASP agent再加一个扫描器（fuzz测试发起的服务端），即可实现一个完整的IAST扫描工具

SQL检测举例

数据库操作的例子

1. 收到请求，进入服务器请求的hook点，开启当前线程的检测开关，并把请求对象和响应对象进行缓存，以便后面使用

2. SQL查询被发起

3. 进入SQLStatementHook点，RASP挂钩了execute,executeUpdate,executeQuery等方法，从这些方法进入的检测流程如下

   1. 受限来自标记线程的调用，才会激活检测
   2. 采集connection_id（仅JDBC支持），SQL语句和数据库类型等信息
   3. 在插件的执行安全检测，决定是拦截请求还是放行仅打印日志

4. 进入SQLResultSetHook点，RASP挂钩了resultSet.next方法

   • 调用插件检查是否发生拖库行为，默认策略为一次查询结果超过500条就告警

5. 若决定拦截攻击

   1. 输出告警日志到logs/alarm.log
   2. 如果header还没发出，默认用302跳转到拦截页面
   3. 如body还没发出，则重置未发送的body
   4. 输出自定义拦截页面跳转js脚本

R(I)ASP补充信息

Java版本工作原理介绍

https://rasp.baidu.com/beta-doc/hacking/architect/java.html

php版本

OpenRasp核心原理为：在MINIT阶段，替换全局compiler_globals的funciton_table与class_table中特定的PHP_FUNCTION对应的函数指针（封装原有的handler，增加前置，后置处理），由此实现对敏感函数的挂钩。通过敏感函数参数结合请求信息判断是否存在攻击行为，进而采取拦截或者放行操作。

https://rasp.baidu.com/beta-doc/hacking/architect/php.html

OpenRASP项目已经实现相当于IAST agent端的OpenRASP agent，在此基础上引入一个扫描端，即可实现一个完整的IAST扫描工具

系统架构

灰盒扫描工具采用python3实现，数据库采用mysql，通讯采用http+json的方式

https://rasp.baidu.com/beta-doc/hacking/architect/iast.html

Hook函数列表

https://rasp.baidu.com/beta-doc/hacking/architect/hook.html

添加新的hook点

支持自定义hook函数，开放的体系

https://rasp.baidu.com/beta-doc/hacking/hook.html

参考