Node.js Express 框架安全问题
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/14612143/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Node.js Express Framework Security Issues
提问by D.Deriso
I'm looking for modules that should be added to a Node/Express app that address the general security concerns listed below:
我正在寻找应该添加到 Node/Express 应用程序的模块，以解决下面列出的一般安全问题：
- Injection Vulnerabilities (JavaScript, SQL, Mongo, HTML)
- Session fixation and hiHymaning
- Cross-Site Vulnerabilities (Scripting, Request Forgery)
- Mass Assignment
- insert relevant concern here
- 注入漏洞（JavaScript、SQL、Mongo、HTML）
- 会话固定和劫持
- 跨站点漏洞（脚本、请求伪造）
- 批量分配
- 在此处插入相关问题
Thanks for your help!
谢谢你的帮助！
----------
----------
Some resources I've found:
我发现的一些资源：
Excellent talk (11/2012): http://lanyrd.com/2012/asfws/sxzbm/(see slides)
ServerFault question (2011-2012): https://serverfault.com/questions/285123/is-node-js-mature-for-enterprise-security
Blog post on topic (9/2012): http://codefol.io/posts/29-Why-Rails-and-not-Sinatra-or-Node-js-
Exploit tester: https://code.google.com/p/skipfish/
Passport Module: https://github.com/jaredhanson/passport
EveryAuth Module: https://github.com/bnoguchi/everyauth
精彩演讲 (11/2012)：http://lanyrd.com/2012/asfws/sxzbm/ （见幻灯片）
ServerFault 问题（2011-2012）：https: //serverfault.com/questions/285123/is-node-js-mature-for-enterprise-security
关于主题的博客文章 (9/2012)：http://codefol.io/posts/29-Why-Rails-and-not-Sinatra-or-Node-js-
漏洞利用测试器：https: //code.google.com/p/skipfish/
护照模块：https: //github.com/jaredhanson/passport
EveryAuth 模块：https: //github.com/bnoguchi/everyauth
采纳答案by Adam Baldwin
I wrote a blog post that gives a great starting point on Writing Secure Express.js Apps. It covers a few other things beyond csrf and helmet as was mentioned by zeMirco.
我写了一篇博客文章，为编写安全 Express.js 应用程序提供了一个很好的起点。它涵盖了 zeMirco 提到的 csrf 和头盔之外的其他一些内容。
The other thing is you can't compare express.js to rails. They are apples and oranges. For example, there is no ORM that is bundled with Express, that implementation or use of a third party module is up to you.
另一件事是您无法将 express.js 与 rails 进行比较。它们是苹果和橙子。例如，没有与 Express 捆绑的 ORM，第三方模块的实现或使用取决于您。
I'll try and give a breakdown of each of your concerns.
我会尝试对您的每个问题进行细分。
-Injection Vulnerabilities (JavaScript, SQL, Mongo, HTML)
Again, these are things not built into express. The closest thing would be XSS worries over injection in templates. Jade or EJS templates that are commonly used with express output encode < > " ' and & by default, but remember there are other contexts like user input into JavaScript or CSS that you would need to worry about.
同样，这些东西并没有内置到 express 中。最接近的是 XSS 担心模板中的注入。默认情况下，与 express 输出一起使用的 Jade 或 EJS 模板对 < > " ' 和 & 进行编码，但请记住，您还需要担心其他上下文，例如用户输入到 JavaScript 或 CSS 中。
-Session fixation and hiHymaning
Again see the blog post above, but Express is based on and uses most of the connectmiddleware one of these is the session middleware. Biggest thing here is to properly set your cookie flags.
再次查看上面的博客文章，但 Express 基于并使用了大部分连接中间件，其中之一是会话中间件。这里最重要的是正确设置您的 cookie 标志。
-Cross-Site Vulnerabilities (Scripting, Request Forgery)
See above. It also comes with express.csrf() middleware. The blog post mentioned shows how to implement it.
看上面。它还带有 express.csrf() 中间件。提到的博客文章展示了如何实现它。
-Mass Assignment
Not an issue with express.js as it has no concepts in which this type of vulnerable would be applicable, however the custom logic you write may be in fact vulnerable to this problem, so again it's a problem of verifying if your code is vulnerable or if the third party module you used is...
这不是 express.js 的问题，因为它没有适用于此类易受攻击的概念，但是您编写的自定义逻辑实际上可能易受此问题的影响，因此再次验证您的代码是否易受攻击或如果您使用的第三方模块是...
回答by zemirco
回答by andrewrk
One thing to be wary of is bodyParser. See http://andrewkelley.me/post/do-not-use-bodyparser-with-express-js.html
需要警惕的一件事是 bodyParser。见http://andrewkelley.me/post/do-not-use-bodyparser-with-express-js.html
回答by Eric Elliott
You should be aware that if you specify a catch-all error handler, you should NOT restart the server or do anything blocking in that handler in response to USER errors (the 4xxrange) because it could lead to a DOS vulnerability. This vulnerability is addressed automatically in express-error-handler, and the service will shut down as soon as it can (when active connections are drained or a timeout occurs) so restarts shouldn't be a big deal. Implementing this behavior made a really big difference in my exploit tests.
您应该知道，如果您指定了一个包罗万象的错误处理程序，则不应重新启动服务器或在该处理程序中执行任何阻塞以响应 USER 错误（4xx范围），因为这可能导致 DOS 漏洞。此漏洞在 中自动解决express-error-handler，服务将尽快关闭（当活动连接耗尽或发生超时时），因此重新启动应该没什么大不了的。实现这种行为对我的漏洞利用测试产生了很大的影响。
BTW, it's NOT safe to simply ignore all unhandled errors. That would leave your application in an undefined state, which just presents another type of DOS vulnerability.
顺便说一句，简单地忽略所有未处理的错误是不安全的。这将使您的应用程序处于未定义状态，这只是另一种类型的 DOS 漏洞。
