接集团预警通报 2022 年第 13 号：监测发现，Java 开发组件 fastjson 存在反序列化漏洞。fastjson 被众多 java 软件作为组件集成，广泛存在于 java 应用的服务端代码中。攻击者可利用上述漏洞实施任意文件写入、服务端请求伪造等攻击行为，造成服务器权限被窃取、敏感信息泄漏等严重影响。此次事件影响 fastjson 1.2.80 及之前所有版本。目前，已发布 fastjson 最新版本 1.2.83 以修复该漏洞，组件升级地址为： github.com/alibaba/fastjson/releases/tag/1.2.83 。请各系统建设部门及时排查梳理受影响情况，在确保安全的前提下修复漏洞、消除隐患，提高网络系统安全防护能力，严防网络攻击事件。同时，加强安全监测，做好应急处置准备，发现突出情况要迅速处置并第一时间报告数据中心。

没用过 fastjson ，但是经常看到爆出漏洞的新闻。

Spring Boot 默认 logback 和 Jackson ，真是 nice 。

阿里巴巴：fastjson 现在负面有点多，这样吧咱们出个 fastjson2 重来 😜

github.com/alibaba/fastjson2

没想到还真有

序列化库都这样

我之前也想把项目从 fastjson 迁移到 spring 自带的 jackson 去，然而当我点开一个转换工具类，5 位数行代码里一片 jsonobject 、jsonarray ，我放弃了...

又不是不能用.jpg

bugest json

问个问题，为啥不用 gson 呢？

我就问你快不快吧，毕竟不叫 safejson

其实我一直想不明白，JSON 这么重要的场景，Java 都没有一个官方的序列化的库吗，反而各种库横行（ Jackson, FastJson, Gson 等等）。其他语言如 PHP, Go, Python 都是官方支持 JSON 解析的吧

所以现在 fastjson2 能用了吗，依赖太多实在换不动

开个地图炮，用着 spring 全家桶，还在用 fastjson 的，都是 sb 。

个人几乎不用阿里开源框架 /工具

＃10 Gson 性能一般，还是 Jackson 好

不好意思，傻逼就是在下

其实 jackson 之类的一样有漏洞，一样要升级（ spring 全家桶的话跟着一起升级就行）
只是 fastjson 作为阿里开源，相关消息关注度更高

有官方（现在应该不算了）规范，JSON-P 和 JSON-B ，但是实现都在 Jakarta EE 容器里面。

＃13 fastjson2 有个 2.0 版 还有个 2.0 兼容版

我不能理解 “用 spring ，又特意改为 fastjson” 这种操作。

先入为主吧，像初学者搜索问下 Java 怎么处理 Json ，推荐的基本是 fastjson ，用习惯了 api 又怎么能轻易换

阿里继续向外输出人才后估计又有更多公司要改成 Java ，按他们的习惯用上各种阿里的库（

＃12 Java 有官方的序列化，因为安全漏洞实在难以修复，已经确定要被抛弃，只是因为替代品还没弄好一直没有正式抛弃。至于 JSON ，它属于类似 XML 那样的跨平台数据格式，原本不是为序列化 /反序列化服务的，即无法成为 Java 内部标准，也无法让 Java 为其提供 JDK 级别的实现，这点跟 XML 一样的待遇，很正常。

基本没人改 Spring MVC 的默认 JSON 序列化库吧......

我觉得 java 不支持 json 主要是因为强类型吧。

一般的序列化库都有问题，包括 Jackson ，可以看下这个 github.com/GrrrDog/Java-Deserialization-Cheat-Sheet
不过貌似 Gson 没出过大问题

Java 这么繁荣是有道理的，连个 JSON 解析库都做不好，大把的输出时间换工资啊。

组内大部分同事对阿里开源有蜜汁崇拜，fastjson ，easyexcel ，nacos 都在用，劝都劝不动

原来在你的逻辑里， 越麻烦 就越流行啊？ 真是万年一遇的天才。

谢谢回复，我搜了一下，也没找到 gson 性能差多少的资料，能找到的性能比较看起来那点性能差异对服务影响不大，除非是那种大量解大 json 任务的

没多少人特意改为吧？ 接收参数，响应参数等 框架自带的功能 又没人动。 只是需要手工处理 json 的时候 采用 fastjson ，因为用起来方便，不需要自己写工具类。jackson 确实麻烦了一点点。 只是一点点。

hutool 的 json 咋样

我还以为你是抖机灵, 没想到还真有!

存在即合理，我是发现者，不是定义者。

你这个就是 fastjson 使用者的典型例子。

很多 fastjson 的使用者不知道，jackson 的 objectMapper 早就注入到 spring context 里了。
直接用就好了，压根不存在“需要手工处理 json 的时候 采用 fastjson ，因为用起来方便，不需要自己写工具类”。

看来学艺不精的不在少数，spring 全家桶稍微研究一下就知道 objectMapper 是现成的，直接拿来用就行了

那为啥.net 有呢

缺乏统一的标准，Java 也有注解，抄一下 serde 作业也是好的。

记者：你有什么特长
大爷：我心算很快
记者：1+1 等于多少
大爷：5
记者：不对
大爷：但我算的快

建议离阿里的开源项目远一点

dotnet 新的内置（特指 system.text.json ）其实就是收编了牛汤杰森

gson 并不比 fastjson 难用，上手极快

