sandbox 沙盒选项

    Chromium主要的安全特征之一便是所有的blink渲染或者JavaScript代码都在sandbox内运行。 该sandbox使用OS特定特征来保障运行在渲染器内的进程不会损害系统。

    也就是说，在sandbox模式下，渲染器只能通过IPC委派任务给主进程来对操作系统进行更改。 下述是有关sandbox更多的信息。

    Electron的一个主要特性就是能在渲染进程中运行Node.js（使用web技术能让我们更加便捷的构建一个桌面应用），但是在渲染进程中沙箱是不可用的。 这是因为大多数Node.js 的API都需要系统权限。 比如 ，没有文件系统权限的情况下require()是不可用的，而该文件系统权限在沙箱环境下是不可用的。

    通常，对于桌面应用来说这些都不是问题，因为应用的代码都是可信的；但是显示一些不是那么受信任的网站会使得Electron相比Chromium而言安全性下降。 因为应用程序需要更多的安全性，sandbox 标记将使electron产生一个与沙箱兼容的经典chromium渲染器。

    一个沙箱环境下的渲染器没有node.js运行环境，并且不会将Node.js 的 JavaScript APIs 暴露给客户端代码。 唯一的例外是预加载脚本, 它可以访问electron渲染器 API 的一个子集(subset)。

    另一个区别是沙箱渲染器不修改任何默认的 JavaScript API。 因此, 某些 api ，（比如 window.open）将像在chromium中一样工作 (即它们不返回 BrowserWindowProxy `)。

    创建沙盒窗口, 只需将 sandbox: true 传递到 webPreferences `:

    以上代码中被创建的禁用了node.js，并且只能使用IPC通信。 这个选项的设置阻止electron在渲染器中创建一个node.js运行环境。 Also, within this new window window.open follows the native behavior (by default Electron creates a BrowserWindow and returns a proxy to this via window.open).

    An app can make customizations to sandboxed renderers using a preload script. 例如：

    和 preload.js:

    在预加载脚本中要注意的重要事项:

    • Even though the sandboxed renderer doesn’t have Node.js running, it still has access to a limited node-like environment: Buffer, process, setImmediate, clearImmediate and require are available.

    • 预加载脚本可以通过 remote 和 ipcRenderer 模块间接访问主进程中的所有 api。

    • The preload script must be contained in a single script, but it is possible to have complex preload code composed with multiple modules by using a tool like webpack or browserify. An example of using browserify is below.

    要创建 browserify 包并将其用作预加载脚本, 应使用类似下面的内容:

    -x 标志应该和已经在预加载作用域中公开的所有引用到的模块一起使用, 并通知 browserify 使用封闭的 require 函数。 --insert-global-vars 将确保 process、Buffer 和 setImmediate 也从封闭作用域 (通常 browserify 为这些代码注入代码) 中获取。

    当前预加载作用域中提供的 函数公开了以下模块:

    • electron
    • 事件
    • url

    Rendering untrusted content in Electron is still somewhat uncharted territory, though some apps are finding success (e.g. Beaker Browser). Our goal is to get as close to Chrome as we can in terms of the security of sandboxed content, but ultimately we will always be behind due to a few fundamental issues:

    1. We do not have the dedicated resources or expertise that Chromium has to apply to the security of its product. We do our best to make use of what we have, to inherit everything we can from Chromium, and to respond quickly to security issues, but Electron cannot be as secure as Chromium without the resources that Chromium is able to dedicate.

    2. Some security features in Chrome (such as Safe Browsing and Certificate Transparency) require a centralized authority and dedicated servers, both of which run counter to the goals of the Electron project. As such, we disable those features in Electron, at the cost of the associated security they would otherwise bring.

    3. There is only one Chromium, whereas there are many thousands of apps built on Electron, all of which behave slightly differently. Accounting for those differences can yield a huge possibility space, and make it challenging to ensure the security of the platform in unusual use cases.

    4. We can’t push security updates to users directly, so we rely on app vendors to upgrade the version of Electron underlying their app in order for security updates to reach users.

    Here are some things to consider before rendering untrusted content:

    • A preload script can accidentally leak privileged APIs to untrusted code, unless is also enabled.

    • While we make our best effort to backport Chromium security fixes to older versions of Electron, we do not make a guarantee that every fix will be backported. Your best chance at staying secure is to be on the latest stable version of Electron.