电子文档中标题为Using Preload Scripts的页面上写着：
IPC安全性
请注意我们是如何将ipcRenderer.invoke('ping')调用 Package 在一个helper函数中，而不是直接通过上下文桥公开ipcRenderer模块的。您永远不想通过预加载直接公开整个ipcRenderer模块。这将给予您的渲染器能够向主进程发送任意IPC消息，这将成为恶意代码的强大攻击媒介。
这里描述的威胁是什么？
因为当我编写一个电子应用程序时，我同时编写主进程和渲染器--为什么渲染器的特权必须低于主进程？
在渲染器中而不是在进程中运行的外来（潜在恶意）代码（如果有）是什么？
3条答案
按热度按时间f2uvfpb91#
渲染器进程的权限较低，无法减少RCE、XSS或其他可能对运行电子应用程序的底层系统造成损害的攻击。这最适用于您分发给其他人的应用程序，在这些应用程序中，您无法信任用户与您的应用程序的交互方式。除了与您的应用程序交互的恶意行为者之外，我不能说风险是0（仅仅是因为可能会发生一些事情），但它可能非常小。
除了关注使用IPC和渲染器/主进程的安全优势外，在我看来，这是一个很好的关注点分离，如果你决定在未来这样做，它可以设置你的应用程序在一个地方分发它。
我写了关于history of Electron的文章，以及IPC是如何工作的，以及框架是如何改变成 * 现在 * 强调/促进IPC的（如果你想读的话）。
mfuanj7w2#
reZach's answer链接到文章：
其中包括这一段：
你看，在渲染器进程中添加Node会使我们的应用程序面临RCE（远程代码执行）攻击。通过独特的方式，一个有动机的人可以打开你的电子应用程序上的开发工具（记住，窗口只是一个Chromium浏览器），找到对fs的引用，然后嘣-你所有的文件都消失了。
链接的文章是 * 基于Joplin ElectronJS的客户端：雅罗斯拉夫·洛巴切夫斯基的《从XSS到RCE*》开始：
有一天，我在阅读西尔维娅·维利的硕士论文，她基本上应用了卢卡·卡瑞托尼的auditing checklist。我在GitHub项目中搜索了一些有趣的关键字，然后手动检查和测试漏洞。她论文的假设是，由于电子框架有许多不安全的默认值，所以一定有大量易受攻击的应用程序。这似乎是真的，她得到了一堆不错的CVE。
就我个人而言，我发现基于电子的应用程序中的漏洞很有趣，因为缺乏进程隔离，这很容易导致“简单”的XSS在运行的机器上执行代码。
该审核检查表是 * 电子安全检查表开发人员和审核人员指南 *，2017年发布于
blackhat.com。其前两个检查清单项目包括：
总之，“不可信的起源”似乎证实了雷扎克的评论：
当渲染器从第三方网站加载脚本或由外部用户使用时，该威胁最（可能仅）适用，这是可能发生RCE、XSS或其他攻击的地方。
huwehgph3#
您可能在渲染器中存在XSS漏洞，例如，如果您不转义用户输入或来自外部源的数据。
例如，如果由于某种原因，您有一个从HTML
input文本开始的eval调用，而该调用没有以任何方式进行检查，那么您共享的段落中所解释的内容将避免向主进程发送可能危及应用程序安全的意外IPC消息。