cal*_*are 5 browser security webview node.js electron
一个多星期前，我在 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、ElectronBrowserView或完全避免嵌入内容的架构。
链接：https : //electronjs.org/docs/api/webview-tag
似乎我无法避免嵌入内容，我选择研究使用 BrowserView，但我发现也不是很有动力。就目前而言，建议是做两件事：
nodeIntegrationcontextIsolation在查看安全和最佳实践页面后，我还将附加以下步骤：
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
现在，考虑到上述所有因素，许多开发人员仍然选择使用 Electron 创建 Web 浏览器，这些浏览器经常使用外部和不受控制的内容。
使用 Electron 的浏览器（直接从 Electron 的网站链接）：
在我看来，为了方便而让用户接受上述安全隐患似乎是不负责任的。
话虽如此，我的问题是：您能否安全地确保用户的完整性，使用 Electron 为不受控制的内容实现 Web 浏览功能？
感谢您的时间。
原帖链接：https : //discuss.atom.io/t/security-implications-in-electron-as-a-web-browser/70653
一些不适合评论框的想法：
[项目]必须有嵌入式网络浏览器
所以我认为这个项目不仅仅是一个网络浏览器。那里还有其他内容可能可以访问 Node，但您只想将其嵌入式 Web 浏览器部分适当地沙箱化，对吗？
关于 的评论<webview>，是的，它被认为是不稳定的，Electron 建议使用 aBrowserView代替。我不认为它被标记为“实验性”的事实一定会阻止您使用它（特别是考虑到 Electron 团队正在推荐它[尽管可能是两害相权取其一]）。
实验并不意味着它不稳定。这可能只是意味着 Electron 团队正在尝试这种方法，但这种方法将来可能会发生变化（届时我希望 Electron 能够提供一条前进的过渡路径）。尽管这是一种可能的解释，但最终 Electron 必须对此发表评论。
建议...是做两件事：
- 禁用节点集成
- 启用上下文隔离
我还会利用继承自 的sandbox选项BrowserWindows。关于构造函数选项的BrowserView's文档说：
webPreferences对象（可选）- 请参阅 BrowserWindow。
这告诉我BrowserView接受与 相同的选项BrowserWindow。
你可以这样设置：
new BrowserView({ webPreferences: {
sandbox: true,
nodeIntegration: false,
contextIsolation: true,
preload: "./pathToPreloadScript.js"
}});
请在此处查看有关此方法的更多信息。预加载脚本会将一些 Node IPC API 公开给您正在加载的沙盒内容。请注意底部的“状态”部分，其中显示：
请谨慎使用该
sandbox选项，因为它仍然是一个实验性功能。我们仍然不知道将一些 Electron 渲染器 API 暴露给预加载脚本的安全隐患
如果您正在加载的内容BrowserView永远不需要与应用程序通信，那么您根本不需要预加载脚本，只需将BrowserView.
查看安全性和最佳实践页面后，我还将附加以下步骤：
- 拒绝来自远程内容（网络摄像头、麦克风、位置等）的会话权限请求
- 在创建中捕获 webview 元素并剥离默认权限
- 禁止创建新窗口
- 禁用远程模块
当然，这些听起来很合理。请注意，如果您的嵌入式浏览器需要能够打开新窗口（通过window.open或<a target="_blank" />），那么您必须允许弹出窗口。
为了保护外部内容，需要采取相当多的步骤。
当然可以，但是您主要关心的是应用程序的安全性，还是需要做多少工作才能确保其安全？浏览器开发人员需要考虑类似的事情，以确保网页无法访问操作系统。这只是游戏的一部分。
再次强调，该列表只是将风险降到最低，并没有消除风险。如果您的目标是显示网站，那么浏览器将是更安全的选择。
这只是说，如果您想做的只是显示一个网站，那么只需使用浏览器，因为这就是它们的用途。
如果您需要做其他事情，那么您就无法使用浏览器，因此您必须制作自己的应用程序，确保它相当安全。
我认为，如果您遵循安全文档中的建议并及时了解新的 Electron 版本，那么您就已经尽力了。
至于这是否足够好，我不能说。这取决于您正在开发什么以及您想要防范什么。
然而，我的想法不能替代 Electron 团队中更专业的意见。这个问题当然可以使用他们的一些指导。
| 归档时间： |
|
| 查看次数： |
1197 次 |
| 最近记录： |