Node.js 安全最佳实践
大家好，我是 ConardLi。
最近 Node.js 团队在官方文档上公布了一份最新的安全实践，解读了一些 Node.js 服务下一些常见的攻击场景以及预防手段，我们一起来看看吧！
计时攻击
计时攻击可能会让攻击者获取到一些潜在的敏感信息，例如，测量应用程序响应请求所需的时间。这种攻击并不是特定于 Node.js 的，几乎可以针对所有运行时。
我们的程序代码中可能会存在一些时间段敏感的操作，比如我们需要校验一个用户的密码是否正确。
我们可能会从数据库检索出来的用户信息中比较密码。对于相同的长度值，使用内置字符串比较可能需要更长的时间。这种比较在以可接受的数量运行时会增加请求的响应时间。通过比较请求响应时间，攻击者可以在大量请求中猜测密码的长度和值。
缓解措施
crypto API
crypto API提供了一个timingSafeEqual函数，当你需要进行比较的值比较敏感时，它可一采用恒定时间算法进行比较。对于密码比较，你可以使用 crypto模块上提供的scrypt(https://nodejs.org/api/crypto.html#cryptoscryptpassword-salt-keylen-options-callback)。避免在可变时间操作中使用密钥，包括密钥分支，并且当攻击者可能位于同一基础设施（例如同一台云机器）上时，使用密钥作为内存索引。用 JavaScript编写恒定时间的代码还是很困难的，对于加密应用程序，推荐使用内置的加密 API 或WebAssembly。
恶意第三方模块
目前，在 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 中指定依赖项确切的版本号或范围，但这只能保证直接依赖的固定，我们仍然无法保障间接依赖的不确定性更新。
缓解措施
防止 npm使用——ignore-scripts执行任意脚本可以使用 npm config set ignore-scripts true全局禁用它将 lock文件将依赖版本固定到特定的不可变版本，而不是一个范围（当然后续要手动定期更新）将 npm audit引入 CI 流程，自动检查漏洞诸如 Socket之类的工具可以用来分析带有静态分析的包，以发现诸如网络或文件系统访问之类的风险行为使用 npm ci代替npm install，这将强制执行lockfile，避免它与package.json文件之间的不一致会导致错误仔细检查 package.json文件中依赖项名称中的错误/错别字。
内存访问冲突
基于内存或基于堆的攻击取决于代码中的内存管理错误和可利用的内存分配器的组合。与所有运行时一样，如果项目运行在共享的机器上，Node.js 很容易受到这些攻击。使用 secure heap 有助于防止由于指针溢出和不足而导致敏感信息泄漏。
但是，secure heap 在 Windows 上不可用，更多信息可以看这个文档：https://nodejs.org/dist/latest-v18.x/docs/api/cli.html#--secure-heap
缓解措施
根据程序的时机情况使用 ——secure-heap=n，其中n是分配的最大字节大小；不要在共享机器上运行比较重要的应用程序。
猴子修补
猴子补丁指的是为了改变现有的行为在运行时修改属性，比如：
// 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
缓解措施
避免不安全的递归合并（https://gist.github.com/DaniAkash/b3d7159fddcff0a9ee035bd10e34b277#file-unsafe-merge-js） 为外部/不受信任的请求实施 JSON模式验证使用 Object.create(null)创建没有原型的对象使用 Object.freeze(MyObject.prototype)冻结原型使用 --disable-proto标志禁用Object.prototype.__proto__属性检查属性是否直接存在于对象上，而不是从使用 Object.hasOwn(obj, keyFromObj)避免使用 Object.prototype中的方法。
路径引入漏洞
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服务器时，不要使用insecureHTTPParser选项；前端服务器的配置要尽量规范化，避免歧义请求； 持续监控 Node.js 和前端服务器中是否存在新的 HTTP请求走私漏洞；使用 HTTP/2端到端并尽可能禁用HTTP降级。
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 错误，当发送的请求量过大时，我们的服务就会崩溃。
缓解措施
使用反向代理接收请求并将请求转发到 Node.js应用程序。反向代理可以提供缓存、负载平衡、IP 黑名单等功能，从而降低DoS攻击生效的可能性；正确配置服务器超时，以便可以放弃空闲或速度太慢的连接。例如 http.Server 中的 headersTimeout、requestTimeout timeout keepAliveTimeout；限制每台主机打开的 Socket总数，可以参考http中的agent.maxSockets、agent.maxTotalSockets、agent.maxFreeSockets、server.maxRequestsPerSocket
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
缓解措施
通过附加一个 process.on(‘SIGUSR1’, …)侦听器来禁用SIGUSR1信号上的检查器不要在生产环境中运行 inspector协议
NPM 敏感信息泄漏
在包发布期间，包含在当前目录中的所有文件和文件夹都会被推送到 npm 注册表中，如果我们的开发目录中包含了一些敏感信息，它们都会被泄露出去。
我们可以通过用 .npmignore 和 .gitignore 定义一个阻止列表或者在 package.json 中定义一个 allowlist 来控制这种行为
缓解措施
使用 npm publish——dry-run列出所有要发布的文件，确保在发布包之前进行检查；创建和维护诸如 .gitignore和.npmignore这样的忽略文件也很重要。在这些文件中，你可以指定不应该发布哪些文件/文件夹；
最后
参考：https://nodejs.org/en/docs/guides/security/
如果你想加入高质量前端交流群，或者你有任何其他事情想和我交流也可以添加我的个人微信 ConardLi 。
如果这篇文章帮助到了你，欢迎点赞和关注。
抖音安全团队正在招聘前端，感兴趣请查看：抖音安全团队招聘前端工程师
点赞和在看是最大的支持⬇️❤️⬇️