前端原始碼安全

2021-09-20 13:45:06 字數 2210 閱讀 4877

今天思考下前端原始碼安全的東西(不是前端安全,只是針對於原始碼部分)。在我看來,原始碼安全有兩點,一是防止抄襲,二是防止被攻破。實際上講,前端的**大多是沒有什麼可抄襲性,安全更是形同虛設的(任何前端輸入都是不能相信的)。但如果還是想防止原始碼被檢視,html、css並不能做什麼,最終都會用露出來(最簡單用chrome開發者工具就可以看到),所以只能針對js做檔案的壓縮合併和混淆。

關於抄襲

其實就前端來講,**沒有什麼好抄襲的,大多人都是抄ui設計(這個是躲不了),還有一些富前端的控制項和演算法,重要之處還是在於後端,而後端是抄不了的。所以前端檔案壓縮合併,目的並不是防止抄襲,而是為了減少檔案體積、加快載入速度,提高程式的執行效能,當然壓縮也有混淆的功能。檔案混淆是防止其他人檢視**邏輯,但是生成的**比原**體積大得多,所以檔案如果做了混淆,載入速度和執行速度都會有所下降。

關於安全

所有的使用者輸入都是不能相信的,如果後端的檢查校驗還做得不好,那就可能被攻破。前端**的邏輯如果還被了解清楚,那就是雪上加霜。後端的問題我們前端管不著,前端的**安全,簡單的可以用壓縮解決、再進一步就去混淆,讓別人看不懂。

html壓縮

很少有人去做html的壓縮(特指去除空白字元和注釋),根據其他資料有幾個原因:

1. html文件中,多個空白字元等價為乙個空白字元。也就是說換行等空白字元的刪除是不安全的,可能導致元素的樣式產生差異。

2. html元素中,有乙個pre, 表示 preformatted text. 裡面的任何空白,都不能被刪除。

3. html中有可能有 ie 條件注釋。這些條件注釋是文件邏輯的一部分,不能被刪除。

也是鑑於上面幾個原因,不提倡壓縮html,通過gzip壓縮就已經能達到很好的效果。

css壓縮合併

css壓縮合併很常見,或者說是必做的,可以由後端動態生成或工具提前生成。目的也只是為了提高載入速度,css即便的壓縮之後,**也是清晰可見,沒有混淆說法。css壓縮合併的工具很多,一般是用sass、less直接生成壓縮後的css,如果是直接壓縮,用grunt還不錯。

js壓縮合併混淆

grunt需要配置兩個檔案:

package.json:宣告應用資訊和使用依賴庫的版本

,

"devdependencies":

}

gruntfile.js:宣告壓縮合併的檔案

module.exports = function

(grunt),

uglify : }}

});grunt.loadnpmtasks('grunt-contrib-concat');

grunt.loadnpmtasks('grunt-contrib-uglify');

grunt.registertask('default', ['concat','uglify']);

}

js的混淆我到現在為止還沒用過,原理都是類似的,混淆是把js**變成亂七八糟的字串,然後用eval執行。

ps:uglify本身有一定的混淆作用,但也只是對變數名的混淆,混淆度並不夠。

混淆前:

function

hello()

混淆後:

eval(function(p,a,c,k,e,r)];e=function();c=1};while(c--)if(k[c])p=p.replace(new regexp('\\b'+e(c)+'\\b','g'),k[c]);return p}('1 0()',3,3,'hello|function|alert'.split('|'),0,{}))
不同混淆演算法混淆的結果不一樣,而且混淆後也不是一勞永逸,還是可以被反混淆的。另外混淆會降低程式執行效能,所以是否需要做混淆得做評估。

總結

我覺得做好檔案壓縮合併,簡單的變數名混淆就可以了,並不需要那麼徹底的混淆。即便是前端被人挖得清清楚楚,只要後端強勁也就沒問題了。所以當你想進行**混淆時候,想想是為了什麼,值不值得。

另外我們有時可能會做一些富前端的外包,那我們在交付之前可以對前端指令碼進行加密,供演示使用。

1. 在**裡面設定乙個**過期時間,過期後**就無法使用了。

2. 對js進行壓縮混淆。

分類: 

5.前後端安全

前端原始碼安全

今天思考下前端原始碼安全的東西 不是前端安全,只是針對於原始碼部分 在我看來,原始碼安全有兩點,一是防止抄襲,二是防止被攻破。實際上講,前端的 大多是沒有什麼可抄襲性,安全更是形同虛設的 任何前端輸入都是不能相信的 但如果還是想防止原始碼被檢視,html css並不能做什麼,最終都會用露出來 最簡單...

閱讀前端專案原始碼的正確姿勢

這篇文章主要介紹下筆者看原始碼的一些心得和方式,由於筆者看的大部分是前端專案,當然也看過一些其它領域的原始碼,不過不多,所以內容主要還是以前端專案為主 在準備看乙個開源專案原始碼的時候先去熟悉下這個專案的背景 功能以及相應的api。這步為了理解整個專案的功能做準備,也是為了後面重點看哪些模組做準備 ...

前端小菜狗看vue原始碼Part One

聽說vue3.0出原始碼了?我2.0的原始碼還沒看過,小菜狗記錄一下。首先vue官方文件中,教程基礎 vue例項下。newvue 首先是創造了乙個vue例項。那麼看向原始碼處。首先進入入口檔案 引入公用api import from global api index import from core...