Node.js 安全实践：拒绝用动态变量加载模块（Safe Module Loading）

• 文档
• 教程
• 后端

本篇文章聚焦于 Node.js 最佳实践清单（README.md 第 6.17 条Avoid module loading using a variable）所阐述的核心议题：禁止以用户可控的变量作为require/import的路径参数。你将理解这类写法为何会导致任意文件访问甚至代码执行，掌握从"写死静态路径"到"白名单校验 + Linter 自动化检测"的完整防御套路，并把规则扩展到fs.readFile()等敏感资源访问场景，直接应用于日常的 Node.js 安全代码审查。

一、什么是"使用变量加载模块"，它为什么危险

在 Node.js 中，require()与 ESM 的import都接受一个字符串路径作为模块定位依据。当这个路径不是字面量（literal），而是由运行时变量拼接、且该变量可能来自用户输入时，就打开了一扇攻击之门。

原文档（sections/security/safemoduleloading.md，波兰语版本见 sections/security/safemoduleloading.polish.md，中文版本见 sections/security/safemoduleloading.chinese.md）用一句话概括了这条规则的出发点：

避免以参数形式传入的路径来require/import另一个文件，因为该路径变量可能源自用户输入（untrusted user input）。

这条规则还可以进一步推广：凡是"用动态变量访问敏感资源"的写法都要警惕，例如fs.readFile()这类文件系统操作，或其他由用户输入驱动的敏感资源访问。

攻击后果

当恶意输入进入模块加载路径时，攻击者可以：

• 加载被篡改的文件：例如诱导require()指向攻击者先前上传到服务器文件系统上的恶意 JS 文件，从而执行任意代码；
• 读取既有系统文件：把路径指向/etc/passwd、配置文件等敏感文件，造成信息泄露。

README 第 6.17 节对"如果不遵守会怎样"给出了更直白的描述（见 README.md#-617-avoid-module-loading-using-a-variable）：

恶意用户输入可能流入用于加载被篡改文件的参数，例如先前上传到文件系统的文件；或者让应用访问已存在的系统文件。

有趣的是，README 为该条目标注的 OWASP 威胁标签同时覆盖了A7: Cross-Site Scripting (XSS)、A1: Injection和A4: XML External Entities (XXE)，说明动态路径问题本质上是"注入类 + 敏感数据访问类"的组合型风险，而不只是代码规范问题。

二、原文档给出的正反示例

这是本实践最核心、必须 100% 继承的实操代码（原样取自原文档）：

// 不安全：helperPath 变量可能已被用户输入修改 const badWayToRequireUploadHelpers = require(helperPath); // 安全：使用硬编码的静态相对路径 const uploadHelpers = require('./helpers/upload');

两行代码道出了全部要点：

核心原则一句话：模块路径必须是静态字面量，永远不要把用户输入拼进模块解析路径。

三、攻击面扩展：规则不仅限于require

原文档明确指出，这条规则"可以扩展到一般情况下的文件访问"：

// 反例：用户输入直接进入文件系统操作 const path = req.body.userinput; fs.readFile(path); // 攻击者可读取任意文件

这类"非字面量文件名（non-literal filename）"是 Node.js 应用中一类非常典型的不安全模式。仓库在 sections/security/lintrules.md（第 6.1 条 Embrace linter security rules）中给出了同源反例，并展示了eslint-plugin-security如何将其识别为规则detect-non-literal-fs-filename：

// eslint-plugin-security 的 detect-non-literal-fs-filename 规则示例 const path = req.body.userinput; fs.readFile(path);

可见，动态路径问题的本质是"用户输入进入敏感 API 的路径参数"，require、fs.readFile、fs.createReadStream、child_process的 shell 命令等都是同一类风险的载体。仓库内与之呼应的相邻实践还包括：

• sections/security/avoideval.md（6.15 避免eval）：演示了eval(userInput)如何把"require('child_process').spawn('rm', ['-rf', '/'])"变成真实攻击载荷；
• sections/security/childprocesses.md（6.19 谨慎使用子进程）：exec()拼接未净化的用户输入，可能触发&& rm -rf --no-preserve-root /一类的 shell 注入；
• sections/security/saferedirects.md（6.24 防止不安全重定向）：res.redirect(req.query.url)直接把用户输入当跳转目标；
• sections/security/sandbox.md（6.18 在沙箱中运行不安全代码）：当确实需要执行运行期代码时，用独立进程或沙箱隔离。

