快捷導(dǎo)航

基于NodeJS的前后端分離的思考與實(shí)踐（四）安全問(wèn)題解決方案

更新時(shí)間：2014年09月26日 10:16:32 作者：taobaoued

本文就在前后端分離模式的架構(gòu)下，針對(duì)前端在Web開(kāi)發(fā)中，所遇到的安全問(wèn)題以及應(yīng)對(duì)措施和注意事項(xiàng)，并提出解決方案。

前言

在前后端分離的開(kāi)發(fā)模式中，從開(kāi)發(fā)的角色和職能上來(lái)講，一個(gè)最明顯的變化就是：以往傳統(tǒng)中，只負(fù)責(zé)瀏覽器環(huán)境中開(kāi)發(fā)的前端同學(xué)，需要涉獵到服務(wù)端層面，編寫(xiě)服務(wù)端代碼。而擺在面前的一個(gè)基礎(chǔ)性問(wèn)題就是如何保障Web安全？

本文就在前后端分離模式的架構(gòu)下，針對(duì)前端在Web開(kāi)發(fā)中，所遇到的安全問(wèn)題以及應(yīng)對(duì)措施和注意事項(xiàng)，并提出解決方案。

跨站腳本攻擊(XSS)的防御

問(wèn)題及解決思路

跨站腳本攻擊（XSS，Cross-site scripting）是最常見(jiàn)和基本的攻擊Web網(wǎng)站的方法。攻擊者可以在網(wǎng)頁(yè)上發(fā)布包含攻擊性代碼的數(shù)據(jù)，當(dāng)瀏覽者看到此網(wǎng)頁(yè)時(shí)，特定的腳本就會(huì)以瀏覽者用戶的身份和權(quán)限來(lái)執(zhí)行。通過(guò)XSS可以比較容易地修改用戶數(shù)據(jù)、竊取用戶信息以及造成其它類(lèi)型的攻擊，例如：CSRF攻擊。

預(yù)防XSS攻擊的基本方法是：確保任何被輸出到HTML頁(yè)面中的數(shù)據(jù)以HTML的方式進(jìn)行轉(zhuǎn)義（HTML escape）。例如下面的模板代碼：

復(fù)制代碼代碼如下:

<textarea name="description">$description</textarea>

這段代碼中的$description為模板的變量（不同模板中定義的變量語(yǔ)法不同，這里只是示意一下），由用戶提交的數(shù)據(jù)，那么攻擊者可以輸入一段包含”JavaScript”的代碼，使得上述模板語(yǔ)句的結(jié)果變成如下的結(jié)果：

復(fù)制代碼代碼如下:

<textarea name="description">

</textarea><script>alert('hello')'</script>

</textarea>

上述代碼，在瀏覽器中渲染，將會(huì)執(zhí)行JavaScript代碼并在屏幕上alert hello。當(dāng)然這個(gè)代碼是無(wú)害的，但攻擊者完全可以創(chuàng)建一個(gè)JavaScript來(lái)修改用戶資料或者竊取cookie數(shù)據(jù)。

解決方法很簡(jiǎn)單，就是將$description的值進(jìn)行html escape，轉(zhuǎn)義后的輸出代碼如下

復(fù)制代碼代碼如下:

<textarea name="description">

&lt;/textarea&gt;&lt;script&gt;alert(&quot;hello!&quot;)&lt;/script&gt;

</textarea>

以上經(jīng)過(guò)轉(zhuǎn)義后的HTML代碼是沒(méi)有任何危害的。

Midway的解決方案

轉(zhuǎn)義頁(yè)面中所有用戶輸出的數(shù)據(jù)

對(duì)數(shù)據(jù)進(jìn)行轉(zhuǎn)義有以下幾種情況和方法：

1. 使用模板內(nèi)部提供的機(jī)制進(jìn)行轉(zhuǎn)義

中途島內(nèi)部使用KISSY xtemplate作為模板語(yǔ)言。

