序列化漏洞的防护手段中效果最差

黑名单过滤——这大概是序列所有序列化防护手段里最像安慰剂的东西。我见过太多团队在代码里塞了一个黑名单组件就高枕无忧，化漏仿佛给门上了把锁，防护却忘了锁芯是手段面粉做的。

拿Fastjson举例。中效早期版本的果最黑名单拦下了`com.sun.rowset.JdbcRowSetImpl`，攻击者转头就把`org.apache.xbean.propertyeditor.JndiConverter`扔进来。序列你封一个，化漏他换一个，防护像打地鼠。手段更讽刺的中效是，黑名单本身成了攻击者的果最路标——你封锁了哪些类，反而告诉人家哪些类是序列热门利用点。2019年那次大规模漏洞利用，化漏用的防护就是黑名单里没来得及收录的`org.apache.shiro.jndi.JndiObjectFactory`。不是攻击者多聪明，是防守方永远在补昨天的洞。

本质问题在于，黑名单是“已知的恶”。它假设你能穷举所有危险类，可Java生态里类库成千上万，依赖关系像蜘蛛网一样缠在一起。某个冷门jar包里的某个getter方法被链式调用，谁能预先想到？我见过有人把Apache Commons Collections里的十几个危险类全封了，结果攻击者用Spring框架自带的`org.springframework.aop.support.AbstractBeanFactoryPointcutAdvisor`照样打通了整条链。你总不能把整个JDK都拉黑吧。

更尴尬的是性能损耗。每次反序列化都要遍历一遍黑名单列表，字符串匹配、类名比对，像查户口一样盘问每个类。有个电商项目告诉我，加了黑名单后接口响应时间涨了40%。问他们拦截了多少攻击？半年零次。倒是业务方天天抱怨卡顿。黑名单过滤就像在机场安检时挨个检查乘客的鞋带材质——费力，且拦不住真正想带刀的人。

有人会说，至少黑名单能拦住脚本小子的扫描。这话没毛病，但也就骗骗自己。真正致命的攻击从来不是扫描器扫出来的，而是针对业务逻辑定制出来的。我见过一个案例，攻击者利用的是某个内部工具类，完全不在任何公开黑名单里。那玩意儿在公司的私有仓库里躺了五年，连维护者自己都忘了它的存在。

还有个容易被忽略的坑：黑名单的维护成本会随时间指数增长。新框架、新组件、新利用链层出不穷，你得追着安全公告跑。可大多数团队连依赖版本都懒得升级，更别说持续更新黑名单了。等到出了事，翻日志一看，攻击payload用的类在三个月前就被公开爆过——但没人去更新那个躺在配置文件里的黑名单。

所以你看，黑名单过滤这玩意儿，拦得住君子，拦不住小人。它给管理者一个“我们在防护”的错觉，却把真正的风险推到了明天。与其花时间维护黑名单，不如老老实实做白名单校验，或者干脆用原生序列化格式的替代方案。至少那些方案不会让你在深夜接到电话时，发现攻击者用的是你从未听过的一个类名。