可信前端之路-代碼保護

摘要： 可信前端之路-代碼保護       0x00 前言 在信息安全領域，可信系統（Trusted system）是一個讓人心動的目標，它指的是一個通過實施特定的安全策略而達到一定可信程度的系統。 在計算機中，可信平臺模塊（Trusted Platform Module，TPM）已經投入使用，它符合可信賴計算組織（Trusted Computing Group，TCG）制定的TPM規範，是爲了實現可信系統目標的而打造的一款安全芯片。

可信前端之路-代碼保護

 

 

 

0x00 前言

在信息安全領域，可信系統（Trusted system）是一個讓人心動的目標，它指的是一個通過實施特定的安全策略而達到一定可信程度的系統。

在計算機中，可信平臺模塊（Trusted Platform Module，TPM）已經投入使用，它符合可信賴計算組織（Trusted Computing Group，TCG）制定的TPM規範，是爲了實現可信系統目標的而打造的一款安全芯片。作爲可信系統的信任根，TPM是可信計算的核心模塊，爲計算機安全提供了強有力的保障。

而在我們的web系統中，想打造一個可信系統似乎是個僞命題，"永遠不要相信客戶端的輸入"是基本的安全準則。實際上，在可信系統中的可信也並不是說真的是絕對安全，維基上對其的解釋爲：“可信的”（Trusted）未必意味着對用戶而言是“值得信賴的”（Trustworthy）。確切而言，它意味着可以充分相信其行爲會更全面地遵循設計，而執行設計者和軟件編寫者所禁止的行爲的概率很低。

從這個角度講，我們把其當做一個美好的願景，我們希望能夠構造一個web系統中的TPM，可以把惡意行爲控制在一定的概率之內，從而實現一個相對可信的web系統。

0x01 可信前端

在可信系統中，TPM的一個重要作用就是鑑別消息來源的真實性，保障終端的可信。在web系統中，我們的消息來源就是用戶。隨着撞庫、惡意註冊、薅羊毛等產業的蓬勃發展，在越來越多的場景我們需要鑑別請求數據是否來自真實的用戶，保護真實用戶的數據安全。

所以想要構造一個web系統中的TPM，首要問題就是需要保證輸入數據安全，打造一個相對可信的前端環境。但是由於web的開放特性，前端作爲數據採集的最前線，js代碼始終暴露在外，在這種情況下，防止惡意僞造請求變得非常困難，可信前端也就成了無稽之談。

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

1、爲什麼需要js混淆

顯而易見，是爲了保護我們的前端代碼邏輯。

在web系統發展早期，js在web系統中承擔的職責並不多，只是簡單的提交表單，js文件非常簡單，也不需要任何的保護。

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

· 合併多個js文件

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

· 壓縮js裏面的變量名

· 剔除掉註釋

壓縮後的代碼

雖然壓縮工具出發點都是爲了減少js文件的體積，但是人們發現壓縮替換後的代碼已經比源代碼可讀性差了很多，間接起到了代碼保護的作用，於是壓縮js文件成爲了前端發佈的標配之一。但是後來市面上主流瀏覽器chrome、Firefox等都提供了js格式化的功能，能夠很快的把壓縮後的js美化，再加上現代瀏覽器強大的debug功能，單純壓縮過的js代碼對於真正懷有惡意的人，已經不能起到很好的防禦工作，出現了"防君子不防小人"的尷尬局面。

chrome開發者工具格式化之後的代碼

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

原文鏈接