一个阳光灿烂的冬日清晨，我一如既往地躲在被窝里刷着手机。突然，freebuf公众号头条的一篇文章吸引了我：那些FastJson漏洞不为人知的事情（开发角度）

https://www.freebuf.com/articles/web/258827.html

哇塞，这标题，一看就是大佬的力作！

但是看着看着，这文章感觉不对啊，当中的许多观点都是“颠覆性的创新”，完全改变了我对fastjson漏洞的认知！难道我之前学的都是错的？

所以抱着大胆假设，小心求证的科（杠）学（精）精神，对该文中的一些观点进行探究。

注：本文中的观点仅做纯事实的研究和讨论，不针对任何组织和个人，与本人所代表的本人无关~

OK，Let’s go!

1 fastjson漏洞的利用条件到底是啥

在文章中，作者是这样描述fastjson反序列化漏洞的利用条件的：

这之一个条件就让我产生了很多问号：

Fastjson的漏洞修复史相信各位师傅早已烂熟于心：1.2.25之前默认打开autotype，1.2.48修复了缓存的全局map的问题，1.2.68增加safeMode，1.2.69修复了由于expectClass而产生的autoType绕过。

至于这里为啥给了一个<=1.2.47的条件，嗯，我也不知道为啥。

不过好在第二条还是很合理，这个fastjson的反序列化 *** 确实是一切开发噩梦的“万恶之源”（此处省略开发同学的头发100根），也是安全人员保住饭碗的三大支柱之一啊！

2 达成这个漏洞到底难不难

在文中，作者是这么对漏洞进行定性的：

然后作者接着对@RequestBody这个注解进行了分析。这块内容确实分析地很细致，想学习SpringBoot自动反序列化的同学可以认真看一下。在一通猛如虎操作之后，作者得到了结论：

天呐，Jackson的漏洞是多么的危险啊！但此时我的内心是这样的：

毕竟Jackson每年的反序列化漏洞的数量，那可是和fastjson一时瑜亮，堪比卧龙凤雏，难分高下啊~

言归正传，SpringBoot默认是使用Jackson来进行反序列化，这点从官方文档中是可以找到的：

并且在搭建项目时，通过maven引入spring-boot-starter-web后，可以看到其依赖结构中自动引入了Jackson-databind：

所以对于这个问题：

我猜项目经理应该说的是：Spring里边都有Jackson了，你还拿个fastjson过来干啥？

不过既然Jackson是Spring Boot默认（推荐）的反序列化工具，那我们是不是就可以不接受它的推荐，让@RequestBody这个注解用fastjson来进行反序列化呢？说干就干~

根据SpringBoot文档7.1.2中的指示，我们可以通过使用自定义HttpMessageConverter的方式来替换默认的Http Request和Response转换 *** （即反序列化和序列化 *** ）：

我们先把SpringBoot里边自带的Jackson给去掉，然后加上我们所需要的fastjson：

然后根据文档创建一个配置：

这段代码中我们创建了一个FastJsonHttpMessageConverter，这是fastjson为了适配SpringBoot框架所写的一个转换器，接着我们设置编码为UTF-8，设置数据类型Content-Type为application/json。

然后我们写一个简单的用户类：

再来一个添加用户的Controller：

然后使用postman发包进行调试：

我们可以看到系统自动调用了fastjson的 *** ON.parseObject *** ：

可以看到我们的报文成功返回了，说明反序列化成功！

以上的实验证明：

1 我们可以通过简单配置实现fastjson在springboot框架中对于jackson的替换。

2 在替换过程中、及后续的反序列化过程中，不必显示调用fastjson中的 *** ON.parseObject *** 。

3 到底该怎么发现fastjson漏洞

在文中作者提出了通过全文搜代码来发现漏洞的 *** ：

个人觉得这个 *** 还是有一定效果的，但是如果说仅仅依赖这个搜索就判定不受漏洞影响，这并不完整，很容易被攻击者骗、被攻击者偷袭。

原因在上一节中我们已经说了一部分，因为我们可以替换默认 *** ON解析工具。那么在使用@RequestBody注解时，实际调用的 *** 就变成了fastjson的 *** ON.parseObject()。

另外还有的是， *** ON.parseObject()这个 *** 虽然是反序列化的核心 *** ，但是有时候开发人员并不会直接调用它，而是根据业务情况和个人习惯调用一些其他 *** ，比如： *** ON.parse()或者 *** ON.parseArray()等。再考虑到一些反射调用的情况。想要最完整地发现相关调用链，还是要通过动态分析来发现。所以目前最安全的方式还是通过升级版本或者打开safeMode来实现。

4 总结

学习使我快乐~