反序列化入口排查怎么做
反序列化问题出现在「把外部数据还原成对象」的地方：Cookie、隐藏表单字段、消息队列消息、缓存值、会话存储。排查目标是入口与防护控制，而不是构造利用链——后者对目标可用性影响大，也极易越界。有效做法是两条线并行：从流量侧找形态可疑的二进制或编码流，从代码侧走查反序列化调用点与数据来源，再看有没有类型白名单与完整性签名。
基本信息
| 入口特征 | Cookie 或参数中出现二进制流、编码流、可疑魔术字节 |
|---|---|
| 代码线索 | Java 的 ObjectInputStream、PHP 的 unserialize 类调用 |
| 防护控制 | 类型白名单、完整性签名、隔离运行环境 |
| 排查方式 | 流量侧抽样 + 代码走查，两侧交叉 |
| 纪律 | 不构造利用链、不下载利用工具验证 |
典型使用场景
- 代码审计中的常见问题类型核查
- 评估会话与缓存数据的完整性保护机制
- 消息队列链路核查：内部通道的序列化数据同样需要防护
- 排查「Cookie 很长且不可读」这类现象的技术背景
- 修复验证：确认已实现类型白名单与签名校验
排查步骤
排查步骤
1. 收集请求中的可疑样本（自有账号）：Cookie、隐藏字段、参数
关注形态：以特定编码开头、长度异常、无法以文本解读
2. 代码走查：定位反序列化调用点与数据来源，确认能否被外部影响
3. 核查防护：是否具备类型白名单、完整性签名与版本校验
4. 检查消息队列与缓存的写入侧：内部数据是否可能被外部构造
5. 输出入口清单与加固建议；不构造利用链验证入口与检查点
| 入口 | 检查点 |
|---|---|
| Cookie 与隐藏字段 | 数据来源是否可信，是否校验完整性 |
| 会话存储 | 会话数据是否可被客户端影响 |
| 消息队列 | 生产者权限与消息来源校验 |
| 缓存值 | 写入路径是否可控，是否做类型校验 |
不要构造或下载利用链验证：该类验证对可用性影响大、破坏性强，且极易越界，排查阶段应止于入口与防护结论。
仅凭请求里出现编码字符串不能判定风险：很多正常的压缩与编码数据也长这样，必须结合代码侧确认是否进入反序列化。