把希望寄托在“过滤关键词”上，反序是列化漏洞反序列化漏洞防护里效果最差的做法。没有之一。防段中

我见过不止一个团队在代码里写这样的护手逻辑：拿到序列化数据后，先转成字符串，效果检查里面有没有Runtime、最差ProcessBuilder、反序exec这些词，列化漏洞有就拒绝。防段中看起来很直接，护手像给门上加了一把锁。效果问题是最差，攻击者根本不走你正门。反序

Java反序列化的列化漏洞利用链，从来不是防段中靠一个显眼的类名就能拦住的。以CommonsCollections这条经典链为例，入口类可能是AnnotationInvocationHandler，中间经过LazyMap、ChainedTransformer，最终才落到Runtime.exec。你在序列化字节流里搜Runtime，确实能搜到——但前提是攻击者没有对字符串做编码或拆分。把Runtime写成Ru\u006etim\u0065，或者通过反射在运行时拼接类名，你的关键词过滤就瞎了。更不用说还有大量不依赖Runtime的利用方式，比如写文件、JNDI注入、加载远程类。

关键词过滤的另一个致命伤是它只盯着“已知的坏词”。反序列化漏洞的利用面极广，Java生态里存在几十条公开利用链，涉及CommonsCollections、Spring、Groovy、BeanShell、Rome、XStream等不同库。你今天把InvokerTransformer加进黑名单，明天攻击者换一条Jdk7u21的链，里面根本没有你过滤的那个词。这种防护本质上是在和攻击者玩打地鼠，而且你永远慢一步。

有人会说，那我用正则匹配更复杂的模式呢？比如检测readObject调用链的特征。这比单纯关键词好一点，但仍然不可靠。序列化数据是二进制格式，经过gzip压缩、base64编码、自定义加密之后，你的正则连原始字节都看不到。我见过一个真实案例：某服务在入口处做了关键词过滤，攻击者把payload用AES加密后放在一个字段里，服务端解密后再反序列化。过滤逻辑完全失效，因为检查发生在解密之前。

那为什么还有这么多人在用关键词过滤？因为它便宜。不用改架构，不用引入新组件，加几行代码就能交差。安全扫描器扫出来一个反序列化点，开发随手加个黑名单，工单就关了。这种“看起来做了防护”的假象，比不做防护更危险——它让人放松警惕，以为问题已经解决。

真正有效的防护手段是另一回事。要么在反序列化前做白名单校验，只允许特定的类被反序列化；要么用安全的序列化格式替代Java原生序列化，比如JSON或Protobuf；要么在JVM层面加ObjectInputFilter，做细粒度的类和方法过滤。这些方案都有成本，需要改代码、改配置、甚至改通信协议。但它们是结构性的，不依赖攻击者用哪个词。

关键词过滤的问题不在于它“不够强”，而在于它的防护逻辑本身就是错的。它假设攻击者的payload里一定包含某些固定字符串，而反序列化漏洞的本质是合法类的非法组合。你过滤的是词，攻击者利用的是类加载和方法调用链。两者根本不在一个层面上。

我个人的判断很简单：如果一份反序列化防护方案里，核心手段是字符串匹配，那它约等于没做。省下来的那点开发时间，迟早会在应急响应时加倍还回去。