Fastjson反序列化漏洞,我踩过的那些坑（血泪经验分享）
哎,兄弟们，今天想跟你们唠唠Fastjson反序列化这个事儿，说真的，我刚开始接触Java安全的时候，压根没把这玩意儿当回事，心想不就是个JSON解析库吗？能有多大事儿？结果呢，现实狠狠给了我一个大嘴巴子，真疼啊！
那段被Fastjson支配的日子
记得那是去年秋天,我接手了一个老项目的代码审计，打开pom.xml一看，好家伙，Fastjson 1.2.24版本，乖乖，这版本号看得我眼皮直跳，你们可能不知道，这个版本简直就是漏洞界的“活化石”啊！我当时心里就咯噔一下，有种不祥的预感。
果不其然,在某个用户登录接口里，我看到了JSON.parseObject(request.getParameter("data"), User.class)这样的代码，我当时那个心情啊，真是又气又笑——这不就是典型的“找死”写法吗？用户的输入直接丢给Fastjson解析，连个过滤都没有，这不是明摆着给黑客递刀子吗？
Fastjson反序列化到底有多可怕？
咱们说话得有理有据,我给你们讲讲原理，Fastjson在解析JSON字符串的时候，支持@type字段指定反序列化的类，这个功能本来是为了处理多态场景设计的，结果却被黑客玩出了花——他们可以通过这个特性，让Fastjson去实例化任意类，然后利用某些类的getter/setter方法里面的逻辑漏洞，实现远程代码执行（RCE）。
唉,说到这儿我就想起前几天看的那个案例，某大厂因为一个Fastjson漏洞，整个内网被打穿，服务器直接被种了挖矿木马，CPU飙到100%，运维半夜被报警短信轰炸，那场面，简直不忍直视啊！
我的亲身经历
其实我自己也栽过跟头,那是一次渗透测试，目标系统用了Fastjson 1.2.47，我先是探测了下版本，用了个经典的payload：
{"@type":"java.lang.Class","val":"com.sun.rowset.JdbcRowSetImpl"}结果对方返回了错误信息,但版本信息泄露了，我又试了绕过高版本的限制，用POC构造了JNDI注入的payload，填了个恶意RMI服务的地址，唉，你们猜怎么着？我这边都准备好庆祝了，结果连接超时了，人家防火墙给拦了。
不过这事儿也让我长了个记性：Fastjson的漏洞利用不是那么简单的，咱们得深入理解它的绕过技巧和防护措施。
防守之道（划重点！）
说到防御,兄弟们一定要记好这几点，我都是用血泪换来的：
-
升级升级升级！ 重要的事情说三遍，目前推荐使用Fastjson 2.x版本，或者直接用Jackson/Gson替代，真的，别拿旧版本在生产环境裸奔了。
-
配置安全拦截：如果非要用Fastjson，记得开启
ParserConfig.getGlobalInstance().addAccept()白名单机制，或者设置Feature.SupportNonPublicField为false。 -
统一异常处理：别把堆栈信息直接返回给前端，那等于把系统的底裤都扒给别人看了。
-
WAF防护规则：把常见的攻击特征啊，比如
@type、JdbcRowSetImpl这些敏感字符串都加进过滤规则里去。
再唠叨几句
唉,做安全这块儿，真的是一步一个坎儿，Fastjson反序列化这个坑，估计还得陪咱们走很长一段时间，我现在每次看到客户的代码里有JSON.parseObject的时候，都会下意识地皱眉头，条件反射了属于是。
好了，今天就分享到这儿吧，如果你也想学习网络安全，对Java安全研究感兴趣，或者想交流渗透测试技巧，都可以加我QQ：123456789（备注：网络安全）。 咱们可以一起探讨Fastjson的进阶利用技巧，也可以聊聊那些年被0day支配的恐惧，毕竟，网络安全的路上，一个人走太孤单了，找个同路人互相搭把手，它不香吗？
这篇文章也是写给我自己的,提醒自己——安全无小事，Fastjson需谨慎啊！兄弟们，共勉！😭💪
