这些FastJson漏洞已经人尽皆知的事情（安全角度）

	一个阳光灿烂的冬日清晨 我一如既往地躲在被窝里刷着手机。突然 有一篇公众号头条的一篇文章吸引了我： 那些FastJson漏洞不为人知的事情（开发角度） 哇塞 这标题，一看就是大佬的力作！ 但是看着看着，这文章感觉不对啊，当中的许多观点都是颠覆性的创新 完全改变了我对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的JSON.parseObject方法： 可以看到我们的报文成功返回了，说明反序列化成功！ 以上的实验证明： 1 我们可以通过简单配置实现fastjson在springboot框架中对于jackson的替换。 2 在替换过程中 及后续的反序列化过程中 不必显示调用fastjson中的JSON.parseObject方法。 3 到底该怎么发现fastjson漏洞 在文中作者提出了通过全文搜代码来发现漏洞的方法： 个人觉得这个方法还是有一定效果的 但是如果说仅仅依赖这个搜索就判定不受漏洞影响 这并不完整 很容易被攻击者骗、被攻击者偷袭。 原因在上一节中我们已经说了一部分 因为我们可以替换默认JSON解析工具。那么在使用@RequestBody 注解时实际调用的方法就变成了fastjson的JSON.parseObject()。 另外还有的是 JSON.parseObject()这个方法虽然是反序列化的核心方法，但是有时候开发人员并不会直接调用 它而是根据业务情况和个人习惯调用一些其他方法 比如：JSON.parse()或者JSON.parseArray()等。再考虑到 一些反射调用的情况 想要最完整地发现相关调用链，还是要通过动态分析来发现。所以目前最安全的方式还是 通过升级版本或者打开safeMode来实现。 4 总结 学习使我快乐~