PHP反序列化漏洞白盒审计需聚焦魔术方法中隐藏的敏感函数调用，重点检查__wakeup、__destruct等自动触发方法体内是否含system、eval、file_get_contents等危险操作，并结合AST工具进行sink普查与pattern识别双轴验证，确认属性可控性及函数链可达性。
PHP反序列化漏洞的白盒审计中，敏感函数本身不直接出现在反序列化调用点，但它是整条POP链能否落地执行的关键终点。定位敏感函数，本质是逆向追踪“谁会在反序列化过程中被自动触发、又恰好调用了危险操作”。这和SQL注入里找mysql_query、命令执行里找system逻辑一致，只是触发路径更隐蔽。
重点盯住魔术方法里的危险调用
反序列化不会直接执行任意代码，但它会按需触发特定魔术方法——这些方法就是天然的“入口钩子”。审计时必须逐个检查以下方法体内是否出现危险函数：
-
__wakeup()：反序列化时立即触发，常见于重置连接、重建资源，容易藏
file_get_contents、curl_exec、unserialize（二次反序列化） -
__destruct()：对象销毁时触发，常用于清理工作，但攻击者可控制对象生命周期，使其在脚本末尾强制触发，这里高频出现
system、exec、call_user_func -
__toString()：对象被当作字符串拼接或输出时触发，易配合
echo $obj、print_r($obj)等上下文，内部若调用file_get_contents($this->file)就构成文件读取链 -
__invoke()：对象被当函数调用时触发，如
$obj()，常被用来包装回调逻辑，若参数未过滤，可能导向assert、eval或preg_replace（/e修饰符已废弃，但仍有遗留）
关注非显式调用的“间接危险点”
有些危险行为不靠函数名暴露，而是由语言特性或框架机制隐式引入：
-
动态方法调用：如
$obj->$method_name()，若$method_name来自反序列化数据且未白名单校验，就可能跳转到任意公开方法，包括__call中未设防的反射调用 -
__call / __get / __set 中的反射操作：例如
call_user_func_array([$this, $name], $args)，若$name或$args可控，即可绕过常规函数签名约束 -
类自动加载（__autoload / spl_autoload_register）中的文件包含：若反序列化构造的类名可控，且加载器拼接路径未过滤，可能触发
require或include导致任意文件包含
结合sink普查与pattern识别双轴验证
单靠grep魔术方法名远远不够。真实项目中，危险调用往往分散、嵌套、条件触发。推荐用结构化方式推进：
立即学习“PHP免费学习笔记（深入）”；
- 用AST工具（如tree-sitter + XERJ）普查全部
__wakeup、__destruct等方法定义，并提取其函数体内的所有函数调用——这属于sink轴覆盖 - 同步扫描是否存在
$obj->$x()、call_user_func、unserialize($var)等模式，尤其注意参数是否来自$this->xxx属性——这属于pattern轴补漏 - 对每个命中点，人工确认该属性是否可通过反序列化控制：查看类声明中该属性是否为
public；若为private或protected，确认序列化字符串中是否能正确构造出对应字段名（如"%00*%00cmd"）
别忽略“看起来安全”的函数组合
很多漏洞不是单个函数危险，而是多个普通函数串联后形成攻击面：
-
json_decode($data, true)+unserialize(serialize($arr))：看似只是类型转换，实则可能绕过某些WAF对unserialize的关键词拦截 -
base64_decode()+unserialize()：常见于配置项或缓存字段，base64只是编码层，不改变语义风险 -
gzuncompress()+unserialize()：压缩后再反序列化，同样用于规避简单正则检测
