PHP 7.3网站是否存在反序列化漏洞，核心在于确认是否将用户可控输入（如Cookie、GET/POST参数）未经校验直接传给unserialize()；需分步定位反序列化点、检测危险魔术方法、构造payload验证触发行为，并关注__destruct等稳定可利用的钩子。
PHP 7.3 网站是否存在反序列化漏洞，核心验证逻辑是：确认应用是否在未校验的情况下，将用户可控输入（如 Cookie、GET/POST 参数、HTTP 头）直接传给 unserialize() 函数。验证不是靠猜，而是分步定位、构造、触发、观察。
确认反序列化点是否真实存在
先找代码里调用 unserialize() 的位置，重点排查以下常见入口：
- Cookie 值处理（尤其是
PHPSESSID被自定义解析、或存在remember_token类字段） - Session 反序列化场景（如使用
session.serialize_handler=php_serialize但服务端用php方式读取） - POST 或 GET 中名为
data、payload、input、serialized的参数 - 日志、缓存、队列等中间件中被动态反序列化的数据（如 Redis 存储的 session 值）
若无法看源码，可用被动方式试探：向疑似参数提交一个明显非法的序列化字符串（如 O:1:"A":0:{}），观察响应是否报错 Notice: unserialize(): Error at offset 或 Invalid data —— 报错说明该处确实在尝试反序列化。
检查是否有可利用的类和魔术方法
反序列化本身不等于漏洞，关键要看有没有已加载的类定义了危险魔术方法（__wakeup、__destruct、__toString 等），且方法体内执行了敏感操作（如 file_get_contents、system、call_user_func）。验证步骤：
立即学习“PHP免费学习笔记（深入）”；
- 通过错误回显、PHPInfo 或文件读取（如
php://filter）收集网站使用的框架（Laravel、ThinkPHP、Yii）、组件或自定义类路径 - 搜索这些代码中是否包含类似
public function __destruct() { include $this->file; }的逻辑 - 若使用开源项目，直接查对应版本的 CVE（例如 ThinkPHP 5.0.23 有
__destruct触发eval的公开 PoC）
构造并发送可控 payload 进行行为验证
不追求 RCE，先验证是否能控制对象属性或触发预期行为。例如：
- 构造一个基础类实例：
O:4:"User":1:{s:4:"name";s:5:"test";}，提交后观察页面是否输出test或影响业务逻辑（如用户名显示异常） - 若发现某个类的
__toString()方法会拼接并返回$this->log，可构造含log属性的 payload，再让该对象被当作字符串使用（如参与echo $obj或数组json_encode） - 对 PHP 7.3 特别注意：该版本默认禁用
__wakeup在某些继承场景下的调用，但__destruct仍稳定触发；优先测试析构函数路径
观察响应与侧信道信号
成功利用不一定立刻回显命令结果，要关注间接证据：
- HTTP 状态码突变为 500 或响应时间明显延长（可能因
sleep(5)类 payload） - 服务器日志中出现异常文件读取、DNS 请求（如用
system("ping xxx.dnslog.com")） - 响应体中出现预期类名、属性名、或报错信息泄露（如
Fatal error: Uncaught Error: Call to undefined method ...） - 配合 DNSLog、Collaborator 等平台确认外连行为
验证过程务必在授权范围内进行，避免对生产环境造成干扰。发现可疑点后，应立即停止探测，转入修复评估阶段。
