摘要：所以我們整理了一個應用安全備忘錄，以幫助你在部署啟動應用程序的時候進行安全檢查。這可以保護應用程序不被攻擊。應該用日志記錄下來，而不是顯示給用戶。

本人的博客http://www.wjs.photo/,感興趣的可以看看哦，基于NodeJs框架ThinkJs

本文翻譯自 www.risingstack.com ,并非逐字逐句的翻譯，有錯誤的地方請指出，謝謝啦
應用程序的安全就像是你房間里突然出現一只大象，那么明顯，但是寫代碼的同學還是會忽略。也都認為應用程序的安全非常重要但是卻很少有時間認真對待，畢竟我們有那么多bug要改（壞笑）。所以我們整理了一個NodeJs應用安全備忘錄，以幫助你在部署啟動NodeJs應用程序的時候進行安全檢查。當然，這些項目大部分是通用的，適用于所有的語言和框架而不僅僅是Node.js。但是本文具體還涉及到一些Node.js的工具。感興趣的同學也可以查看我的介紹Node.js的安全性的博客。

Strict-Transport-Security：強制通過（SSL/TLS上的HTTP）連接到服務器
X-Frame-Options：提供阻止點擊挾持攻擊
X-XSS-Protection：啟用瀏覽器內置的跨站點腳本（XSS）篩選器
X-Content-Type-Options：防止瀏覽器從MIME探查從聲明內容類型的響應
Content-Security-Policy：防止各種攻擊，包括跨站點腳本和其他跨網站注射
在Express中，我們可以很容易用helmet來設置這些頭部：

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

當然，在koa框架中也可以使用：傳送門
這些頭部不只是可以放在代碼中，也可以配置在web服務器中（Apache、nginx），這樣也就省了改動程序代碼

    # nginx.conf
    add_header X-Frame-Options SAMEORIGIN; 
    add_header X-Content-Type-Options nosniff; 
    add_header X-XSS-Protection "1; mode=block"; 
    add_header Content-Security-Policy "default-src "self"";

nginx服務器的配置也可以參考：這里

在部署前端應用程序時要確保不會將秘密的API公開,公開的API會被任何人訪問
雖然沒有好的自動檢查的方法，但有兩個注意點可以減輕由于意外而暴露敏感數據的風險
1.檢查使用的請求
2.常規的代碼審查

暴力破解（也稱窮舉法），即將密碼進行逐個推算直到找到真正的密碼，然后在web應用程序中登錄。
為了防止應用程序受到暴力破解的攻擊，應用程序最好要有密碼錯誤容許次數機制，在NodeJs中，你可以使用：ratelimiter

      var limit = new Limiter({ id: email, db: db }); 
      limit.get(function(err, limit) { });
      

當然啦，你也可以將他包裝成一個中間件，就可以放在應用程序中，無論是Express框架還是Koa框都有厲害的中間件，在koa框架中，他可能是這個樣子：

  var ratelimit = require("koa-ratelimit");  
  var redis = require("redis");  var koa = require("koa");  
  var app = koa(); 
  var emailBasedRatelimit = ratelimit({
  db: redis.createClient(),   
  duration: 60000,   
  max: 10,   
  id: function (context) {     
  return context.body.email;   
  } }); 
  var ipBasedRatelimit = ratelimit({
  db: redis.createClient(),   
  duration: 60000,   
  max: 10,   
  id: function (context) {     
   return context.ip;   
   } 
   }); 
   app.post("/login", ipBasedRatelimit, emailBasedRatelimit, handleLogin); 

我們在這里做的是有限的用戶在給定的時間里（60000毫秒）可以出錯多少次（10次），這樣我們的程序可以減輕被暴力破解的風險。不過這些配置必須為給定的應用，不要直接復制粘貼他們。

