以下通过一个跨应用SQL注入问题，明确跨应用分析中需要解决的问题，及一些相关概念。

在该case中存在两个应用，WEB调用RPC服务。WEB获取name参数，调用RPC服务sayHello方法，RPC服务进行SQL拼接，最终在SQL执行处产生SQL注入问题。

为了适应devops的单应用并行CI、CD模式，及代码量等一系列问题，把相关应用代码仓库放到一起进行分析不是一个合适选择，所以我们通过单个工程的视角进行分析，通过摘要关联应用间污点信息。

1.应用间调用关系

1.1.收集跨应用callsite、callable

跨应用请求存在客户端调用与服务端两个端点，通过callsite记录客户端请求调用点，通过callable来记录服务端服务点。

根据不同的跨应用交互方式及不同的框架代码特征，在代码中提取callsite点及callable点，并在callsite点提取可关联外部callable关联信息，在callable提取服务信息。

以下为列举部分跨应用交互方式：

• RPC

• callsite：RPC函数调用点

• callsite关联信息：依赖具体框架，如示例关联合约接口，客户端token

• callable：RPC服务函数

• callable信息：依赖具体框架，如示例关联合约接口、服务端token

• HTTP

• callsite：HTTP客户端请求调用点

• callsite关联信息：路径、请求域名IP等信息

• callable：HTTP请求controller方法

• callable信息：请求路径、应用部署域名IP等

• MQ

• callsite：MQ客户端生产函数调用点

• callsite关联信息：MQ的IP、域名、topic等信息

• callable：MQ服务端消费函数

• callable信息：MQ的IP、域名、topic等信息

1.2.构建应用内调用关系图

根据单个应用内收集的callable、callsite及依赖关系建立应用内调用关系图，通过点上tag记录关联信息。

图.3.1.2-应用内调用关系图

• 点

• 应用

• callable：服务提供点

• callstie ：服务调用点，并在节点tag上记录callsite关联信息

• 边

• 应用 -> callable：表示callable归属于某个应用

• 应用 -> callsite：表示callsite归属于某个应用

• callable -> callsite：表示该callable在执行过程中依赖了哪些外部调用。（通过应用内CG链路提取）

1.3.建立应用间调用关系图

通过应用间调用关系图记录全量应用间调用关系。

图.3.1.3-应用间调用关系图

• 点

• 应用

• callable：服务提供点，并在节点上记录callable服务信息

• 边

• 应用 -> callable：表示callable归属于某个应用

• callable -> callable：表示callable2在执行过程中，调用callable3

1.4. 图生成过程

• 针对单个应用callable及服务信息、callsite及关联信息、callable->callsite依赖关系进行收集

• 创建应用内调用关系图，创建app、callable、callsite、callable->callsite依赖关系

• 创建应用间调用关系图，根据应用内callableX->callsite依赖关系边中callsite关联信息，搜索应用间服务信息对应callableY节点，在应用间链接callableX->callableY，关联应用间callable依赖。如示例中图.3.1.2-应用内调用关系图中callable2->callsite2边中callsite2关联信息可找到图.3.1.3-应用间调用关系图中callable3节点，即可以在应用间图中关联callable2 -> callable3表示调用依赖关系

2.跨应用污点分析

2.1. 摘要设计

为了描述callable内数据流特征，需要设计摘要描述污点数据流特征，供上游调用方加载生成污点分析规则。

在该RPC服务中，入参为User对象，sayHello方法获取name字段并作为返回值返回。该case中sayHello可为上游提供一个由形参1到返回值的propagator摘要，且形参1是一个对象，其name字段引起了propagator行为。

根据该case，摘要的设计还需支持除sink外其他类型的数据流类型，并且需要通过Access Path支持针对类、集合等复杂数据结构的域敏感传播。

目前我们实现了Java下RPC的摘要设计：

<type, signature, from-postion, from-access-path, to-position, to-access-path>

• type – 摘要数据流类型

• source：RPC函数调用引入了不可信数据

• propagator：污点流经RPC函数，并返回到调用点

• sink：污点流入RPC函数，并触发漏洞执行

• sanitizer：因RPC函数实现存在于其他仓库，在分析当前应用时，其他应用内数据流自然断开，所以策略中一般不需要生成RPC的sanitizer策略。

• signature – RPC函数全限定名及参数列表

• from postion – 污点传入位置

• Pn ：RPC函数的形参位置，表示第n个参数传入污点数据。

• O   ：RPC函数的base对象，一般情况下，base类只是用来封装RPC函数，并不会绑定污点对象。

• from access path – 污点传入位置access path支持域敏感，access path需要支持以下数据结构

• Object filed

• 数组

• 集合类

• to position – 污点传出位置

• Pn ：函数的形参位置，RPC数据传递只传值，即不会因为入参对象的filed改变导致调用方field改变。

• O ：RPC函数的base对象，一般情况下，base类只是用来封装RPC函数，并不会绑定污点对象。

• R ：RPC函数返回值，唯一会引起污点传出的位置

• to access path – 污点传出位置access path支持域敏感，access path需要支持以下数据结构

• Object filed

• 数组

• 集合类

2.2.运算顺序

跨应用的污点分析通过指定一入口应用开始计算：

• 在入口应用的应用内调用关系图提取callsite

• 通过callsite关联关系找到对应应用间调用关系图中callable，如图中callsite2找到callable3。

• 在应用间调用关系图中callable获取以该节点为根节点无环子树，如图callable3、callable4、callable5组成

• 在无环子树中，从叶子节点自下而上计算污点摘要。

• 完成根节点污点摘要，返回给入口应用加载，进行入口应用污点分析。

工程化落地

安全运营

在跨应用视角下，漏洞威胁从单应用变更到多应用，在跨应用漏洞运营体系建设中，我们进行了以下设计：

• 通过制定漏洞修复点标准，把漏洞涉及多个应用问题转化为只存在一个最优修复应用问题，进而融入单应用工单体系。

• 在工单流程中增加二次确认机制，在安全运营确认漏洞及修复归属后，业务结合业务属性判定是否为最佳修复点，对于业务否认的，则重置漏洞归属，进行新的工单分配。

• 对于代码安全，修复点负责人只能看到自己应用内数据流，除此之外还需要提供全局视角信息，提供应用间数据关联信息，让修复人更明确漏洞产生场景。

未来规划

• 目前只支持Java场景，对于跨语言的传输方式，需要设计语言兼容的摘要。

• 目前只支持RPC场景，需要支持HTTP、MQ等数据传输方式。

• 应用间调用关系，在安全方向，可以借助其他安全能力，如IAST等动态能力补充或优化数据。也可封装应用间调用关系提供元数据，为研发提供应用间调用关系梳理提供抓手。

参考

• https://www.blackhat.com/us-21/briefings/schedule/#do-you-speak-my-language-make-static-analysis-engines-understand-each-other-22797

• https://mp.weixin.qq.com/s/NG9Qc8PQveu7r1_NbKZz7Q