淘寶攻略
Web前端JS代碼需要保護嗎？
這得具體情況具體分析：
- 如果只是寫一段web頁面圖片輪播，或是跑馬燈效果等等之類簡單的功能。那不需要保護。
- 如果是精心設(shè)計一個絢麗的特效，如果想要保護這段自己付諸幸苦實現(xiàn)的特效代碼不被他人隨意拿去使用，那應(yīng)該保護這段JS代碼！
- 如果頁面上有重要的功能是用JS代碼管控的，比如交易邏輯、帳號密碼信息、個人隱私、甚至有與遠程服務(wù)器或數(shù)據(jù)庫的通信等等，那么相關(guān)的js代碼非常應(yīng)該被保護、應(yīng)該做JS代碼防盜保護！否則可能引起被黑客分析、攻擊等嚴重問題。安全相關(guān)的事情，從來都要防患于未然、不可心存僥幸。除非它對你毫不重要。
如何保護Web前端JS代碼？
- 打包&壓縮
有人認為打包、壓縮就是對JS代碼的保護。確實，打包在一定程度上可以起碼些許保護作用，好像看起來是如此。但打包、壓縮的目的并不是為了保護JS代碼，而是為了使用方便、減小代碼體積，方便使用、便于傳輸。比如模塊化的編程可能產(chǎn)生200個JS文件，如果使用時逐一用“script src”進行引用……這是種折磨，不管是對于代發(fā)人員，還是網(wǎng)絡(luò)加載（瀏覽器也會生氣！x_x）。類似Webpacket、Gulp進行打包，可以將這些多個JS合成到一個文件，并且可能會進行回車、換行、空格的刪除，以實現(xiàn)代碼壓縮，也有一些簡單混淆操作：把長變量名改為統(tǒng)一風格的短變量名等。然后，最終生成的一個文件。代碼總量減小了、可讀性差了、使用方便了。同時讓有些人認為這也實現(xiàn)了JS代碼保護。其實、實際上、當然的代碼并沒有被保護：可讀性依舊，只是代碼量大了一些而已，只要稍稍耐心的讀代碼，會發(fā)現(xiàn)，代碼依然是很易理解的，沒有多少安全性可言。 - 混淆&加密
前端JS代碼的保護，必需要混淆和加密共用。單獨的JS源代碼加密，是行不通的，更不可能有所謂的JS不可逆加密。因為代碼在瀏覽器端執(zhí)行時，必須轉(zhuǎn)解密還原成原始代碼，才能被瀏覽器的JS引擎識別和運行。在解密后，會存在完整的原始JS代碼。這是非常不安全的存在，有多種方法可將原始的JS代碼顯示出來。
JS代碼混淆被不少開發(fā)人員認為是不夠高端的JS代碼保護方式，聽起來不如JS源碼加密更具安全性。事實上，混淆也有多個級別。比如比較低端的字符搜索和串替換、隨機插入偽僵尸代碼、字符串十六進制化等等。而也有高端的手法，會先進行語法分析、詞法分析，重建語法樹，相當于已經(jīng)實現(xiàn)了一個JS引擎，在引擎中處理代碼，那么，就可以在其中任意一步進行自由度極高的操作，比如在語法樹中插入新的語法結(jié)構(gòu)、比如可以將字符串全部提取并進行加密、可以對變量進行整體有規(guī)則化的重定義使無意義化等等。這樣就可以實現(xiàn)真正的代碼重建。這樣重建的JS代碼安全性，將會有一個質(zhì)的提升。
當正真的混淆和加密聯(lián)合使用，可以實現(xiàn)真正的JS代碼安全保護。JS混淆中融入JS加密，JS加密中又嵌入JS混淆。這樣保護后的代碼，即使在客戶端執(zhí)行環(huán)境中被逆向還原，得到的也是大量含義不明的函數(shù)、代碼、字符串。特別重點是：代碼已經(jīng)經(jīng)過了重建，這時逆向得到的也是分離后的重建的無意義JS代碼、大量的僵尸代碼、混淆的字符串、不明含意的變量?？勺x性與原始代碼相比……天壤之別。
固執(zhí)的人或許還會說：沒有破解不了的保護方案，只要我認真、用心、用時的分析，還是能分析出原始代碼含意的，確實，可能如此。
但是，原本的代碼，可能只需要讀10分鐘，而從這樣保護后的JS代碼讀取原始含意，可能需要……10個月。而這時候，我們的JS代碼可能已經(jīng)更新到下一版了。
JS代碼保護的目的已經(jīng)達到了，不是嗎？
