安全測試===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進行通訊：

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也可能掉坑裏

• 本地存儲數據泄露

• 缺少靜態資源完整性校驗

咱們但願能經過對這些問題的介紹，引發前端開發小夥伴的注意，儘量提早繞過這些安全問題的坑。