一个阳光灿烂的冬日清晨,我一如既往地躲在被窝里刷着手机。突然,freebuf公众号头条的一篇文章吸引了我:那些FastJson漏洞不为人知的事情(开发角度)
https://www.freebuf.com/articles/web/258827.html
哇塞,这标题,一看就是大佬的力作!
但是看着看着,这文章感觉不对啊,当中的许多观点都是“颠覆性的创新”,完全改变了我对fastjson漏洞的认知!难道我之前学的都是错的?
所以抱着大胆假设,小心求证的科(杠)学(精)精神,对该文中的一些观点进行探究。
注:本文中的观点仅做纯事实的研究和讨论,不针对任何组织和个人,与本人所代表的本人无关~
OK,Let’s go!
在文章中,作者是这样描述fastjson反序列化漏洞的利用条件的:
这第一个条件就让我产生了很多问号:
Fastjson的漏洞修复史相信各位师傅早已烂熟于心:1.2.25之前默认打开autotype,1.2.48修复了缓存的全局map的问题,1.2.68增加safeMode,1.2.69修复了由于expectClass而产生的autoType绕过。
至于这里为啥给了一个<=1.2.47的条件,嗯,我也不知道为啥。
不过好在第二条还是很合理,这个fastjson的反序列化方法确实是一切开发噩梦的“万恶之源”(此处省略开发同学的头发100根),也是安全人员保住饭碗的三大支柱之一啊!
在文中,作者是这么对漏洞进行定性的:
然后作者接着对@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方法。
在文中作者提出了通过全文搜代码来发现漏洞的方法:
个人觉得这个方法还是有一定效果的,但是如果说仅仅依赖这个搜索就判定不受漏洞影响,这并不完整,很容易被攻击者骗、被攻击者偷袭。
原因在上一节中我们已经说了一部分,因为我们可以替换默认JSON解析工具。那么在使用@RequestBody注解时,实际调用的方法就变成了fastjson的JSON.parseObject()。
另外还有的是,JSON.parseObject()这个方法虽然是反序列化的核心方法,但是有时候开发人员并不会直接调用它,而是根据业务情况和个人习惯调用一些其他方法,比如:JSON.parse()或者JSON.parseArray()等。再考虑到一些反射调用的情况。想要最完整地发现相关调用链,还是要通过动态分析来发现。所以目前最安全的方式还是通过升级版本或者打开safeMode来实现。
学习使我快乐~