PHP反序列化漏洞，何规说白了就是反序攻击者把精心构造的字符串喂给`unserialize()`，让程序在恢复对象时意外执行了危险代码。列化漏洞这不是何规什么高深魔法——2018年ThinkPHP的RCE、2021年Drupal的反序CVE-2021-32720，全是列化漏洞这条路上的翻车现场。你不需要成为黑客才能防住它，何规只需要搞懂它怎么发生，反序然后堵死那几条路。列化漏洞

先看最典型的何规坑：`__wakeup()`和`__destruct()`这两个魔术方法，一个在反序列化时自动调用，反序一个在对象销毁时触发。列化漏洞攻击者不需要知道你的何规业务逻辑，只要猜出类名和方法名，反序把属性值改成一串恶意字符串，列化漏洞比如把`$filePath`改成`/etc/passwd`，或者把`$command`改成`system('rm -rf /')`，程序一跑就完蛋。我见过一个真实案例，某后台管理系统用cookie存用户偏好，直接`unserialize($_COOKIE['pref'])`，结果被塞了个`O:8:"getFlag":0:{ }`进去，服务器直接泄露了数据库配置。

规避的第一原则：**永远不要反序列化不可信数据**。这听起来像废话，但99%的漏洞都栽在这上面。用户输入、HTTP头、cookie、第三方API返回——这些统统算不可信。如果非要存对象，那就用`json_encode`+`json_decode`代替，虽然会丢类型，但安全得多。你可能会说“我序列化的是自己的数据，没经过用户”，可攻击者能通过参数篡改、存储型XSS等方式污染数据源，防不胜防。

第二个硬招是**白名单类过滤**。PHP 7.0之后`unserialize()`支持第二个参数，允许你限制能反序列化的类名。比如你只允许`User`和`Config`这两个类，就写`unserialize($data, ['allowed_classes' => ['User', 'Config']])`。这样攻击者哪怕塞了`O:8:"EvilClass":0:{ }`，PHP也会直接返回`false`，连魔术方法都不会触发。别小看这个参数，它能挡掉80%的POP链攻击——那些靠串联多个类魔术方法实现RCE的花活，全被掐死在门口。

光有过滤还不够，你得**检查魔术方法里的操作**。`__wakeup()`里如果有文件操作、命令执行、数据库写入，那就等于给攻击者开了后门。我审计过的代码里，有人把日志写入逻辑放在`__wakeup()`里，参数用对象属性拼接文件路径，结果攻击者用`../../../../tmp/evil.php`直接写了个webshell进去。这种时候，哪怕有白名单类，只要合法类的方法本身不安全，照样被利用。所以审查每个魔术方法的行为，禁用危险函数，比加一百层过滤都实在。

还有个小细节容易被忽略：**序列化字符串中的属性个数可以伪造**。比如`O:4:"User":2:{ s:4:"name";s:3:"abc";s:6:"isAdmin";b:1;}`，攻击者把属性个数从2改成3，某些老版本PHP会跳过属性赋值直接进入`__wakeup()`，导致初始化逻辑被绕过。解决方法是升级到PHP 7.4以上，同时用`hash_equals()`校验序列化数据的完整性——比如加个HMAC签名，数据一变就拒绝反序列化。

最后，别依赖`__autoload()`或`__destruct()`做清理工作。这些方法在反序列化失败时也可能被调用，攻击者利用这个特性触发任意代码执行。更稳妥的做法是，在反序列化之前先`class_exists()`检查类是否存在，并且把对象赋值给临时变量，手动`unset()`销毁，别让PHP的垃圾回收机制替你决定什么时候调用`__destruct()`。

说句实在话，规避这个漏洞的核心就一句话：**把输入当毒药，把魔术方法当雷区**。你不需要成为安全专家，但得养成习惯——写`unserialize()`之前问自己三遍：这数据我能信任吗？这类的魔术方法安全吗？有没有更简单的替代方案？如果答案让你犹豫，那就换`json_decode`，或者加白名单加签名。毕竟，比起修复被攻破的系统，多敲几行防御代码的成本低太多了。

(责任编辑：焦点)