從***看防護——前端視野下的web安全思考

做者：徐嘉偉--騰訊高級前端工程師

@IMWeb前端社區

各端安全之爭

受開發職能劃分的影響，不少人也會下意識地把web安全劃分爲前端安全和後端安全。更有甚者，甚至會延伸出探討前端安全與後端安全哪一個重要之類的爭論。或許做爲前端的你，曾經也會聽到相似前端安全無心義論的聲音，理由大概有：①前端代碼開源暴露於瀏覽器，不安全；②前端影響面侷限於單用戶瀏覽器，不重要；林林總總。

但爭論並無意義，重要的是靜下來思考。

從新思考

本人近期對自身業務進行了一遍web安全梳理，對web安全有了必定的思考。因自身崗位視野的限制，在對web安全的思考上，不免會有必定的侷限性，故題目加上了「前端視野下」這樣的修飾詞，但願個人思考能給你們帶來收穫。

web安全，我的認爲更多的是一個體系性的東西，目的是爲了保護web系統的安全。它既須要單端防護（前端或後端），同時又須要先後端相互配合防護。

我的定義的web安全

那究竟什麼是web安全呢？web安全，通俗說就是對***進行防範。兩個核心名詞：***、防範。

***是***者作的，防範則是web平臺提供方要完成的行爲。因此，咱們不妨換個思路——從***來看防護。

從***看防護

一、***的目的

壞人要***你，總有他的緣由，有的爲了盜取你的密碼，有的爲了查看你的隱私，林林總總。總結起來，我的認爲其實能夠概括爲兩類：

①竊取用戶信息

       獲取用戶登陸態、獲取賬號密碼、獲取用戶私密信息等等；信息獲取後就能夠作更多事了，如冒用用戶身份、盜取賬號資產、售賣用戶隱私等。

②致使產品沒法正常使用

       頻繁調用服務器接口以搞垮服務器，同類產品的競爭，不免會存在此類目的的***。相信紅包大戰下，除了表面的一片繁華外，也會暗藏着對手對咱們的***吧。

正因要達到以上目的，纔會產生具體的***行爲。而有***行爲，固然也會有與之對應的***對象，因此思考***行爲前，咱們不妨先看下web的***對象。

二、***對象&***武器

***行爲必然地會對應到具體的***對象上，而web***的***對象天然就是web體系內的東西了。我的認爲***對象有三大塊：瀏覽器、傳輸通道、服務器，這也是web體系的核心內容。

上圖中綠色箭頭表明的是數據的流向。在web體系中，數據是前端與後端通訊的惟一標識，但同時也是***者***的有利武器。

說到這裏，是否是對***的本質很明朗了呢。

三、***的本質

web***，本質上是***者經過一系列***方式，利用數據流對***對象（瀏覽器、傳輸通道、服務器）進行***，只要其中一個***對象被成功攻破，便能達成***目的。

咱們web安全要作的防護，實質上是針對每種***手段，判斷其要***的對象，並對***對象實施保護。

讓咱們從***對象看***方式，並針對具體***方式思考防護方式吧。

四、從***的具體對象，看防護方式

①***傳輸通道

web中的傳輸通道有兩種：

       狹義上來看，是鏈接瀏覽器和服務器的網絡通道，數據從瀏覽器端發出，經過網絡通道，到達服務器，服務器再把數據結果經過網絡通道返回到瀏覽器。

       廣義上來看，還包括網站的傳播，好比把網址地址經過微信或手Q分享、QQ消息或郵件或博客或論壇傳播等等。

對傳輸通道的***，兩種類型通道的***手段相似，有兩種：數據竊取、數據篡改，對應的防護方法是數據加密、參數簽名。

         一、數據加密：

         因前端代碼開源於瀏覽器，通常會採用非對稱加密算法，後臺把公鑰和有時效性的隨機數傳給前端，前端經過非對稱加密算法（如：rsa算法）將原數據加密後再發送給後臺，後臺再根據私鑰進行解密，得到原數據。這樣即便數據到達傳輸通道被人截取了，對方沒有私鑰，其截取到的數據也是沒有意義的。

         上述防護方案能夠看出，數據加密的防護手段須要前端和後臺配合完成，而不只僅只需某一端防護。

         二、數據簽名：

         對於微信分享之類的傳播通道，頁面的url在傳播過程當中很容易被篡改，如對url參數進行篡改。爲了防護該類***，每每須要對url參數進行簽名，並在url上帶上簽名參數。這樣，若是在傳輸過程當中url參數被篡改，因最終簽名串驗證不一致，後臺會進行攔截，防止該類***。（也因前端代碼開源於瀏覽器，簽名方法通常由後臺或本地控件（程序/原生app）提供，前端直接調用來簽名。）

         上述方案可見，數據簽名的防護手段依然是須要前端和後臺配合的，僅靠其中一端依然不可行。

②***瀏覽器

