前端安全機制與解決方案

1、概述

　　「安全」是個很大的話題，各類安全問題的類型也是種類繁多。若是咱們把安全問題按照所發生的區域來進行分類的話，那麼全部發生在後端服務器、應用、服務當中的安全問題就是「後端安全問題」，全部發生在瀏覽器、單頁面應用、Web頁面當中的安全問題則算是「前端安全問題」。好比說，SQL注入漏洞發生在後端應用中，是後端安全問題，跨站腳本攻擊（XSS）則是前端安全問題，由於它發生在用戶的瀏覽器裏。

2、常見前端安全問題及防禦

一、跨站腳本攻擊（Cross-Site Scripting）

　　XSS是跨站腳本攻擊（Cross-Site Scripting）的簡稱。XSS這類安全問題發生的本質緣由在於：瀏覽器錯誤的將攻擊者提供的用戶輸入數據當作JavaScript腳本給執行了。
　　XSS有幾種不一樣的分類辦法，例如按照惡意輸入的腳本是否在應用中存儲，XSS被劃分爲「存儲型XSS」和「反射型XSS」，若是按照是否和服務器有交互，又能夠劃分爲「Server Side XSS」和「DOM based XSS」。
　　不管怎麼分類，XSS漏洞始終是威脅用戶的一個安全隱患。攻擊者能夠利用XSS漏洞來竊取包括用戶身份信息在內的各類敏感信息、修改Web頁面以欺騙用戶，甚至控制受害者瀏覽器，或者和其餘漏洞結合起來造成蠕蟲攻擊，等等。總之，關於XSS漏洞的利用，只有想不到沒有作不到。

　　如何防護？

　　對數據進行嚴格的輸出編碼，使得攻擊者提供的數據再也不被瀏覽器認爲是腳本而被誤執行。例如<script>在進行HTML編碼後變成了&lt;script&gt;，這段數據就不會被當作腳本執行了。
須要根據輸出數據所在的上下文來進行相應的編碼。數據放置於HTML元素中，需進行HTML編碼，放置於URL中，須要進行URL編碼。此外，還有JavaScript編碼、CSS編碼、HTML屬性編碼、JSON編碼等等。(一些主流前端開發框架基本上都默認提供了前端輸出編碼，這大大減輕了前端開發小夥伴們的工做負擔)
　　其餘的防護措施，例如設置CSP HTTP Header、輸入驗證、開啓瀏覽器XSS防護等等都是可選項，緣由在於這些措施都存在被繞過的可能，並不能徹底保證能防護XSS攻擊。不過它們和輸出編碼卻能夠共同協做實施縱深防護策略。

二、使用iframe的風險

　　有時前端頁面須要用到第三方提供的頁面組件，一般會以iframe的方式引入。典型的例子是使用iframe在頁面上添加第三方提供的廣告、天氣預報、社交分享插件等等。　　
　　iframe在給咱們的頁面帶來更多豐富的內容和能力的同時，也帶來了很多的安全隱患。由於iframe中的內容是由第三方來提供的，默認狀況下他們不受咱們的控制，他們能夠在iframe中運行JavaScirpt腳本、Flash插件、彈出對話框等等，這可能會破壞前端用戶體驗。
　　若是說iframe只是有可能會給用戶體驗帶來影響，看似風險不大，那麼若是iframe中的域名由於過時而被惡意攻擊者搶注，或者第三方被黑客攻破，iframe中的內容被替換掉了，從而利用用戶瀏覽器中的安全漏洞下載安裝木馬、惡意勒索軟件等等，這問題可就大了。

　　如何防護？

　　在HTML5中，iframe有個sandbox安全屬性，經過它能夠對iframe的行爲進行各類限制，充分實現「最小權限「原則。例如： <iframe sandbox src="..."> ... </iframe>
sandbox提供了豐富的配置參數，能夠進行較爲細粒度的控制。
　　allow-forms：容許iframe中提交form表單
　　allow-popups：容許iframe中彈出新的窗口或者標籤頁（例如，window.open()，showModalDialog()，target=」_blank」等等）
　　allow-scripts：容許iframe中執行JavaScript
　　allow-same-origin：容許iframe中的網頁開啓同源策略
　　更多詳細的資料，能夠參考iframe中關於sandbox的介紹。