在xtemplate實(shí)現(xiàn)中，語(yǔ)法上使用兩個(gè)中括號(hào)（ {{val}}）解析模板數(shù)據(jù)，，默認(rèn)既是對(duì)數(shù)據(jù)進(jìn)行HTML轉(zhuǎn)義的，所以開(kāi)發(fā)者可以這樣寫(xiě)模板：

復(fù)制代碼代碼如下:

<textarea name="description">{{description}}</textarea>

在xtemplate中，如果不希望輸出的數(shù)據(jù)被轉(zhuǎn)義，需要使用三個(gè)中括號(hào)（{{{val}}}）。

2. 在Midway中明確的調(diào)用轉(zhuǎn)義函數(shù)

開(kāi)發(fā)者可以在Node.js程序或者模板中，直接調(diào)用Midway提供的HTML轉(zhuǎn)義方法，顯示的對(duì)數(shù)據(jù)進(jìn)行轉(zhuǎn)義，如下：

方法1：在Node.js程序中對(duì)數(shù)據(jù)進(jìn)行HTML轉(zhuǎn)義

復(fù)制代碼代碼如下:

var Security= require('midway-security');

//data from server，eg {html:'</textarea>'，other:""}

data.html =Security.escapeHtml(data.html);

xtpl = xtpl.render(data);

方法2：在模板中對(duì)HTML數(shù)據(jù)進(jìn)行HTML轉(zhuǎn)義

復(fù)制代碼代碼如下:

<textarea name="description">Security.escapeHtml({{{description}}})</textarea>

注意：只有當(dāng)模板內(nèi)部沒(méi)有對(duì)數(shù)據(jù)進(jìn)行轉(zhuǎn)義的時(shí)候才使用Security.escapeHtml進(jìn)行轉(zhuǎn)義。否則，模板內(nèi)部和程序會(huì)兩次轉(zhuǎn)義疊加，導(dǎo)致不符合預(yù)期的輸出。

推薦：如果使用xtemplate，建議直接使用模板內(nèi)置的{{}}進(jìn)行轉(zhuǎn)義；如果使用其他模板，建議使用Security.escapeHtml進(jìn)行轉(zhuǎn)義。

過(guò)濾頁(yè)面中用戶輸出的富文本

你可能會(huì)想到：“其實(shí)我就是想輸出富文本，比如一些留言板、論壇給用戶提供一些簡(jiǎn)單的字體大小、顏色、背景等功能，那么我該如何處理這樣的富文本來(lái)防止XSS呢？”

1. 使用Midway中Security提供的richText函數(shù)

Midway中提供了richText方法，專(zhuān)門(mén)用來(lái)過(guò)濾富文本，防止XSS、釣魚(yú)、cookie竊取等漏洞。

有一個(gè)留言板，模板代碼可能如下：

復(fù)制代碼代碼如下:

<div class="message-board">

{{{message}}}

</div>

因?yàn)閙essage是用戶的輸入數(shù)據(jù)，其留言板的內(nèi)容，包含了富文本信息，所以這里在xtemplate中，使用了三個(gè)大括號(hào)，默認(rèn)不進(jìn)行HTML轉(zhuǎn)義；那么用戶輸入的數(shù)據(jù)假如如下：

復(fù)制代碼代碼如下:

上述的富文本數(shù)據(jù)如果直接輸出到頁(yè)面中，必然會(huì)導(dǎo)致eval.com站點(diǎn)的js注入到當(dāng)前頁(yè)面中，造成了XSS攻擊。為了防止這個(gè)漏洞，我們只要在模板或者程序中，調(diào)用Security.richText方法，處理用戶輸入的富文本。

調(diào)用方法與escapeHtml類(lèi)似，有如下兩種方式

方法1: 直接在Node.js程序中調(diào)用

復(fù)制代碼代碼如下:

message =Security.richText(message);

var html = xtpl.render(message)

方法2：在模板中調(diào)用

復(fù)制代碼代碼如下:

