fastjson的这些坑,你误入了没?

背景:
最近 fastjson 被爆出新的远程代码执行漏洞之后,赶紧督促项目组快马加鞭去修改(
吐槽:真改不动,架不住项目既多又老
),鉴于项目不同,依赖的 fastjson 版本也不同,本次着重谈 fastjson 1.2.16 版本遇到的那些问题?
1

1




兼容性
:低版本没问题,高版本抛异常





 

一、抛问题。

摘取部分代码片段,稍加改造如下。

import com.alibaba.fastjson.JSONArray;

import com.alibaba.fastjson.JSONObject;


import java.util.ArrayList;

import java.util.HashMap;

import java.util.List;

import java.util.Map;


/**

* fastjson 坑啊!

*

* @author 一猿小讲

*/

public class T {

public static void main(String[] args) {

JSONObject retJson = new JSONObject();

retJson.put("retCode", "0000");

retJson.put("retMsg", "Pay Succ");


List<Map<String, Object>> retList = new ArrayList<Map<String, Object>>();

Map<String, Object> retMap = new HashMap<String, Object>();

retMap.put("orderId", "O010000088888");

retMap.put("payerName", "张三");

retList.add(retMap);


retJson.put("retList", retList);


if (retJson.containsKey("retList")) {

JSONArray jsonArray = retJson.getJSONArray("retList");

for (Object object : jsonArray) {

JSONObject orderObject = (JSONObject) object;

System.out.println("假装要执行的处理===>" + orderObject);

}

}

}

}

引入依赖(低版本):

<dependency>

<groupId>com.alibaba</groupId>

<artifactId>fastjson</artifactId>

<version>1.2.16</version>

</dependency>

代码跑起来(真爽,飞一般的感觉):

假装要执行的处理===>{"orderId":"O010000088888","payerName":"张三"}

此时,把 fastjson 升级成高版本:

<dependency>

<groupId>com.alibaba</groupId>

<artifactId>fastjson</artifactId>

<version>1.2.70</version>

</dependency>

代码跑起来(浪奔浪流,万里涛涛泪水永不休):

Exception in thread "main" java.lang.ClassCastException: java.util.HashMap cannot be cast to com.alibaba.fastjson.JSONObject

at T.main(T.java:31)

很明显,第 31 行代码抛出了异常

JSONObject orderObject = (JSONObject) object;

而且很明确:
java.util.HashMap
不能转换成
com.alibaba.fastjson.JSONObject

二、1.2.16 版本没问题,升级到 1.2.70 就抛异常,敢问这是为什么?

分析一:fastjson 1.2.16 版本下捉虫子。

fastjson的这些坑,你误入了没?

分析二:fastjson 1.2.70 版本下捉虫子。

fastjson的这些坑,你误入了没?

版本 1.2.16
vs
 版本 1.2.70:

  • 两幅图的标注 1 对比着看,会发现
    低版本的 JSONArray 中存进去的是 JSONObject,而高版本的存进去的是 HashMap;


  • 两幅图的标注 2 对比着看,会发现
    低版本中 JSONObject 强转成 JSONObject,当然没问题,而高版本拿 HashMap 强转成 JSONObject 就会出

    现 ClassCastException。

到这儿,感觉还不是很解气,势必要打破砂锅刨到底!

版本 1.2.16 的源码刨到底:

而顺着版本 1.2.16 的源码一路看到底,会发现会对 Map 进行二次封装处理,最终会包装成 JSONObject 对象(
这或许就是能强转成 JSONObject 的原因,存进去的是牛,强转成牛,当然没问题
)。

fastjson的这些坑,你误入了没?

版本 1.2.70 的源码刨到底:

fastjson的这些坑,你误入了没?

版本 1.2.70 vs 版本 1.2.16,
很显然 1.2.70 版本增加了一个集合的条件分支判断,如果根据 key 获取的 value 是 List,则会构建 JSONArray 对象,如下面源码截图示意,List 里面的值不会做变化,如果 List 中放入的是 Map,则不会对 Map 进行二次处理(
这可能就是强制转换成 JSONObect 失败的原因,存进去的是牛,非要强转成马,当然行不通
)。

fastjson的这些坑,你误入了没?

三、该怎么解决版本升级,带来的兼容性问题呢?

很简单,既然高版本的没有对 list 中的 Object 进行转换,咱们就刻意调用 toJSON 方法进行转换一番。

retJson.put("retList", retList);

修改为

retJson.put("retList", JSON.toJSON(retList));

代码跑起来,Debug 看看效果如何:

fastjson的这些坑,你误入了没?

很明显,JSONArray 中获取的 object 类型已变为 JSONObject,当然在 1.2.16、1.2.70 版本跑起来都畅通无阻,那么版本升级带来的问题就迎刃而解。

四、闲扯淡(走心)

  • 写代码时候还是需要注意点,能稍微规范些,就尽量按照规范,就如本次提到的问题,向 JSONObject 中加入 List<Map<String,Object> 时,不妨先提前 toJSON 转换一番,这样版本升级也不会有问题。

  • 由于依赖包升级导致不兼容的情况很常见,不过绝大多数都是向下兼容的,例如 JDK … 5、6、7、8 …,所以如果你正在开发核心代码,若涉及到版本更新,尽量考虑兼容性问题,如果涉及到老功能废弃时,不妨采用注解标注一下,这样后人会尽早发现问题。

