FastJson是如何导致App Crash的

FastJson是如何导致App Crash的这要从去年6月份的一个高级漏洞说起,阿里云监测到FastJson存在0day漏洞,攻击者可以利用该漏洞绕过黑名单策略进行远程代码执行。虽然具体来复现这个漏洞笔者没有进行深入研究,不过看上去就很严重的样子,可以远程让服务端执行指定的代码,就意味着服务端都不再安全了,更别提我们处心…

去年FastJson的严重漏洞

       这要从去年6月份的一个高级漏洞说起,阿里云监测到FastJson存在0day漏洞,攻击者可以利用该漏洞绕过黑名单策略进行远程代码执行。虽然具体来复现这个漏洞笔者没有进行深入研究,不过看上去就很严重的样子,可以远程让服务端执行指定的代码,就意味着服务端都不再安全了,更别提我们处心积虑地各种加密的客户端了,什么加密混淆加固这一切努力都将白费。就像一个没穿衣服的人,你戴再多帽子那也是徒劳。

​       具体漏洞如下,相信大家肯定也看到过类似的帖子,或者被公司的同事提醒过:

FastJson是如何导致App Crash的

关于这次漏洞,开发者需要做什么

       这一次漏洞覆盖面太广了,但是阿里官方当然不会坐视不管,自己的各种项目里都用着FastJson,任由病毒肆意蔓延,最后的损失将不可估量。于是在发现这个漏洞的第一时间FastJson官方就发出了解决方案,强烈建议大家升级FastJson到1.2.58版本以上。笔者也被公司的运维同学通知到了该消息,于是第一时间对该问题进行了处理,当时还小嘚瑟了一下,感觉没有比单纯升级一个sdk,改改版本号更简单的需求了。我当时上Github上看了下FastJson的最新版本是1.2.60,于是就修改了项目中build.gradle中的FastJson版本号为1.2.60。

解决这次漏洞,仅仅是改版本号这么简单吗?

       升级以后,准备上传代码的时候我多留了一个心眼。按理说不会有什么问题,但是小心驶得万年船,心里想着既然是官方紧急发布的版本,是不是在修复了这个漏洞的同时,会同时带来其他的问题呢?我首先随便点了几个使用了FastJson进行解析的页面,并没有发现问题。但是问题经常就出现在特殊情况下,特别是第三方SDK对于自己就像个黑盒的时候。于是我习惯性地进行了一些健壮性测试,这是其中的一个测试案例,具体测试代码如下:

String jsonStr = "";
JSONObject.parseObject(jsonStr,JavaBean.class);

​       果不其然,当需要解析的字符串是空字符串时,将会发生crash,具体的错误堆栈信息如下:

