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 `:

    `` ``` let win app.whenReady().then(() => { win = new BrowserWindow({ webPreferences: { sandbox: true } }) win.loadURL(‘http://google.com‘) })

    let win app.whenReady().then(() => { win = new BrowserWindow({ webPreferences: { sandbox: true, preload: path.join(app.getAppPath(), ‘preload.js’) } }) win.loadURL(‘‘) })

    // 一旦javascript上下文创建,这个文件就会被自动加载 它在一个 //私有环境内运行, 可以访问 electron 渲染器的 api的子集 。 Without // contextIsolation enabled, it’s possible to accidentally leak privileged // globals like ipcRenderer to web content. const { ipcRenderer } = require(‘electron’)

    const defaultWindowOpen = window.open

    window.open = function customWindowOpen (url, …args) { ipcRenderer.send(‘report-window-open’, location.origin, url, args) return defaultWindowOpen(url + ‘?from_electron=1’, …args) }

    browserify preload/index.js \ -x electron \ —insert-global-vars=filename,dirname -o preload.js ```

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

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

    • electron
      • crashReporter
      • desktopCapturer
      • nativeImage
      • webFrame
    • 事件
    • timers
    • url

    More may be added as needed to expose more Electron APIs in the sandbox.

    1. 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.

    2. 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.

    3. 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 contextIsolation is also enabled.

    • Some bug in the V8 engine may allow malicious code to access the renderer preload APIs, effectively granting full access to the system through the remote module. Therefore, it is highly recommended to . If disabling is not feasible, you should selectively filter the module.