<div class="message-board">

Security.richText({{{message}}})

</div>

通過(guò)調(diào)用Security的richText方法后，最終的輸出如下：

復(fù)制代碼代碼如下:

<div class="message-board">

<span style="color:red;font-size:20px;">我在留言中</span>

</div>

可以看出，首先：會(huì)造成XSS攻擊的script標(biāo)簽被直接過(guò)濾掉；同時(shí)style標(biāo)簽中CSS屬性position:fixed;樣式也被過(guò)濾了。最終輸出了無(wú)害的HTML富文本

了解其他可能導(dǎo)致XSS攻擊的途徑

除了在頁(yè)面的模板中可能存在XSS攻擊之外，在Web應(yīng)用中還有其他幾個(gè)途徑也可能會(huì)有風(fēng)險(xiǎn)。

1. 出錯(cuò)頁(yè)面的漏洞

一個(gè)頁(yè)面如果找不到，系統(tǒng)可能會(huì)報(bào)一個(gè)404 Not Found的錯(cuò)誤，例如：http://localhost/page/not/found

404 NotFound
Page /page/not/found does not exsit
很顯然：攻擊者可以利用這個(gè)頁(yè)面，構(gòu)造一個(gè)類(lèi)似這樣的連接，http://localhost/%3Cscript%3Ealert%28%27hello%27%29%3C%2Fscript%3E，并引誘受害者點(diǎn)擊；假如出錯(cuò)頁(yè)面未對(duì)輸出變量進(jìn)行轉(zhuǎn)義的話，那么連接中隱藏的 <script>alert('hello')</script> 將會(huì)被執(zhí)行。

在express中，發(fā)送一個(gè)404頁(yè)面的方法如下

res.send(404，'Sorry，we don\'t find that!')
這里就需要開(kāi)發(fā)者注意錯(cuò)誤頁(yè)面(404或者其他錯(cuò)誤狀態(tài))的處理方式。如果錯(cuò)誤信息的返回內(nèi)容帶有路徑信息（其實(shí)更準(zhǔn)確的講，是用戶輸入信息)，就一定要進(jìn)行escapeHtml了。

后續(xù)，錯(cuò)誤處理的安全機(jī)制，會(huì)在Midway框架層面中完成。

Midway解決方案的補(bǔ)充說(shuō)明

其他模板引擎

Midway默認(rèn)支持xtemplate模板，但將來(lái)也有可能支持其他模板：如jade、mustache、ejs等。目前在主流模板中，都提供了默認(rèn)轉(zhuǎn)義和不轉(zhuǎn)義的輸出變量寫(xiě)法，需要開(kāi)發(fā)者特別留意其安全性。

關(guān)于escape的其他支持

除了對(duì)頁(yè)面中輸出的普通數(shù)據(jù)和富文本數(shù)據(jù)，一些場(chǎng)景中也還包含其他可能需要轉(zhuǎn)義的情況，Midway提供了如下幾個(gè)常用的轉(zhuǎn)義方法，供開(kāi)發(fā)者使用：

escapeHtml 過(guò)濾指定的HTML中的字符，防XSS漏洞
jsEncode 對(duì)輸入的String進(jìn)行JavaScript 轉(zhuǎn)義對(duì)中文進(jìn)行unicode轉(zhuǎn)義，單引號(hào)，雙引號(hào)轉(zhuǎn)義
escapeJson 不破壞JSON結(jié)構(gòu)的escape函數(shù)，只對(duì)json結(jié)構(gòu)中name和vaule做escapeHtml處理
escapeJsonForJsVar 可以理解就是jsEncode+escapeJson
例子如下

復(fù)制代碼代碼如下:

var jsonText ="{\"<script>\":\"<script>\"}";

console.log(SecurityUtil.escapeJson(jsonText));// {"&lt;script&gt;":"&lt;script&gt;"}

var jsonText ="{\"你好\":\"<script>\"}";

