基于NodeJS的前后端分離的思考與實踐(四)安全問題解決方案

1、基于 NodeJS 的前后端分離的思考與實踐（四）安全問題解決方案前言在前后端分離的開發(fā)模式中，從開發(fā)的角色和職能上來講， 一個最明顯的變化就是：以往傳統(tǒng)中，只負責瀏覽器環(huán)境中開發(fā)的前端同學(xué)， 需要涉獵到服務(wù)端層面，編寫服務(wù)端代碼。而擺在面前的一個基礎(chǔ)性問題就是如何保障Web 安 全 ？ 本文就在前后端分離模式的架構(gòu)下，針對前端在Web 開發(fā)中，所遇到的安全問題以及應(yīng)對措施和注意事項，并提出解決方案。跨站腳本攻擊 (XSS) 的防御問題及解決思路跨站腳本攻擊（XSS， Cross-site scripting ）是最常見和基本的攻擊 Web 網(wǎng)站的方法。 攻擊者可以在網(wǎng)頁上發(fā)布包含攻擊性代碼的

2、數(shù)據(jù)，當瀏覽者看到此網(wǎng)頁時，特定的腳本就會以瀏覽者用戶的身份和權(quán)限來執(zhí)行。通過 XSS 可以比較容易地修改用戶數(shù)據(jù)、竊取用戶信息以及造成其它類型的攻擊，例如： CSRF 攻擊。預(yù)防 XSS 攻擊的基本方法是：確保任何被輸出到 HTML 頁面中的數(shù)據(jù)以 HTML 的方式進行轉(zhuǎn)義（ HTML escape ）。例如下面的模板代碼：代碼如下 :復(fù)制代碼開發(fā)者可以這樣寫模板：$description 這段代碼中的 $description為模板的變量 （不同模板中定義的變量語法不同，這里只是示意一下），由用戶提交的數(shù)據(jù)，那么攻擊者可以輸入一段包含”JavaScript”的代碼，使得上述模板語句的結(jié)果變

3、成如下的結(jié)果：復(fù)制代碼代碼如下 :alert(hello) 上述代碼， 在瀏覽器中渲染， 將會執(zhí)行 JavaScript 代碼并在屏幕上alert hello 。當然這個代碼是無害的，但攻擊者完全可以創(chuàng)建一個JavaScript 來修改用戶資料或者竊取cookie 數(shù)據(jù)。解決方法很簡單，就是將$description的值進行 html escape， 轉(zhuǎn)義后的輸出代碼如下復(fù)制代碼代碼如下 :alert(hello!)以上經(jīng)過轉(zhuǎn)義后的HTML代碼是沒有任何危害的。Midway的解決方案轉(zhuǎn)義頁面中所有用戶輸出的數(shù)據(jù)對數(shù)據(jù)進行轉(zhuǎn)義有以下幾種情況和方法：使用模板內(nèi)部提供的機制進行轉(zhuǎn)義中途島內(nèi)部使用KI

4、SSY xtemplate作為模板語言。在 xtemplate 實現(xiàn)中，語法上使用兩個中括號（val）解析模板數(shù)據(jù)，默認既是對數(shù)據(jù)進行HTML轉(zhuǎn)義的，所以Security.escapeHtml 進行沒有對數(shù)據(jù)進行轉(zhuǎn)義的時候才使用description在 xtemplate 中，如果不希望輸出的數(shù)據(jù)被轉(zhuǎn)義，需要使用三個中括號（val）。在 Midway中明確的調(diào)用轉(zhuǎn)義函數(shù)開發(fā)者可以在Node.js 程序或者模板中，直接調(diào)用Midway 提供的 HTML轉(zhuǎn)義方法，顯示的對數(shù)據(jù)進行轉(zhuǎn)義，如下： 方法 1：在 Node.js 程序中對數(shù)據(jù)進行HTML轉(zhuǎn)義復(fù)制代碼代碼如下 :var Security=

5、require(midway-security);/data from server， eg html: ，other:data.html =Security.escapeHtml(data.html);xtpl = xtpl.render(data); 方法 2：在模板中對HTML數(shù)據(jù)進行HTML轉(zhuǎn)義復(fù)制代碼代碼如下 :Security.escapeHtml(description)注意：只有當模板內(nèi)部轉(zhuǎn)義。否則，模板內(nèi)部和程序會兩次轉(zhuǎn)義疊加，導(dǎo)致不符述的富文本數(shù)據(jù)如果直接輸出到頁面中，必然會導(dǎo)致合預(yù)期的輸出。推薦：如果使用 xtemplate，建議直接使用模板內(nèi)置的 進行轉(zhuǎn)義； 如果使用其

