摘要：前言這將是一個(gè)分為兩部分，內(nèi)容是關(guān)于在生產(chǎn)環(huán)境下，跑應(yīng)用的最佳實(shí)踐。潛在的攻擊者可以通過它們進(jìn)行針對性的攻擊。

這將是一個(gè)分為兩部分，內(nèi)容是關(guān)于在生產(chǎn)環(huán)境下，跑Express應(yīng)用的最佳實(shí)踐。第一部分會關(guān)注安全性，第二部分最會關(guān)注性能和可靠性。當(dāng)你讀這篇文章時(shí)，假設(shè)你已經(jīng)對Node.js和web開發(fā)有所了解，并且對生產(chǎn)環(huán)境有了概念。

生產(chǎn)環(huán)境，指的是軟件生命循環(huán)中的某個(gè)階段。當(dāng)一個(gè)應(yīng)用或API已經(jīng)被它的終端用戶所使用時(shí)，它便處在了生產(chǎn)環(huán)境。相反的，在開發(fā)環(huán)境下，你任然在不斷得修改和測試代碼，應(yīng)用也不能被外部所訪問。

開發(fā)環(huán)境和生產(chǎn)環(huán)境經(jīng)常有很大的配置上的和要求上的不同。一些在開發(fā)環(huán)境下可以使用的東西，在生產(chǎn)環(huán)境下，它們不一定是能夠被接受的。例如，在開發(fā)環(huán)境下，我們需要詳細(xì)的錯(cuò)誤日志信息來幫助我們debug，而在生產(chǎn)環(huán)境下，這則會帶來安全隱患。又比如，在開發(fā)環(huán)境下，你不必考慮可伸縮性和可靠性還有性能的問題，但這些在生產(chǎn)環(huán)境下都非常重要。

以下是將Express應(yīng)用部署于生產(chǎn)環(huán)境中的一些安全性方面的最佳實(shí)踐。

Express 2.x 和 3.x 已經(jīng)不再被維護(hù)了。這些版本上的安全和性能問題都將不會被修復(fù)。所以不要使用它們！如果你還沒有遷移至Express 4，可以參考這份遷移指南。

同時(shí)也保證不要使用在安全更新列表中列出的這些不可靠版本的Express。如果你不巧使用了，請升級至穩(wěn)定版，最好是最新版。

如果你的應(yīng)用需要處理或傳輸敏感數(shù)據(jù)，請使用TLS來確保連接和信息的安全。這項(xiàng)技術(shù)會在數(shù)據(jù)被從客戶端發(fā)出前加密它。盡管Ajax和POST請求中發(fā)出的數(shù)據(jù)看上去并不可見，但它們的網(wǎng)絡(luò)環(huán)境仍可以被嗅探和進(jìn)行中間人攻擊。

你可能已經(jīng)對SSL加密有所了解。TLS是進(jìn)化版的SSL。換句話說，如果你正在使用SSL，請更新成使用TLS。大多數(shù)情況下，我們推薦使用Nginx來處理TLS。關(guān)于如何在Nginx（或其他服務(wù)器）上配置TLS，請參考推薦的服務(wù)器配置（Mozilla Wiki）。

另外，有一個(gè)可以很方便地取得TLS證書的工具是Let’s Encrypt。它是一個(gè)免費(fèi)的，自動化的，開放的CA。由ISRG提供。

Helmet通過適當(dāng)?shù)卦O(shè)置一些HTTP頭，來幫助你的應(yīng)用免受一些廣為人知的web攻擊。

Helmet其實(shí)就是九個(gè)設(shè)置與安全相關(guān)的HTTP頭的中間件的集合：

csp 設(shè)置了Content-Security-Policy頭來幫助抵擋跨站腳本攻擊和其他跨站注入。

hidePoweredBy 移除了X-Powered-By頭。

hpkp 添加了Public Key Pinning頭來抵擋使用偽造證書的中間人攻擊。

hsts 設(shè)置了Strict-Transport-Security頭來強(qiáng)制使用安全連接。

ieNoOpen 為IE8+設(shè)置了X-Download-Options頭。

noCache 設(shè)置了Cache-Control和Pragma頭來禁止客戶端緩存。

noSniff 設(shè)置了X-Content-Type-Options頭來阻止瀏覽器進(jìn)行MIME嗅探。

frameguard 設(shè)置了X-Frame-Options頭來提供對點(diǎn)擊劫持的保護(hù)。

xssFilter 設(shè)置了X-XSS-Protection頭來啟用大多數(shù)現(xiàn)代瀏覽器中的XSS過濾器。

安裝Helmet的過程和其他模塊沒有什么兩樣：

$ npm install --save helmet

然后像其他中間件一樣使用它：

...
var helmet = require("helmet");
app.use(helmet());
...

如果你不想使用Helmet，那么你至少需要禁用X-Powered-By頭。攻擊者可以利用這個(gè)頭（默認(rèn)被啟用）來了解到你的應(yīng)用是一個(gè)Express應(yīng)用，然后進(jìn)行有針對性的攻擊。

所以，最佳實(shí)踐是使用app.disable()關(guān)閉這個(gè)頭：

