当前位置：首页 > news >正文

PHP反序列化漏洞实战：从魔术方法到文件包含与协议利用

news 2026/6/23 10:10:39

1. 项目概述：从靶场到实战的PHP反序列化漏洞通关手册

最近在复盘CTFshow F5杯的“eazy-unserialize”系列题目，这两道题可以说是把PHP反序列化漏洞的经典利用链和进阶玩法串了个遍。从最基础的魔术方法触发，到利用__destruct或__wakeup作为跳板，再到结合文件包含（File Inclusion）和PHP内置协议（PHP Wrappers）进行深度利用，整个过程就像在搭一个精密的多米诺骨牌。很多刚接触Web安全的朋友，一看到反序列化就头疼，觉得概念抽象、利用链复杂。其实，只要你把几个关键“机关”的位置和触发顺序搞明白，剩下的就是按图索骥的“组装”工作。这篇文章，我就以这两道题为蓝本，拆解从漏洞发现到最终利用的完整链条，并重点分享在文件包含与协议利用环节那些容易踩坑的细节。无论你是正在打CTF的赛棍，还是想夯实Web安全基础的开发者，这篇避坑指南都能帮你把这条路走通、走顺。

2. 核心漏洞原理与CTFshow题目环境搭建

2.1 PHP反序列化漏洞的本质：对象重建与魔术方法

要利用漏洞，先得明白漏洞从哪来。PHP反序列化函数unserialize()的作用，是将一个序列化后的字符串，还原成一个PHP值（通常是对象）。这个“还原”过程，就潜藏着风险。序列化字符串里包含了对象的类名、属性及其值。当unserialize()处理一个包含对象数据的字符串时，PHP需要根据类名去找到对应的类定义，并实例化一个对象，然后把属性值填进去。

关键在于，PHP中有一类特殊的函数，叫做魔术方法（Magic Methods）。它们在对象生命周期的特定时刻会被自动调用。与反序列化漏洞最相关的几个是：

__wakeup(): 当unserialize()函数成功还原一个对象后，如果该对象的类中定义了此方法，则会立即自动调用。常用来重新建立数据库连接或初始化资源。
__destruct(): 当对象被销毁时（如脚本执行结束、对象被unset或没有引用指向它时）自动调用。这是最常用的“跳板”之一，因为它的触发相对确定。
__toString(): 当一个对象被当作字符串处理时（如echo $obj）自动调用。

漏洞的根源就在于，攻击者可以构造一个恶意的序列化字符串。当这个字符串被unserialize()还原时，攻击者可以控制对象的属性值。如果这个对象的类（或者其继承的父类、使用的特质）中，存在上述魔术方法，并且这些方法中的代码使用了对象属性，那么攻击者就能通过控制属性值，来影响这些代码的执行流程，最终可能实现任意代码执行（RCE）、文件操作等危害。

举个例子，假设一个类FileHandler有一个__destruct方法会删除$this->filename指定的文件。如果$filename属性用户可控，那么攻击者通过反序列化传入一个filename为../../../etc/passwd的对象，就可能造成任意文件删除。

2.2 CTFshow F5杯“eazy-unserialize”场景复现

CTFshow的题目通常会把漏洞场景模拟得非常清晰。“eazy-unserialize”的第一题，往往是一个直接的反序列化入口。你可能看到一个接收data参数的接口，代码逻辑大致如下：

<?php highlight_file(__FILE__); class Welcome{ public $name; public $arg; function __wakeup(){ $this->name = "Welcome to CTFshow!"; } function __destruct(){ echo $this->name; } } if(isset($_GET['data'])){ $data = $_GET['data']; unserialize($data); } else { $w = new Welcome(); $w->name = "Hello"; echo serialize($w); } ?>

这段代码提供了一个“示例输出”和漏洞入口。我们的目标通常是利用__destruct或__wakeup方法。但这里有个小坑：__wakeup在反序列化后立刻执行，它会将$name强制改为固定字符串，覆盖了我们传入的值。所以，直接利用__destruct中的echo $this->name似乎行不通，因为name已经被改了。

