去年我们遇到了所谓的 java 对象反序列化漏洞（看起来不是 java 的问题），该漏洞对对象进行反序列化，可能会导致远程代码执行 (RCE) 或拒绝服务 (DoS) 攻击。
请参阅https://dzone.com/articles/java-serialization-vulnerability-threatens-million了解详细信息。
基本上，如果代码无法验证传入的对象，则它很容易受到攻击。
这种攻击的影响会非常高，如中所述， 在 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：关闭反序列化 迄今为止最好的解决方案。
在反序列化不容忽视的情况下，除了黑白名单之外，是否有更好的方法来验证并阻止坏数据爆炸？
首先，您需要考虑风险以及谁获得序列化数据。只有 3 个超级管理员能够访问的内部管理界面不需要像公共网站那样受到关注。在第一种情况下，您甚至可能不会修复它并使用补偿控件来解决。 其次，您需要优先考虑您的建议：关闭序列化是最好的选择，因为它消除了风险。将特定类列入白名单是第二好的选择，如果无法关闭序列化，则应选择白名单，但不建议将其列入黑名单，因为您不会考虑所有选项，并且会被绕过。我不认为将黑名单作为有效的解决方案。 根据用例，另一种可能的解决方案是对序列化数据进行加密和/或签名 (HMAC)。在.NET中，您拥有可用于反序列化攻击的Viewstate来接管它，但如果它以正确的方式签名或加密，您将无法修改它，因此这是另一个有效的解决方案。所以你可以选择这3个之一（不包括黑名单）。