序列化漏洞原理

一个攻击者往你的序列登录表单里塞了一串精心构造的字符串，服务器居然就把内存里的化漏对象给改了——甚至直接执行了系统命令。这不是洞原科幻剧情，这是序列序列化漏洞干的事。2017年，化漏Apache Struts 2的洞原漏洞让某家大型航空公司泄露了数千万乘客数据，根子就在反序列化处理不当。序列

先别急着背概念。化漏序列化本身挺无辜的洞原，它就是序列把你程序里的对象——那些有属性有方法的家伙——转成一串字节或者文本，方便存文件、化漏传网络。洞原反过来，序列反序列化就是化漏把那串东西再变回活生生的对象。问题出在第二步：如果程序在“复活”对象的洞原时候，完全信任了输入的数据，没检查里面藏了什么，那攻击者就可以在序列化数据里塞私货。

你可能会问，对象复活而已，能有什么私货？关键在“魔法方法”。Java里有readObject，PHP里有__wakeup，Python里有__reduce__。这些方法在反序列化过程中会被自动调用。攻击者只要找到一条从这些方法通向危险函数的路径——比如Java的Runtime.exec()，或者PHP的eval()——就能让服务器在反序列化时干点别的。这就像你收到一个快递，盒子外面写着“玩具”，打开却是炸弹，而且你拆快递的动作本身就是引信。

更阴的是，攻击者不需要直接控制服务器上的类。他们可以构造一个对象图，利用现有类的方法链，把无害的调用串成有害的。业内管这叫“gadget chain”，像乐高积木一样，单个看都没问题，拼起来就成了一把钥匙。Apache Commons Collections这个库里的几个类，就经常被拿来当积木用——因为太多Java应用都依赖它，攻击者根本不需要知道目标系统具体代码长啥样。

真实世界里，这东西比SQL注入更隐蔽。SQL注入好歹你能在请求里看到明显的引号和关键字，序列化攻击的payload是一长串二进制乱码，WAF很难识别。有的攻击者甚至把它藏在cookie里，服务器每次自动解析cookie，等于把后门开在了门口。

怎么防？最粗暴的做法是别反序列化不可信数据，但现实是很多老系统改不动。退而求其次，用白名单过滤类，或者用替代格式比如JSON——但JSON只能存数据，存不了对象状态，业务复杂度一上来就有人偷偷用回原生序列化。还有个土办法，在反序列化前后加校验和签名，但这只能挡粗心的攻击者，挡不住那些能拿到合法签名payload的人。

我见过最讽刺的案例：某团队为了“安全”给序列化数据加了AES加密，结果密钥硬编码在代码里，攻击者反编译一下就能拿到。安全这东西，最怕的就是你以为自己做了防护。

说到底，序列化漏洞的核心就一句话：程序把外部输入的“描述”当成了“指令”来执行。只要这个信任边界不清晰，今天堵住了Java的readObject，明天Python的pickle又会出事。别指望一劳永逸，多盯着点那些自动执行的魔法方法，比啥都强。