在《8大前端安全問題（上）》這篇文章里我們談到了什么是前端安全問題，並且介紹了其中的4大典型安全問題，本篇文章將介紹剩下的4大前端安全問題，它們分別是：
-
防火防盜防豬隊友：不安全的第三方依賴包
-
用了HTTPS也可能掉坑里
-
本地存儲數據泄露
-
缺乏靜態資源完整性校驗
防火防盜防豬隊友：不安全的第三方依賴包
現如今進行應用開發，就好比站在巨人的肩膀上寫代碼。據統計，一個應用有將近80%的代碼其實是來自於第三方組件、依賴的類庫等，而應用自身的代碼其實只占了20%左右。無論是后端服務器應用還是前端應用開發，絕大多數時候我們都是在借助開發框架和各種類庫進行快速開發。
這樣做的好處顯而易見，但是與此同時安全風險也在不斷累積——應用使用了如此多的第三方代碼，不論應用自己的代碼的安全性有多高，一旦這些來自第三方的代碼有安全漏洞，那么對應用整體的安全性依然會造成嚴峻的挑戰。
（圖片來自：http://t.cn/RlAQsZ0）
舉個例子，jQuery就存在多個已知安全漏洞，例如jQuery issue 2432，使得應用存在被XSS攻擊的可能。而Node.js也有一些已知的安全漏洞，比如CVE-2017-11499，可能導致前端應用受到DoS攻擊。另外，對於前端應用而言，除使用到的前端開發框架之外，通常還會依賴不少Node組件包，它們可能也有安全漏洞。
手動檢查這些第三方代碼有沒有安全問題是個苦差事，主要是因為應用依賴的這些組件數量眾多，手工檢查太耗時，好在有自動化的工具可以使用，比如NSP(Node Security Platform)，Snyk等等。
用了HTTPS也可能掉坑里
為了保護信息在傳輸過程中不被泄露，保證傳輸安全，使用TLS或者通俗的講，使用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=<seconds>; includeSubDomains; preload
這里的“強制性”表現為瀏覽器無論在何種情況下都直接向服務器端發起HTTPS請求，而不再像以往那樣從HTTP跳轉到HTTPS。另外，當遇到證書或者鏈接不安全的時候，則首先警告用戶，並且不再讓用戶選擇是否繼續進行不安全的通信。
（圖片來自：http://t.cn/Rfj3Tku）
本地存儲數據泄露
以前，對於一個Web應用而言，在前端通過Cookie存儲少量用戶信息就足夠支撐應用的正常運行了。然而隨着前后端分離，尤其是后端服務無狀態化架構風格的興起，伴隨着SPA應用的大量出現，存儲在前端也就是用戶瀏覽器中的數據量也在逐漸增多。
前端應用是完全暴露在用戶以及攻擊者面前的，在前端存儲任何敏感、機密的數據，都會面臨泄露的風險，就算是在前端通過JS腳本對數據進行加密基本也無濟於事。
舉個例子來說明，假設你的前端應用想要支持離線模式，使得用戶在離線情況下依然可以使用你的應用，這就意味着你需要在本地存儲用戶相關的一些數據，比如說電子郵箱地址、手機號、家庭住址等PII（Personal Identifiable Information）信息，或許還有歷史賬單、消費記錄等數據。
盡管有瀏覽器的同源策略限制，但是如果前端應用有XSS漏洞，那么本地存儲的所有數據就都可能被攻擊者的JS腳本讀取到。如果用戶在公用電腦上使用了這個前端應用，那么當用戶離開后，這些數據是否也被徹底清除了呢？前端對數據加密后再存儲看上去是個防御辦法，但其實僅僅提高了一點攻擊門檻而已，因為加密所用到的密鑰同樣存儲在前端，有耐心的攻擊者依然可以攻破加密這道關卡。
所以，在前端存儲敏感、機密信息始終都是一件危險的事情，推薦的做法是盡可能不在前端存這些數據。
缺乏靜態資源完整性校驗
出於性能考慮，前端應用通常會把一些靜態資源存放到CDN（Content Delivery Networks）上面，例如Javascript腳本和Stylesheet文件。這么做可以顯著提高前端應用的訪問速度，但與此同時卻也隱含了一個新的安全風險。
如果攻擊者劫持了CDN，或者對CDN中的資源進行了污染，那么我們的前端應用拿到的就是有問題的JS腳本或者Stylesheet文件，使得攻擊者可以肆意篡改我們的前端頁面，對用戶實施攻擊。這種攻擊方式造成的效果和XSS跨站腳本攻擊有些相似，不過不同點在於攻擊者是從CDN開始實施的攻擊，而傳統的XSS攻擊則是從有用戶輸入的地方開始下手的。
防御這種攻擊的辦法是使用瀏覽器提供的SRI（Subresource Integrity）功能。顧名思義，這里的Subresource指的就是HTML頁面中通過<script>和<link>元素所指定的資源文件。
每個資源文件都可以有一個SRI值，就像下面這樣。它由兩部分組成，減號（-）左側是生成SRI值用到的哈希算法名，右側是經過Base64編碼后的該資源文件的Hash值。
<script src=“https://example.js” integrity=“sha384-eivAQsRgJIi2KsTdSnfoEGIRTo25NCAqjNJNZalV63WKX3Y51adIzLT4So1pk5tX”></script>
瀏覽器在處理這個script元素的時候，就會檢查對應的JS腳本文件的完整性，看其是否和script元素中integrity屬性指定的SRI值一致，如果不匹配，瀏覽器則會中止對這個JS腳本的處理。
小結
在上一篇和本篇文章中，我們為大家介紹了在開發前端應用的時候容易遇到的8大安全問題，它們是：
-
老生常談的XSS
-
警惕iframe帶來的風險
-
別被點擊劫持了
-
錯誤的內容推斷
-
防火防盜防豬隊友：不安全的第三方依賴包
-
用了HTTPS也可能掉坑里
-
本地存儲數據泄露
-
缺乏靜態資源完整性校驗
我們希望能通過對這些問題的介紹，引起前端開發小伙伴的注意，盡可能提前繞過這些安全問題的坑。