Caused by: com.alibaba.fastjson.JSONException: syntax error,except start with { or [,but actually start with EOF at com.alibaba.fastjson.parser.DefaultJSONParser.parseObject(DefaultJSONParser.java:688) at com.alibaba.fastjson.JSON.parseObject(JSON.java:383) at com.alibaba.fastjson.JSON.parseObject(JSON.java:287) at com.alibaba.fastjson.JSON.parseObject(JSON.java:560)

​       从报错信息来看,像是传空字符串时,FastJson并没有进行健壮性处理。我第一反应是看一下升级以前的版本是不是也有相同的问题,于是我回退代码再跑了一遍,发现并没有问题。这只能说明被我不幸言中了,正是1.2.60这版本新出现的问题。因为笔者项目里有很多地方都是通过传参的方式传入json字符串,然后用FastJson进行解析的,难保有些地方由于网络不好,没有请求到Json数据。或者是页面间传参丢失等,出现解析空字符串的情况,而且具体哪些地方可能出现也不好排查。幸好在上线前发现了这一问题,既然之前版本存在重大漏洞,然后最新版本又不能用。所以项目里最终是用Gson来代替了FastJson上线,避免了可能存在的crash问题。

从源码角度分析Crash来源

       那1.2.60版本为什么会报这个crash呢,我们从源码的角度来看看吧。这部分代码很简单,首先从使用的地方看起吧,我们使用FastJson对Json字符串解析成Bean的时候大概都是这样子的:

JSONObject.parseObject(jsonStr,JavaBean.class);

​       继续点下去的话大概会经过几个重载方法,然后最后一个parseObject()方法大概是这样的:

public static <T> T parseObject(...){    //省略无用代码
    DefaultJSONParser parser = new DefaultJSONParser(input, config, featureValues);
    T value = (T) parser.parseObject(clazz, null);
    //省略无用代码
}

​       我们可以看到,FastJson是这样做的,首先初始化了一个DefaultJSONParser类,然后通过这个类的parseObject()方法来实现真正的逻辑,最后该方法的返回值就是最终我们需要的Bean对象。接下来再看看DefaultJSONParser类中的parseObject()方法吧,方法具体实现也很简单,我这里也贴出来,大致如下:

public static<T>T parseObject(...){
    //省略无用代码
    if (deserializer.getClass() == JavaBeanDeserializer.class) {
        if (lexer.token()!= JSONToken.LBRACE && lexer.token()!=JSONToken.LBRACKET) {
        throw new JSONException("syntax error,except start with { or [,but actually start with "+ lexer.tokenName());
    }
        return (T) ((JavaBeanDeserializer) deserializer).deserialze(this, type, fieldName, 0);
    } else {
        return (T) deserializer.deserialze(this, type, fieldName);
    }
    //省略无用代码}

​       看到这里报错的位置就已经出来了,很明显如果lexer.token()不是JSONToken.LBRACE或者JSONToken.LBRACKET的时候,就会抛出前面遇到的异常,那么两个枚举是什么意思呢?

FastJson是如何导致App Crash的FastJson是如何导致App Crash的

​       我们点到枚举类里去看一下,注释已经很清楚了,这两个枚举分别代表左大括号和左中括号。也就是说想要解析必须以左大括号和左中括号开始,否则就抛出我们看到的那个异常。那么答案就水落石出了,当json为空字符串的时候,明显不是以左大括号和左中括号开始的,所以就crash了。

​       之前版本是并没有这个问题的,那么在1.2.55版本这一块的代码是怎么处理的呢?同样点进去,我们发现在1.2.55里面并没有主动抛出这个异常:

FastJson是如何导致App Crash的

​       而是在接着往下面解析的时候,将结果置为Null进行返回了。

FastJson是如何导致App Crash的

​       所以使用1.2.55版本的FastJson的话,结果是返回空的对象。如果我们有在代码里对解析以后的对象进行判空的话,至少不会发生crash了。

截止到今天,FastJson是否已修复该问题

​       那截止到目前2020/6/11,FastJson是否修复了该问题呢?答案是肯定的,我们也来看下在最新的1.2.70版本里面FastJson源码是怎么处理的吧,代码非常简单:

FastJson是如何导致App Crash的

       我们可以看到,相比1.2.55,在1.2.70中是将json字符串的判空逻辑前置了,所以也不会有问题了。

总结

​       本文分享了一个项目中实际发生的FastJson踩坑实例,由一个例子也引申出了FastJson的部分简单源码。当然大家并不需要担心,因为在1.2.70里面已经修复了这个问题。代码里有准备使用1.2.60版本的FastJson的同学,或者是现在正在使用1.2.60版本的同学需要注意了,要尽量升级到1.2.70,防患于未然。

​       通过这次事件,有一个值得深思的事件似乎冒了出来,那就是我们不能完全相信SDK会做好健壮性处理。虽然阿里的开发工程师和测试工程师都很强大,但是也不可避免地有可能会出现一些披露。所以我们在升级SDK的时候,一定不能大意了,不要觉得改一个版本号就没事了。就算是改版本号也要跟项目组里的测试同学反映一下,做一下简单的回归测试。其次,自己也可以做一些极限条件下的模拟测试,来尽量减少上线以后可能出现的问题。

       有句话说得很对,那就是上线前测出一百个问题,实际严重程度比不上线上出的一个问题。上线前出问题最多只是延长发版的时间,这是完全可以接受的,但是线上出问题了,作为非Hybrid开发的功能来说,又要经过漫长的bug修复、代码Review、回归测试、申请应用市场、用户重新下载安装才能算是成功修复了,而且出问题期间的损失又有多少?

​       在这个任何行业竞品App满天飞的时代,有多少用户会因为这个crash问题从而卸载App,转而投向竞品App的怀抱呢?

FastJson是如何导致App Crash的

今天的文章FastJson是如何导致App Crash的分享到此就结束了,感谢您的阅读。

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
如需转载请保留出处:https://bianchenghao.cn/17696.html

(0)
编程小号编程小号

相关推荐

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注