摘要：盡管這樣，我們還沒(méi)有形成很多的安全準(zhǔn)則。在這篇文章中，我會(huì)分享一些關(guān)于提高安全性方面的技巧。注跨站腳本攻擊發(fā)生這種情況時(shí)，攻擊者注入可執(zhí)行代碼的響應(yīng)。這樣可能會(huì)被跨站點(diǎn)腳本攻擊。

毫無(wú)疑問(wèn)，Node.js現(xiàn)在是越來(lái)越成熟。盡管這樣，我們還沒(méi)有形成很多的安全準(zhǔn)則。
在這篇文章中，我會(huì)分享一些關(guān)于提高Node.js安全性方面的技巧。

你不僅僅要避免使用eval － 你也應(yīng)該避免使用在下列情況，他們等價(jià)于直接使用eval；

setInterval(String, 2)
setTimeout(String, 2)
new Function(String)

注* eval: 直接將字符串轉(zhuǎn)化為代碼執(zhí)行，如： eval("alert("hi")")

如果你對(duì)用戶(hù)輸入的內(nèi)容進(jìn)行了eval運(yùn)行（千萬(wàn)不要這么設(shè)計(jì)），你就有可能受到注入攻擊。并且這種運(yùn)行方式很慢。

使用這種模式將限制你的變量聲明，并總會(huì)將一些可能隱藏的錯(cuò)誤拋出來(lái)，下面是幾個(gè)例子：

"use strict";
delete Object.prototype; // TypeError

"use strict";  
var obj = {  
    a: 1, 
    a: 2 
}; 
// syntax error

var obj = { x: 17 };  
with (obj) // !!! syntax error  
{

}

使用 JSLint, JSHint 或 ESLint 來(lái)靜態(tài)分析你的代碼. 靜態(tài)代碼分析可以讓你在早期捕獲一些潛在的BUG.

這一點(diǎn)不言而喻：測(cè)試，測(cè)試再測(cè)試。

不僅僅是單元測(cè)試，你應(yīng)該進(jìn)行全面測(cè)試（test pyramid）。

很多人使用超級(jí)用戶(hù)權(quán)限運(yùn)行Node應(yīng)用，不是嗎？因?yàn)樗麄兿Ｍ麘?yīng)用程序直接偵聽(tīng)80或443端口（注* http和https的默認(rèn)端口）

這一點(diǎn)是不對(duì)的，進(jìn)程中的任何一個(gè)錯(cuò)誤/漏洞都將讓整個(gè)系統(tǒng)宕機(jī)，然后你就什么也干不了。

所以你應(yīng)該使用一個(gè)HTTP反向代理服務(wù)去轉(zhuǎn)發(fā)這些請(qǐng)求。可以用nginx, Apache 你看著辦。

下面的代碼段有什么問(wèn)題？

child_process.exec("ls", function (err, data) {  
    console.log(data);
});

child_process.exec 命令調(diào)用的是 /bin/sh， 它啟動(dòng)了一個(gè)解釋器，而非程序。

這是有問(wèn)題的，當(dāng)該方法執(zhí)行用戶(hù)輸入的一個(gè)方法，比于一個(gè)反引號(hào)或$（）中的內(nèi)容，一個(gè)新的命令就可能被攻擊者注入。

為了避免這個(gè)問(wèn)題，你只需要使用child_process.execFile。詳解。

創(chuàng)建文件時(shí)，如處理上傳的文件格外注意。這些文件可以輕松吃掉你所有的磁盤(pán)空間。

為了解決這個(gè)問(wèn)題，你應(yīng)該使用Streams。

不光是Node－所有的Web應(yīng)用程序都應(yīng)該加密。（注* https）

發(fā)生這種情況時(shí)，攻擊者注入可執(zhí)行代碼的HTTP響應(yīng)。一個(gè)應(yīng)用程序容易受到這種類(lèi)型的攻擊，它會(huì)在客戶(hù)端執(zhí)行未驗(yàn)證的腳本（主要是用Javascript寫(xiě)的）。它使攻擊者能夠竊取cookie，剪貼板的內(nèi)容或修改頁(yè)面本身。

比如

http://example.com/index.php?user=

如果這條用戶(hù)查詢(xún)未經(jīng)過(guò)驗(yàn)證直接插入到DOM（HTML）中，它就會(huì)被執(zhí)行。

永遠(yuǎn)不要往DOM中插入不可信的數(shù)據(jù)
在插入前去除HTML

默認(rèn)情況下，Cookie可以通過(guò)Javascript在同一個(gè)域中讀取。這樣可能會(huì)被跨站點(diǎn)腳本攻擊。而且它們還有可能被第三方的JavaScript庫(kù)閱讀。

例如

var cookies = document.cookie.split("; ");

為了防止這種情況，你可以在Cookies上使用HttpOnly，這個(gè)標(biāo)簽可以讓JavaScript無(wú)法讀取這個(gè)cookie。 （注* 比如服務(wù)器端用到的Cookie）

內(nèi)容安全策略（CSP）是一個(gè)附加的安全層，幫助檢測(cè)和緩解某些類(lèi)型的攻擊，包括跨站點(diǎn)腳本（XSS）和數(shù)據(jù)注入攻擊。

CSP可以通過(guò) Content-Security-Policy 被啟用。

比如：

Content-Security-Policy: default-src "self" *.mydomain.com

注* CSP的更多內(nèi)容

這個(gè)header頭信息將只接收信任的域名及其子域名的發(fā)過(guò)來(lái)的內(nèi)容。

CSRF是一種迫使終端用戶(hù)在他目前已驗(yàn)證授權(quán)的Web應(yīng)用程序中執(zhí)行其它的actions。

這時(shí)侯問(wèn)題就可能發(fā)生了，因?yàn)閏ookie也會(huì)發(fā)送到被請(qǐng)求的網(wǎng)站（此網(wǎng)站你已經(jīng)被授權(quán)） - 即使當(dāng)這些請(qǐng)求來(lái)自不同的位置。

例如

注* 此頁(yè)面在另外一個(gè)域名中

這樣會(huì)直接導(dǎo)致這個(gè)用戶(hù)信息被刪除。

為了防止CSRF，您應(yīng)該實(shí)現(xiàn)同步令牌模式 - 幸運(yùn)的是，node社區(qū)已經(jīng)幫你做了。下面是它的工作原理：

當(dāng)發(fā)起一個(gè)GET請(qǐng)求時(shí)，服務(wù)器檢查你的CSRF令牌 - 如果它不存在，創(chuàng)建一個(gè)
當(dāng)用戶(hù)顯示輸入時(shí)，確保添加一個(gè)隱藏的CSRF令牌值
當(dāng)Form表單提交時(shí)，確保該值與該表單與Session中的內(nèi)容相匹配

via ourjs
原文