一切的前端安全都是紙老虎

引子

最近逼乎有一個很火熱的問題，叫前端可否限制用戶截圖？

當我看到這個問題，我就以爲這個提問者應該是個萌新，或者已經被產品經理或SB leader 折磨的失去理智。由於下方有一個很是直中要害的回答：

不管多麼牛的技術手段限制了軟件的截圖, 用戶只要簡單的掏出手機對着屏幕拍照就行了。

這個問題，真的說明一切的前端安全，其實都是紙老虎。

接下來，我結合本身遇到的幾個場景，來談一些作前端以來，本身遇到的那些僞前端安全需求。

曾經那些被懟回去的安全需求

最近幾年互聯網數據泄露很是頻繁，我上一家公司是作金融貸款的，很是強調數據安全，這兩年也作了很多關於安全的需求。

前端數據脫敏

前端數據脫敏是一個很常見的需求，特別是當今隱私被賣的這麼猖狂的時代，因此不少公司都開始注重這些細節，最基礎的就是數據脫敏。

數據脫敏，就是將用戶的隱私信息，用一些手段，讓這些信息有必定辨識度，但又沒法準確獲取，好比：

• 金*胖
• 186**2892
• 510*1262
• 川A 7*1

上面通常是咱們常見到的數據脫敏格式，我又叫他數據馬賽克。前端能不能作，確定能作，一個正則配上一個String.replace方法就搞定。但若是產品讓咱們實現這種需求，咱們確定要拒絕，由於前端作數據脫敏就是被單裏眨眼睛 - 自欺欺人。

歸根揭底，一個稍微有點IT常識的人，若是想要這些數據，直接從請求拿就是了，何須從頁面複製。

因此數據脫敏這種事，必定要交給後端作，從源頭開始脫敏。

可能後面一些場景，有些被脫敏的數據，在前端又要被用到。好比列表數據脫敏，到詳情/表單編輯操做時又須要脫敏前的，那就根據ID再發一次請求獲取脫敏前的數據，而後對這個接口調用作權限限制和日誌記錄，讓敏感數據的使用相對安全。

表單校驗是爲了安全麼

咱們在作表單時，不少時候都會針對數據格式作校驗，好比郵箱、電話號碼、銀行卡號這些，甚至還有一些很是複雜的聯動校驗。

前端作校驗是爲了安全麼？

可能有那麼一丁點意思吧，好比之前咱們老是在提校驗輸入防XSS攻擊。但如今前端這種格式校驗，更可能是爲了：提高用戶體驗,提高用戶體驗,提高用戶體驗。

• 首先提醒並引導用戶，應該怎麼輸入；
• 其次，若是用戶輸入半天，前端不校驗，直接到後臺，後臺發現格式不正確，再提示用戶，這是一個很是耗時且不專業的交互體驗；
• 若是前端沒校驗，後端也沒校驗，那這就是一條髒數據插入到數據庫，有可能形成XSS攻擊 或 SQL攻擊, 這就很是危險了。

數據報表加水印

頁面加水印，其實在前端很廣泛，好比釘釘, 企業微信 的羣聊都是加了水印的，不少在線圖片編輯工具也是加了的，好比我經常使用的圖怪獸，你想白嫖，他就給你加個水印：

而當時咱們有些列表，由於運營須要，有些數據無法作數據脫敏，因此領導說，前端能不能作個水印，讓數據安全一點：防止運營人員不按規範處理問題，私自截圖。因此當我看到知乎那個提問是，我特別慶幸，沒有讓我作：限制用戶截圖。

從我我的經驗來說，前端加水印有三個層次：

• 經過 CSS 背景加水印，簡單粗暴，能騙一點文科運營。但稍微懂行的人，就知道經過 Elements 編輯面板屏蔽這個水印。正所謂你加的簡單，別人去掉更簡單。
• 經過 JS 定向植入水印dom節點，這個比上一個稍微複雜點，但仍是經過Elements 編輯面板屏蔽，只不過多思考一下，操做步驟多點。
• 終解: 服務端加水印生成列表圖片，實現思路和圖怪獸網站一致。但這個操做描述起來簡單，具體實現就很是複雜，須要考慮投入產出比。

有可能你會疑問，爲何是服務端加水印生成圖片，而不是前端本身經過 canvas 生成？

• 第一，同上面提到過的，經過請求拿到敏感數據，自己就是不安全的；
• 第二，JS 自己是不安全的，可篡改；

JS 可篡改

我上面反覆在說前端安全是個僞需求，你可能不信。但若是你知道 JS 是可篡改的，那你就明白爲何了。咱們老是在提JS醜化，但醜化更可能是減小包的體積，在某種程度上，可讓發佈的js資源可讀性更差，但作到不可讀很難。

接下來體驗一下什麼叫 JS 可篡改吧

實戰演練

• 第一步：Chrome 下載安裝 Header Editor 插件

• 第二步：找一個目標網站，並找到一個你想篡改的 JS 資源。我這裏以我經常使用的做圖網站的jquery 資源（https://js.tuguaishou.com/js/...）引用爲例；
• 第三步：拷貝代碼帶編輯器，輸入你想篡改的內容，我這裏就只加了個console輸出, 而後本地起一個靜態資源服務

// ...
  console.log('do some change, ho ho ho');
  var c = []
    , d = c.slice
    , e = c.concat
  // ...

• 第四步，使用插件重定向網站靜態資源，我這裏就是使用本地的jquery 代替網站原有的，保存配置並啓動那個規則；

• 第五步: 強刷瀏覽器，使代理資源生效，當你看到請求被標成了307的響應，說明篡改生效，而後看console，就有了對應的輸出；

至此，一次完整的篡改完成。但這個教程並非讓你用這個方法去作一些XX的事情，而只是讓你明白因爲JS的可篡改，咱們在作網站設計時，你須要時刻思考代碼安全的事，能作不表明能夠作。

分享個趣事

年初，前公司要作一次大的系統融合：就是兩個子公司各有各的權限系統，而後資本青睞的一方佔優(以系統設計來說，咱們的權限系統設計更專業)，被遺棄的咱們不得不改咱們現有系統，去對接對方的系統。

這中間由於異地溝通問題，對方開始沒把規則說好，而後對接人將咱們清洗重組後的數據導入了數據庫。後面因爲須要修改一些數據，網站頁面提示咱們導入數據key的格式不對，而這個key，又被設置成了只讀，這就走入了死路。而後溝通能不能把數據庫數據刪除了從新導入，對方一萬個不情願，讓咱們本身在網站上本身刪除再添加數據，那但是200多條數據啊，侮辱誰呢？？？？

這真的把我同事們惹毛了，而後就試了上面的招數，看了對方的JS，代理而後再一提交，成功！！！

知道對方業餘，但沒想到這麼業餘：僅在前端作了限制，服務端沒校驗。

這個案例提醒咱們，前端重在交互，服務端重在安全，JS是可篡改的；因此不要產品覺得，要你覺得，用你的專業Say no!!!；也告訴咱們作技術，謙虛點，能幫忙就儘可能幫，作個好人。

結語

又摧拉枯朽扯了一堆，希望對你之後的需求評審和方案設計有用。前端安全重要嗎？重要。網站的安全全交給前端合適嗎? 不合適。