PHP 8.0.20 不支持 unserialize() 白名单机制，因 allowed_classes 参数直到 PHP 8.4.0 才引入；必须改用 json_decode()、手动类名预检、禁用危险魔术方法或升级至 8.4.27/8.5.12。
PHP 8.0.20 不支持反序列化白名单机制。该版本发布于2021年，远早于PHP官方引入unserialize()安全控制的任何内置白名单功能。
PHP直到8.4.0（2024年12月发布） 才首次引入 unserialize() 的 allowed_classes 参数增强支持（配合 unserialize() 第二个参数数组），而真正具备生产级白名单能力、并默认禁用危险类的机制，是在 PHP 8.5.0（2025年12月） 中通过 unserialize() 的 allowed_classes 严格模式 + __unserialize() 钩子校验 + unserialize_callback_func 拦截共同构成的防御体系。
因此，在 PHP 8.0.20 环境下：
-
unserialize()没有原生白名单参数 -
allowed_classes选项在 8.0.x 中完全不存在（会报致命错误或被忽略） - 所有依赖
__wakeup()或魔术方法的反序列化行为都处于高风险裸奔状态
必须采用的替代防护策略
使用
json_decode()替代unserialize()处理外部数据
只要业务逻辑允许，将序列化格式统一改为 JSON。它天然不可执行代码，无反序列化漏洞面。若必须用
unserialize()，需手动实现类名过滤
在调用前对原始字符串做预检，提取类名（正则匹配O:开头的序列化对象结构），再比对硬编码白名单：
function safeUnserialize(string $data, array $allowedClasses): mixed {
if (preg_match('/O:\d+:"([^"]+)":/', $data, $matches)) {
if (!in_array($matches[1], $allowedClasses, true)) {
throw new InvalidArgumentException('Disallowed class: ' . $matches[1]);
}
}
return unserialize($data);
}⚠️ 注意：该正则仅覆盖标准对象序列化，无法防御 C:（自定义反序列化）、a:（数组嵌套触发 gadget）等复杂变体，属于基础防护，非银弹。
立即学习“PHP免费学习笔记（深入）”；
- 禁用危险类的自动加载与反射调用
在php.ini中设置：zend.enable_gc=1 unserialize_callback_func="my_unserialize_callback"
并定义回调函数拦截未知类：
function my_unserialize_callback($class) {
if (!in_array($class, ['MySafeClass', 'DataTransferObject'], true)) {
throw new Error("Blocked unserialize of class: $class");
}
}- 彻底移除
__wakeup()中的敏感操作
尤其避免在__wakeup()中执行system()、eval()、文件写入、数据库查询等。该方法是反序列化链最常利用的入口点。
为什么不能“合理设置”白名单？
因为 PHP 8.0.20 的 unserialize() 是无钩子、无回调、无上下文感知的黑盒解析器。它不区分来源、不验证签名、不检查类是否已声明——只要字节流格式合法，就直接实例化并触发魔术方法。所谓“白名单”，只能靠你代码层前置拦截，且极易被绕过（如利用 Exception 子类、ArrayObject gadget、或未列入白名单但可触发危险行为的标准库类）。
最务实的建议
立即升级 PHP 版本至 8.4.27 或 8.5.12（二者均为当前安全基线，含 php2shell 漏洞修复）
-
升级后启用现代反序列化防护：
$data = unserialize($input, [ 'allowed_classes' => ['App\Models\User', 'App\DTO\Config'], 'max_depth' => 3, ]); 对遗留系统无法升级的场景，禁止接收任何用户可控的序列化数据，改用签名+JSON方案（如 JWT payload + HS256 校验）。
不复杂但容易忽略：PHP 8.0.20 已停止维护近三年，连基础安全补丁都不再提供。所谓“白名单设置”，本质是在沙盒里修裂缝——而沙盒本身早已失效。
