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

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

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

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

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

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

使用這種模式將限制你的變量聲明，并總會將一些可能隱藏的錯誤拋出來，下面是幾個例子：

"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 來靜態(tài)分析你的代碼. 靜態(tài)代碼分析可以讓你在早期捕獲一些潛在的BUG.

這一點不言而喻：測試，測試再測試。

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

很多人使用超級用戶權(quán)限運行Node應(yīng)用，不是嗎？因為他們希望應(yīng)用程序直接偵聽80或443端口（注* http和https的默認(rèn)端口）

這一點是不對的，進程中的任何一個錯誤/漏洞都將讓整個系統(tǒng)宕機，然后你就什么也干不了。

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

下面的代碼段有什么問題？

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

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

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

為了避免這個問題，你只需要使用child_process.execFile。詳解。

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

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

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

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

比如

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

如果這條用戶查詢未經(jīng)過驗證直接插入到DOM（HTML）中，它就會被執(zhí)行。

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

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

例如

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

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

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

CSP可以通過 Content-Security-Policy 被啟用。

比如：

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

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

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

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

這時侯問題就可能發(fā)生了，因為cookie也會發(fā)送到被請求的網(wǎng)站（此網(wǎng)站你已經(jīng)被授權(quán)） - 即使當(dāng)這些請求來自不同的位置。

例如

注* 此頁面在另外一個域名中

這樣會直接導(dǎo)致這個用戶信息被刪除。

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

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

via ourjs
原文