Java - 不受信任数据的反序列化解决方法

Question

去年我们遇到了所谓的 Java对象反序列化漏洞（看起来并不是Java的问题），这是反序列化可能导致远程代码执行（RCE）或拒绝服务（DoS）攻击的对象。

请参见 https://dzone.com/articles/java-serialization-vulnerability-threatens-million 了解详细信息。

基本上，如果代码未能验证传入的对象，则存在漏洞。

如What is the security impact of deserializing untrusted data in Java?所述，此攻击的影响将非常大。

首先，攻击者使用了Apache Commons Collections中的InvokerTransformer类作为建立攻击链的方式。 解决方案1：黑名单不接受已用于构建小工具链的类。

但是，这还不够，因为可以通过许多其他方式构建攻击链。请参阅， https://github.com/frohoff/ysoserial/tree/master/src/main/java/ysoserial/payloads 解决方案2：白名单通过使用“SecureObjectStream”覆盖ObjectStream，该方法验证实际由应用程序预期的类。

同样，这并不能完全消除攻击。有一个使用jre7u21的RCE和使用HashSets的拒绝服务攻击。 解决方案3：关闭反序列化是目前最好的方法。

问题

在无法忽略反序列化的情况下，是否有更好的方法来验证和阻止恶意数据在爆炸之前停止，而不是黑白名单？

- Sudershan

---

一些不错的指南：https://www.securecoding.cert.org/confluence/pages/viewpage.action?pageId=27492407 - GhostCat

也许使用像json、xml或协议缓冲这样的传输格式是另一种选择？ - Taylor

解决方案4：仅接受来自可信源的数据 - 可通过RSA / ECC签名进行验证。 - Robert

请将您的commons collection jar更新至3.2.2版本。 - s.ijpma

在这种情况下，只有解决方案3是安全的。Java序列化格式是移动代码，您永远不应该向世界公开代码执行接口。而应该使用仅限数据的格式。 - Robert

Answer 1

首先，你需要考虑风险和谁获取序列化数据。仅有3个超级管理员能够访问的内部管理界面不需要像公共网站那样引起同样的注意。在第一种情况下，您甚至可能不需要修复它，并解决补偿控制问题。

其次，您需要为您的建议确定优先级：关闭序列化是最佳选择，因为它可以消除风险。白名单特定类是第二好的选择，如果无法关闭序列化，则应选择该选项，但不推荐黑名单，因为您无法考虑到所有选项并且该方法容易被绕过。我不认为黑名单是一个有效的解决方案。

根据用例，另一个可能的解决方案是对序列化数据进行加密和/或签名（HMAC）。在.NET中，您可以使用Viewstate进行反序列化攻击来接管它，但如果以适当的方式签名或加密，您将无法修改它，因此这是另一个有效的解决方案。因此，您可以从这三种（不包括黑名单）中选择一种。

- Gil Cohen