三、點擊劫持

　　這是一種欺騙性比較強，同時也須要用戶高度參與才能完成的一種攻擊。一般的攻擊步驟是這樣的：
　　一、攻擊者構造一個誘導用戶點擊的內容，如Web頁面小遊戲
　　二、將被攻擊的頁面放入到iframe當中
　　三、利用z-index等CSS樣式將這個iframe疊加到小遊戲的垂直方向的正上方
　　四、把iframe設置爲100%透明度
　　五、受害者訪問這個頁面，肉眼看到的是一個小遊戲，若是受到誘導進行了點擊的話，實際上點擊到的倒是iframe中的頁面
　　點擊劫持的危害在於，攻擊利用了受害者的用戶身份，在其不知情的狀況下進行一些操做。

如何防護？

　　有多種防護措施均可以防止頁面遭到點擊劫持攻擊，例如Frame Breaking方案。一個推薦的防護方案是，使用X-Frame-Options：DENY 這個HTTP Header來明確的告知瀏覽器，不要把當前HTTP響應中的內容在HTML Frame中顯示出來。

　　關於點擊劫持更多的細節，能夠查閱OWASP Clickjacking Defense Cheat Sheet。連接地址：https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet

四、錯誤的內容推斷

　　攻擊場景：某網站容許用戶在評論裏上傳圖片，攻擊者將含有惡意JavaScript的腳本文件擴展名改爲圖片格式進行上傳（這涉及到了惡意文件上傳這個常見安全問題，可是因爲和前端相關度不高所以暫不詳細介紹）。接下來，受害者在訪問這段評論的時候，瀏覽器會去請求這個假裝成圖片的JavaScript腳本，而此時若是瀏覽器錯誤的推斷了這個響應的內容類型（MIME types），那麼就會把這個圖片文件當作JavaScript腳本執行，因而攻擊也就成功了。
　　問題的關鍵：後端服務器在返回的響應中設置的Content-Type Header僅僅只是給瀏覽器提供當前響應內容類型的建議，而瀏覽器有可能會自做主張的根據響應中的實際內容去推斷內容的類型。
　　上例中，後端經過Content-Type Header建議瀏覽器按圖片來渲染HTTP響應，但瀏覽器發現響應的實際上是JavaScript，因而就擅自作主把這段響應當作JS腳原本解釋執行，安全問題也就產生了。

如何防護？
　　瀏覽器根據響應內容來推斷其類型，原本這是個很「智能」的功能，是瀏覽器強大的容錯能力的體現，可是卻會帶來安全風險。要避免出現這樣的安全問題，辦法就是經過設置X-Content-Type-Options這個HTTP Header明確禁止瀏覽器去推斷響應類型。
　　一樣是上面的攻擊場景，後端服務器返回的Content-Type建議瀏覽器按照圖片進行內容渲染，瀏覽器發現有X-Content-Type-Options HTTP Header的存在，而且其參數值是nosniff，所以不會再去推斷內容類型，而是強制按照圖片進行渲染，從而最終防止了安全問題的發生。
　　更多關於X-Content-Type-Options的細節請參考：https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options

五、不安全的第三方依賴包

　　現現在進行應用開發，不管是後端服務器應用仍是前端應用開發，絕大多數時候咱們都是在藉助開發框架和各類類庫進行快速開發。
　　這樣作的好處顯而易見，可是與此同時安全風險也在不斷累積——應用使用瞭如此多的第三方代碼，不論應用本身的代碼的安全性有多高，一旦這些來自第三方的代碼有安全漏洞，那麼對應用總體的安全性依然會形成嚴峻的挑戰。

如何防護？

　　儘可能減小第三方依賴，選用相對成熟的依賴包。
　　使用自動化工具檢查這些第三方代碼有沒有安全問題，好比NSP(Node Security Platform)，Snyk等等。