2



 

不规范的传入:导致内存溢出

 




 

分享一段有意思的代码,一起享受其中乐趣。

import com.alibaba.fastjson.JSON;

/**

* fastjson 坑啊!

* @author 一猿小讲

*/

public class T {

public static void main(String[] args) {

String str = "{/"key1/":/"//value1/"}";

Object obj = JSON.parse(str);

System.out.println(obj);

}

}

代码能跑起来,运行结果绝对正常

{"key1":"/u000Balue1"}

此时,我们动点手脚,把 value1 的值变掉

String str = "{/"key1/":/"//x";

程序运行,word 天 ,惊呆

Exception in thread "main" java.lang.OutOfMemoryError: Java heap space

at com.alibaba.fastjson.parser.JSONLexerBase.putChar(JSONLexerBase.java:2835)

at com.alibaba.fastjson.parser.JSONLexerBase.scanString(JSONLexerBase.java:866)

at com.alibaba.fastjson.parser.DefaultJSONParser.parseObject(DefaultJSONParser.java:428)

at com.alibaba.fastjson.parser.DefaultJSONParser.parse(DefaultJSONParser.java:1302)

at com.alibaba.fastjson.parser.DefaultJSONParser.parse(DefaultJSONParser.java:1268)

at com.alibaba.fastjson.JSON.parse(JSON.java:137)

at com.alibaba.fastjson.JSON.parse(JSON.java:128)

at T.main(T.java:11)

好奇不?咋回事?
Debug 分析一番就清楚啦。

fastjson的这些坑,你误入了没?
当 json 字符串是以 /x 结尾时,由于低版本的 fastjson 并未对其进行校验,将会导致其继续尝试获取字符。

fastjson的这些坑,你误入了没?

由于 index>= this.len 始终成立,则意味着会直接获取到 /u001A,相当于 26,带来的结果就是 isEOF 永远为 false,意味着要无休止的读下去。

fastjson的这些坑,你误入了没?

就这样陷入了死循环 1–>2–>3–>1,直到内存溢出。

fastjson的这些坑,你误入了没?

Debug 一趟肯定比我说的要清楚,当然,此问题早已在版本 1.2.60 中修复。

fastjson的这些坑,你误入了没?

1.2.70 版本肯定也不会有此问题啦,在高版本下直接提示格式错误啦,摆脱了内存异常。

Exception in thread "main" com.alibaba.fastjson.JSONException: invalid escape character /x

at com.alibaba.fastjson.parser.JSONLexerBase.scanString(JSONLexerBase.java:984)

at com.alibaba.fastjson.parser.DefaultJSONParser.parseObject(DefaultJSONParser.java:479)

at com.alibaba.fastjson.parser.DefaultJSONParser.parse(DefaultJSONParser.java:1401)

at com.alibaba.fastjson.parser.DefaultJSONParser.parse(DefaultJSONParser.java:1367)

at com.alibaba.fastjson.JSON.parse(JSON.java:183)

at com.alibaba.fastjson.JSON.parse(JSON.java:193)

at com.alibaba.fastjson.JSON.parse(JSON.java:149)

at T.main(T.java:11)

走心:

  • 金无足赤人无完人,代码有 Bug 很正常,需要一步一步去迭代,要敢于让团队犯错、试错、容错。

  • 通过此段测试,项目开发中参数格式校验就很有必要。

3

寄语写最后

本次,仅以项目中依赖 fastjson 类库作为切入点,主要想传达:在使用三方轮子时,尽可能做对三方的轮子了如之掌,知己知彼方能百战不殆。

另外,借助 fastjson 升级的事情,也想传达写出规范性的代码,是很有必要,不然升级的时候就很麻烦。代码修炼系列分享,仍会结合实际项目进行继续分享,请各位持续关注。

(一)改掉这些坏习惯,还怕写不出健壮的代码?

(二)改掉这些坏习惯,还怕写不出优雅的代码?

(三)改掉这些坏习惯,还怕写不出优雅的代码?

(四)改掉这些坏习惯,还怕写不出健壮的代码?

(五)改掉这些坏习惯,还怕写不出精简的代码?


好了,本次就谈到这里,



一起聊技术、谈业务、喷架构,少走弯路,不踩大坑。

会持续输出原创精彩分享,敬请期待!

fastjson的这些坑,你误入了没?

坚持是一种信仰,在看是一种态度!

原文 

http://mp.weixin.qq.com/s?__biz=MzU2MDg5NzYzNA==&mid=2247485740&idx=1&sn=cfe3690b635d7376c9e8dec6242ff7f6

本站部分文章源于互联网,本着传播知识、有益学习和研究的目的进行的转载,为网友免费提供。如有著作权人或出版方提出异议,本站将立即删除。如果您对文章转载有任何疑问请告之我们,以便我们及时纠正。

PS:推荐一个微信公众号: askHarries 或者qq群:474807195,里面会分享一些资深架构师录制的视频录像:有Spring,MyBatis,Netty源码分析,高并发、高性能、分布式、微服务架构的原理,JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源,目前受益良多

转载请注明原文出处:Harries Blog™ » fastjson的这些坑,你误入了没?

赞 (0)
分享到:更多 ()

评论 0

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址