我第一次在CTF里遇到PHP反序列化题目时，整个人是懵的。一串带着花括号的字符串，解码后竟然能直接执行系统命令，当时的我盯着payload看了半天，愣是没明白它是怎么跑起来的。后来在真实代码审计里反复碰到类似问题，又啃了不少框架源码，才慢慢把这层纸捅破。PHP反序列化说白了就是一次格式转换背后的信任问题：程序把一堆面向对象的数据结构还原成对象，而还原过程中触发的方法调用没有设防，攻击者就能借此构造出任意代码执行的链路。这里我把自己从入门到实战踩过的坑、梳理过的思路整理成文，适合对Web安全感兴趣的开发者、审计人员和刚接触CTF的朋友，读完你应该能自己看懂一条POP链是怎么来的，也能知道线上系统到底该怎么防。
1. 先弄明白：序列化与反序列化到底在干嘛
1.1 serialize的输出格式怎么读
在PHP里，序列化就是把一个对象或者数组转换成一段可以传输、存储的字符串。日常搬砖时你多半见过json_encode，也有不少人用json存Session，但PHP原生的serialize格式细节更丰富，因为它要完整还原对象的结构，包括类型、访问级别、属性名这些信息。
举个例子，一个简单的类：
class User { public $name = 'admin'; public $isAdmin = true; } $u = new User(); echo serialize($u);输出内容是：
O:4:"User":2:{s:4:"name";s:5:"admin";s:7:"isAdmin";b:1;}拆开来看，O表示这个字符串描述的是一个对象，4是类名长度，User是类名，2表示这个类里有2个属性。后面的s:4:"name"说明属性名是字符串类型、长度4、值是name，s:5:"admin"是属性值，b:1表示布尔值true。如果类是private或protected属性，序列化时属性名前会被塞入空字节和类名信息，比如private属性$cmd在serialize之后会变成类似s:9:"\0User\0cmd";的形式，这就是为什么有些payload要用urlencode处理，否则空字节在HTTP传输时会被直接丢掉的。
反序列化就是把这串字符串还原成对象的过程，unserialize是serialize的逆操作。到这里一切都很合理，就像快递把包裹打包寄出去，收件人再拆开使用。问题出在拆包这个动作本身，它并不像我们想象的那么“机械”。
1.2 魔术方法：反序列化过程中的隐式回调
如果说序列化和反序列化只是打包拆包，那拆包过程本身不会有安全风险。但PHP有个非常特殊的设计：反序列化过程中会自动触发一系列魔术方法，它们是不需要你写调用代码的“隐式回调”。
比如这段代码：
class User { public $name; public function __wakeup() { echo "对象被反序列化恢复了"; } public function __destruct() { echo "对象被销毁了"; } }__wakeup在unserialize执行时自动触发，__destruct在对象生命周期结束、变量被释放时自动触发。除了这两个，还有__toString（对象被当成字符串使用的时候）、__call（调用不可访问的方法时）、__get（访问不存在属性时）、__invoke（对象被当成函数调用时）等。
| 魔术方法 | 触发时机 | 利用场景 |
|---|---|---|
| __wakeup | unserialize执行时 | 反序列化入口点，可立即进行方法调用 |
| __destruct | 对象销毁时 | 最常见危险点，脚本结束也会触发 |
| __toString | 对象被当字符串拼接/输出时 | 文件读取、拼接路径 |
| __call | 调用不可访问或不存在的方法时 | 动态分发方法调用 |
| __get | 读取不可访问属性时 | 返回敏感对象或值 |
| __invoke | 对象被当成函数调用时 | 回调函数场景串联 |
漏洞利用基本就围绕这些魔术方法展开。攻击者虽然不能直接写调用代码，但可以控制反序列化恢复出来的对象属性。属性一变，方法里的逻辑就可能全变了。
这里引出一个非常关键的认知：
反序列化漏洞的本质不是“格式转换”本身，而是不可信数据在还原对象时，触碰到了程序里预设的可利用方法。
2. 漏洞的根：为什么一次格式转换会变成代码执行
2.1 第一现场：不可信数据流入unserialize
先说一句很多人不爱听的话：unserialize本身不危险，危险的是拿它处理外部可控的数据。真实项目里最常见的出事写法，就是直接把请求参数、Cookie、数据库字段里的内容塞给unserialize。
举个例子：
$data = $_COOKIE['user']; $user = unserialize($data);这段代码在老项目里真的出现过不少次。攻击者把原本序列化的User对象，替换成自己手工构造的字符串提交给Cookie，程序就会按照攻击者指定的类名和属性去创建对象。如果项目里恰好存在一个类，它的某个魔术方法里调用了危险函数，比如__destruct里eval、__wakeup里call_user_func，那构造出来的对象在销毁或唤醒的一瞬间，危险逻辑就执行了。
有朋友会问：那是不是说，只要项目里没有这种“自带危险逻辑”的类就安全了？并不是。真实框架动辄几百个类，你以为没有，实际上某个第三方库的类里可能藏着__toString拼接路径、__call调用任意函数、__destruct删除文件的逻辑。所以反序列化漏洞的挖掘，本质上就是在代码库里寻找“从魔术方法到敏感函数”的路径。
2.2 POP链：把多个类串联起来找危险终点
单个类能直接到达危险函数当然最好，但现实往往不是这样。更多情况是A的魔术方法调用了B的方法，B的方法又触发了C的属性拼接，C最后走到system。这种从入口到出口的方法调用链条，行业内叫POP链，全称是Property-Oriented Programming，属性导向编程。
理解POP链有个很合适的类比：你想按下保险柜里的按钮，但柜子是锁死的，你手边只有一堆道具：扳手、螺丝刀、铁丝。它们单独看都跟按钮没有直接关系，但只要按正确顺序组合操作，就能打开柜子够到按钮。POP链就是在已有的类库中寻找这条“正确顺序”。
举例说明，假设代码里有两个类：
class A { public $obj; public function __wakeup() { $this->obj->execute(); } } class B { public $cmd; public function execute() { system($this->cmd); } }攻击者构造一个A对象，把obj属性设为B对象，cmd设为whoami。序列化后的字符串类似：
O:1:"A":1:{s:3:"obj";O:1:"B":1:{s:3:"cmd";s:6:"whoami";}}提交给目标后，unserialize时A的__wakeup触发，调用B的execute方法，cmd参数可控，直接执行系统命令。这个链条只有两步，但真实利用可能跨四五个类，还要兼顾属性类型、访问控制、构造函数参数，这就是为什么很多人觉得反序列化难的真正原因。其实思路始终一致：从入口魔术方法出发，沿着源码里的调用关系图，判断能否到达敏感函数。
这里额外提一个重要细节：反序列化要触发某个类的魔术方法，前提是这个类已经被PHP加载了。如果在unserialize时类还不存在，PHP会把对象还原成一个__PHP_Incomplete_Class，调用方法时就不会按照预期走。这也是为什么利用反序列化漏洞之前，往往需要先搞清楚目标环境里到底加载了哪些类。
2.3 常见误区：反序列化利用不一定非要getshell
很多教程讲到反序列化就喜欢拿RCE（远程命令执行）出来说事，仿佛只有命令执行才叫利用成功。根据我的经验，真实环境里能直接RCE的gadget往往很难找，但反序列化漏洞的价值远不止命令执行。
__destruct里unlink可以删文件，__toString里file_get_contents可以读文件，__call里call_user_func可以配合特定函数搞SSRF，__debugInfo可以读配置信息。攻击者只要有可控对象，能触达的敏感操作都可能成为突破口。所以审计的时候别只盯着system、eval这种高危函数，要打开思路，文件操作、网络请求、数据库读写都算危险终点。
3. 从源码泄露到Flag：一次完整的反序列化利用实战
3.1 第一步：从备份文件抠出源码
反序列化题目和漏洞利用的起点，往往是信息收集。CTF里常见的一个情况是：网站根目录放着机器人文件或者注释里提到backup，目录扫描发现www.zip或者index.php.bak这类备份文件。极客大挑战2019里的PHP题就是这个路子的典型代表，让你下载源码后做代码审计。真实系统里也一样，源码泄露确实是反序列化漏洞最常见的“助攻条件”，因为你需要知道目标代码里有哪几种类、哪些魔术方法。
拿到备份之后，我一般先看三样东西：入口文件（通常叫index.php）、所有类的定义、配置里和序列化相关的逻辑。入口文件决定参数从哪进去，类的定义决定你能构造什么对象。如果连源码都拿不到，也不是完全没法测，可以试着发一个反序列化字符串，通过报错信息里的类名回显猜测目标使用的类，但效率低很多，在真实环境中也容易触发告警，不值得推荐。
3.2 第二步：审计源码，找到反序列化入口与危险方法
假设下载下来后，index.php的代码结构是这样的，这也是反序列化CTF题里非常常见的骨架，我把题目中的结构做了等价简化：
<?php class Info { public $name; public $content; public function __destruct() { eval($this->content); } } if (isset($_GET['data'])) { $data = base64_decode($_GET['data']); unserialize($data); } else { highlight_file(__FILE__); } ?>审计时一眼就能看到两个关键点：入口是GET参数data，base64解码后直接进unserialize；出口是Info类的__destruct方法，里面有个eval，参数是对象的content属性。这两者一结合，构造一个Info对象，把content设置成要执行的代码，提交即可。
3.3 第三步：手工构造POP链payload
既然Info类单个类就能从__destruct到达eval，不需要跨类串联，那生成payload就很简单了。在你自己的本地环境写同样的类定义：
<?php class Info { public $name = "guest"; public $content = "system('id');"; } $p = new Info(); echo base64_encode(serialize($p)); ?>运行后输出一串base64字符串，把它拼到URL参数上，格式类似：
http://target/index.php?data=你生成的base64内容这里有个关键认知：你不需要在目标服务器上运行这段PHP，本地只要保证类名、属性名和类型完全一致，序列化出来的字符串格式就是通用的。如果类里有private属性，务必用PHP脚本自己生成payload，不要用文本编辑器手写，因为空字节不好表示，手写很容易翻车。
我建议在本地输出时顺手做一次urlencode，因为反序列化字符串里有分号、花括号、引号，直接塞进URL有很大概率被解析器截断。虽然PHP在接收$_GET参数时会自动做一次URL解码，但额外编码一次能避免很多莫名的报错。
3.4 第四步：版本差异和练手环境
如果你在本地复现这个利用链，发现payload交给目标后不执行，先别急着怀疑构造逻辑，先看PHP版本。PHP 7.4之前存在一个CVE-2016-7124，说的是序列化字符串里声明对象属性个数比真实属性个数多时，__wakeup会被绕过。这个特性在PHP 7.4之后已经被彻底修复，网上很多老博客的payload在新版本里直接就失效了。所以复现最好用Docker拉一个和题目环境一致的PHP版本镜像，省得自己编译环境浪费时间。
如果你想拿真实靶场练手，pikachu靶场里有一个专门的反序列化漏洞模块，可以直接用来验证今天这些思路。这类模块代码量不大，很适合拿来练习“先审源码、再构造payload、最后看回显”的完整流程。
4. 容易被忽视的触发面：phar协议与session序列化器
4.1 phar反序列化：不需要unserialize也能触发
很多人以为反序列化漏洞一定要代码里写了unserialize才会发生，这是一个很大的认知盲区。PHP里的phar文件包装器在处理phar://协议时，会自动反序列化phar文件元数据区域存储的对象。这意味着某些文件操作函数，比如file_exists、getimagesize、fopen，只要传入的参数包含我们能控制的phar://路径，就可能触发一次隐式反序列化。这就是常说的phar反序列化。
现实攻击场景大致是这样：上传点允许传图片，程序用getimagesize检查图片尺寸，我们把一个构造好的phar文件后缀改成jpg传上去，再找一个文件操作参数传入phar://uploads/xxx.jpg的路径，就能触发反序列化。构造phar文件需要本地php.ini中phar.readonly=0，示例代码：
<?php class Info { public $content = "system('id');"; } $phar = new Phar('exploit.phar'); $phar->startBuffering(); $phar->setStub('GIF89a<?php __HALT_COMPILER(); ?>'); $phar->setMetadata(new Info()); $phar->addFromString('test.txt', 'test'); $phar->stopBuffering(); ?>setStub前面加GIF89a是一个非常实用的技巧，能让生成的phar文件在开头带上GIF图片头，绕过一部分图片类型检测。在授权测试这类思路时，注意先确认目标PHP环境已经启用phar扩展，并且相关文件操作函数的参数确实可控，否则构造得再完美也触发不了。
4.2 session序列化处理器的差异
另一个容易被忽略的触发点是session。PHP的session序列化处理器有php、php_binary、php_serialize三种，它们把session数据写入文件时的格式完全不同。如果PHP配置里写入处理器和读取处理器不一致，攻击者就有可能往session中注入伪造的序列化数据。
三种处理器的存储格式差异，可以直接看这个表：
| 处理器 | 存储格式示例 | 说明 |
|---|---|---|
| php | name|s:5:"admin"; | 键名和值用竖线分隔 |
| php_binary | 4位长度键名\0name|s:5:"admin"; | 键名前有长度前缀 |
| php_serialize | a:1:{s:4:"name";s:5:"admin";} | 整体是标准序列化数组 |
举个例子，如果php.ini配置写入时用的是php_serialize，但某段业务代码里session_start时指定了session.serialize_handler=php，两种handler处理数据时对“键名|值”分隔的理解不同，攻击者可以通过上传文件名等可控输入，构造出竖线字符，把自己的序列化数据注入到session文件里。之后只要有一个反序列化点会读取session内容，就能触发利用。
这类问题的防御其实很简单：线上环境统一把session.serialize_handler设置为php_serialize，不要在业务代码里随意覆盖这个配置。很多框架默认是php处理器，如果把服务器配置改了但框架内部又指定了另一个，差异就埋下了，长期来看都是隐患。
5. 防御实践：从代码审计到线上加固
5.1 入口防御：白名单类过滤和allowed_classes
PHP 7.0之后，unserialize函数提供了第二个参数allowed_classes，可以直接限制允许反序列化哪些类。最简单的场景，如果业务里只需要恢复一个配置数组，完全可以设为false：
$data = unserialize($payload, ['allowed_classes' => false]);如果需要某些类，就把类名列出来：
$data = unserialize($payload, ['allowed_classes' => ['Config', 'User']]);白名单之外的对象会被还原成__PHP_Incomplete_Class，不会触发魔术方法，攻击者构造再漂亮的POP链也跑不起来。但要强调一点：allowed_classes不是万能药，如果白名单里的类本身就有可利用的危险魔术方法，照样能被串进链子里。白名单的粒度尽量细化，能不开的类坚决不开。
5.2 纵深防御：签名校验、JSON替代与数据隔离
对于已经上线的老项目，大规模改动unserialize逻辑往往会牵扯一堆兼容性问题，我更推荐先做防篡改签名。思路是写入序列化字符串时，用服务端密钥做HMAC，读取时先验签再反序列化。攻击者拿不到密钥，就无法修改序列化内容，POP链再强也触发不了。
$payload = base64_encode(serialize($data)); $sig = hash_hmac('sha256', $payload, $secret); setcookie('user', $payload . '.' . $sig); // 读取时 [$payload, $sig] = explode('.', $_COOKIE['user']); if (hash_equals(hash_hmac('sha256', $payload, $secret), $sig)) { $data = unserialize(base64_decode($payload)); }另一个方向是数据格式替代。新的业务尽量别做对象序列化，用json_encode/json_decode去存配置、Session、缓存，JSON不会触发PHP魔术方法，天然免疫反序列化攻击。缺点是丢失类型信息，但对大多数存储场景来说完全够用。如果必须依赖对象序列化，可以考虑把可序列化的对象拆成独立DTO类，最小化暴露面，只保留真正需要恢复的属性。
5.3 给审计人员的建议：怎么快速定位反序列化风险点
最后说点审计实战。我做代码审计时定位反序列化风险，不会逐行读代码，而是先搜关键字，把候选入口拉出来，再逐个判断数据流。搜的时候重点覆盖：
- unserialize(，然后追参数来源，是请求参数、Cookie还是数据库；
- session_start配合session.serialize_handler的配置，确认读写处理器是否一致；
- phar://，看文件操作函数是否可能带入不可控路径；
- file_exists、getimagesize、md5_file、fopen等文件函数，它们都可能是phar触发点；
- __wakeup、__destruct、__toString、__call、__get等魔术方法定义，尤其是方法体里出现eval、system、call_user_func、include、unlink、file_put_contents的情况。
先找入口，再找出口，两个集合有交集的地方就是高危区。反序列化利用链的构造确实烧脑，但防御侧其实没那么复杂，核心就一句话：永远不要让不可信数据流向反序列化入口。哪怕POP链绕了一百层，只要入口封死，它就无从发挥。
说实话，反序列化这个知识点我前前后后啃了很多遍，每次以为彻底懂了，下一次遇到新花样的POP链还是会被绕晕。印象最深的是有一次在真实业务里排查一起诡异的文件删除故障，最后定位到是第三方日志库的某个类里藏着__destruct触发的unlink逻辑，那一刻我才真正意识到，这类漏洞离业务一点都不远。给你一个最实用的建议：不管是开发还是做审计，先把你项目里所有魔术方法列出来，逐个检查它们操作的对象属性是否有可能被外部影响，这一步做完，你已经比大多数开发者更接近安全了。