第一个避坑点：绕过__wakeup在PHP版本小于5.6.25或7.x小于7.0.10的特定环境下，存在一个CVE-2016-7124漏洞。当序列化字符串中，表示对象属性数量的值（大括号内的那个数字）大于实际属性数量时，__wakeup()方法将不会被执行。这是早期CTF中常见的绕过技巧。虽然现代环境已修复，但靶场为了教学常会复现此环境。对于本题，我们可以构造：O:7:"Welcome":2:{s:4:"name";s:10:"HackedName";s:3:"arg";N;}注意这里的2，而类中实际只有$name和$arg两个属性，但我们将数量写为2（在某些特定版本下，大于2才有效，这里需根据环境测试），可能触发绕过，使得__wakeup失效，__destruct中输出的就是我们传入的HackedName。

但这只是热身。真正的挑战在于，如何从一个简单的echo或属性操作，跳转到更有危害的操作，比如文件包含。

3. 利用链构造：从反序列化到文件包含的桥梁

3.1 寻找POP链的入口与跳板

单一的类往往很难直接完成利用。我们需要寻找一条“属性到属性”的调用链，即POP链（Property-Oriented Programming）。核心思路是：控制A对象的属性a，使其值为B对象。当A的魔术方法（如__toString）被触发时，它可能会对属性a进行操作（比如echo $this->a），而如果$this->a是一个B对象，那么触发B对象的__toString方法，从而将执行流导向B类。

在“eazy-unserialize”的第二题或更复杂的场景中，题目可能会提供多个类，或者暗示存在其他可用的内置类（PHP Native Classes）。

关键步骤：

审计源码：寻找所有定义了__wakeup、__destruct、__toString、__call、__get、__set等魔术方法的类。
分析敏感操作：在这些魔术方法中，寻找诸如include($this->file)、file_get_contents($this->url)、system($this->cmd)、eval($this->code)等函数调用。这些是理想的目标终点。
连接调用链：如果终点（如include）所在的类无法直接从我们的入口点触发，就需要寻找中间类。例如，入口类A的__destruct中有echo $this->obj，而$this->obj可以被我们控制为类B的对象。类B的__toString方法中恰好有include $this->file。这样，链子就形成了：unserialize->A::__destruct->echo $this->obj->B::__toString->include($this->file)。

3.2 利用内置类与文件包含漏洞

当题目没有提供明显包含文件操作函数的类时，我们需要转向PHP的内置类。一个著名的利器是SplFileObject类。但这个类通常用于读取文件，我们需要的是包含并执行PHP代码。这时，就需要结合文件包含漏洞。

假设我们通过POP链，最终能控制一个include或require语句的参数（$this->file）。这就是一个本地文件包含（LFI）漏洞。单纯的LFI可以读取源码，但要执行代码，我们需要让被包含的文件内容是有效的PHP代码。

经典利用方式：结合文件上传

如果网站存在图片上传功能，我们可以上传一个内容为<?php phpinfo();?>的图片文件（如shell.jpg）。
通过LFI漏洞，包含这个上传的图片文件。因为include会将被包含文件的内容当作PHP代码来解析（只要该文件被PHP引擎处理），从而执行我们的代码。
在CTF中，上传点可能被限制，但有时可以通过日志文件注入或PHP内置协议来绕过。

4. 协议利用的魔法：php://filter与php://input

这是PHP反序列化结合文件包含中最强大、也最容易出错的环节。PHP提供了一系列封装协议（Wrappers），允许以流的方式访问各种数据源。

4.1 php://filter 的读取与编码转换

php://filter是一个元封装器，设计用于数据流打开时的筛选过滤应用。在文件包含中，它主要有两大用途：

1. 读取源码（绕过死亡代码）当网站使用include包含文件，但被包含的文件内容被直接echo出来（而不是作为代码执行）时，我们可以用php://filter来读取其源码。例如，题目包含?file=index.php，但输出的是渲染后的HTML。我们可以尝试：?file=php://filter/read=convert.base64-encode/resource=index.php这个路径会让PHP先读取index.php文件的内容，然后经过convert.base64-encode过滤器进行Base64编码，最后输出。这样我们就得到了Base64编码后的源码，解码即可查看。这在CTF中常用于读取关键配置文件、数据库连接信息或flag位置。