app.disable("x-powered-by");

如果你使用了Helmet，則它會幫你完成這件事。

確保不要讓cookies暴露了你應(yīng)用的信息。不要使用默認(rèn)的session cookie名，并且要配置好cookie的安全選項(xiàng)。

Express中有兩個(gè)主要的cookie session中間件模塊：

express-session 代替了Express 3.x中內(nèi)建的express.session中間件。

cookie-session 代替了Express 3.x中內(nèi)建的express.cookieSession中間件。

這兩個(gè)模塊的主要區(qū)別是它們存儲cookie session的方式。express-session在服務(wù)端存儲session信息。它只在cookie中存儲session ID，而不是session數(shù)據(jù)。默認(rèn)情況下，它使用內(nèi)存存儲，在生產(chǎn)環(huán)境下，你需要自己配置可伸縮的session-store。以下是一個(gè)session-store的列表。

相反地，cookie-session中間件則把數(shù)據(jù)都存儲在了cookie中：它將整個(gè)session序列化至cookie，而不僅僅是一個(gè)session ID。請僅僅在session數(shù)據(jù)很小且被早早得加密過時(shí)才使用它。瀏覽器支持的每個(gè)cookie的大小通常最多是4093B。所以請確保不要超過它。另外，cookie中的數(shù)據(jù)時(shí)可以被客戶端看見的。所以如果你需要對其中的數(shù)據(jù)進(jìn)行保密，使用express-session將是一個(gè)更好的選擇。

這點(diǎn)和禁用X-Powered-By頭是類似的。潛在的攻擊者可以通過它們進(jìn)行針對性的攻擊。

所以請使用比較普遍的cookie名；如：

var session = require("express-session");
app.set("trust proxy", 1) // trust first proxy
app.use( session({
  secret : "s3Cur3",
  name : "sessionId",
  })
);

通過配置以下的cookie選項(xiàng)來加強(qiáng)安全性：

secure – 確保瀏覽器使用HTTPS發(fā)送cookie。

httpOnly – 確保cookie僅通過HTTP(S)被發(fā)送，而不是客戶端的JavaScript。用來幫助抵御跨站腳本攻擊。

domain – 指定cookie的域。使用它來與將要發(fā)送cookie的URL作比較。只有比較結(jié)果通過，才會繼續(xù)檢查下面的path屬性。

path – 指定cookie的路徑。使用它來比較請求的路徑。如果比較結(jié)果通過，才會發(fā)送cookie。

expires – 為持久化的cookie設(shè)置過期時(shí)間。

以下是一個(gè)使用cookie-session中間件的例子：

var session = require("cookie-session");
var express = require("express");
var app = express();
var expiryDate = new Date( Date.now() + 60 * 60 * 1000 ); // 1 hour
app.use(session({
  name: "session",
  keys: ["key1", "key2"],
  cookie: { secure: true,
          httpOnly: true,
          domain: "example.com",
          path: "foo/bar",
          expires: expiryDate
          }
  })
);

使用npm來管理你應(yīng)用的依賴是強(qiáng)大而方便的。但是你的依賴庫如果有安全隱患，這也會影響到你的應(yīng)用。你的應(yīng)用只會和其最虛弱的那部分一樣的健壯。

幸運(yùn)的是，有兩個(gè)工具可以幫助你檢查第三方庫的安全性：nsp和requireSafe。這兩個(gè)工具大致上干了相同的事情，所以選其一使用便好。

nsp是一個(gè)用來檢查你應(yīng)用的依賴庫與它的Node Security Project數(shù)據(jù)庫中的存儲的漏洞相對比的命令行工具，你可以通過以下方式安裝它：

$ npm i nsp -g

然后使用以下命令來進(jìn)行檢查你應(yīng)用的npm-shrinkwrap.json和package.json：

$ cd your-app
$ nap check

使用requireSafe的過程也是類似的：

$ npm install -g requiresafe
$ cd your-app
$ require safe check

以下是一些從Node.js安全清單中提出安全建議。詳細(xì)的建議請自行參閱它：

對應(yīng)用實(shí)現(xiàn)一個(gè)訪問頻率限制機(jī)制來抵御暴力破解。你可以使用如express-limiter這樣的中間件。

使用csurf中間件來抵擋跨站請求偽造（CSRF）。

總是檢查和過濾用戶的輸入，來防止XSS和命令注入。

通過使用參數(shù)化的查詢（parameterized queries）或預(yù)處理語句（prepared statements），來抵擋SQL注入攻擊。

使用開源的sqlmap工具來偵測你的應(yīng)用中可能被SQL注入的地方。

使用namp和sslyze來測試你的SSL配置。

使用safe-regex來確保你的正則表達(dá)式的健壯性。

除了Node Security Project代替你檢查出的Express或其他模塊的漏洞外。Express應(yīng)用也是一個(gè)web應(yīng)用，所以你也要關(guān)注其他相關(guān)的已知的web漏洞，并且避免它們。

原文鏈接：https://strongloop.com/strongblog/best-practices-for-express-in-production-part-one-security/