8 大前端安全問題（下）

在《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進行通訊：

這裡的“強制性”表現為瀏覽器無論在何種情況下都直接向伺服器端發起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頁面中通過和元素所指定的資原始檔。

每個資原始檔都可以有一個SRI值，就像下面這樣。它由兩部分組成，減號（-）左側是生成SRI值用到的雜湊演算法名，右側是經過Base64編碼後的該資原始檔的Hash值。

瀏覽器在處理這個script元素的時候，就會檢查對應的JS指令碼檔案的完整性，看其是否和script元素中integrity屬性指定的SRI值一致，如果不匹配，瀏覽器則會中止對這個JS指令碼的處理。

小結

在上一篇和本篇文章中，我們為大家介紹了在開發前端應用的時候容易遇到的8大安全問題，它們是：

• 老生常談的XSS
• 警惕iframe帶來的風險
• 別被點選劫持了
• 錯誤的內容推斷
• 防火防盜防豬隊友：不安全的第三方依賴包
• 用了HTTPS也可能掉坑裡
• 本地儲存資料洩露
• 缺乏靜態資源完整性校驗

我們希望能通過對這些問題的介紹，引起前端開發小夥伴的注意，儘可能提前繞過這些安全問題的坑。