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

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

為什么需要Java混淆

顯而易見，是為了保護前端代碼邏輯。

在Web系統(tǒng)發(fā)展早期，js在Web系統(tǒng)中承擔的職責并不多，只是簡單的提交表單，js文件非常簡單，也不需要任何的保護。但隨著js文件體積的增大，為了縮小js體積，加快http傳輸速度，開始出現(xiàn)了很多對js的壓縮工具，比如uglify、compressor、clouser……它們的工作主要是：

• 合并多個js文件

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

• 壓縮js里面的變量名

• 剔除掉注釋

下圖是壓縮后的代碼：

雖然壓縮工具出發(fā)點都是為了減少js文件的體積，但是人們發(fā)現(xiàn)壓縮替換后的代碼比源代碼可讀性差了很多，間接起到了代碼保護的作用，于是壓縮js文件成為了前端發(fā)布的標配之一。

但是后來市面上主流瀏覽器Chrome、Firefox等都提供了js格式化的功能，能夠很快的把壓縮后的js美化，再加上現(xiàn)代瀏覽器強大的debug功能，單純壓縮過的js代碼對于真正懷有惡意的人，已經不能起到很好的防御工作，出現(xiàn)了"防君子不防小人"的尷尬局面。

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

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

Java混淆是不是紙老虎

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

.NET混淆器dotFuscator：

其實正是因為js傳輸?shù)木褪窃创a，我們才需要進行混淆。因為暴露在外的代碼沒有絕對的安全，但是在對抗中，精心設計的混淆代碼能夠給破壞者帶來不小的麻煩，也能夠為防守者爭取更多的時間。相對于破解來說，混淆器規(guī)則的更替成本要小得多，在高強度的攻防中，可以大大增加破解者的工作量，起到防御作用。從這個角度來講，關鍵代碼進行混淆是必不可少的步驟。