修复console任意文件读取漏洞

[Potatowo233]

原代码中如果路径名以@plugin-开头则不对路径做任何校验，不是js文件的话(如koishi.yml)能直接sendFile(filename)返回

koishi的后台账号密码完全明文写在koishi.yml中，因此一旦读取到能够直接进入后台进行更加高危的操作比如任意代码执行

服务端代码执行示例（无需额外安装任何插件）：

修复方案对插件文件先目录规范化后去除所有./和../，再判断目录位置是否合法

[ilharp]

已在 Koishi v4.18.9 + plugin-console v5.30.10 上复现。目测此漏洞危害极大、影响极大，需要尽快修复。

ping @shigma

[ilharp]

Closed by mistake. Reopening

[DGCK81LNN]

@shigma 我对此修复有疑问。这里的逻辑是 filename = resolve(this.root, files[0] + name.slice(8 + key.length))，其中 files 是插件开发者定的路径，name 是请求 URL 中出现的、相对于 files[0] 的路径。只要 name 不包含 .. 段不就是安全的吗？为什么还要用 !filename.startsWith(this.root) && !filename.includes('node_modules') 作判断标准？以下是我的修复：

const relativePath = name.slice(8 + key.length)
if (relativePath.split(/[/\\]/g).includes("..")) {
  return ctx.status = 403
}
const filename = files[0] + relativePath

控制台插件开发者可能引用绝对路径不包含“node_modules”的 JavaScript 文件，我认为这本身没有问题，而在本 PR 的修改后这些控制台插件加载时都会返回 403 错误。而本 PR 的修改并没有阻止访问者读取任何绝对路径包含“node_modules”的文件，我认为这是不妥的。

[shigma]

@DGCK81LNN

从结果来看，这个文件的代码确实可能并不是最优的，但这并不意味着这个 PR 有问题。此文件的另一处位置已经包含了类似的逻辑（判断 startsWith + includes），因此这个 PR 符合最小改动原则。此外，从安全性的角度，对路径拼接的结果进行判断总是比判断片段更安全。

关于 node_modules 的问题，确实可以另做讨论，欢迎新的 issue 和 PR。