8大前端安全問題（下）
在《8大前端安全問題(上)》這篇文章里我們談到了什么是前端安全問題，并且介紹了其中的4大典型安全問題，本篇文章將介紹剩下的4大前端安全問題，它們分別是：
- 防火防盜防豬隊友：不安全的第三方依賴包
- 用了HTTPS也可能掉坑里
- 本地存儲數(shù)據(jù)泄露
- 缺乏靜態(tài)資源完整性校驗(yàn)
防火防盜防豬隊友：不安全的第三方依賴包
現(xiàn)如今進(jìn)行應(yīng)用開發(fā)，就好比站在巨人的肩膀上寫代碼。據(jù)統(tǒng)計，一個應(yīng)用有將近80%的代碼其實(shí)是來自于第三方組件、依賴的類庫等，而應(yīng)用自身的代碼其實(shí)只占了20%左右。無論是后端服務(wù)器應(yīng)用還是前端應(yīng)用開發(fā)，絕大多數(shù)時候我們都是在借助開發(fā)框架和各種類庫進(jìn)行快速開發(fā)。
這樣做的好處顯而易見，但是與此同時安全風(fēng)險也在不斷累積——應(yīng)用使用了如此多的第三方代碼，不論應(yīng)用自己的代碼的安全性有多高，一旦這些來自第三方的代碼有安全漏洞，那么對應(yīng)用整體的安全性依然會造成嚴(yán)峻的挑戰(zhàn)。
(圖片來自：http://t.cn/RlAQsZ0)
舉個例子，jQuery就存在多個已知安全漏洞，例如jQuery issue 2432，使得應(yīng)用存在被XSS攻擊的可能。而Node.js也有一些已知的安全漏洞，比如CVE-2017-11499，可能導(dǎo)致前端應(yīng)用受到DoS攻擊。另外，對于前端應(yīng)用而言，除使用到的前端開發(fā)框架之外，通常還會依賴不少Node組件包，它們可能也有安全漏洞。
手動檢查這些第三方代碼有沒有安全問題是個苦差事，主要是因?yàn)閼?yīng)用依賴的這些組件數(shù)量眾多，手工檢查太耗時，好在有自動化的工具可以使用，比如NSP(Node Security Platform)，Snyk等等。
用了HTTPS也可能掉坑里
為了保護(hù)信息在傳輸過程中不被泄露，保證傳輸安全，使用TLS或者通俗的講，使用HTTPS已經(jīng)是當(dāng)今的標(biāo)準(zhǔn)配置了。然而事情并沒有這么簡單，即使是服務(wù)器端開啟了HTTPS，也還是存在安全隱患，黑客可以利用SSL Stripping這種攻擊手段，強(qiáng)制讓HTTPS降級回HTTP，從而繼續(xù)進(jìn)行中間人攻擊。
問題的本質(zhì)在于瀏覽器發(fā)出去第一次請求就被攻擊者攔截了下來并做了修改，根本不給瀏覽器和服務(wù)器進(jìn)行HTTPS通信的機(jī)會。大致過程如下，用戶在瀏覽器里輸入URL的時候往往不是從https://開始的，而是直接從域名開始輸入，隨后瀏覽器向服務(wù)器發(fā)起HTTP通信，然而由于攻擊者的存在，它把服務(wù)器端返回的跳轉(zhuǎn)到HTTPS頁面的響應(yīng)攔截了，并且代替客戶端和服務(wù)器端進(jìn)行后續(xù)的通信。由于這一切都是暗中進(jìn)行的，所以使用前端應(yīng)用的用戶對此毫無察覺。
解決這個安全問題的辦法是使用HSTS(HTTP Strict Transport Security)，它通過下面這個HTTP Header以及一個預(yù)加載的清單，來告知瀏覽器在和網(wǎng)站進(jìn)行通信的時候強(qiáng)制性的使用HTTPS，而不是通過明文的HTTP進(jìn)行通信：
- Strict-Transport-Security: max-age=<seconds>; includeSubDomains; preload
這里的“強(qiáng)制性”表現(xiàn)為瀏覽器無論在何種情況下都直接向服務(wù)器端發(fā)起HTTPS請求，而不再像以往那樣從HTTP跳轉(zhuǎn)到HTTPS。另外，當(dāng)遇到證書或者鏈接不安全的時候，則首先警告用戶，并且不再讓用戶選擇是否繼續(xù)進(jìn)行不安全的通信。
(圖片來自：http://t.cn/Rfj3Tku)
本地存儲數(shù)據(jù)泄露
以前，對于一個Web應(yīng)用而言，在前端通過Cookie存儲少量用戶信息就足夠支撐應(yīng)用的正常運(yùn)行了。然而隨著前后端分離，尤其是后端服務(wù)無狀態(tài)化架構(gòu)風(fēng)格的興起，伴隨著SPA應(yīng)用的大量出現(xiàn)，存儲在前端也就是用戶瀏覽器中的數(shù)據(jù)量也在逐漸增多。
前端應(yīng)用是完全暴露在用戶以及攻擊者面前的，在前端存儲任何敏感、機(jī)密的數(shù)據(jù)，都會面臨泄露的風(fēng)險，就算是在前端通過JS腳本對數(shù)據(jù)進(jìn)行加密基本也無濟(jì)于事。
舉個例子來說明，假設(shè)你的前端應(yīng)用想要支持離線模式，使得用戶在離線情況下依然可以使用你的應(yīng)用，這就意味著你需要在本地存儲用戶相關(guān)的一些數(shù)據(jù)，比如說電子郵箱地址、手機(jī)號、家庭住址等PII(Personal Identifiable Information)信息，或許還有歷史賬單、消費(fèi)記錄等數(shù)據(jù)。
盡管有瀏覽器的同源策略限制，但是如果前端應(yīng)用有XSS漏洞，那么本地存儲的所有數(shù)據(jù)就都可能被攻擊者的JS腳本讀取到。如果用戶在公用電腦上使用了這個前端應(yīng)用，那么當(dāng)用戶離開后，這些數(shù)據(jù)是否也被徹底清除了呢?前端對數(shù)據(jù)加密后再存儲看上去是個防御辦法，但其實(shí)僅僅提高了一點(diǎn)攻擊門檻而已，因?yàn)榧用芩玫降拿荑€同樣存儲在前端，有耐心的攻擊者依然可以攻破加密這道關(guān)卡。
所以，在前端存儲敏感、機(jī)密信息始終都是一件危險的事情，推薦的做法是盡可能不在前端存這些數(shù)據(jù)。
缺乏靜態(tài)資源完整性校驗(yàn)
出于性能考慮，前端應(yīng)用通常會把一些靜態(tài)資源存放到CDN(Content Delivery Networks)上面，例如Javascript腳本和Stylesheet文件。這么做可以顯著提高前端應(yīng)用的訪問速度，但與此同時卻也隱含了一個新的安全風(fēng)險。
如果攻擊者劫持了CDN，或者對CDN中的資源進(jìn)行了污染，那么我們的前端應(yīng)用拿到的就是有問題的JS腳本或者Stylesheet文件，使得攻擊者可以肆意篡改我們的前端頁面，對用戶實(shí)施攻擊。這種攻擊方式造成的效果和XSS跨站腳本攻擊有些相似，不過不同點(diǎn)在于攻擊者是從CDN開始實(shí)施的攻擊，而傳統(tǒng)的XSS攻擊則是從有用戶輸入的地方開始下手的。
防御這種攻擊的辦法是使用瀏覽器提供的SRI(Subresource Integrity)功能。顧名思義，這里的Subresource指的就是HTML頁面中通過
- <script src=“https://example.js” integrity=“sha384-eivAQsRgJIi2KsTdSnfoEGIRTo25NCAqjNJNZalV63WKX3Y51adIzLT4So1pk5tX”></script>
瀏覽器在處理這個script元素的時候，就會檢查對應(yīng)的JS腳本文件的完整性，看其是否和script元素中integrity屬性指定的SRI值一致，如果不匹配，瀏覽器則會中止對這個JS腳本的處理。
小結(jié)
在上一篇和本篇文章中，我們?yōu)榇蠹医榻B了在開發(fā)前端應(yīng)用的時候容易遇到的8大安全問題，它們是：
- 老生常談的XSS
- 警惕iframe帶來的風(fēng)險
- 別被點(diǎn)擊劫持了
- 錯誤的內(nèi)容推斷
- 防火防盜防豬隊友：不安全的第三方依賴包
- 用了HTTPS也可能掉坑里
- 本地存儲數(shù)據(jù)泄露
- 缺乏靜態(tài)資源完整性校驗(yàn)
我們希望能通過對這些問題的介紹，引起前端開發(fā)小伙伴的注意，盡可能提前繞過這些安全問題的坑。
【本文是51CTO專欄作者“ThoughtWorks”的原創(chuàng)稿件，微信公眾號：思特沃克，轉(zhuǎn)載請聯(lián)系原作者】
