[特殊字符] 一次经典Web漏洞复现：修改序列化对象直接提权为管理员（附完整步骤）

💡 本文通过一个实验靶场，演示如何因为不安全的序列化机制 ，导致普通用户可以直接修改 cookie，伪造管理员身份并删除其他用户。这类漏洞在一些老系统、PHP 项目和不规范框架中仍然很常见。

一、漏洞背景：什么是"序列化对象"？

在 Web 系统中，我们经常需要保存用户状态，比如：

是否已登录
用户名
是否为管理员

一些开发者为了方便，会把对象直接 serialize() 序列化，然后存在：

✔ cookie

✔ session token

✔ URL 参数

例如（PHP）：

php 复制代码

O:5:"User":2:{s:5:"admin";b:0;s:4:"name";s:6:"wiener";}

其中：admin = b:0 表示 false（普通用户）

❗漏洞发生的关键点

⚠ 如果这个序列化对象是放在客户端的，并且没有做完整性校验

那么我们可以直接修改它：

把：b:0 改成：b:1

👉 系统就相信你是 管理员。

二、实验环境与账号

靶场链接：https://portswigger.net/web-security/deserialization/exploiting/lab-deserialization-modifying-serialized-objects

portswigger靶场提供普通用户账号：靶场提供：用户名：wiener 密码：peter

登录之后进入：/my-account

浏览器会生成如上图所示一个 session cookie

看上去像一串乱码，其实是：👉 URL + Base64 编码后的数据

在 Burp Suite 中打开请求，使用 Inspector 查看 cookie。

解码后内容如下：

a:2:{ s:5:"admin";b:0; s:4:"name";s:6:"wiener"; }

解释一下：

字段	含义
admin	是否管理员
b:0	false（不是管理员）

📌（这里可以放上第一张截图：Inspector 解码后页面）

四、修改序列化对象 → 变成管理员

把请求发送到 Repeater ，找到 cookie 中的 admin 字段：

复制代码

上图b:0 修改为：b:1

Burp 会帮我们：

✔ 自动重新序列化

✔ 自动重新 Base64 编码

✔ 自动更新 cookie

点击 Send 。

五、结果：后台管理入口出现

这说明：

系统已经认为当前用户是管理员。

六、进入后台并删除用户 carlos

访问：/admin

后台里有一个"删除用户"的接口，我们直接请求：

/admin/delete?username=carlos

请求发送后：

✔ carlos 用户被删除

✔ 实验完成

七、漏洞原理总结（非常适合考试/面试）

🎯 漏洞本质：客户端可控的序列化对象 + 存在敏感权限字段 + 缺乏签名校验

系统错误地相信：

"只要 cookie 里写的是 admin=true，那一定是真的用户"

属于典型的：

✔ 权限提升（Privilege Escalation）

✔ 业务逻辑漏洞

✔ 不安全序列化

八、安全开发防护建议（这一段加分）

安全做法应该是：

1️⃣ 不在客户端存敏感权限信息

管理员判断，必须：

✔ 服务端 session

✔ 数据库重新查询

2️⃣ 即使必须放客户端，也要：

对数据 加签（HMAC）
校验完整性
禁止用户直接篡改

3️⃣ 避免使用 serialize() 直接持久化对象

尤其在：

PHP
Java
Python pickles

九、结语

这个实验虽然简单，但意义很大：

🛑 只要系统把"是否管理员"这种敏感信息交到客户端，我们就可以控制整个系统。

希望通过这篇文章：

✔ 你理解了序列化对象为何危险

✔ 知道了如何发现类似漏洞

✔ 也能在项目中提醒开发避免这种设计