一、 前言

在信息安全領(lǐng)域，可信系統(tǒng)(Trusted system)是一個(gè)讓人心動(dòng)的目標(biāo)，它指的是一個(gè)通過實(shí)施特定的安全策略而達(dá)到一定可信程度的系統(tǒng)。

在計(jì)算機(jī)中，可信平臺(tái)模塊(Trusted Platform Module，TPM)已經(jīng)投入使用，它符合可信賴計(jì)算組織(Trusted Computing Group，TCG)制定的TPM規(guī)范，是為了實(shí)現(xiàn)可信系統(tǒng)目標(biāo)的而打造的一款安全芯片。作為可信系統(tǒng)的信任根，TPM是可信計(jì)算的核心模塊，為計(jì)算機(jī)安全提供了強(qiáng)有力的保障。

[[173920]]

而在我們的web系統(tǒng)中，想打造一個(gè)可信系統(tǒng)似乎是個(gè)偽命題，"永遠(yuǎn)不要相信客戶端的輸入"是基本的安全準(zhǔn)則。實(shí)際上，在可信系統(tǒng)中的可信也并不是說真的是絕對安全，維基上對其的解釋為：“可信的”(Trusted)未必意味著對用戶而言是“值得信賴的”(Trustworthy)。確切而言，它意味著可以充分相信其行為會(huì)更全面地遵循設(shè)計(jì)，而執(zhí)行設(shè)計(jì)者和軟件編寫者所禁止的行為的概率很低。

從這個(gè)角度講，我們把其當(dāng)做一個(gè)美好的愿景，我們希望能夠構(gòu)造一個(gè)web系統(tǒng)中的TPM，可以把惡意行為控制在一定的概率之內(nèi)，從而實(shí)現(xiàn)一個(gè)相對可信的web系統(tǒng)。

二、可信前端

在可信系統(tǒng)中，TPM的一個(gè)重要作用就是鑒別消息來源的真實(shí)性，保障終端的可信。在web系統(tǒng)中，我們的消息來源就是用戶。隨著撞庫、惡意注冊、薅羊毛等產(chǎn)業(yè)的蓬勃發(fā)展，在越來越多的場景我們需要鑒別請求數(shù)據(jù)是否來自真實(shí)的用戶，保護(hù)真實(shí)用戶的數(shù)據(jù)安全。

所以想要構(gòu)造一個(gè)web系統(tǒng)中的TPM，首要問題就是需要保證輸入數(shù)據(jù)安全，打造一個(gè)相對可信的前端環(huán)境。但是由于web的開放特性，前端作為數(shù)據(jù)采集的最前線，js代碼始終暴露在外，在這種情況下，防止惡意偽造請求變得非常困難，可信前端也就成了無稽之談。

在反復(fù)對抗中，代碼保護(hù)也就是通常意義上的js代碼混淆的重要性逐漸彰顯出來。今天我就想和大家聊一聊js混淆的問題。

1、為什么需要js混淆

顯而易見，是為了保護(hù)我們的前端代碼邏輯。

在web系統(tǒng)發(fā)展早期，js在web系統(tǒng)中承擔(dān)的職責(zé)并不多，只是簡單的提交表單，js文件非常簡單，也不需要任何的保護(hù)。

隨著js文件體積的增大，為了縮小js體積，加快http傳輸速度，開始出現(xiàn)了很多對js的壓縮工具，比如 uglify、compressor、clouser。。。它們的工作主要是

· 合并多個(gè)js文件

· 去除js代碼里面的空格和換行

· 壓縮js里面的變量名

· 剔除掉注釋

壓縮后的代碼