它们共同构成了"用户输入永不直接进入敏感 API"这一安全红线。

四、为什么必须在代码审查阶段就拦截：自动化 Linter 检测

人工审查难免遗漏，仓库推荐的方案是引入安全类 Lint 规则让工具"提前报警"。README 第 6.17 节明确写道：

eslint-plugin-security这类 Linter 可以捕获此类模式并及时发出警告。

在 sections/security/lintrules.md 中可以看到该插件针对本主题的关键规则：detect-non-literal-fs-filename（文件系统访问使用了非字面量路径）。此外它还覆盖detect-pseudoRandomBytes、detect-eval-with-expression、detect-non-literal-regexp等相邻风险。下图展示了在 Node.js 项目中对上述不安全代码运行eslint-plugin-security的效果（图片见仓库 assets/images/eslint-plugin-security.png）：

接入方式非常轻量：在项目中安装并启用该插件，把检测规则并入现有 ESLint 配置，即可在require(variableAsPath)、fs.readFile(userInput)这类代码合入前被拦下。正如 lintrules.md 引用的观点：Lint 不只是管空格和分号，它还能作为消灭危险代码模式的强力框架。

五、落地防护清单：从写死路径到纵深防御

综合原文档与仓库中相关实践，推荐按以下层次加固：

1. 模块加载路径一律写死：require/import只接受字面量相对/绝对路径；如果必须支持"按需加载"，也应由服务端维护的静态映射表决定，而不是用户直接传路径。
2. 文件系统访问做白名单校验：若业务确实需要按用户输入读取文件（如头像、导出文件），把输入映射到受控目录内的固定文件名，校验解析后路径仍落在允许的根目录内（防目录穿越），例如path.resolve()后检查前缀。
3. 可复用的校验函数集中管理：参考 sections/security/saferedirects.md 中"安全重定向白名单"的思路——用getValidRedirect(url)这样的集中函数统一校验后再使用，而不是在每个调用点临时判断。
4. 最小权限 + 隔离：即使防护失效，也要让损失可控——以非特权用户运行进程（见 sections/security/non-root-user.md）、把运行期代码放进沙箱或独立子进程（见 sections/security/sandbox.md）。
5. Linter 自动化拦截：启用eslint-plugin-security，让detect-non-literal-fs-filename等规则在 CI 阶段提前报警，避免不安全写法流入主干。

六、自查清单与 FAQ

审查代码时可对照以下问题：

• 所有require()/import的路径是否都是字面量？
• fs.readFile()/fs.createReadStream()等文件操作的路径参数是否可能被请求参数、查询串或消息体影响？
• 是否存在"用户上传文件路径被直接用于加载"的场景？
• 动态加载需求是否已通过白名单映射表实现？
• 项目的 ESLint 是否已启用安全类插件并跑在 CI 上？

FAQ 要点：

• 问：插件系统必须动态加载用户写的模块，怎么办？
  答：这是"运行不安全代码"场景，应遵循 sections/security/sandbox.md 的隔离思路（独立进程、serverless 环境或沙箱包），而不是在服务主进程里直接require(pluginPath)。
• 问：用path.join拼接就安全了吗？
  答：不能保证。规范化之后的路径仍可能逃逸出预期目录（目录穿越），且require本身就能执行任意 JS；正确做法是让用户输入只参与"选择"（如映射表键值），不参与"路径构造"。

七、小结

"避免使用变量加载模块"是 Node.js 安全实践中投入产出比极高的一条：它改动极小（写死路径）、收益极大（掐断一条通向任意代码执行/任意文件读取的路径），并且可以低成本地通过 Linter 自动化。把这条规则连同其扩展（fs等敏感资源访问）纳入团队的代码规范与审查清单，是 Node.js 应用上线前必须完成的一步。原文档全文可继续查阅英文版 sections/security/safemoduleloading.md，中文版 sections/security/safemoduleloading.chinese.md，以及其在清单中的位置 README.md#-617-avoid-module-loading-using-a-variable。

• 文档
• 教程
• 后端