安全使用Cookie的重要性不能被低估：尤其是在動態Web應用程序，這就需要保持整個無狀態協議狀態，如HTTP。
Cookie的屬性列表：
secure —這個屬性設置為true時是告訴瀏覽器如果正在通過HTTPS發送請求，只發送cookie。
HttpOnly—-如果Cookie中設置了這個屬性，那么通過程序(JS腳本、Applet等)將無法讀取到Cookie信息，可以有效的用來防止諸如跨站點腳本攻擊
限制cookie的作用范圍
Domain--這個屬性是用來比較中被請求的URL服務器的域。如果域匹配，或者如果它是一個子域，則路徑屬性將下一個檢查。
path--除了Domain，該Cookie有效期可以指定URL路徑。如果域名和路徑匹配，那么該cookie將被請求發送。
expires --這個屬性是用來設置Cookie的到期時間，因為該cookie不會過期，直到超出設定的日期

在NodeJs中，可以很容易的創建cookie, 通過cookies或者cookie-session

 var cookieSession = require("cookie-session");  
 var express = require("express"); var app = express(); 
 app.use(cookieSession({    name: "session",   
 keys: [     process.env.COOKIE_KEY1,     process.env.COOKIE_KEY2   ] }));
 app.use(function (req, res, next) {    
     var n = req.session.views || 0;   
     req.session.views = n++;    
     res.end(n + " views"); 
    }); 
 app.listen(3000); 

（這個例子是取自cookie的會話模塊文檔）。

