Node 的 Browserify 是否规避了 Javascript 的沙箱？

Question

我还没有真正掌握 Node 的 Browserify 模块可以做的所有事情，但很明显，您可以使用 Node 编写的函数（例如文件系统操作）可以在客户端访问。

更具体地说，如果我们有以下节点代码，

window.readFile=function(){
fs.readFile(dir+file, "utf-8", function (err, data) {
    var dataString;     
      if (err){
        throw err;
      }
      if (data){
        dataString = data.toString('utf8');
      }
    console.log(dataString);
    return dataString;
});
}

然后我们猜测目录和文件名，甚至通过基本目录解析并输出所有内容（在 node 中很容易做到），然后我们在文档加载时简单地调用 readFile，这不会规避所有浏览器安全以确保恶意脚本不会访问您的文件系统，或者我在这里遗漏了什么？

Answer 1

没有。 Browserify 使在浏览器上下文中使用 require 样式的依赖项成为可能。并非所有在 Node 中工作 server-side 的东西都工作 client-side（没有修改或没有语义差异）。对于 fs 模块，您不能使用常规的 as-is，而必须让 browserify 将其替换为 browserify-fs，这不会让您任意访问用户的文件系统；相反，它会给你一个 fileystem-like API 用于在浏览器中存储数据，但你将只能使用它来回读你以前在同一网站上写的文件。

我不知道browserify-fs中的具体实现（该网站声称它使用基于LevelDB的自己的数据库，但没有说明该数据库的底层数据存储在哪里），但从历史上看，有几个浏览器 API 用于 client-side 存储，包括 WebSQL (deprecated), IndexedDB, and the FileSystem API (non-standard). There have been various polyfills over the years (e.g. idb.filesystem.js)，它们在 lower-level 存储上提供 file-like 操作。

Answer 2

当您在 browserify 中包含 standard-lib 模块时，它不包含来自您节点安装的副本，而是 a copy browserify includes specifically for the browser.

也就是说，fs 模块是一个 no-op in browserify 有几个原因，安全性是其中之一（以及浏览器的文件访问方法不涵盖相同的 space 该节点的做。）对于 child_process、module、net、dgram 等模块也是如此——在这些模块中不容易（或有时可能！）转换到浏览器环境中。

如果您需要在浏览器中访问磁盘中的文件，有一个 browserify 转换，brfs，它将在编译时将文件中的数据作为静态字符串包含到包中。

Node 的 Browserify 是否规避了 Javascript 的沙箱？

Does Node's Browserify circumvent Javascript's sandbox?

javascript

security

sandbox

node.js

browserify