雖然壓縮工具出發(fā)點(diǎn)都是為了減少js文件的體積，但是人們發(fā)現(xiàn)壓縮替換后的代碼已經(jīng)比源代碼可讀性差了很多，間接起到了代碼保護(hù)的作用，于是壓縮js文件成為了前端發(fā)布的標(biāo)配之一。但是后來市面上主流瀏覽器chrome、Firefox等都提供了js格式化的功能，能夠很快的把壓縮后的js美化，再加上現(xiàn)代瀏覽器強(qiáng)大的debug功能，單純壓縮過的js代碼對于真正懷有惡意的人，已經(jīng)不能起到很好的防御工作，出現(xiàn)了"防君子不防小人"的尷尬局面。

chrome開發(fā)者工具格式化之后的代碼

而在web應(yīng)用越來越豐富的今天，伴隨著瀏覽器性能和網(wǎng)速的提高，js承載了更多的工作，不少后端邏輯都在向前端轉(zhuǎn)移，與此同時(shí)也讓更多的不法分子有機(jī)可乘。在web模型中，js往往是不法分子的第一個(gè)突破口。知曉了前端邏輯，不法分子可以模擬成一個(gè)正常的用戶來實(shí)施自己的惡意行為。所以，在很多登錄、注冊、支付、交易等等頁面中，關(guān)鍵業(yè)務(wù)和風(fēng)控系統(tǒng)依賴的js都不希望被人輕易的破解，js混淆應(yīng)運(yùn)而生。

2、js混淆是不是紙老虎

這是一個(gè)老生常談的問題。實(shí)際上，代碼混淆早就不是一個(gè)新鮮的名詞，在桌面軟件時(shí)代，大多數(shù)的軟件都會(huì)進(jìn)行代碼混淆、加殼等手段來保護(hù)自己的代碼。Java和.NET都有對應(yīng)的混淆器。黑客們對這個(gè)當(dāng)然也不陌生，許多病毒程序?yàn)榱朔床闅?，也?huì)進(jìn)行高度的混淆。只不過由于js是動(dòng)態(tài)腳本語言，在http中傳輸?shù)木褪窃创a，逆向起來要比打包編譯后的軟件簡單很多，很多人因此覺得混淆是多此一舉。

NET混淆器dotFuscator

其實(shí)正是因?yàn)閖s傳輸?shù)木褪窃创a，我們才需要進(jìn)行混淆，暴露在外的代碼沒有絕對的安全，但是在對抗中，精心設(shè)計(jì)的混淆代碼能夠給破壞者帶來不小的麻煩，也能夠?yàn)榉朗卣郀幦「嗟臅r(shí)間，相對于破解來說，混淆器規(guī)則的更替成本要小得多，在高強(qiáng)度的攻防中，可以大大增加破解者的工作量，起到防御作用。從這個(gè)角度來講，關(guān)鍵代碼進(jìn)行混淆是必不可少的步驟。

3、如何進(jìn)行js混淆

js混淆器大致有兩種:

· 通過正則替換實(shí)現(xiàn)的混淆器

· 通過語法樹替換實(shí)現(xiàn)的混淆器

第一種實(shí)現(xiàn)成本低，但是效果也一般，適合對混淆要求不高的場景。第二種實(shí)現(xiàn)成本較高，但是更靈活，而且更安全，更適合對抗場景，我這里主要講一下第二種?；谡Z法層面的混淆器其實(shí)類似于編譯器，基本原理和編譯器類似，我們先對編譯器做一些基本的介紹。

名詞解釋

token: 詞法單元，也有叫詞法記號(hào)的，詞法分析器的產(chǎn)物，文本流被分割后的最小單位。

AST: 抽象語法樹，語法分析器的產(chǎn)物，是源代碼的抽象語法結(jié)構(gòu)的樹狀表現(xiàn)形式。

編譯器VS混淆器

編譯器工作流程

