Electron 作为 Web 浏览器的安全隐患答案

【问题标题】：Security Implications in Electron as a Web BrowserElectron 作为 Web 浏览器的安全隐患
【发布时间】：2020-04-14 21:56:36
【问题描述】：

一个多星期前，我在 Atom 论坛（下面的链接）上问了这个问题，但没有收到回复，所以我在这里重新发布它，希望有人能够就我的问题提供见解.

最近，我参与了一个使用 Electron 作为前端的开源项目。这个项目有两个要求：它必须是跨平台的，并且它必须有一个嵌入式 Web 浏览器（它应该能够像典型的浏览器一样浏览 Web 和呈现内容）。考虑到 Electron 已经占用了我的应用程序相当大的空间，尝试在它旁边使用另一个嵌入式 Web 框架似乎是个坏主意。因此，为了简化我的项目并保留基于 Electron 构建的 UI，我正在考虑使用 Electron 本身作为 Web 浏览器。这就是我遇到问题的地方。

在 Electron 文档的安全页面中，明确指出，

理解很重要……Electron 不是网络浏览器

这句话来自于 Electron——或者更确切地说是在其上运行的代码——具有与用户操作系统交互的独特能力，这与典型的 Web 应用程序不同。页面接着说，

显示来自不受信任来源的任意内容会带来严重的安全风险，Electron 不打算处理

此时，我很想放弃使用 Electron 作为内置浏览器的想法，但在同一页面的更下方，您会发现另一个非常有趣的花絮：

要显示远程内容，请使用<webview> 标记或BrowserView，[并且] 确保禁用nodeIntegration 并启用contextIsolation

链接：https://electronjs.org/docs/tutorial/security#isolation-for-untrusted-content

首先，关于使用 webviews，Electron 自己的文档建议完全避免使用它们：

Electron 的 webview 标签基于 Chromium 的 webview ，它正在经历巨大的架构变化。这会影响webviews 的稳定性，包括渲染、导航和事件路由。我们目前建议不要使用 webview 标签并考虑替代品，例如 iframe、Electron 的 BrowserView 或完全避免嵌入内容的架构。

链接：https://electronjs.org/docs/api/webview-tag

似乎我无法避免嵌入内容，我选择考虑使用 BrowserView，但我发现也不是很有动力。就目前而言，建议是做两件事：

禁用nodeIntegration
启用contextIsolation

查看安全和最佳实践页面后，我还将附加以下步骤：

拒绝来自远程内容（网络摄像头、麦克风、位置等）的会话权限请求
在创建过程中捕获 webview 元素并去除默认权限
禁用新窗口的创建
禁用远程模块

在保护外部内容方面需要执行相当多的步骤。更不用说，最佳实践页面中还散布着一些额外的警告，如下所示：

（关于在创建前验证 webview 选项）

同样，此列表只是将风险降至最低，并没有将其删除。如果您的目标是显示网站，浏览器将是更安全的选择。

链接：https://electronjs.org/docs/tutorial/security#11-verify-webview-options-before-creation

（关于禁用remote 模块）

但是，如果您的应用可以运行不受信任的内容，并且即使您相应地对渲染器进程进行沙箱处理，远程模块也可以让恶意代码轻松逃离沙箱并通过主进程的更高权限访问系统资源。

链接：https://electronjs.org/docs/tutorial/security#15-disable-the-remote-module

更不用说，在导航到BrowserView 页面时，整个班级都被列为实验班。

这一切都更不用说由 Electron 创建的附加攻击面，例如去年 webview 组件中的漏洞：CVE-2018-1000136

现在，考虑到以上所有因素，许多开发人员仍然选择创建 Web 浏览器，这些浏览器通常会使用 Electron 使用外部和不受控制的内容。

使用 Electron 的浏览器（直接从 Electron 网站链接）：

对我来说，为了方便而让用户接受上述安全隐患似乎是不负责任的。

话虽如此，我的问题是：您能否安全地使用 Electron 为不受控制的内容实施 Web 浏览功能，以确保用户的完整性？

感谢您的宝贵时间。

原帖链接： https://discuss.atom.io/t/security-implications-in-electron-as-a-web-browser/70653

【问题讨论】：

标签： node.js security browser webview electron

【解决方案1】：

一些不适合评论框的想法：

[项目]必须有嵌入式网络浏览器

所以我认为这个项目不仅仅是一个网络浏览器。那里还有其他内容可以访问 Node，但您只希望它的嵌入式网络浏览器部分被适当地沙盒化，对吧？

关于 <webview> 的 cmets，是的，它被认为是不稳定的，Electron 建议改用 BrowserView。我不认为它被标记为“实验性”的事实一定会阻止你使用它（特别是考虑到 Electron 团队正在推荐它[尽管可能是两害相权的最佳选择]）。

实验并不意味着它不稳定。这可能只是意味着 Electron 团队正在试验这种方法，但这种方法将来可能会改变（在这一点上，我希望 Electron 提供一个前进的过渡路径）。虽然这是一种可能的解释，但最终 Electron 必须对此发表评论。

建议...是做两件事：

禁用节点集成

启用上下文隔离

我还会使用从BrowserWindows 继承的sandbox option。 BrowserView's docs 在构造函数选项上说：

webPreferences 对象（可选） - 请参阅 BrowserWindow。

这告诉我BrowserView 接受与BrowserWindow 相同的选项。

你可以这样设置：

new BrowserView({ webPreferences: {
    sandbox: true,
    nodeIntegration: false,
    contextIsolation: true,
    preload: "./pathToPreloadScript.js"
}});

查看有关此方法的更多信息here。预加载脚本会将一些 Node IPC API 暴露给您正在加载的沙盒内容。注意底部的Status section，上面写着：

请谨慎使用sandbox 选项，因为它仍是一项实验性功能。我们仍然没有意识到将一些 Electron 渲染器 API 暴露给预加载脚本的安全隐患

如果您在BrowserView 中加载的内容永远不需要与应用程序进行通信，那么您根本不需要预加载脚本，只需将BrowserView 沙箱化即可。

查看安全和最佳实践页面后，我还将附加以下步骤：

拒绝来自远程内容（网络摄像头、麦克风、位置等）的会话权限请求

在创建过程中捕获 webview 元素并去除默认权限

禁用新窗口的创建

禁用远程模块

当然，这些听起来很合理。请注意，如果您的嵌入式浏览器需要能够打开新窗口（通过window.open 或<a target="_blank" />），那么您必须允许弹出窗口。

这是确保外部内容安全的相当多的步骤。

当然可以，但您主要关心的是应用的安全性，还是需要做多少工作才能确保其安全？浏览器开发人员需要考虑类似的事情，以确保网页无法访问操作系统。这只是游戏的一部分。

同样，此列表只是将风险降至最低，并没有将其删除。如果您的目标是显示网站，浏览器将是更安全的选择。

这只是说如果所有你想要做的是显示一个网站，那么只需使用浏览器，因为这就是他们的目的。

如果你需要做其他事情，那么你不能使用浏览器，所以你必须制作自己的应用程序，确保它合理安全。

我认为，如果您遵循安全文档中的建议并及时了解新的 Electron 版本，那么您已经尽了最大努力。

至于这是否足够好，我不能说。这取决于您正在开发什么以及您要防止什么。

但是，我的想法无法替代 Electron 团队中那些更专业的意见。这个问题当然可以使用他们的一些指导。

【讨论】：