console.log(SecurityUtil.escapeJsonForJsVar(jsonText));//{\"\u4f60\u597d\":\"&lt;script&gt;\"}

var str ="alert(\"你好\")";

console.log(SecurityUtil.jsEncode(str));// alert(\"\u4f60\u597d\")

跨站請(qǐng)求偽造攻擊(CSRF)的預(yù)防

問(wèn)題及解決思路

名詞解釋?zhuān)?表單：泛指瀏覽器端用于客戶端提交數(shù)據(jù)的形式；包括a標(biāo)簽、ajax提交數(shù)據(jù)、form表單提交數(shù)據(jù)等，而非對(duì)等于HTML中的form標(biāo)簽。

跨站請(qǐng)求偽造（CSRF，Cross-site request forgery）是另一種常見(jiàn)的攻擊。攻擊者通過(guò)各種方法偽造一個(gè)請(qǐng)求，模仿用戶提交表單的行為，從而達(dá)到修改用戶的數(shù)據(jù)或執(zhí)行特定任務(wù)的目的。

為了假冒用戶的身份，CSRF攻擊常常和XSS攻擊配合起來(lái)做，但也可以通過(guò)其它手段：例如誘使用戶點(diǎn)擊一個(gè)包含攻擊的鏈接。

解決CSRF攻擊的思路分如下兩個(gè)步驟

1.增加攻擊的難度。GET請(qǐng)求是很容易創(chuàng)建的，用戶點(diǎn)擊一個(gè)鏈接就可以發(fā)起GET類(lèi)型的請(qǐng)求，而POST請(qǐng)求相對(duì)比較難，攻擊者往往需要借助JavaScript才能實(shí)現(xiàn)；因此，確保form表單或者服務(wù)端接口只接受POST類(lèi)型的提交請(qǐng)求，可以增加系統(tǒng)的安全性。
2.對(duì)請(qǐng)求進(jìn)行認(rèn)證，確保該請(qǐng)求確實(shí)是用戶本人填寫(xiě)表單或者發(fā)起請(qǐng)求并提交的，而不是第三者偽造的。

一個(gè)正常用戶修改網(wǎng)站信息的過(guò)程如下

用戶請(qǐng)求修改信息(1) -> 網(wǎng)站顯示用戶修改信息的表單(2) -> 用戶修改信息并提交(3) -> 網(wǎng)站接受用戶修改的數(shù)據(jù)并保存(4)
而一個(gè)CSRF攻擊則不會(huì)走這條路線，而是直接偽造第2步用戶提交信息

直接跳到第2步(1) -> 偽造要修改的信息并提交(2) -> 網(wǎng)站接受攻擊者修改參數(shù)數(shù)據(jù)并保存(3)
只要能夠區(qū)分這兩種情況，就能夠預(yù)防CSRF攻擊。那么如何區(qū)分呢？就是對(duì)第2步所提交的信息進(jìn)行驗(yàn)證，確保數(shù)據(jù)源自第一步的表單。具體的驗(yàn)證過(guò)程如下：

用戶請(qǐng)求修改信息(1) -> 網(wǎng)站顯示用于修改信息的空白表單，表單中包含特殊的token同時(shí)把token保存在session中(2) -> 用戶修改信息并提交，同時(shí)發(fā)回token信息到服務(wù)端(3) -> 網(wǎng)站比對(duì)用戶發(fā)回的token和session中的token，應(yīng)該一致，則接受用戶修改的數(shù)據(jù)，并保存
這樣，如果攻擊者偽造要修改的信息并提交，是沒(méi)辦法直接訪問(wèn)到session的，所以也沒(méi)辦法拿到實(shí)際的token值；請(qǐng)求發(fā)送到服務(wù)端，服務(wù)端進(jìn)行token校驗(yàn)的時(shí)候，發(fā)現(xiàn)不一致，則直接拒絕此次請(qǐng)求。

Midway解決方案

禁用GET提交表單

