审核呆子有话说：
从系统全局配置文件入手以便精准锁定框架入口和审计对象，对框架运行流程的分析足以体现作者深厚的代码审计功底。
大型的Java系统都会使用Commons Collections这个组件，当开发者在不慎使用readObject()时，便会产生严重的后果。功夫不负有心人，全静态审计并找出反序列化的触发点，导致远程命令执行。
（本篇分析源自2017年7月精品漏洞第三名，360众测第一人，jkg006）。
Section1:绪论
当你面对一个几个G的大型框架代码时候，怎么能够剥茧抽丝，把一个个小点放大到到处都是漏洞，这个就需要我们队javaweb框架进行整理的分析评估，因为拿到你手上的并不能调试，你只能根据代码功底，一个个的分析，找出来影响输入输出的点.
分析对象为某软件公司的大型财务软件。
Section2:漏洞分析
从一个javaweb的入口文件开始，我们分析web.xml
这个里面跟进去看看
如果以/~开始我们可以假设/~uap/UploadServlet 那么最后moduleName就是uap serviceName就是UploadServlet。
通过这里的getServiceobject来获取对应的路由规则，最后执行各个目标的service函数。
这里适用crl+t可以看出所以实现这个类的子类关系，里面的实例都有可能被调用，只要他满足上面两个条件，并且有service接口。当然，这个不是我们要解决的问题，我们要弄明白整体的框架调用关系，才能一本万利抓取更多的漏洞。
主要看看这个接口：
从这里分析，无非来自三处
1. moduleName 为空的时候，来自NCLocator
2. 不为空的时候来自serviceObjMap，当然了这个应该是个启动缓存，其实真正来源于BusinessAppServer，这个第一次初始化回存储到serviceObjMap里面，第二次调用就不会再反复去计算了。
跟进getContainer看：
这里的nameModulesMap是这个类初始化创建的，看它的init方法。
然后我们分析以下initEnv，初始化上下文。
这里初始化了所有的模块调用的上下文，不多继续深入了，我们举例子说明。刚才假设的是/~uap/UploadServlet，我们就去modules里面去找uap模块。
里面在meta-INF所有已upm结尾的就是它的配置文件，
modules\uap\meta-INF\S_uapbase63.upm 看看这里的结构
里面又属性为accessProtected ，这个为false就是不需要验证的，并且可以对外调用的，为true就是内部调用的接口。这里整个module以及全局配置文件的解析过程都在：
总体上来看就是解析.module文件，并且这个配置文件accessProtected="false"才可以被外部调用。搜索一下有多少个这样的：
这个将近有461处，放大这么多接口，肯定有很多漏洞。知道了所有的整体流程，那么才开始我们的漏洞检查。
这里直接进行了反序列化操作。构造payload