【实战】某博彩资讯站的反序列化RCE

一、故事背景

这次对某博彩资讯站做代码审计与渗透。目标系统提供博彩资讯、赛事数据与投注入口的综合站点，前后端分离架构。后端是 Java 应用，客户提供了源码用于白盒审计。我在拿到授权后，重点审计了反序列化相关代码。反序列化漏洞是 Java 应用的高危漏洞，一旦存在且数据可控，往往能直接实现远程代码执行。

二、信息收集

信息收集阶段，我在源码中搜索了反序列化的调用点。发现有一个接口接收客户端传来的序列化数据，并使用 ObjectInputStream 的 readObject 方法直接反序列化，且没有对类进行白名单过滤。这是反序列化漏洞的典型特征。

三、漏洞发现

我确认了漏洞的可利用性。数据源是客户端可控的请求参数，服务端直接反序列化，没有任何过滤。这意味着攻击者可以构造恶意的序列化数据，利用 Java 的 gadget chain 实现任意代码执行。我进一步分析了应用中使用的依赖库，确认了 CommonsCollections 库的版本可利用。

四、漏洞利用

我使用 ysoserial 工具构造攻击载荷。ysoserial 可以生成 CommonsCollections 系列的反序列化 payload。我选择了 CommonsCollections5 这条链，生成了一段恶意的序列化数据，这段数据在被反序列化时会执行指定的命令。我设置了命令为反弹 shell。

五、权限获取

我把生成的序列化数据编码后发送给目标接口。服务端反序列化时触发了命令执行，我在 VPS 上成功收到了反弹 shell，且是应用运行用户的权限。至此，反序列化 RCE 漏洞被完整利用。我随后整理了详细的审计报告和利用过程。

六、复盘总结

这次渗透的根因是反序列化数据未做安全过滤。修复建议：第一，尽量避免使用 Java 原生反序列化，改用 JSON 等安全的数据格式；第二，如果必须使用反序列化，必须做类白名单过滤，使用 ObjectInputFilter 限制可反序列化的类；第三，升级存在 gadget chain 的依赖库到安全版本；第四，对反序列化接口做严格的身份认证和来源限制。

本文为授权安全评估实录，目标均已脱敏（IP 为文档保留段），仅用于安全研究与学习交流。