跨站請求偽造一種挾持用戶在當前已登錄的web應用程序上執行非自己操作的攻擊方法，這種攻擊專門針對更改請求，而不是竊取數據，因為攻擊者也沒法比見到偽造請求的響應
在NodeJs中要減輕這種攻擊，可以使用 [csrf] (https://www.npmjs.com/package...塊，由于這個比較底層，也有不同的框架包裝好的，這個例子是csurf模塊，用于CSRF保護明文中間件
在路由中，你需要做的是：

 var cookieParser = require("cookie-parser");   
 var csrf = require("csurf");  
 var bodyParser = require("body-parser");         
 var express = require("express"); 
 // setup route middlewares 
 var csrfProtection = csrf({ cookie: true });  
 var parseForm = bodyParser.urlencoded({ extended: false }); 
 // create express app 
 var app = express(); 
 // we need this because "cookie" is true in csrfProtection  
 app.use(cookieParser()); 
 app.get("/form", csrfProtection, function(req, res) {  
 // pass the csrfToken to the view   
   res.render("send", { csrfToken: req.csrfToken() }); }); 
   app.post("/process", parseForm, csrfProtection, function(req, res) {    
     res.send("data is being processed");
    });

然后在視圖層：

 
    
  Favorite color: 
  
  Submit
 
 

（這個例子是取自csurf模塊文檔）。

XSS有兩個相似，但不同類型的攻擊防范。一個是跨站腳本的反射版本，另一個是存儲跨站腳本。
反射式跨站腳本，通過注入發送帶有惡意腳本代碼參數的URL，當URL地址被打開時，特有的惡意代碼參數被HTML解析、執行。
存儲跨站腳本，指的是惡意腳本代碼被存儲進被攻擊的數據庫，當其他用戶正常瀏覽網頁時，站點從數據庫中讀取了非法用戶存入非法數據，惡意腳本代碼被執行。
為了抵御這類攻擊，確保你過濾或者清理用戶輸入。

SQL注入是由用戶輸入部分或完整的SQL查詢的注入。它可以讀取敏感信息。

 select title, author from books where id=$id

在這個實例代碼中，參數$id如果用戶輸入的是2 or 1=1？，那查詢變為如下：

select title, author from books where id=2 or 1=1

防范這類攻擊的最簡單的方法是使用參數化查詢或準備好的語句。
SqlMap是一個開源的滲透測試工具，它可以自動檢測并利用SQL注入漏洞和接管數據庫服務器的過程。使用此工具來測試SQL注入漏洞的應用程序。

命令注入是由攻擊者向遠程的Web服務器上運行的系統命令的技術。用這種方法攻擊者可能甚至得到的系統的密碼。
在實際開發中，如果你有一個網址，如：

https://example.com/downloads?file=user1.txt 

它可以變成：

https://example.com/downloads?file=%3Bcat%20/etc/passwd 

在這個例子中%3B變成了分號，所以多個系統命令可以運行。
為了抵御這類攻擊，確保你始終過濾或清理了用戶輸入。
另外，在Node.js中我們可以這樣來檢測：

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

child_process.exec創建一個子線程來調用執行/bin/sh，所以他是一個bash的解釋，而不是一個程序的啟動，當用戶輸入被傳遞給這個方法，就會被執行，顯示目錄下的所有文件。一個新的命令被攻擊者注入。
為了防止被攻擊，可以使用child_process.execFile

由于HTTP是一種明文協議，如果通過了SSL / TLS隧道，被稱為HTTPS進行保護。如今高檔的密碼通常使用，在服務器配置錯誤可以用來強制使用弱密碼 - 或者在最壞的情況沒有加密。
你必須測試：

密碼，鑰匙和重新談判的配置是否正確

證書有效期

使用工具NMAP和sslyze可以很容易掃描出來
檢查證書信息

nmap --script ssl-cert,ssl-enum-ciphers -p 443,465,993,995 www.example.com

利用sslyze可以測試SSL / TLS的漏洞

./sslyze.py --regular example.com:443

在配置管理的一部分，我們使用這個briefly - Strict-Transport-Security 頭強制執行安全（基于SSL的HTTP / TLS）連接到服務器上。就拿從Twitter下面的例子：

strict-transport-security:max-age=631138519 

這里max-age定義為秒，瀏覽器自動將所有的HTTP請求轉換為HTTPS的數量。
它的測試是非常簡單的：

curl -s -D- https://twitter.com/ | grep -i Strict 

帳戶鎖定是減少暴力攻擊的方法。這就意味著，如果賬戶多次登錄失敗，就讓這個賬戶在一定時間內（最初也可以是一兩分鐘，然后就可以成倍增加）鎖定。
這可以保護應用程序不被攻擊。

大多數正則表達式可能會導致攻擊者的破解工作變得緩慢和低效。這些的正則表達式被稱為邪惡的正則表達式：

與重復分組

里面的重復組

重復

輪換具有重疊

([a-zA-Z]+)*，(a+)+或者(a|a?)+是所有弱勢的正則表達式作為一個簡單的輸入一樣aaaaaaaaaaaaaaaaaaaaaaaa!會導致重計算。每增加一個a，時間就會翻倍。

在NodeJs中，如果要檢查正則表達式，你可以safe-regex

$ node safe.js "(beep|boop)*" true  $ node safe.js "(a+){10}" false 

不同的錯誤情況的應用程序可能會泄漏對底層基礎架構的敏感細節，如：X-Powered-By:Express。
棧跟蹤不被視為自己的漏洞，但他們往往可能是吸引的攻擊者的信息。提供了調試信息和產生錯誤操作的結果都被認為是不好的做法。應該用日志記錄下來，而不是顯示給用戶。

NPM有很多包提供給大家使用，但是這也是有代價的：應該好好檢查你需要為你的應用程序是什么。也許你使用之后可能含有重要的安全問題。

不過幸運的是，有一個偉大的工具--The Node Security Platform，可以檢查使用的模塊為已知的漏洞。

npm i nsp -g  # either audit the shrinkwrap nsp audit-shrinkwrap  # or the package.json nsp audit-package 

你還可以使用requireSafe。

SnykSnyk

SnykSnyk類似于The Node Security Platform，但他的目的是提供一種工具，不能只檢測，只是在代碼庫修復安全相關的問題。
更多信息你可以看看snyk.io
本人的博客http://www.wjs.photo/,感興趣的可以看看哦，基于NodeJs框架ThinkJs