Node.js 有一个奇怪的特性，允许一个参数有多个值。假设有一个参数叫做 email，我们给这个参数传递了多个值，最终 email 参数将包含这两个值，两个值之间用逗号隔开。

  该特性可用来进行参数解析漏洞的利用。

  Unprotected Routes

  现在大部分应用程序都采用 MVC 架构。我们首先了解这个 MVC 是什么。MVC 将应用程序分成三个逻辑组件：Model，View，Controller。其有效地帮助开发人员和软件架构师将业务逻辑从代码层面分离出来。

  所有的 URL 被称为路由，保存在路由文件中。有一个“路由器”来协调当用户点击了链接时，应该触发那个控制器。

  而在可信和不可信路由之间就容易产生这样一个问题，从名字我们就可以猜到，可信的路由就是某用户登陆以后有权限访问的页面 URL。

  为了演示这个功能， 我们构建了一个 Node.js 的测试平台 Nodegoat。它是一个有多个用户的退休金管理平台。但是只有一个管理员可以查看其他用户的退休金。

  如下所示，退休金路由（URL）并没有检查访问用户是否是管理员，因此任意的用户都能查看他人的退休金 。

  如下所示，我们以普通用户身份登录，没有显示退休金的功能：

  我们以管理员登录，该功能出现了：

  为了验证上述漏洞，我们切换到普通用户，强制浏览器访问退休金页面，我们成功的查看到了页面的内容：

  修复未保护的路由（URL）

  我们增加一个 isAdmin 的中间件来确保只有管理员可以访问该页面：

  之后，我们又一次尝试访问退休金页面，则被跳转到重新登陆页面：

  Global Namespace Pollution

  当一个变量定义在全局作用域的范围内时，该应用上的所有的代码都可以访问和修改该变量值，这就容易产生一个 confusion银行卡js验证规则，不同的函数任意时刻访问这个变量可能会有相同的、不同的、甚至被覆盖的值。这个行为被称作 Global Namespace Pollution（全局命名空间污染）。从安全的角度来看，这种行为可能会被利用，取决于存储在全局作用域的值是什么类型的变量或函数。

  如下所示，我们定义了一个变量叫做 global，我们只是简单的将其加一，然后打印：

  问题就是，无论什么时候用户访问，该值都会加一，然后显示给用户。这中行为有一个风险，如果 session token 被存储在全局名字空间中，且和这样有相似的行为，则 attacker 可以轻易的猜测到下一个要分配给用户的 session cookie。

  Cross Site Scripting

  XSS 通常是由于在缺乏合适的有效的验证，不可信的用户输入被包含在了应用服务的响应当中。就 Node.js 而言，内置的模块没有对抗 XSS 攻击。这样会导致新手程序员会犯一些低级错误，而给 attacker 留下了一些可趁之机。

  如下所示，我们直接显示了用户的输入，没有丝毫验证：

  进一步利用：

  在 Node.js 中为了对抗 XSS 攻击银行卡js验证规则，显然我们需要实现上下文相关的过滤，我们可以使用一个包叫做 html-entities，可以使用命令 npm install html-entities 安装。添加后的现象，可见 payload 并没有执行。

  Insecure Components

  不安全的组件的问题影响所有你使用的第三方库。从一个安全角度来看，在使用这些库时，非常有必要 review 下它们的代码。查看它们官网的漏洞公告，来确保你使用的是最新和最稳定的版本。更进一步也可以使用特定的工具来自动检查这个风险，本节之后将提到。

  我们使用 nodegota 来举例说明，它用到的一个包 marked 曾有一个版本有XSS漏洞。如下所示，当插入如下 payload 时，它一个 link 被嵌入 JavaScrip t脚本。

  <pre>Click here to download)</pre>

  我们可以使用现成的工具 snyk 和 npm-check 来自动验证不安全和过时的组件。可以使用如下命令来安装这些工具：

  <pre>npm install -g npm-check</pre>

  我们在测试程序 nodegota 上执行这些工具，看看效果。如下，npm-check 的检查给一些不宜使用的包打 flag，告诉我们这些包该升级了。

  对于使用 synk，你需要配置你的账户，配置好之后，切换到 nodegoat 的主目录，执行命令 snyk test。

  如下所示：它发现了有漏洞的包，同时标记出来：

  Secure Code Review

  对于一个大型的应用来说实现代码 review 是一个极其费力的活，需要遍历成百上千行的代码。一般建议使用半自动化的方式来实现代码 review。比如手工检查业务逻辑，同时自动完成重复性的那些工作，比如查找漏洞函数，包，模块的名字和配置等。确保所有的函数都进行了，用户输入的处理，文件的操作，数据库的查询，硬编码的信息，不安全的 SSL/TLS 版本，不安全的加密，全局变量等等。进一步，我们使用上述提到的工具 snyk 和 node-check 来检查过时和有漏洞的包。

  结束语

  从这个系列提到的漏洞中，我们可以得出，大部分的漏洞都是源于不安全的用户输入。因此，要经常进行过滤和验证用户的输入，确保使用了合适的中间件来避免不可信的流程。这篇文章没有提到 Ajin Abraham 开发的神奇的工具 NodeJsScan。该工具是一款静态代码分析工具。它使用了大量的正则表达式规则来扫描可能的漏洞代码和不安全的配置，同时允许用户扩展自己的功能。可以从这下载NodeJsScan。

  引用

  本文由 看雪翻译小组 ghostway 编译，来源Sahil Dhar@INFOSECINSTITUTE

  看雪论坛：

  微信公众号 ID：ikanxue

  微博：看雪安全

  投稿、合作：