瀏覽器，是前端代碼的運行平臺。該類***是數據抵達瀏覽器後進行的***。主要***方式有兩種：利用瀏覽器特性***、利用前端邏輯漏洞***。

         一、利用瀏覽器特性***：

         以XSS***爲例，XSS***實際上利用的是瀏覽器HTML的解析特性。HTML內容其實自己就是一串字符串。瀏覽器在解析HTML這些字符串的時候，當解析到具體的HTML語法標籤，就會按照特定語法特性去解析而非當作字符串解析。XSS***利用的正是這點特性，當頁面上有渲染非可控數據時（如用戶本身輸入的數據），若數據爲html代碼，瀏覽器不加防護的話，數據就會被瀏覽器看成代碼渲染執行，好比若數據爲「<script src=「/****者腳本地址*/></script>」，就會去加載一個***者的惡意腳本，而當這個數據能被不少人的頁面看見時（如文章、暱稱、評論等等），***者就能在不少人的頁面上隨心所欲了（執行惡意腳本）。

         爲了防護XSS***，須要頁面自身進行防護，頁面需對非可控數據在渲染前進行過濾處理，過濾方法以下：

         可見，對於利用瀏覽器特性進行的***，通常直接由前端保護便可，後臺的保護更多的只能是提升***門檻而已。（既即便後臺作了過濾，前端仍是須要再作一次的，由於***對象是瀏覽器側的，而數據來源不只僅來源於後臺。該***的本質在前端）

         二、利用前端邏輯漏洞***：

         以URL***爲例。該類***利用的是頁面跳轉邏輯漏洞。（常見於登陸超時後，用戶從新登陸跳回到登陸前的頁面）以下例子代碼所示，頁面跳轉地址依賴於url上非可控參數target，頁面執行完必定操做後（如登陸），會跳轉到target參數值的地址：https://testhost.com/target.shtml。

          而若是前端沒有對該非可控參數（target）實施防護措施（域名白名單過濾等），這個時候很容易被***者利用這一邏輯，把目標地址配成本身釣魚網站。

         爲了防護URL***，需前端對非可控參數（target）增長一層域名白名單過濾判斷，如：

          可見，對於利用前端邏輯漏洞***，仍需由前端自身進行保護。

③***服務器

          服務器，是後臺代碼的運行平臺。該類***是數據對服務器進行的***。***方式與***瀏覽器的方式是相似的，也可分爲兩種：利用服務器特性***、利用服務器邏輯漏洞***。

          一、利用服務器特性***：

         以SQL***爲例。該***其實跟前端的XSS***是同理的，只不過如今要***的對象是後臺數據庫，因此***手段須要針對SQL的特性進行，即發送SQL語法的***性語句，若是後臺沒有實施防護措施，數據就會被當作SQL指令來執行而非普通字符串。防護措施就是對傳入數據進行過濾。

         又以文件上傳***爲例，也是同理的，只不過***對象是後臺的服務器。***者把***性的可執行文件上傳到服務器後臺（好比若後臺語言採用的是php，上傳一php的惡意腳本到服務器），一旦後臺沒有防範，腳本運行，服務器就會被攻破。防護措施是對上傳的文件進行格式判斷、隔離存儲等等。

         可見，與前端同類的這一***，對於利用服務器特性進行的***，通常需由後臺直接保護，前端的保護（前端過濾）更多的只能是提升***門檻。（由於***對象是服務器側的，而前端是能夠被繞過的）

          二、利用後臺邏輯漏洞***：

         後臺邏輯有不少種，這裏以信任邏輯爲例。我的把信任邏輯大體分爲如下三種：

         a、權限區分

         即有無作好角色權限控制。以紅包爲例，要限制只能當前紅包發的羣裏面的人有權限領取，非羣內人員沒法領取。而若是沒有作區分限制的話，一旦被檢查到有角色權限控制不嚴謹的漏洞，就會被利用上這個「官方的」可越權通道進行越權操做（領取無權限紅包）。

         該邏輯漏洞的***須要後臺進行防範，作好嚴謹的權限區分。

         b、惡意用戶識別

         即有無作好惡意用戶監控，識別惡意用戶並作出防護措施。以惡意***爲例，若是***者頻繁調用某接口想要拖垮服務器時，服務器要能快速識別，並作出防護策略（如調用頻率超過必定次數時增長圖片驗證碼校驗或拒絕訪問等）。若是沒有相關防護措施，服務器就會由於這一個接口的頻繁訪問而拖垮，致使產品沒法使用。

         該邏輯漏洞的***也是須要後臺進行防範的。

         c、假裝用戶識別

         即可否正確的識別當前用戶就是該用戶，而非別人。假裝用戶的行爲因涉及到用戶側，因此與前面的***方式不一樣，該類***通常利用的是瀏覽器的特性，而***對象倒是服務器(後臺識別用戶的邏輯不嚴謹）。

         這裏以CSRF***爲例。

         CSRF***利用的是瀏覽器cookies的同源策略，cookies在瀏覽器上是以域名區分存儲的，但同時又共享於全部的標籤頁。當用戶登陸了目標網站（cookies中含有登陸態），中途若是又被引誘進入了釣魚網站，這時釣魚網站就假裝成用戶給目標網站發請求了（因會帶上cookies，cookies上帶有登陸態）。

         因這一特性的存在，後臺識別用戶的邏輯不能僅靠自身寫入cookies中的登陸態，還應藉助前端額外的一些參數進行校驗。

         CSRF的防護措施也是利用的瀏覽器特性：即cookies只能被同域名頁面獲取。前端需在每一個請求均帶上一個cookies中獲取的token傳參，後臺收到的每一個請求都會校驗該token比對下。目前通常的作法是前端獲取cookies中的登陸態skey並作下簡單的加密後傳給後臺，後臺進行判斷處理。

         可見，對於僅僅利用服務器邏輯漏洞進行的***，僅需後臺進行防範便可。而若是還利用了瀏覽器特性進行的***，此時還須要前端和後臺同時配合防護的。

結語

最後，感謝各位的耐心閱讀。

作個簡單的總結。其實經過上面的思考分析，能夠發現web實際上是一個端對端的體系。***是針對某一端或者端與端之間的通道進行的。若是***的對象是通道，此時每每須要兩端協助進行防護；若是***對象與***利用的漏洞同在某一端，則每每只需該端自身進行防護便可；若是***對象和***利用的漏洞不在同一端，此時每每須要兩端協助防護。