六、HTTPS中間人攻擊

　　即便是服務器端開啓了HTTPS，也仍是存在安全隱患，黑客能夠利用SSL Stripping這種攻擊手段，強制讓HTTPS降級回HTTP，從而繼續進行中間人攻擊。
　　問題的本質在於瀏覽器發出去第一次請求就被攻擊者攔截了下來並作了修改，根本不給瀏覽器和服務器進行HTTPS通訊的機會。大體過程以下，用戶在瀏覽器裏輸入URL的時候每每不是從https://開始的，而是直接從域名開始輸入，隨後瀏覽器向服務器發起HTTP通訊，然而因爲攻擊者的存在，它把服務器端返回的跳轉到HTTPS頁面的響應攔截了，而且代替客戶端和服務器端進行後續的通訊。因爲這一切都是暗中進行的，因此使用前端應用的用戶對此毫無察覺。

如何防護？

　　解決這個安全問題的辦法是使用HSTS（HTTP Strict Transport Security），它經過下面這個HTTP Header以及一個預加載的清單，來告知瀏覽器在和網站進行通訊的時候強制性的使用HTTPS，而不是經過明文的HTTP進行通訊：

　　Strict-Transport-Security: max-age=; includeSubDomains; preload

　　這裏的「強制性」表現爲瀏覽器不管在何種狀況下都直接向服務器端發起HTTPS請求，而再也不像以往那樣從HTTP跳轉到HTTPS。另外，當遇到證書或者連接不安全的時候，則首先警告用戶，而且再也不讓用戶選擇是否繼續進行不安全的通訊。

 

7 、本地存儲數據泄露

　　隨着先後端分離，尤爲是後端服務無狀態化架構風格的興起，隨着SPA應用大量出現，存儲在前端數據量也在逐漸增多。

　　前端應用是徹底暴露在用戶以及攻擊者面前的，在前端存儲任何敏感、機密的數據，都會面臨泄露的風險，就算是在前端經過JS腳本對數據進行加密基本也無濟於事。

　　儘管有瀏覽器的同源策略限制，可是若是前端應用有XSS漏洞，那麼本地存儲的全部數據就均可能被攻擊者的JS腳本讀取到。若是用戶在公用電腦上使用了這個前端應用，那麼當用戶離開後，這些數據是否也被完全清除了呢？前端對數據加密後再存儲看上去是個防護辦法，但其實僅僅提升了一點攻擊門檻而已，由於加密所用到的密鑰一樣存儲在前端，有耐心的攻擊者依然能夠攻破加密這道關卡。

　　因此，在前端存儲敏感、機密信息始終都是一件危險的事情，推薦的作法是儘量不在前端存這些數據。

如何防護？

 

8 、CDN劫持/污染

　　以出於性能考慮，前端應用一般會把一些靜態資源存放到CDN上，再提升前端應用的訪問速度的同時也隱含了一個新的安全風險。

若是攻擊者劫持了CDN，或者對CDN中的資源進行了污染，那麼咱們的前端應用拿到的就是有問題的JS腳本或者Stylesheet文件。這種攻擊方式形成的效果和XSS跨站腳本攻擊類似。

如何防護？

　　防護這種攻擊的辦法是使用瀏覽器提供的SRI（Subresource Integrity）功能。

　　每一個資源文件都有一個SRI值。由兩部分組成，減號（-）左側是生成SRI值用到的哈希算法名，右側是通過Base64編碼後的該資源文件的Hash值。<script src="「https://example.js」" integrity="「sha384-eivAQsRgJIi2KsTdSnfoEGIRTo25NCAqjNJNZalV63WKX3Y51adIzLT4So1pk5tX」"/>

　　瀏覽器在處理這個script元素的時候，就會檢查對應的JS腳本文件的完整性，看其是否和script元素中integrity屬性指定的SRI值一致，若是不匹配，瀏覽器則會停止對這個JS腳本的處理。