1. Electron安全概述：架构、攻击面与威胁模型

大家好，我是你们这趟安全之旅的向导。

开始动手之前，咱们得先搞清楚一件事：Electron 到底是个什么东西？它凭什么能搞出那么多安全漏洞？

说白了，Electron 就是一个披着浏览器外衣的桌面应用框架。它用 Chromium 渲染页面，用 Node.js 提供底层能力。这个组合很强大，但也带来了一个天然的矛盾——浏览器安全模型和桌面系统权限之间的冲突。

1.1 Electron 架构：两个进程的故事

Electron 应用由两类进程组成：主进程和渲染进程。

主进程（Main Process）：Node.js 环境，直接操作操作系统。它能读写文件、启动子进程、调用系统 API。说白了，它就是应用的“大脑”。
渲染进程（Renderer Process）：Chromium 环境，运行 HTML/CSS/JS。它负责界面展示，默认情况下没有系统权限。

这两个进程通过 IPC（进程间通信） 交换消息。嗯，这里要注意——IPC 通道往往是攻击者的突破口。

核心安全模型：

Electron 的安全模型基于“最小权限原则”。渲染进程应该被沙箱隔离，主进程应该严格校验来自渲染进程的消息。

但现实是……很多开发者为了方便，直接把 Node.js 能力暴露给了渲染进程。这就是灾难的开始。

1.2 常见攻击面分析

我在项目中遇到过不少 Electron 应用的安全问题。总结下来，攻击面主要集中在以下几个地方：

1.2.1 XSS 与远程代码执行（RCE）

这是最经典的攻击路径。渲染进程如果被注入了恶意脚本，攻击者就能通过 preload.js 暴露的接口，调用 Node.js 能力。

举个例子：

// 危险的 preload.js
const { ipcRenderer } = require('electron');
window.executeCommand = (cmd) => {
    ipcRenderer.send('run-command', cmd);
};

// 主进程
ipcMain.on('run-command', (event, cmd) => {
    require('child_process').exec(cmd); // 直接执行！危险！
});

我曾经见过一个内部工具，渲染进程里直接拼接用户输入到 eval() 里。结果呢？一个简单的 <img src=x onerror=...> 就让整个内网沦陷了。

避坑指南：

我曾经接手过一个项目，他们把 nodeIntegration: true 和 contextIsolation: false 同时打开了。这相当于把整个 Node.js 环境直接暴露给了网页。攻击者只需要一个 XSS 漏洞，就能拿到操作系统的控制权。

记住：永远不要同时开启这两个选项。

1.2.2 原型链污染

Electron 应用经常使用 JSON 解析用户数据。如果解析后的对象被合并到全局对象中，就可能发生原型链污染。

// 危险的合并操作
function merge(target, source) {
    for (let key in source) {
        if (source.hasOwnProperty(key)) {
            target[key] = source[key];
        }
    }
}

let userInput = JSON.parse('{"__proto__": {"isAdmin": true}}');
merge({}, userInput);
// 现在所有对象的 isAdmin 属性都变成了 true

你想想看，如果这个 isAdmin 被用来做权限校验……嗯，后果不用我多说了吧？

1.2.3 文件系统访问

Electron 应用可以读写本地文件。如果渲染进程能控制文件路径，攻击者就能读取 /etc/passwd 或者写入恶意文件。

常见的坑：

使用 dialog.showOpenDialog 后没有校验返回的路径
允许用户自定义下载路径，但没有做路径遍历检查
把用户输入直接拼接到文件路径中

1.2.4 协议处理与外部链接

Electron 可以注册自定义协议（如 myapp://）。如果处理不当，攻击者可以通过网页链接直接调用你的应用。

我记得有个案例：某款聊天软件注册了 chat:// 协议，参数直接拼接到命令行中。攻击者构造了一个恶意链接，用户点击后就直接执行了恶意命令。

1.3 安全威胁模型

搞清楚了攻击面，我们得建立一个威胁模型。我个人习惯用 STRIDE 模型 来分析 Electron 应用：

威胁类型	Electron 中的表现	典型攻击
S - 身份欺骗	伪造 IPC 调用方身份	渲染进程冒充主进程发送消息
T - 篡改	修改渲染进程中的代码或数据	XSS 注入、原型链污染
R - 抵赖	用户操作日志被篡改	本地存储数据被恶意修改
I - 信息泄露	敏感数据被读取	文件遍历、内存 dump
D - 拒绝服务	应用崩溃或资源耗尽	无限循环、内存泄漏
E - 权限提升	从渲染进程获得系统权限	RCE、沙箱逃逸

我的建议：

每次做安全审计时，我都会拿着这个表格逐项检查。特别是 E（权限提升） 和 I（信息泄露），这两项在 Electron 应用中出现的频率最高。

1.4 总结：安全是设计出来的

Electron 的安全问题，说白了就是架构设计的问题。很多漏洞不是因为 Electron 本身不安全，而是开发者没有遵循它的安全模型。

我见过太多项目，上线前才想起来做安全测试。结果发现架构上就有硬伤，改起来伤筋动骨。所以我的建议是：从项目第一天就把安全考虑进去。

接下来的章节，我会带大家逐个击破这些攻击面。咱们先从最基础的配置加固开始。