App下載

前端安全就是紙老虎,唬人用的

猿友 2020-09-21 14:50:55 瀏覽數(shù) (2389)
反饋

文章來源于前端黑洞 ,作者拓巖

在某乎上,最近有一個很火的問題:前端能否限制用戶截圖?

前端能否限制用戶截圖

當(dāng)我瀏覽這個問題的時候,我覺得提問者應(yīng)該是個萌新,或者已經(jīng)被產(chǎn)品經(jīng)理或 SB leader 折磨的失去理智。因為下方有一個非常直中要害的回答:

無論多么牛的技術(shù)手段限制了軟件的截圖, 用戶只要簡單的掏出手機對著屏幕拍照就好了。

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

接下來,我結(jié)合自己遇到的幾個場景,來談一些做前端以來,自己遇到的那些偽前端安全需求。

曾經(jīng)那些被懟回去的安全需求

最近幾年互聯(lián)網(wǎng)數(shù)據(jù)泄露非常頻繁,我上一家公司是做金融貸款的,非常強調(diào)數(shù)據(jù)安全,這兩年也做了不少關(guān)于安全的需求。

前端數(shù)據(jù)脫敏

前端數(shù)據(jù)脫敏是一個很常見的需求,特別是當(dāng)今隱私被賣的這么猖狂的時代,所以很多公司都開始注重這些細節(jié),最基礎(chǔ)的就是數(shù)據(jù)脫敏。

數(shù)據(jù)脫敏,就是將用戶的隱私信息,用一些手段,讓這些信息有一定辨識度,但又無法準(zhǔn)確獲取,比如:

前端數(shù)據(jù)脫敏

上面一般是我們常見到的數(shù)據(jù)脫敏格式,我又叫他數(shù)據(jù)馬賽克。前端能不能做,肯定能做,一個正則配上一個String.replace方法就搞定。但如果產(chǎn)品讓我們實現(xiàn)這種需求,我們肯定要拒絕,因為前端做數(shù)據(jù)脫敏就是被單里眨眼睛 - 自欺欺人。

歸根結(jié)底,一個稍微有點IT常識的人,如果想要這些數(shù)據(jù),直接從請求拿就是了,何必從頁面復(fù)制。

所以數(shù)據(jù)脫敏這種事,一定要交給后端做,從源頭開始脫敏。

可能后面一些場景,有些被脫敏的數(shù)據(jù),在前端又要被用到。比如列表數(shù)據(jù)脫敏,到詳情/表單編輯操作時又需要脫敏前的,那就根據(jù)ID再發(fā)一次請求獲取脫敏前的數(shù)據(jù),然后對這個接口調(diào)用做權(quán)限限制和日志記錄,讓敏感數(shù)據(jù)的使用相對安全。

表單校驗是為了安全么

我們在做表單時,很多時候都會針對數(shù)據(jù)格式做校驗,比如郵箱、電話號碼、銀行卡號這些,甚至還有一些非常 復(fù)雜的聯(lián)動校驗。

表單校驗是為了安全么

前端做校驗是為了安全么?

可能有那么一丁點意思吧,比如以前我們總是在提校驗輸入防XSS攻擊。但現(xiàn)在前端這種格式校驗,更多是為了: 提升用戶體驗,提升用戶體驗,提升用戶體驗

?首先提醒并引導(dǎo)用戶,應(yīng)該怎么輸入;?其次,如果用戶輸入半天,前端不校驗,直接到后臺,后臺發(fā)現(xiàn)格式不正確,再提示用戶,這是一個非常耗時且不專業(yè)的交互體驗;?如果前端沒校驗,后端也沒校驗,那這就是一條臟數(shù)據(jù)插入到數(shù)據(jù)庫,有可能造成XSS攻擊SQL攻擊, 這就非常危險了。

數(shù)據(jù)報表加水印

頁面加水印,其實在前端很普遍,比如釘釘, 企業(yè)微信 的群聊都是加了水印的,很多在線圖片編輯工具也是加了的,比如我常用的圖怪獸[2],你想白嫖,他就給你加個水?。?/p>

數(shù)據(jù)報表加水印

而當(dāng)時我們有些列表,因為運營需要,有些數(shù)據(jù)沒法做數(shù)據(jù)脫敏,所以領(lǐng)導(dǎo)說,前端能不能做個水印,讓數(shù)據(jù)安全一點:防止運營人員不按規(guī)范處理問題,私自截圖。所以當(dāng)我看到知乎那個提問時,我特別慶幸,沒有讓我做:限制用戶截圖