簡單的說，當(dāng)我們讀入一段字符串文本(source code)，詞法分析器會(huì)把它拆成一個(gè)一個(gè)小的單位(token)，比如數(shù)字1 是一個(gè)token, 字符串'abc'是一個(gè)token等等。接下來語法分析器會(huì)把這些單位組成一顆樹狀結(jié)構(gòu)(AST)，這個(gè)樹狀結(jié)構(gòu)就代表了token們的組成關(guān)系。比如 1 + 2 就會(huì)展示成一棵加法樹，左右子節(jié)點(diǎn)分別是token - 1 和token - 2 ，中間token表示加法。編譯器根據(jù)生成的AST轉(zhuǎn)換到中間代碼，最終轉(zhuǎn)換成機(jī)器代碼。

對編譯器更多細(xì)節(jié)感興趣的同學(xué)可以移步龍書：編譯原理

混淆器工作流程

編譯器需要把源代碼編譯成中間代碼或者機(jī)器碼，而我們的混淆器輸出其實(shí)還是js。所以我們從語法分析之后往下的步驟并不需要。想想我們的目標(biāo)是什么，是修改原有的js代碼結(jié)構(gòu)，在這里面這個(gè)結(jié)構(gòu)對應(yīng)的是什么呢?就是AST。任何一段正確的js代碼一定可以組成一顆AST，同樣，因?yàn)锳ST表示了各個(gè)token的邏輯關(guān)系，我們也可以通過AST反過來生成一段js代碼。所以，你只需要構(gòu)造出一顆AST，就能生成任何js代碼!混淆過程如上右圖所示

通過修改AST生成一個(gè)新的AST，新的AST就可以對應(yīng)新的JavaScript代碼。

規(guī)則設(shè)計(jì)

知道了大致的混淆流程，最重要的環(huán)節(jié)就是設(shè)計(jì)規(guī)則。我們上面說了，我們需要生成新的AST結(jié)構(gòu)意味著會(huì)生成和源代碼不一樣的js代碼，但是我們的混淆是不能破壞原有代碼的執(zhí)行結(jié)果的，所以混淆規(guī)則必須保證是在不破壞代碼執(zhí)行結(jié)果的情況下，讓代碼變得更難以閱讀。

具體的混淆規(guī)則各位可以自行根據(jù)需求設(shè)計(jì)，比如拆分字符串、拆分?jǐn)?shù)組，增加廢代碼等等。

參考：提供商業(yè)混淆服務(wù)的jscramble的混淆規(guī)則

實(shí)現(xiàn)

很多人看到這里就望而卻步，因?yàn)樵~法分析和文法分析對編譯原理要求較高。其實(shí)這些現(xiàn)在都有工具可以幫助搞定了，借助工具，我們可以直接進(jìn)行最后一步，對AST的修改。

市面上JavaScript詞法和文法分析器有很多，比如其實(shí)v8就是一個(gè)，還有mozilla的SpiderMonkey, 知名的esprima等等，我這里要推薦的是uglify，一個(gè)基于nodejs的解析器。它具有以下功能：

• parser，把 JavaScript 代碼解析成抽象語法樹 code generator，通過抽象語法樹生成代碼
• scope analyzer，分析變量定義的工具
• tree walker，遍歷樹節(jié)點(diǎn)
• tree transformer，改變樹節(jié)點(diǎn)

對比下我上面給出的混淆器設(shè)計(jì)的圖，發(fā)現(xiàn)其實(shí)只需要修改語法樹 這一步自己完成。

實(shí)例

說了這么多，可能很多人還是一頭霧水，為了幫助各位理解，我準(zhǔn)備了一個(gè)簡單的例子，假設(shè)我們的混淆規(guī)則是想把 var a = 1; 中的數(shù)字1換成16進(jìn)制，我們該如何設(shè)計(jì)混淆器呢。首先對源代碼做詞法分析和語法分析，uglify一個(gè)方法就搞定了，生成一顆語法樹，我們需要做的就是找到語法樹中的數(shù)字然后修改成16進(jìn)制的結(jié)果，如下圖所示：

實(shí)例代碼:

