有风险的地方有两个
1.接口返回xml的格式化操作,SoapFormatAction,但是一般都打了补丁做了处理
实际上还可以在org.apache.xalan.transformer.TransformerIdentityImpl里解析之前加上下面代码也可以防止注入
2.调用接口时,一般来说如果服务是由home里startup.bat/startup.sh(tomcat)来启动的话是不会有风险的，但如果服务是由was启动,就会存在此风险。估计原因时两种服务容器的类加载方式不一样，据查tomcat的类加载器，不完全遵循“双亲委派”，就是自己先找，找不到了才让父加载器加载，而was应该是先交给父加载器加载。
调用接口时,NC采用的是XMLStreamReader来解析的,而它又是由XMLInputFactory来创建的,然而XMLInputFactory再NC里有三个jar包里都有而且路径一致
如果XMLInputFactory实例化的时候用的是jdk的XMLInputFactoryImpl,那就会有问题,而用的是tika-app里的WstxInputFactory就不会有，
因为XMLInputFactoryImpl的reader在解析标签的时候会去执行实体声明的指令，
而WstxInputFactory的reader在解析标签的时候不会执行命令,会根据标签符号判断event类型。
我们可以看到XMLInputFactory是一个静态变量，所以在服务启动之初就有可能已经进行了初始化，事实也是如此，追下代码就会知道，其实在服务启动时，ierp里的xml就是使用Staxs进行解析的。
所以在ws解析之前的StaxInInterceptor拦截器中将线程的类加载器改为系统类加载器也就是jdk的类加载器,XMLInputFactory实例化时一定是用的XMLInputFactoryImpl,那么就一定会有问题(这是在本地进行漏洞复现的方法)
解决办法:
1.在StaxInInterceptor拦截器前增加一个拦截器,专门对读取InputStream里面的XML,对敏感字符进行拦截
2.在StaxInInterceptor拦截器中,指定XMLInputFactory的子类进行实例化
3.XMLInputFactory解析前，设置属性不对引用实体进行解析
ps:风险发生在ReadHeadersInterceptor拦截器里的reader.next()方法里,所以在这之前处理都是可以的