2. 构造可执行的有效载荷更巧妙的用法是，我们可以利用过滤器链，将一个非PHP文件（甚至是我们输入的字符串）转换成包含有效PHP代码的“文件流”，然后被include执行。

例如，我们有一个可控的$file变量被include($file)。我们可以传入：php://filter/read=convert.base64-decode/resource=data://,PD9waHAgc3lzdGVtKCdjYXQgL2ZsYWcnKTs/Pg==这里嵌套了data://协议和convert.base64-decode过滤器。data://,PD9waHA...是<?php system('cat /flag');?>的Base64编码。read=convert.base64-decode会先对这个Base64字符串进行解码，还原出原始的PHP代码。当这个解码后的流被include时，其中的PHP标签和代码就会被执行。

避坑重点：过滤器链的拼接与顺序php://filter可以串联多个过滤器，格式为/read=filter1|filter2|filter3/resource=...。过滤器的执行顺序是从左到右。例如，你想先压缩再Base64编码，顺序就是zlib.deflate|convert.base64-encode。顺序错了会导致数据无法被正确解析。在构造复杂Payload时，务必理清数据处理流程。

4.2 php://input 的直接代码执行

php://input是一个只读流，用于访问请求的原始数据（即HTTP POST请求的body部分）。当allow_url_include配置为On时（CTF靶场常为此设置），它可以被include或require。

利用方式：

发送一个POST请求。
将请求的URL参数设置为?file=php://input。
在POST Body中直接写入要执行的PHP代码，例如<?php system('ls /');?>。

当include遇到php://input时，它会去读取POST Body的内容，并将其作为PHP文件内容来执行。这是一种非常直接的代码执行方式，无需任何文件落地。

避坑重点：allow_url_include与allow_url_fopen
allow_url_include：必须为On，才能include远程文件或php://input这类流。这是最关键的一环。
allow_url_fopen：通常也需要为On，它影响fopen等函数对URL的打开能力，部分流包装器的使用也依赖于此。在实战或CTF中，如果发现php://input利用失败，首先应该检查这两个配置。可以通过phpinfo()页面或利用已有的文件包含读取/proc/self/environ（Linux）等方式来获取PHP配置信息。

5. 完整实战演练与Payload构造

让我们串联一个从CTFshow题目中抽象出的完整场景：

入口点：存在unserialize($_GET['data'])。

可利用类：

class VulnClass { public $cache_file; function __destruct() { include($this->cache_file); } } class Helper { public $handle; function __toString() { return $this->handle->getContents(); } }

目标：执行系统命令读取/flag。

步骤1：分析链子VulnClass::__destruct中有include，是理想终点。我们需要让$cache_file的内容被当作PHP代码执行。Helper::__toString本身不危险，但它可以作为一个跳板。如果我们能让某个echo或字符串操作触发Helper对象的__toString，并且我们能控制$handle，或许能将其指向一个包含代码的流。

步骤2：构造POP链假设题目中还有一个Logger类，其__destruct会echo $this->msg。我们可以构造：

$logger = new Logger();
$logger->msg = new Helper();// 触发Helper::__toString
但Helper::__toString只是返回$handle->getContents()，这需要$handle是一个有getContents方法的对象。我们可以尝试使用内置类SplFileObject，但它读取的是文件内容，不是代码执行。
更直接的思路：我们能否直接控制VulnClass的$cache_file？但入口点是unserialize，我们需要先实例化VulnClass。如果代码中同时存在VulnClass和Logger，我们可以让Logger->msg设置为一个VulnClass对象吗？不行，因为echo一个对象会触发其__toString，而VulnClass没有__toString，会报错。

步骤3：简化利用（假设可以直接触发VulnClass）如果我们能直接让unserialize生成一个VulnClass对象，并控制其$cache_file属性，那么问题就简化为：如何让include($this->cache_file)执行任意代码。