var UglifyJS = require("uglify-js"); 
var code = "var a = 1;"; 
var toplevel = UglifyJS.parse(code); //toplevel就是語法樹 
var transformer = new UglifyJS.TreeTransformer(function (node) { 
if (node instanceof UglifyJS.AST_Number) { //查找需要修改的葉子節(jié)點(diǎn) 
        node.value = '0x' + Number(node.value).toString(16); 
        return node; //返回一個(gè)新的葉子節(jié)點(diǎn) 替換原來的葉子節(jié)點(diǎn) 
    }; 
}); 
toplevel.transform(transformer);  //遍歷AST樹 
var ncode = toplevel.print_to_string(); //從AST還原成字符串 
console.log(ncode); // var a = 0x1; 

上面的代碼很簡單，首先通過parse方法構(gòu)建語法樹，然后通過TreeTransformer遍歷語法樹，當(dāng)遇到節(jié)點(diǎn)屬于UglifyJS.AST_Number類型(所有的AST類型見ast),這個(gè)token具有一個(gè)屬性 value 保存著數(shù)字類型的具體值，我們將其改成16進(jìn)制表示，然后 return node 就會(huì)用新的節(jié)點(diǎn)代替原來的節(jié)點(diǎn)。

效果展示

貼一個(gè)我自己設(shè)計(jì)的混淆器混淆前后代碼：

4、混淆對性能的影響

由于增加了廢代碼，改變了原有的AST，混淆對性能肯定會(huì)造成一定的影響，但是我們可以通過規(guī)則來控制影響的大小。

· 減少循環(huán)混淆，循環(huán)太多會(huì)直接影響代碼執(zhí)行效率

· 避免過多的字符串拼接，因?yàn)樽址唇釉诘桶姹綢E下面會(huì)有性能問題

· 控制代碼體積，在插入廢代碼時(shí)應(yīng)該控制插入比例，文件過大會(huì)給網(wǎng)絡(luò)請求和代碼執(zhí)行都帶來壓力

我們通過一定的規(guī)則完全可以把性能影響控制在一個(gè)合理的范圍內(nèi)，實(shí)際上，有一些混淆規(guī)則反而會(huì)加快代碼的執(zhí)行，比如變量名和屬性名的壓縮混淆，會(huì)減小文件體積，比如對全局變量的復(fù)制，會(huì)減少作用域的查找等等。在現(xiàn)代瀏覽器中，混淆對代碼的影響越來越小，我們只需要注意合理的混淆規(guī)則，完全可以放心的使用混淆。

5、混淆的安全性

混淆的目的是保護(hù)代碼，但是如果因?yàn)榛煜绊懥苏９δ芫蜕岜局鹉┝恕?/p>

由于混淆后的AST已經(jīng)和原AST完全不同了，但是混淆后文件的和原文件執(zhí)行結(jié)果必須一樣，如何保證既兼顧了混淆強(qiáng)度，又不破壞代碼執(zhí)行呢?高覆蓋的測試必不可少：

· 對自己的混淆器寫詳盡的單元測試

· 對混淆的目標(biāo)代碼做高覆蓋的功能測試，保證混淆前后代碼執(zhí)行結(jié)果完全一樣

· 多樣本測試，可以混淆單元測試已經(jīng)完備了的類庫，比如混淆 Jquery 、AngularJS 等，然后拿混淆后的代碼去跑它們的單元測試，保證和混淆前執(zhí)行結(jié)果完全一樣

三、總結(jié)

· 可信web系統(tǒng)是我們的愿景

· 可信web系統(tǒng)離不開可信的前端環(huán)境

· js混淆在對抗中必不可少

· 實(shí)現(xiàn)一款自己的混淆器并沒有那么難

· 混淆器對性能的影響是可控的

四、 參考

https://en.wikipedia.org/wiki/Trusted_Platform_Module

https://en.wikipedia.org/wiki/Trusted_system

http://lisperator.net/uglifyjs

http://esprima.org