從我個人經(jīng)驗來講,前端加水印有三個層次:

  • 通過 CSS 背景加水印,簡單粗暴,能騙一點文科運營。但稍微懂行的人,就知道通過 Elements 編輯面板屏蔽這個水印。正所謂你加的簡單,別人去掉更簡單。
  • 通過 JS 定向植入水印dom節(jié)點,這個比上一個稍微復(fù)雜點,但還是通過Elements 編輯面板屏蔽,只不過多思考一下,操作步驟多點。
  • 終解: 服務(wù)端加水印生成列表圖片,實現(xiàn)思路和圖怪獸網(wǎng)站一致。但這個操作描述起來簡單,具體實現(xiàn)就非常復(fù)雜,需要考慮投入產(chǎn)出比。有可能你會疑問,為什么是服務(wù)端加水印生成圖片,而不是前端自己通過 canvas 生成?
    • 第一,同上面提到過的,通過請求拿到敏感數(shù)據(jù),本身就是不安全的;
    • 第二,JS 本身是不安全的,可篡改;

JS 可篡改

我上面反復(fù)在說前端安全是個偽需求,你可能不信。但如果你知道 JS 是可篡改的,那你就明白為什么了。我們總是在提JS丑化,但丑化更多是減少包的體積,在某種程度上,可以讓發(fā)布的js資源可讀性更差,但做到不可讀很難。

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

實戰(zhàn)演練

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

下載安裝 Header Editor 插件

  • 第二步:找一個目標(biāo)網(wǎng)站,并找到一個你想篡改的 JS 資源。我這里以我常用的作圖網(wǎng)站的jquery 資源(js.tuguaishou.com/js/jquery-1.11.3.min.js)引用為例;
  • 第三步:拷貝代碼帶編輯器,輸入你想篡改的內(nèi)容,我這里就只加了個console輸出, 然后本地起一個靜態(tài)資源服務(wù)

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

  • 第四步,使用插件重定向網(wǎng)站靜態(tài)資源,我這里就是使用本地的jquery 代替網(wǎng)站原有的,保存配置并啟動那個規(guī)則;

使用插件重定向網(wǎng)站靜態(tài)資源

  • 第五步: 強刷瀏覽器,使代理資源生效,當(dāng)你看到請求被標(biāo)成了307的響應(yīng),說明篡改生效,然后看console,就有了對應(yīng)的輸出;

強刷瀏覽器,使代理資源生效

至此,一次完整的篡改完成。但這個教程并不是讓你用這個方法去做一些XX的事情,而只是讓你明白由于JS的可篡改,我們在做網(wǎng)站設(shè)計時,你需要時刻思考代碼安全的事,能做不代表可以做。

分享個趣事

年初,前公司要做一次大的系統(tǒng)融合:就是兩個子公司各有各的權(quán)限系統(tǒng),然后資本青睞的一方占優(yōu)(以系統(tǒng)設(shè)計來講,我們的權(quán)限系統(tǒng)設(shè)計更專業(yè)),被遺棄的我們不得不改我們現(xiàn)有系統(tǒng),去對接對方的系統(tǒng)。

這中間因為異地溝通問題,對方開始沒把規(guī)則說好,然后對接人將我們清洗重組后的數(shù)據(jù)導(dǎo)入了數(shù)據(jù)庫。后面由于需要修改一些數(shù)據(jù),網(wǎng)站頁面提示我們導(dǎo)入數(shù)據(jù)key的格式不對,而這個key,又被設(shè)置成了只讀,這就走入了死路。然后溝通能不能把數(shù)據(jù)庫數(shù)據(jù)刪除了重新導(dǎo)入,對方一萬個不情愿,讓我們自己在網(wǎng)站上自己刪除再添加數(shù)據(jù),那可是200多條數(shù)據(jù)啊,侮辱誰呢????

這真的把我同事們?nèi)敲?,然后就試了上面的招?shù),看了對方的JS,代理然后再一提交,成功?。。?/p>

知道對方業(yè)余,但沒想到這么業(yè)余:僅在前端做了限制,服務(wù)端沒校驗。

這個案例提醒我們,前端重在交互,服務(wù)端重在安全,JS是可篡改的;所以不要產(chǎn)品以為,要你以為,用你的專業(yè)Say no!!!;也告訴我們做技術(shù),謙虛點,能幫忙就盡量幫,做個好人。

結(jié)語

又摧拉枯朽扯了一堆,但愿對你以后的需求評審和方案設(shè)計有用。前端安全重要嗎?重要。網(wǎng)站的安全全交給前端合適嗎? 不合適。

以上就是W3Cschool編程獅關(guān)于前端安全就是紙老虎,唬人用的的相關(guān)介紹了,希望對大家有所幫助。

0 人點贊