Java CVE-2015-4852：评估应用程序的脆弱性

我从的编写和利用示例中了解到，您需要接收用户提供的序列化对象和类路径上存在的Apache commons集合的代码进行利用

有了这两件事，请求应该是可以手工处理的（尽管有些请求可能需要反复试验/了解系统）

同样，对于易受攻击的产品，它不必直接使用

invokerTransfer

。有问题的对象由漏洞攻击请求提供。“易受攻击的应用程序”所要做的就是提供commons collections JAR和逻辑，在用户提供的

InvokerTransformer

实例上调用

.readObject（）

---

假设我正确理解这一点。。。从调用

ObjectInputStream.readObject（）

方法的位置向后追踪，并得出结论，如果流中可能包含外部用户提供的对象，则产品可能易受攻击，基于此对产品（您拥有源代码）进行评估是否足够，如果存在不受信任的数据到达调用ObjectStream的路径。readObject（）且调用器Transformer位于类路径上，则产品或库易受攻击

如果必须接受目的地为反序列化的不受信任数据，则可以阻止包含InvokerTransformer的有效负载。您必须使用自己的可序列化格式解析器，或者找到一个安全的库来实现这一点

另一种缓解措施是在一个单独的类加载器中取消序列化，InvokerTransformer无法访问该类加载器

更好的是，@PhaedrusPhacdelm发现，将允许反序列化的类列入白名单：

---

我真的希望VeraCode和其他静态分析工具将此添加到污染分析中。即使使用数据流分析工具，手动进行这种分析也是非常棘手和耗时的，因此开始了打鼹鼠的游戏。直到找到下一个类（如InvokerTransformer）为止……从开发角度来看，这里有一个很棒的总结：链接到。。。。显示处理此问题的理想方法不是阻止特定类，而是仅通过cutom对象流上的

resolveClass（）

将您愿意接受的类列为白名单。以上博文中的提示请参见Charles Miller（）。InvokerTransformer只是利用反序列化不受信任数据的一种方法。即使没有可用的InvokerTransformer，也可能存在其他类，这些类的副作用会被恶意利用。即使在序列化/反序列化过程中不使用自定义java对象，应用程序是否也会受到影响。例如：如果我的应用程序只是从流中反序列化字符串或其他标准java对象（整数），我是否仍然受到此漏洞的影响（假设InvokerTransformer位于类路径中）？