方案A（文件上传）：上传shell.jpg（内容为<?php system($_GET[‘c’]);?>），然后设置$cache_file为上传文件的路径，如/var/www/html/uploads/shell.jpg。访问时带上?c=cat /flag。
方案B（php://input）：设置$cache_file为php://input。在发送序列化数据的同时，在POST Body中写入<?php system(‘cat /flag’);?>。
方案C（php://filter + data://）：设置$cache_file为php://filter/read=convert.base64-decode/resource=data://,PD9waHAgc3lzdGVtKCdjYXQgL2ZsYWcnKTs/Pg==。

步骤4：构造最终Payload假设我们可以直接序列化VulnClass：

$exp = new VulnClass(); $exp->cache_file = ‘php://input’; echo urlencode(serialize($exp)); // 输出：O%3A9%3A%22VulnClass%22%3A1%3A%7Bs%3A10%3A%22cache_file%22%3Bs%3A11%3A%22php%3A%2F%2Finput%22%3B%7D

发送请求：

GET /vuln.php?data=O%3A9%3A%22VulnClass%22%3A1%3A%7Bs%3A10%3A%22cache_file%22%3Bs%3A11%3A%22php%3A%2F%2Finput%22%3B%7D POST Body: <?php system(‘cat /flag’);?>

6. 常见问题排查与防御建议

6.1 实战中可能遇到的坑

Payload提交后无回显：
- 检查协议：确认使用的是http://还是https://，靶场环境可能不支持https。
- 检查编码：序列化字符串中的字符计数必须精确。例如，s:4:“name”表示一个长度为4的字符串name，多一个少一个空格都会导致反序列化失败。使用serialize()函数生成最保险，手动构造时务必小心。
- 检查魔术引号：虽然现代PHP已移除magic_quotes_gpc，但一些老旧环境或特殊配置可能过滤了引号。确保Payload中的引号是正常的，必要时使用URL编码。
- 查看错误信息：开启display_errors（CTF中有时会开启）或尝试触发一个警告来获取路径信息。
文件包含失败：
- 路径问题：使用绝对路径还是相对路径？include的相对路径是基于当前工作目录，还是包含文件的目录？在Web中通常是基于当前执行脚本的目录。多用../进行目录遍历尝试。
- 文件后缀限制：代码中可能有include($file . ‘.php’)这样的拼接。这时需要利用空字节截断（%00，仅PHP<5.3.4有效）或路径长度截断（超长路径）来绕过，但现代PHP版本已修复。更通用的方法是利用协议封装器，因为php://filter/...后面不跟后缀名。
- allow_url_include为Off：这是最硬性的限制。如果为Off，则php://input和远程URL包含均无效。此时只能寻找真正的文件上传点或利用本地文件（如日志、Session文件）注入PHP代码后再包含。
POP链构造复杂，找不到头绪：
- 使用工具辅助：对于已知框架（如Laravel, ThinkPHP, Yii等）的反序列化链，已有成熟的工具如phpggc可以生成Payload。对于代码审计，可以寻找自动化的POP链挖掘工具或插件。
- 从终点反向推导：先找到包含eval、system、include等危险函数的方法，然后看哪些魔术方法能调用到这个方法，或者能操作这个类的对象，一步步回溯到入口点。

6.2 给开发者的防御建议

永远不要反序列化不可信数据：这是根本原则。如果业务必须使用序列化，考虑使用JSON等更安全的格式。
使用安全的反序列化函数：PHP的unserialize()本身不安全。如果可能，使用json_decode()。对于对象持久化，可以考虑使用__sleep和__wakeup方法进行严格的属性白名单校验。
实施严格的输入过滤：如果无法避免使用unserialize，确保输入数据来自可信源，并在反序列化前进行严格的格式和签名验证。
禁用危险函数和协议：在生产环境中，将allow_url_include和allow_url_fopen设置为Off。在php.ini的disable_functions中禁用eval、system、exec、shell_exec等危险函数。
及时更新和打补丁：保持PHP版本和所用框架、库的最新状态，及时修复已知的反序列化漏洞（如ThinkPHP, Laravel, WordPress插件中的相关漏洞）。
进行代码审计：在代码中搜索unserialize函数，检查其参数是否用户可控。审计所有魔术方法，确保其中没有将对象属性不加校验地传递给危险函数。