反序列化漏洞的防护手段有哪些

2017年，反序Equifax公司因一个未修补的列化漏洞Apache Struts反序列化漏洞，泄露了1.43亿美国人的防段社保号码、驾照信息和信用卡数据。护手这起事件让安全圈彻底明白：反序列化漏洞不是反序理论威胁，而是列化漏洞随时可能引爆的定时炸弹。防护手段说复杂也复杂，防段说简单也简单——核心就一句话：别信输入，护手别偷懒。反序

最彻底的列化漏洞防护是压根不用反序列化。JSON、防段Protocol Buffers这类纯文本或二进制格式，护手解析时不执行任何对象逻辑，反序天然免疫。列化漏洞很多老旧系统非要传Java对象或PHP对象，防段图省事用原生序列化，结果把攻击面全暴露了。我见过不少团队把对象序列化当“内部通信的便利工具”，却忘了攻击者也能伪造请求头。能换格式就换格式，这是治本。

换不了格式？那就上白名单校验。Java的`ObjectInputStream`可以重写`resolveClass()`方法，只允许反序列化预定义的类。PHP的`allowed_classes`参数同理。白名单比黑名单强一百倍——黑名单得追着CVE跑，白名单直接封死未知攻击。2019年那个WebLogic的远程代码执行漏洞，很多公司打补丁打慢了，但用了白名单的压根不受影响，因为攻击类根本不在允许列表里。

运行时防护是第二道防线。反序列化攻击的链路通常很长：恶意对象触发`readObject()`，然后调用`invoke()`，最后执行系统命令。在关键调用点埋监控，比如检测`Runtime.exec()`或`ProcessBuilder`的异常调用来源，能实时掐断攻击。但别指望这招兜底——攻击者会混淆调用链，甚至用反射绕过常规检测。所以运行时监控只能当辅助，不能当主力。

还有个容易被忽略的细节：序列化数据的完整性校验。给序列化字节流加个HMAC签名，密钥放服务端，客户端无法篡改。这招防的是“中间人篡改”场景。但注意，如果攻击者能直接控制服务端内存，签名密钥也会泄露，所以这属于锦上添花，不是救命稻草。

最后说说打补丁这件事。很多人觉得补丁是运维的事，但开发侧更该上心。Apache Commons Collections那个经典利用链，官方在2015年就修了，但直到2019年还有大量系统在用旧版本。你没法保证每个依赖都及时更新，那就得靠前几招兜底。说白了，反序列化防护是分层防御——格式层、类加载层、运行时层、完整性层，每层都设卡，攻击者才可能知难而退。

别把希望寄托在“我们系统内部用，外部访问不到”这种侥幸上。内部威胁、横向移动、供应链攻击，哪条路都通着你的服务器。防护手段就那些，执行不执行，差距就是一场数据泄露的事故报告。