Fastjson 出 bug 就是国产垃圾
Jackson 出 bug 就是难免出问题能理解

jakarta 这玩意...我记得 base in jdk11 吧?

v 站输出阿里也是政治正确吗。。

Dubbo,Druid,Nacos,Sentinel,arthas 等等好像都是阿里的

当一个漏洞公开声明的时候，已经没有利用价值了

反过来想，其实那些“没有问题的库”，出问题风险更大

毕竟国内很多人觉得阿里开源的东西高级

又是 AutoType 的问题。
罪过就是功能太强大，功能一复杂就容易出漏洞。
跟 Log4j 那个漏洞也是有一些相似，有多少人知道为啥一个日志库有动态 class 执行的功能呢。

国外很多开源软件其实也有漏洞。。。大可平常心看待。

早期确实坑爹，现在就平常心看待吧，出问题不可怕，怕的是解决不了以及解决效率。
就这点看来，fastjson 还是优秀的。

另外慎用 fastjson2 ，同事近期还给 fastjson2 提了兼容性 issue 已被确认。

随便找个初中级都知道默认 ObjectMapper 注册到了 Spring Context 中，不要想当然。

＃40 哈哈哈这句话是针对 ＃11 说的吗？哈哈哈
＃11

内置的反序列化库也有洞的吧，前几天刚做到题

的确，Fastjson 的 API 比较简单，jackson 麻烦。

基本的序列化 /反序列化都有类似漏洞，关 authType 保平安，那玩意儿除了 RPC 之外，其它应用场景真的很少

＃36 人家不是说了，要手写工具类，Jackson api 实在不好用，这也是 fastjson 流行的原因之一。而不是注入不注入的问题，哪怕不是注入的，写个单例也比定义个变量再用注解方便

还真不知道。。。每次用的时候不用自己 new 出来？

最常用的 encode/decode ，两者基本没区别

objectMapper.writeValueAsString(car);
JSON.toJSONString(car);
objectMapper.readValue(json, Car.class); 
JSON.parseObject(jsonString, Car.class);

至于使用静态 JSON.xxxx 方法好，还是注入好，这个涉及到个人偏好问题了。

静态就不用 new 了，像 jackson 还要得自己 new ，小白说这可太复杂了，狗头保命。我站 boot ，boot 用啥我用啥

请问在座的各位能写一个又快又安全的 JSON 库出来吗？又要用又要说别人垃圾漏洞多。还能扯到 Java 垃圾连个自带的 json 库都没有。。不能做一个有礼貌的伸手党吗？

writeValueAsString 和 toJSONString ，我觉得后者更直白些，我感觉不爽的是 Jackson 会抛异常，我要专门处理它，所以我一般会写个工具类，用 fastjson 的 api 名字来包一下 Jackson 。静态和注入，我觉得综合考虑还是静态更好，注入的话没法直接在静态方法中使用

只能说对应大部分开发者来说易用性确实大于可扩展性。
性能上的话，当下 fastjson1 对比 jackson 已经没优势了： github.com/fabienrenaud/java-json-benchmark

这个标题, 有的那啥了.
开源是好事, 选择使用, 就要有风险预期. 不然资深开发拿那么高工资, 是玩了.

代码洁癖不能忍受自己的 spring 项目额外依赖个 fastjson

vert.x 里对 jackson 的封装蛮好用的

求问一下 easyexcel 有啥替代品吗😂

.net 和 Java 都写，还是.net 好，json 序列化只有 2 个库，一个官方一个 Newtonsoft ，用到现在也没有听到哪个有重大漏洞。

可以用这个封装 jackjson 的库

com.seepine
json
0.0.2

主要封装了个 J sonObject 以及提供成静态方法
JsonObject jsonObject = Json.parseObj("jsonStr");
ArrayNode arrayNode = Json.parseArray("jsonStr");
Bean bean = Json.parse("jsonStr", Bean.class);
String jsonStr = Json.toJson(bean);

jackson 还是结合 kotlin 最好用

说什么 jackjson 的 api 难用的，就不能自己简单封装几个静态方法么？再说，你们都用不到深拷贝和类型转换的么？

Bugjson

jackson 漏洞也没少啊。fastjson 国内用的多，尤其阿里用的多，国内好多黑灰产都在研究 fastjson 的漏洞，导致看起来 fastjson 的漏洞比 jackson 多不少。就跟 windows 上木马病毒比 linux 多一个道理，并不是 windows 不行，用的人多了，自然就有人来研究各种奇奇怪怪偏门的漏洞了，这反而证明了这个项目非常成功。

复杂的用原生 poi ，简单的用 hutool

写开源软件还真就不是轻松的活

有一说一：fastjson api 确实易用。不用各种处理异常； 还有 nacos 确实比其他注册中心 /配置中心好用多。一套搞定不折腾

特地试了一下，怎么解析下划线和驼峰两种形式的 json ？
比如有些接口返回的 {"user_name":"aa"}，有些接口{"userName":"aa"}。bean 字段 userName 。
自己封装静态方法只能指定一种映射方式，支持了下划线驼峰就会不支持。

类里额外加一个 void setUser_name(xxx)的方法

阿里出品，必属（）

现在都直接 了。而且正常一个接口几十个字段，一个一个加 set 方法也很蠢啊。fastjson 就可以同时兼容下划线和驼峰

存在即合理的真实意思
合理的东西是实在的东西，然后才是实在的东西是合理的