6、他模板，建議使用 Security.escapeHtml 進行轉(zhuǎn)義。過濾頁面中用戶輸出的富文本你可能會想到： “其實我就是想輸出富文本，比如一些留言板、論壇給用戶提供一些簡單的字體大小、顏色、背景等功能，那么我該如何處理這樣的富文本來防止XSS 呢？”1.使用 Midway中 Security 提供的 richText函數(shù)Midway中提供了 richText方法， 專門用來過濾富文本，防止XSS、釣魚、 cookie竊取等漏洞。有一個留言板，模板代碼可能如下：復(fù)制代碼代碼如下 :message因為 message是用戶的輸入數(shù)據(jù)，其留言板的內(nèi)容，包含了富文本信息，所以這里在xtemplate

7、 中，使用了三個大括號，默認不進行HTML轉(zhuǎn)義； 那么用戶輸入的數(shù)據(jù)假如如下：復(fù)制代碼代碼如下 : HYPERLINK /eval.js /eval.jsstyle=color:red;font-size:20px;position:fixed;我在留言中上 站點的js 注入到當前頁面中，造成了 XSS 攻擊。為錯誤，例如： HYPERLINK http:/localhost/page/not/found http:/localhost/page/not/found了防止這個漏洞，我們只要在模板或者程序中，調(diào)用Security.richText方法，處理用戶輸入的富文本。 調(diào)用方法與escap

8、eHtml 類似，有如下兩種方式方法 1:直接在 Node.js 程序中調(diào)用復(fù)制代碼代碼如下 :message =Security.richText(message);var html = xtpl.render(message) 方法 2： 在模板中調(diào)用復(fù)制代碼代碼如下 :Security.richText(message)通過調(diào)用 Security 的 richText方法后，最終的輸出如下：復(fù)制代碼 代碼如下 :我在留言中可以看出， 首先：會造成 XSS攻擊的 script 標簽被直接過濾掉； 同時 style 標簽中 CSS 屬性position:fixed; 樣式也被過濾了。 最終輸

9、出了無害的 HTML 富文本了解其他可能導(dǎo)致 XSS 攻擊的途徑除了在頁面的模板中可能存在 XSS 攻擊之外，在 Web 應(yīng)用中還有其他幾個途徑也可能會有風險。出錯頁面的漏洞一個頁面如果找不到，系統(tǒng)可能會報一個 404 Not Found 的404 NotFound供了默認轉(zhuǎn)義和不轉(zhuǎn)義的輸出變量寫法，需要開發(fā)者特別留Page /page/not/found does not exsit很顯然：攻擊者可以利用這個頁面，構(gòu)造一個類似這樣的連 接 ， HYPERLINK http:/localhost/%3Cscript%3Ealert%28%27hello%27%29%3C http:/local

10、host/%3Cscript%3Ealert%28%27hello%27%29%3C%2Fscript%3E ，并引誘受害者點擊；假如出錯頁面未對輸 出變量進行轉(zhuǎn)義的話，那么連接中隱藏的alert(hello)將會被執(zhí)行。在 express 中，發(fā)送一個404 頁面的方法如下res.send(404， Sorry， we dont find that!)這里就需要開發(fā)者注意錯誤頁面(404 或者其他錯誤狀態(tài)) 的處理方式。如果錯誤信息的返回內(nèi)容帶有路徑信息（其實更準確的講，是用戶輸入信息)，就一定要進行escapeHtml 了。后續(xù)， 錯誤處理的安全機制，會在 Midway框架層面中完成。Mi

11、dway解決方案的補充說明其他模板引擎Midway默認支持 xtemplate 模板，但將來也有可能支持其他模板：如 jade、mustache、ejs 等。目前在主流模板中，都提意其安全性。關(guān)于 escape的其他支持除了對頁面中輸出的普通數(shù)據(jù)和富文本數(shù)據(jù)，一些場景中也 還包含其他可能需要轉(zhuǎn)義的情況，Midway提供了如下幾個常用的轉(zhuǎn)義方法，供開發(fā)者使用：escapeHtml過濾指定的HTML中的字符，防XSS 漏洞jsEncode對輸入的 String 進行 JavaScript轉(zhuǎn)義對中文進行unicode 轉(zhuǎn)義，單引號，雙引號轉(zhuǎn)義escapeJson 不破壞 JSON 結(jié)構(gòu)的 escap

