媒介
这将是一个分为两部份,内容是关于在临盆环境下,跑Express
运用的最好实践。第一部份会关注平安性,第二部份最会关注机能和可靠性。当你读这篇文章时,假定你已对Node.js
和web开辟有所相识,而且对临盆环境有了观点。
概览
临盆环境,指的是软件性命循环中的某个阶段。当一个运用或API已被它的终端用户所运用时,它便处在了临盆环境。相反的,在开辟环境下,你任然在不断得修正和测试代码,运用也不能被外部所接见。
开辟环境和临盆环境常常有很大的设置上的和要求上的差别。一些在开辟环境下可以运用的东西,在临盆环境下,它们不一定是可以被接收的。比方,在开辟环境下,我们须要细致的毛病日记信息来协助我们debug,而在临盆环境下,这则会带来平安隐患。又比方,在开辟环境下,你没必要斟酌可伸缩性和可靠性另有机能的题目,但这些在临盆环境下都非常重要。
以下是将Express
运用布置于临盆环境中的一些平安性方面的最好实践。
不要运用被弃用或不可靠的Express
版本
Express
2.x 和 3.x 已不再被庇护了。这些版本上的平安和机能题目都将不会被修复。所以不要运用它们!假如你还没有迁徙至Express
4,可以参考这份迁徙指南。
同时也保证不要运用在平安更新列表中列出的这些不可靠版本的Express
。假如你不巧运用了,请晋级至稳定版,最好是最新版。
运用TLS
假如你的运用须要处置惩罚或传输敏感数据,请运用TLS
来确保衔接和信息的平安。这项手艺会在数据被从客户端发出前加密它。只管Ajax
和POST
要求中发出的数据看上去并不可见,但它们的收集环境仍可以被嗅探和举行中间人进击。
你能够已对SSL
加密有所相识。TLS
是进化版的SSL
。换句话说,假如你正在运用SSL
,请更新成运用TLS
。大多数情况下,我们引荐运用Nginx
来处置惩罚TLS
。关于如安在Nginx
(或其他服务器)上设置TLS
,请参考引荐的服务器设置(Mozilla Wiki)。
别的,有一个可以很轻易地获得TLS
证书的东西是Let’s Encrypt。它是一个免费的,自动化的,开放的CA
。由ISRG
供应。
运用Helmet
Helmet
经由历程适当地设置一些HTTP头,来协助你的运用免受一些广为人知的web进击。
Helmet
实在就是九个设置与平安相干的HTTP头的中间件的鸠合:
csp 设置了
Content-Security-Policy
头来协助招架跨站剧本进击和其他跨站注入。hidePoweredBy 移除了
X-Powered-By
头。hpkp 添加了Public Key Pinning头来招架运用捏造证书的中间人进击。
hsts 设置了
Strict-Transport-Security
头来强迫运用平安衔接。ieNoOpen 为IE8+设置了
X-Download-Options
头。noCache 设置了
Cache-Control
和Pragma
头来制止客户端缓存。noSniff 设置了
X-Content-Type-Options
头来阻挠浏览器举行MIME嗅探。frameguard 设置了
X-Frame-Options
头来供应对点击挟制的庇护。xssFilter 设置了
X-XSS-Protection
头来启用大多数当代浏览器中的XSS过滤器。
装置Helmet
的历程和其他模块没有什么两样:
$ npm install --save helmet
然后像其他中间件一样运用它:
...
var helmet = require('helmet');
app.use(helmet());
...
最少最少,你须要禁用X-Powered-By
头
假如你不想运用Helmet
,那末你最少须要禁用X-Powered-By
头。进击者可以应用这个头(默许被启用)来相识到你的运用是一个Express
运用,然后举行有针对性的进击。
所以,最好实践是运用app.disable()
封闭这个头:
app.disable('x-powered-by');
假如你运用了Helmet
,则它会帮你完成这件事。
平安地运用cookies
确保不要让cookies暴露了你运用的信息。不要运用默许的session cookie
名,而且要设置好cookie的平安选项。
Express
中有两个重要的cookie session
中间件模块:
express-session 替代了Express 3.x中内建的
express.session
中间件。cookie-session 替代了Express 3.x中内建的
express.cookieSession
中间件。
这两个模块的重要区别是它们存储cookie session
的体式格局。express-session
在服务端存储session
信息。它只在cookie中存储session ID
,而不是session数据。默许情况下,它运用内存存储,在临盆环境下,你须要本身设置可伸缩的session-store
。以下是一个session-store
的列表。
相反地,cookie-session
中间件则把数据都存储在了cookie中:它将全部session序列化至cookie,而不仅仅是一个session ID
。请仅仅在session数据很小且被早早得加密逾期才运用它。浏览器支撑的每一个cookie的大小一般最多是4093B。所以请确保不要凌驾它。别的,cookie中的数据时可以被客户端瞥见的。所以假如你须要对个中的数据举行保密,运用express-session
将是一个更好的挑选。
不要运用默许的session cookie
名
这点和禁用X-Powered-By
头是相似的。潜伏的进击者可以经由历程它们举行针对性的进击。
所以请运用比较广泛的cookie名;如:
var session = require('express-session');
app.set('trust proxy', 1) // trust first proxy
app.use( session({
secret : 's3Cur3',
name : 'sessionId',
})
);
设置cookie的平安选项
经由历程设置以下的cookie选项来增强平安性:
secure – 确保浏览器运用HTTPS发送cookie。
httpOnly – 确保cookie仅经由历程HTTP(S)被发送,而不是客户端的
JavaScript
。用来协助抵抗跨站剧本进击。domain – 指定cookie的域。运用它来与将要发送cookie的URL作比较。只要比较效果经由历程,才会继承搜检下面的
path
属性。path – 指定cookie的途径。运用它来比较要求的途径。假如比较效果经由历程,才会发送cookie。
expires – 为耐久化的cookie设置逾期时候。
以下是一个运用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
来治理你运用的依靠是壮大而轻易的。然则你的依靠库假如有平安隐患,这也会影响到你的运用。你的运用只会和其最衰弱的那部份一样的硬朗。
荣幸的是,有两个东西可以协助你搜检第三方库的平安性:nsp和requireSafe。这两个东西大致上干了雷同的事变,所以选其一运用便好。
nsp
是一个用来搜检你运用的依靠库与它的Node Security Project
数据库中的存储的破绽相对照的敕令行东西,你可以经由历程以下体式格局装置它:
$ npm i nsp -g
然后运用以下敕令来举行搜检你运用的npm-shrinkwrap.json
和package.json
:
$ cd your-app
$ nap check
运用requireSafe
的历程也是相似的:
$ npm install -g requiresafe
$ cd your-app
$ require safe check
其他值得斟酌的事
以下是一些从Node.js平安清单中提出平安发起。细致的发起请自行参阅它:
对运用完成一个接见频次限定机制来抵抗暴力破解。你可以运用如express-limiter如许的中间件。
运用csurf中间件来招架跨站要求捏造(CSRF)。
老是搜检和过滤用户的输入,来防备XSS和敕令注入。
经由历程运用参数化的查询(parameterized queries)或预处置惩罚语句(prepared statements),来招架SQL注入进击。
运用开源的sqlmap东西来侦测你的运用中能够被SQL注入的处所。
运用safe-regex来确保你的正则表达式的硬朗性。
防止其他已知的破绽
除了Node Security Project
替代你搜检出的Express
或其他模块的破绽外。Express
运用也是一个web运用,所以你也要关注其他相干的已知的web破绽,而且防止它们。
末了
原文链接:https://strongloop.com/strongblog/best-practices-for-express-in-production-part-one-security/