如果服務(wù)端不接受GET方式提交的表單數(shù)據(jù)，那么將會(huì)給攻擊者帶來(lái)非常大的難度；因?yàn)樵陧?yè)面上構(gòu)造一個(gè)a標(biāo)簽href屬性或者img標(biāo)簽src屬性來(lái)構(gòu)造一個(gè)請(qǐng)求是非常容易的，但是如果要POST提交，就必須要通過(guò)腳本才可以實(shí)現(xiàn)。

用CSRF token驗(yàn)證請(qǐng)求

因?yàn)镸idway不涉及到淘寶分布式session及token校驗(yàn)這一層面邏輯，所以在Midway框架中，只將token在server和客戶端之間進(jìn)行轉(zhuǎn)發(fā)，本身不做實(shí)際的校驗(yàn)工作。流程如下：

后續(xù)：在Midway中，Node.js和淘寶的分布式session對(duì)接后，可以考慮在Midway這一層自動(dòng)進(jìn)行token校驗(yàn)；畢竟安全校驗(yàn)越早進(jìn)行，成本也會(huì)更低。

建議：在Midway中，可以判斷是否request中有token的值，如果一個(gè)修改操作，沒(méi)有token，可以直接在Midway層認(rèn)為是不安全的，將請(qǐng)求丟棄掉。

其他安全問(wèn)題

關(guān)于常見(jiàn)的Web安全問(wèn)題，還有如下幾種，這里只做一些簡(jiǎn)介，后續(xù)會(huì)持續(xù)繼承到Midway framework中。

HTTP Headers安全
CRLF Injection 攻擊者想辦法在響應(yīng)頭中注入兩個(gè)CRLF特殊字符，導(dǎo)致響應(yīng)數(shù)據(jù)格式異常，從而注入script等
拒絕訪問(wèn)攻擊每個(gè)請(qǐng)求因?yàn)槎紩?huì)默認(rèn)帶上cookie，而服務(wù)器一般都會(huì)限制cookie的大小，這就導(dǎo)致了，如果用戶客戶端cookie被設(shè)置成了超過(guò)某個(gè)閥值，那么用戶就再也無(wú)法訪問(wèn)網(wǎng)站了
cookie防竊取一般cookie竊取都是通過(guò)JavaScript(XSS漏洞)獲取到的，所以盡量將cookie設(shè)置成http only，并且加上cookie過(guò)期時(shí)間
關(guān)于cookie的安全問(wèn)題，之前WebX已經(jīng)有較好的解決方案；此次Midway不負(fù)責(zé)cookie的設(shè)置和校驗(yàn)等工作，只負(fù)責(zé)轉(zhuǎn)發(fā)到WebX層面進(jìn)行check

關(guān)于Node.js

XSS等注入性漏洞是所有漏洞中最容易被忽略，占互聯(lián)網(wǎng)總攻擊的70%以上；開(kāi)發(fā)者編寫(xiě)Node.js代碼時(shí)，要時(shí)刻提醒自己，永遠(yuǎn)不要相信用戶的輸入。

比如如下幾個(gè)例子。

var mod = fs.readFileSync('path'); 如果path來(lái)源于用戶輸入，那么假設(shè)用戶輸入/etc/password，則會(huì)讀取到不應(yīng)該讀取的內(nèi)容，造成密碼泄漏風(fēng)險(xiǎn)
var result = eval(jsonVal); 一定要確保jsonVal是json，而不是用戶的輸入
…… 其他可能包含用戶輸入的地方，一定要確認(rèn)用戶的輸入是我們期望的值
總結(jié)

前后端分離模式下，可以讓傳統(tǒng)的前端開(kāi)發(fā)人員開(kāi)始編寫(xiě)后端代碼，雖然從架構(gòu)上講，只負(fù)責(zé)模板這一層，但也會(huì)接觸大量的后端代碼；所以安全對(duì)于前端來(lái)說(shuō)，這是一個(gè)不小的挑戰(zhàn)。

您可能感興趣的文章: