PHP反序列化漏洞的另类利用：从0CTF真题看where重复触发替换的妙用

PHP反序列化漏洞的另类利用从0CTF真题看where重复触发替换的妙用最近在复盘一些经典的CTF题目时我又重新审视了那道来自0CTF 2016的“piapiapia”。这道题之所以让人印象深刻不仅仅是因为它巧妙地结合了序列化与反序列化更在于它揭示了一种在代码审计中极易被忽略的“字符替换偏移”攻击手法。很多安全研究员在初次接触时可能会直奔主题去寻找反序列化POP链的构造但“piapiapia”却另辟蹊径它利用了一个看似无害的过滤函数通过精密的字符计算实现了对序列化字符串结构的精准“外科手术式”覆盖。这种思路跳出了常规的漏洞利用框架更像是一种对程序逻辑和数据处理流程的深度理解与博弈。今天我们就来深入拆解这种“where重复触发替换”的妙用看看如何将防御机制转化为攻击跳板。1. 场景还原从登录界面到源码泄露拿到一个Web题目第一步永远是信息收集。题目呈现一个标准的登录界面尝试基础的SQL注入无果后目录扫描成了突破口。使用dirsearch这类工具时在实战或某些在线靶场如BUUCTF中需要注意请求频率过快可能导致429状态码适当调整延迟参数-x是必要的。扫描结果通常会给出惊喜比如一个www.zip源码压缩包。解压后我们得到了一套完整的PHP应用源码通常包括index.php: 首页/登录页register.php: 用户注册update.php: 信息更新profile.php: 信息展示class.php: 核心类定义config.php: 配置文件通常藏有flag提示config.php中直接包含flag的设定在CTF中很常见这明确了我们的终极目标——读取这个文件的内容。审计流程通常从用户交互的功能点开始。注册一个账户登录后进入信息更新页面update.php这里收集用户的手机、邮箱、昵称和头像。提交后信息会在profile.php页面展示。功能链路清晰漏洞就隐藏在这看似平常的数据流处理中。2. 核心逻辑审计序列化与过滤的致命交汇漏洞的根源往往存在于数据的“输入-处理-存储-输出”链条中。我们重点分析update.php和class.php。在update.php中用户提交的数据经过一系列正则校验手机号必须为11位数字。邮箱符合简化格式校验。昵称只能包含字母、数字、下划线且长度不超过10。头像文件大小限制在5字节到1MB之间。校验通过后数据被组装成一个数组$profile然后调用$user-update_profile($username, serialize($profile))。这里用户控制的$profile数组被序列化成字符串并传入update_profile方法。update_profile方法位于class.php或其继承的类中是关键所在。它通常包含两个操作过滤Filter: 对传入的用户名和序列化后的字符串进行过滤。更新数据库Update: 将过滤后的值更新到数据库中。我们来看一个典型的、存在问题的filter函数实现public function filter($string) { $escape array(\, \\\\); $escape / . implode(|, $escape) . /; $string preg_replace($escape, _, $string); $safe array(select, insert, update, delete, where); $safe / . implode(|, $safe) . /i; return preg_replace($safe, hacker, $string); }这个函数做了两件事将单引号和反斜杠替换为下划线防SQL注入。将一些SQL关键字select,insert,update,delete,where不区分大小写地替换为字符串hacker。而update函数则是简单地拼接SQL语句并执行。在profile.php中流程反向进行从数据库取出序列化字符串直接进行unserialize()操作然后将数组中的photo字段值作为文件路径用file_get_contents读取并base64编码输出。至此攻击面变得清晰我们能否构造一个特殊的序列化字符串经过filter函数“处理”后在反序列化时改变其结构使得photo字段指向config.php3. 漏洞原理字符替换引发的“溢出”常规的反序列化漏洞利用侧重于寻找类中的魔术方法如__wakeup,__destruct并构造POP链。但本题的类非常简单没有这些魔术方法。我们需要换一种思路利用序列化字符串本身的格式特性。一个序列化数组的格式是严格定义的例如a:4:{i:0;s:3:123;i:1;s:3:abc;i:2;s:4:4567;i:3;s:4:defg;}其中s:4:defg表示一个长度为4的字符串defg。反序列化器会严格按照这个格式和指定的长度来解析数据。如果我们能篡改序列化字符串中表示长度的数字或者让解析器错误地识别字段边界就能实现越权读取。本题的突破点在于filter函数中的preg_replace。preg_replace在进行字符串替换时如果匹配到的子串长度与被替换成的字符串长度不同就会导致整个字符串的长度发生变化。例如将where5个字符替换为hacker6个字符字符串总长度增加1。假设我们构造的昵称nickname在序列化后是s:10:xxxxxxxxxx。如果xxxxxxxxxx内部包含一个where经过filter后变成hacker那么实际存储的字符串变成了s:10:xxxhackerxxx假设替换发生在中间。但注意序列化字符串中记录的长度s:10并没有改变当profile.php从数据库取出这个字符串进行反序列化时解析器仍然认为nickname字段是一个长度为10的字符串。它会从s:10:后面的双引号开始读取10个字符作为值。如果因为替换导致有效内容变长那么多出来的字符以及其后的字符就会被“挤”到下一个字段的解析空间中从而可能破坏整个序列化结构实现字段值的覆盖。这就是“字符替换偏移”攻击的核心通过精心控制输入使过滤操作引入确定的长度变化从而精准地偏移后续数据的解析起点达到篡改反序列化对象结构的目的。4. 利用链构造精确计算与“where”的狂欢理论有了如何实践目标是让photo字段的值在反序列化后变成config.php。原始序列化字符串结构大致如下a:4:{s:5:phone;s:11:13800138000;s:5:email;s:15:testexample.com;s:8:nickname;s:10:your_nick;s:5:photo;s:22:upload/md5_filename.jpg;}我们需要在nickname字段的值部分做文章使其经过filter替换后尾部溢出的字符恰好能闭合当前对象并重新定义photo字段。由于nickname有长度限制strlen($_POST[nickname]) 10直接传入很长的恶意字符串是不行的。但这里存在一个常见绕过strlen()对数组返回的是元素个数而非字符串长度。如果以数组形式提交nickname例如nickname[]payloadstrlen()检查会失效。序列化一个数组和序列化一个字符串格式不同这需要我们调整payload结构。更关键的是长度计算。我们需要让nickname字段原始序列化后的值部分即双引号内的内容在经过filter把其中所有where替换为hacker后整体长度增加的量刚好等于我们想要“注入”的恶意payload的长度。设N 我们需要注入的payload长度例如闭合结构并定义新photo的字符串长度。R 每出现一次where被替换为hacker所增加的长度6 - 5 1。那么我们需要在nickname的值中重复写入where的次数X ≈ N / R。例如我们的恶意payload可能是;}s:5:photo;s:10:config.php;}计算这个字符串的长度注意引号和分号都是字符 1; 1} 1s:5:photo; 12s:10:config.php; 17} 1 总长度 11112171 33。注意由于我们将nickname作为数组提交序列化格式不同可能需要在payload前额外添加一个}来闭合外层的数组结构因此实际payload可能为}s:5:photo;s:10:config.php;}长度需要重新计算。假设最终计算出的所需增长长度为34。那么我们需要在nickname数组的某个元素值中填入34个where因为每替换一个增加1个字符长度紧接着就是我们的payload。像这样wherewherewherewhere...34个where;}s:5:photo;s:10:config.php;}当这个字符串被序列化作为数组的一个元素值并经过filter时34个where被替换为34个hacker导致该部分字符串总长度增加34。反序列化器在解析时仍按照原来的较短的长度去读取nickname的值结果就把后面多出来的34个字符即我们的payload当作后续的序列化数据解析了从而成功将photo字段覆盖为config.php。5. 实战演练与脚本化理解了原理手动构造和测试依然繁琐尤其是需要精确计算偏移量时。编写一个简单的Python或PHP脚本来自动化这个过程会高效很多。脚本的核心任务是生成包含精确数量where和恶意payload的原始字符串。模拟filter函数的替换逻辑计算替换后的字符串。生成最终用于提交的HTTP请求数据包。下面是一个概念性的Python脚本示例用于辅助计算和生成攻击载荷#!/usr/bin/env python3 import re def simulate_filter(input_str): 模拟PHP中filter函数的替换逻辑 # 替换单引号和反斜杠本例中可能不影响长度计算但需知晓 # 重点替换SQL关键字 safe_keywords [select, insert, update, delete, where] pattern re.compile(|.join(safe_keywords), re.IGNORECASE) # 注意preg_replace会替换所有非重叠匹配 # 我们模拟将匹配到的词替换为hacker result pattern.sub(hacker, input_str) return result def calculate_required_where_count(payload_len): 计算需要多少个where来产生足够的长度增长 # 每个where(5) - hacker(6)增长1 growth_per_where len(hacker) - len(where) # 需要的增长量应至少等于payload_len # 因为payload是紧跟在where串后面的增长量就是where串整体增长的长度 required_count payload_len // growth_per_where # 确保增长量大于等于payload长度 if (required_count * growth_per_where) payload_len: required_count 1 return required_count # 假设我们最终的恶意payload考虑数组序列化格式后的 # 实际构造时需要根据目标源码的序列化格式微调 malicious_payload ;}s:5:photo;s:10:config.php;} payload_length len(malicious_payload) print(f恶意payload长度: {payload_length}) where_count calculate_required_where_count(payload_length) print(f需要连续写入 where 的次数: {where_count}) # 构造原始字符串 original_value where * where_count malicious_payload print(f\n原始字符串 (替换前):) print(original_value) print(f原始长度: {len(original_value)}) # 模拟过滤后 filtered_value simulate_filter(original_value) print(f\n过滤后字符串:) print(filtered_value) print(f过滤后长度: {len(filtered_value)}) length_increase len(filtered_value) - len(original_value) print(f\n长度增加量: {length_increase}) print(f预期payload起始偏移: {len(where * where_count) length_increase}) # 提示在实际攻击中需要将original_value作为nickname[]数组参数提交在实际操作中我们通过Burp Suite拦截注册或更新信息的请求将nickname参数修改为数组形式nickname[]...并将上述计算出的original_value作为其值。提交后访问profile.php查看页面中头像图片对应的base64数据解码即可得到config.php的内容从而获得flag。6. 防御思考与进阶利用这种漏洞的根源在于对序列化数据进行了不安全的“净化”处理。序列化字符串是一个结构化的数据格式任何在序列化之后、反序列化之前对其内容进行的修改尤其是可能改变长度的替换操作都可能破坏其结构引发不可预料的后果。有效的防御措施包括在序列化前过滤而非序列化后对用户输入的每个字段值进行严格的校验和过滤然后再组装成数组进行序列化。确保进入序列化流程的数据已经是“干净”的。使用安全的序列化格式考虑使用json_encode/json_decode代替serialize/unserialize。JSON格式同样可读且没有PHP序列化格式的复杂特性受这类替换操作影响的风险较低。签名或加密序列化数据对序列化后的字符串进行HMAC签名或加密。在反序列化前验证签名或解密。任何对序列化字符串的篡改都会导致验证失败。避免将用户可控数据直接反序列化如果可能使用数据库字段单独存储各个用户属性而不是存储整个序列化字符串。对“替换”操作保持警惕在安全过滤函数中如果必须进行字符串替换尽量确保替换前后字符串长度一致或者充分评估长度变化对后续处理逻辑尤其是格式解析逻辑的影响。进阶利用思路“where重复触发替换”只是这类漏洞的一个具体表现。其本质是“字符串操作导致的解析歧义”。在其他场景中也可能出现str_replace的多次替换如果替换是递归或多次进行的计算会变得更复杂。字符编码转换例如某些过滤或处理过程中发生的字符集转换可能使多字节字符长度发生变化。其他结构化数据的解析如XML、YAML、特定格式的日志文件等如果解析前进行了字符串替换也可能引发类似问题。审计时需要关注任何先序列化或格式化后处理再反序列化或解析的数据流。重点检查处理函数是否可能改变数据的长度或结构。7. 工具与资源延伸对于希望深入研究此类漏洞和CTF Web题目的朋友除了手动审计和编写PoC还可以利用一些优秀的工具和资源工具/资源名称类型主要用途/特点PHPGGC漏洞利用框架生成PHP反序列化漏洞的POP链利用载荷适用于存在魔术方法利用的场景。Burp Suite 插件渗透测试工具链Burp Suite用于拦截、重放、测试HTTP请求。搭配PHP Object Injection Check等插件辅助检测。dirsearch / gobuster目录扫描工具快速发现源码泄露、备份文件、隐藏目录等是Web渗透的信息收集第一步。SecLists字典集合包含大量的路径、文件名、参数名字典用于FUZZ和扫描。在线PHP代码执行环境测试平台在隔离环境里快速测试PHP代码片段、序列化/反序列化结果验证思路。理解漏洞原理始终是关键。工具能提高效率但无法替代对代码逻辑的深入分析。像“piapiapia”这道题考验的正是审计者能否跳出常规思维发现数据在流动过程中那些微妙的、会产生累积效应的变化点。这种利用过滤函数自身特性来“锻造”攻击载荷的手法充满了技巧性和艺术性也再次印证了安全领域那句老话有时最坚固的防线其弱点恰恰在于它自身。