我第一次在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、值是names: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对象被当成函数调用时等。魔术方法触发时机利用场景__wakeupunserialize执行时反序列化入口点可立即进行方法调用__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参数database64解码后直接进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.readonly0示例代码?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中注入伪造的序列化数据。三种处理器的存储格式差异可以直接看这个表处理器存储格式示例说明phpname|s:5:admin;键名和值用竖线分隔php_binary4位长度键名\0name|s:5:admin;键名前有长度前缀php_serializea:1:{s:4:name;s:5:admin;}整体是标准序列化数组举个例子如果php.ini配置写入时用的是php_serialize但某段业务代码里session_start时指定了session.serialize_handlerphp两种handler处理数据时对“键名|值”分隔的理解不同攻击者可以通过上传文件名等可控输入构造出竖线字符把自己的序列化数据注入到session文件里。之后只要有一个反序列化点会读取session内容就能触发利用。这类问题的防御其实很简单线上环境统一把session.serialize_handler设置为php_serialize不要在业务代码里随意覆盖这个配置。很多框架默认是php处理器如果把服务器配置改了但框架内部又指定了另一个差异就埋下了长期来看都是隐患。5. 防御实践从代码审计到线上加固5.1 入口防御白名单类过滤和allowed_classesPHP 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逻辑那一刻我才真正意识到这类漏洞离业务一点都不远。给你一个最实用的建议不管是开发还是做审计先把你项目里所有魔术方法列出来逐个检查它们操作的对象属性是否有可能被外部影响这一步做完你已经比大多数开发者更接近安全了。