12、e函數(shù)， 只對 json 結(jié)構(gòu)中 name 和 vaule 做 escapeHtml 處理escapeJsonForJsVar 可以理解就是jsEncode+escapeJson例子如下復(fù)制代碼代碼如下 :var jsonText =:;console.log(SecurityUtil.escapeJson(jsonText);/ :var jsonText =你好 :;1.增加攻擊的難度。GET 請求是很容易創(chuàng)建的，用戶點擊一console.log(SecurityUtil.escapeJsonForJsVar(jsonText);/u4 f60u597d:var str =alert(你好

13、);console.log(SecurityUtil.jsEncode(str);/alert(u4f60u597d)跨站請求偽造攻擊(CSRF) 的預(yù)防問題及解決思路名詞解釋：表單：泛指瀏覽器端用于客戶端提交數(shù)據(jù)的形式；包括 a 標簽、 ajax 提交數(shù)據(jù)、 form 表單提交數(shù)據(jù)等，而非對等于 HTML中的 form標簽?？缯菊埱髠卧欤–SRF， Cross-site request forgery）是另一種常見的攻擊。攻擊者通過各種方法偽造一個請求，模仿用戶提交表單的行為，從而達到修改用戶的數(shù)據(jù)或執(zhí)行特定任務(wù)的目的。為了假冒用戶的身份，CSRF 攻擊常常和XSS 攻擊配合起來做，但也可以

14、通過其它手段：例如誘使用戶點擊一個包含攻擊的鏈接。解決 CSRF 攻擊的思路分如下兩個步驟GET 類型的請求， 而 POST 請求相對比較個鏈接就可以發(fā)起token 同時把token 保存在session 中單，表單中包含特殊的難，攻擊者往往需要借助JavaScript 才能實現(xiàn)；因此，確保form 表單或者服務(wù)端接口只接受POST 類型的提交請求， 可以增加系統(tǒng)的安全性。對請求進行認證，確保該請求確實是用戶本人填寫表單或者發(fā)起請求并提交的，而不是第三者偽造的。一個正常用戶修改網(wǎng)站信息的過程如下用戶請求修改信息(1) -網(wǎng)站顯示用戶修改信息的表單(2)-用戶修改信息并提交(3) -網(wǎng)站接受用戶

15、修改的數(shù)據(jù)并保存 (4)而一個 CSRF 攻擊則不會走這條路線，而是直接偽造第2 步用戶提交信息直接跳到第2 步(1) -偽造要修改的信息并提交(2) -網(wǎng)站接受攻擊者修改參數(shù)數(shù)據(jù)并保存(3)只要能夠區(qū)分這兩種情況，就能夠預(yù)防CSRF 攻擊。那么如何區(qū)分呢？就是對第 2 步所提交的信息進行驗證，確保數(shù)據(jù)源自第一步的表單。具體的驗證過程如下：用戶請求修改信息(1) -網(wǎng)站顯示用于修改信息的空白表(2) -同時發(fā)回 token 信息到服務(wù)端(3)用戶修改信息并提交，建議： 在 Midway中，可以判斷是否request 中有 token 的值，- 網(wǎng)站比對用戶發(fā)回的 token 和 session

16、 中的 token，應(yīng)該一致，則接受用戶修改的數(shù)據(jù)，并保存這樣，如果攻擊者偽造要修改的信息并提交，是沒辦法直接訪問到 session 的，所以也沒辦法拿到實際的 token 值；請求發(fā)送到服務(wù)端， 服務(wù)端進行 token 校驗的時候， 發(fā)現(xiàn)不一致， 則直接拒絕此次請求。Midway 解決方案禁用 GET 提交表單如果服務(wù)端不接受GET 方式提交的表單數(shù)據(jù)， 那么將會給攻擊者帶來非常大的難度；因為在頁面上構(gòu)造一個a 標簽 href 屬性或者 img 標簽 src 屬性來構(gòu)造一個請求是非常容易的， 但是如果要POST 提交，就必須要通過腳本才可以實現(xiàn)。用 CSRF token 驗證請求因為 Mid

17、way不涉及到淘寶分布式session 及 token 校驗這一層面邏輯，所以在Midway框架中，只將token 在 server 和客戶端之間進行轉(zhuǎn)發(fā)，本身不做實際的校驗工作。流程如下： 后續(xù)：在 Midway中， Node.js 和淘寶的分布式session 對接后，可以考慮在Midway這一層自動進行token 校驗；畢竟安全校驗越早進行，成本也會更低。沒有 token，可以直接在Midway如果一個修改操作，層認為發(fā)到 WebX 層面進行check是不安全的，將請求丟棄掉。其他安全問題關(guān)于常見的Web 安全問題， 還有如下幾種， 這里只做一些簡介，后續(xù)會持續(xù)繼承到Midway fra

18、mework中。HTTP Headers 安全CRLF Injection攻擊者想辦法在響應(yīng)頭中注入兩個CRLF特殊字符，導(dǎo)致響應(yīng)數(shù)據(jù)格式異常，從而注入script 等拒絕訪問攻擊每個請求因為都會默認帶上cookie ，而服務(wù)器一般都會限制cookie 的大小，這就導(dǎo)致了，如果用戶客戶端cookie 被設(shè)置成了超過某個閥值，那么用戶就再也無法訪問網(wǎng)站了cookie 防竊取一般 cookie 竊取都是通過JavaScript(XSS 漏洞 ) 獲取到的，所以盡量將cookie 設(shè)置成 http only ，并且加上cookie 過期時間關(guān)于 cookie 的安全問題， 之前 WebX 已經(jīng)有較好的解決方案； 此次 Midway不負責 cookie 的設(shè)置和校驗等工作，只負責轉(zhuǎn)關(guān)于 Node.jsXSS 等注入性漏洞是所有漏洞中最容易被忽略，占互聯(lián)網(wǎng)總攻擊的 70%以上；開發(fā)者編寫Node.js 代碼時，要時刻