公司Iast优化方案

---

Secpoint

Plugin类结构

EventBusPlugin结构

StartupPlugin结构

分发阶段

Asm&JavaAgent装配流程

污点跟踪流程

优化体系

流程上的优化

我这一部分想的是从代码片段的Asm修改守着安全的代码入口
变换到我根据这些内存数据并追随这些内存数据流向去看是否有安全隐患问题

原情况

原公司利用JavaAgent以及Asm根据下发的Policy策略对NeedHook的点transformer->进行Asm代码修改InvokeStatic到GROZA的a
所有的PolicyContext->MethodContext都会进行这个InvokeStatic->GROZA
来到GROZA的代码流程根据不同的MethodContext#Phase再进行分类dispatch分发: Source[污染]、Propagation[传播]、Rule[触发]、Tag[打标]、Custom[自定义]

改进项

从Source污点这边就得监视MethodContext相关的污点数据是否产生
以及相关的Propagation以及Sink根据 Jvmti提供的接口都是通过监视器监控
监控当前内存流动的情况, 如果有Access以及Modifier操作
则根据Jvm StackFrame跟踪是否有Propagation和Rule相关动作

优缺点

• 优点
  • 只是监视数据, 能够取消大量的AsmHook点,攻击是极少情况下发生, 百分之99都应用正常运行时,能够避免百分之99的情况不会跑入Hook判断代码逻辑片段
  • 更加清晰的数据链路数据流向, 随数据看隐患, 随数据查溯源
• 缺点
  • 对原有的框架变动较大, 落地不易
  • Hook点过多, 与Jvm交互更多, 带来不稳定性
  • 兼容性更多, 由于底层Hook的手段更多了, 考虑JNI操作对jvm一定的兼容性

基础物料

Jvmti.h

内容来源: https://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html

• 字段监视器
• 对象引用回调
• 获取堆栈帧及所有堆栈帧跟踪
• 获取对象变量数据
• …..剩余可利用Api

结构上的优化

我觉得我们的Secpoint功能太完全了, 有些功能可能产品上线之后可能客户很少会用到 但是内存一直会常驻这些功能代码片段
我想到的是拆包+责任上抛Astp服务端
有些功能如果需要用则按需下载并加载, 部分计算逻辑从Agent端转移到Astp服务端
如果Astp:Agent比例数量大确实可以放在Agent端,避免Astp服务端造成计算压力点

拆包

我主要考虑到公司有各种对框架的支持性
CustomerHookHandler下有各种类似Dubbo、Feign、Hsf、Ribbon、Shiro等等
我觉得这些逻辑性操作可以利用lua或者js的引擎器来执行这类的脚本逻辑操作
对这些引擎提供相关的Jvm操作入口并桥接类似JNI操作

责任转移

相关的漏洞分析、拆分等环节的工作转移到Astp服务端
Agent只负责去重和采样还有防御工作, 减轻Agent工作量, 提供正常应用的稳定性

网络上的优化

我看到公司用Websocket是很明智的

线程模型的优化

·····