Node.js 安全最佳实践

602次阅读  |  发布于2年以前

最近 Node.js 团队在官方文档上公布了一份最新的安全实践，解读了一些 Node.js 服务下一些常见的攻击场景以及预防手段，我们一起来看看吧！

计时攻击

计时攻击可能会让攻击者获取到一些潜在的敏感信息，例如，测量应用程序响应请求所需的时间。这种攻击并不是特定于 Node.js 的，几乎可以针对所有运行时。

我们的程序代码中可能会存在一些时间段敏感的操作，比如我们需要校验一个用户的密码是否正确。

我们可能会从数据库检索出来的用户信息中比较密码。对于相同的长度值，使用内置字符串比较可能需要更长的时间。这种比较在以可接受的数量运行时会增加请求的响应时间。通过比较请求响应时间，攻击者可以在大量请求中猜测密码的长度和值。

缓解措施

crypto API

恶意第三方模块

目前，在 Node.js 中，任何包都可以访问网络、文件系统，他们可以将任何数据发送到任何地方。

所有运行在 Node.js 进程中的代码都能够通过使用 eval() 加载和运行额外的任意代码。所有具有文件系统写访问权限的代码都可以通过写入加载的新文件或现有文件来实现相同的目的。

Node.js 有一个实验性的 策略机制(https://nodejs.org/api/permissions.html#policies) 来声明加载的资源是否是不受信任的。

我们应该确保使用通用工作流或 npm script 固定依赖版本、自动检查漏洞。在安装依赖包之前，请确保这个还是在维护的并包含你期望的所有内容。注意，Github 源代码并不总是与发布的包相同，最好在 node_modules 中验证一下。

供应链攻击

供应链攻击一般指控制上游包的攻击者可以发布包含恶意代码的新版本。如果我们的 Node.js 应用程序依赖于这个包，而没有严格确定哪个版本可以安全使用，则该包可以自动更新到最新的恶意版本，从而危及应用程序。

供应链攻击攻击最近在 Node.js 的依赖生态中频发发生，比如前段时间的 node-ipc，针对俄罗斯和白俄罗斯 IP，会尝试覆盖当前目录、父目录和根目录的所有文件，把所有内容替换成 ❤。

这主要还是因为 Node.js 生态对依赖项的规范过于松懈了，比如允许不需要的更新，我们可能悄无声息的在某一次上线中为我们的程序带来了巨大的危机。

虽然我们可以在 package.json 中指定依赖项确切的版本号或范围，但这只能保证直接依赖的固定，我们仍然无法保障间接依赖的不确定性更新。

缓解措施

内存访问冲突

基于内存或基于堆的攻击取决于代码中的内存管理错误和可利用的内存分配器的组合。与所有运行时一样，如果项目运行在共享的机器上，Node.js 很容易受到这些攻击。使用 secure heap 有助于防止由于指针溢出和不足而导致敏感信息泄漏。

但是，secure heap 在 Windows 上不可用，更多信息可以看这个文档：https://nodejs.org/dist/latest-v18.x/docs/api/cli.html#--secure-heap

缓解措施

猴子修补

猴子补丁指的是为了改变现有的行为在运行时修改属性，比如：

// eslint-disable-next-line no-extend-native
Array.prototype.push = function (item) {
  // overriding the global [].push
};

缓解措施

--frozen-intrinsics 标志可以启用实验性的 冻结内置函数，启用后所有内置的 JavaScript 对象和函数都被递归冻结。下面的代码片段不会覆盖 Array.prototype.push 的默认行为

// eslint-disable-next-line no-extend-native
Array.prototype.push = function (item) {
  // overriding the global [].push
};

// Uncaught:
// TypeError <Object <Object <[Object: null prototype] {}>>>:
// Cannot assign to read only property 'push' of object ''

但需要注意的是，你仍然可以使用 globalThis 定义新的全局变量并替换现有的全局变量：

> globalThis.foo = 3; foo; // you can still define new globals
3
> globalThis.Array = 4; Array; // However, you can also replace existing globals
4

Object.freeze(globalThis) 可用于保证不会替换任何全局变量。

原型污染

原型污染是指通过滥用 _proto_、 constructor、prototype 和其他从内置原型继承的其他属性来修改或将属性注入 JavaScript 语言项的攻击，这是一种继承自 JavaScript 语言的潜在漏洞。

比如下面的代码，一个外部传入的数据可能会影响到我们整个 Node.js 服务的 Object 对象的默认行为：

const a = {"a": 1, "b": 2};
const data = JSON.parse('{"__proto__": { "polluted": true}}');

const c = Object.assign({}, a, data);
console.log(c.polluted); // true

// Potential DoS
const data2 = JSON.parse('{"__proto__": null}');
const d = Object.assign(a, data2);
d.hasOwnProperty('b'); // Uncaught TypeError: d.hasOwnProperty is not a function

缓解措施

路径引入漏洞

Node.js 按照模块解析算法（https://nodejs.org/api/modules.html#modules_all_together）加载模块。因此，它默认假定请求（require）模块的目录是受信任的。

也就是说，这意味着以下应用程序行为是预期的。假设有以下目录结构：

app/
  server.js
  auth.js
  auth

如果 server.js 使用 require('./auth') ，它将遵循模块解析算法并加载 auth 而不是 auth.js。

缓解措施

具有完整性检查的实验性策略机制（https://nodejs.org/api/permissions.html#integrity-checks）可以避免上述威胁。对于上述目录，可以使用以下 policy.json

{
  "resources": {
    "./app/auth.js": {
      "integrity": "sha256-iuGZ6SFVFpMuHUcJciQTIKpIyaQVigMZlvg9Lx66HV8="
    },
    "./app/server.js": {
      "dependencies": {
        "./auth" : "./app/auth.js"
      },
      "integrity": "sha256-NPtLCQ0ntPPWgfVEgX46ryTNpdvTWdQPoZO3kHo0bKI="
    }
  }
}

当引入 auth 模块时，系统将验证完整性，如果与预期的不匹配则抛出错误。

» node --experimental-policy=policy.json app/server.js
node:internal/policy/sri:65
      throw new ERR_SRI_PARSE(str, str[prevIndex], prevIndex);
      ^

SyntaxError [ERR_SRI_PARSE]: Subresource Integrity string "sha256-iuGZ6SFVFpMuHUcJciQTIKpIyaQVigMZlvg9Lx66HV8=%" had an unexpected "%" at position 51
    at new NodeError (node:internal/errors:393:5)
    at Object.parse (node:internal/policy/sri:65:13)
    at processEntry (node:internal/policy/manifest:581:38)
    at Manifest.assertIntegrity (node:internal/policy/manifest:588:32)
    at Module._compile (node:internal/modules/cjs/loader:1119:21)
    at Module._extensions..js (node:internal/modules/cjs/loader:1213:10)
    at Module.load (node:internal/modules/cjs/loader:1037:32)
    at Module._load (node:internal/modules/cjs/loader:878:12)
    at Module.require (node:internal/modules/cjs/loader:1061:19)
    at require (node:internal/modules/cjs/helpers:99:18) {
  code: 'ERR_SRI_PARSE'
}

注意：始终建议使用 --policy-integrity 来避免策略突变。

HTTP 请求走私攻击（HTTP Request Smuggling）

这是一种涉及两个 HTTP 服务器（通常是代理服务和Node.js 应用服务）的攻击。客户端发送 HTTP 请求，这个请求首先通过前端服务器（代理），然后重定向到后端服务器（应用程序）。当前端和后端对模糊的 HTTP 请求的解释不同时，攻击者就有可能发送前端看不到但后端会看到的恶意消息，有效地通过代理服务器进行了 “走私” 。

通俗地理解就是：攻击者发送一个语句模糊的请求，就有可能被解析为两个不同的 HTTP 请求，第二请求可能会 “逃过” 正常的安全设备的检测，使攻击者可以绕过安全控制，未经授权访问敏感数据并直接危害其他应用程序用户。

由于这种攻击产生的根本原因是 Node.js 与另一个 HTTP 服务器解释 HTTP 请求的方式不同，我们可以认为它是 Node.js、前端服务器两者的漏洞 。如果 Node.js 解释请求的方式是符合 HTTP 规范（https://datatracker.ietf.org/doc/html/rfc7230#section-3）的，那么它就不被认为是 Node.js 中的漏洞。

缓解措施

HTTP 服务拒绝访问

很多时候，由于我们错误的代码逻辑或者错误的配置可能会导致 HTTP 服务无法访问，参考下面的代码：

const net = require('net');

const server = net.createServer(function(socket) {
  // socket.on('error', console.error) // this prevents the server to crash
  socket.write('Echo server\r\n');
  socket.pipe(socket);
});

server.listen(5000, '0.0.0.0');

我们的 WebServer 没有正确的处理 Socket 错误，当发送的请求量过大时，我们的服务就会崩溃。

缓解措施

DNS 重绑定

这是一种针对在使用 --inspect (https://nodejs.org/en/docs/guides/debugging-getting-started/) 启用调试检查器的情况下运行的 Node.js 应用程序的攻击。

由于在 Web 浏览器中打开的网站可以发出 WebSocket 和 HTTP 请求，它们可以针对本地运行的调试检查器。这通常会被现代浏览器实施的同源策略所阻止，这个策略会禁止脚本访问来自不同来源的资源（意味着恶意网站无法读取从本地 IP 地址请求的数据）。

但是，通过 DNS 重绑定，攻击者可以暂时控制其请求的来源，使它们看起来像是来自本地 IP 地址。这是通过控制网站和用于解析其 IP 地址的 DNS 服务器来完成的。详细可以了解：https://en.wikipedia.org/wiki/DNS_rebinding

缓解措施

NPM 敏感信息泄漏

在包发布期间，包含在当前目录中的所有文件和文件夹都会被推送到 npm 注册表中，如果我们的开发目录中包含了一些敏感信息，它们都会被泄露出去。

我们可以通过用 .npmignore 和 .gitignore 定义一个阻止列表或者在 package.json 中定义一个 allowlist 来控制这种行为

缓解措施

最后

参考：https://nodejs.org/en/docs/guides/security/

Copyright© 2013-2020

All Rights Reserved 京ICP备2023019179号-8