从 ChatGPT 漏洞看跨窗口消息审计
文章称，攻击者曾通过共享会话、MathLive 消息监听器与 HTML 预览组合实现 ChatGPT 账户接管，相关漏洞已修复。作者拆解攻击链，并介绍针对消息监听器的静态审计脚本。
原文暂未完整获取，基于公开信息的快读
一篇 dev.to 文章拆解了涉及 ChatGPT 的账户接管攻击链：按文中描述，受害者只需打开共享会话链接，攻击者就能串联 MathLive 消息监听器与 HTML Preview，在 chatgpt.com 来源下执行 JavaScript，读取私有会话和访问令牌。摘要称相关漏洞已修复，但现有材料不足以核实修复的具体范围。
目前能确认什么
节选给出的入口是跨窗口消息 API postMessage。共享会话中的交互式图表触发 MathLive 加载，HTML Preview 则从独立的沙箱来源发送消息。按作者分析，MathLive 监听器没有校验发送方，接收了攻击者控制的键盘布局 HTML，并通过 innerHTML 渲染。
后续链路利用未设置 sandbox 的 srcdoc iframe 继承父页面来源，再借助 CSP 允许的 YouTube 地址及其回调响应执行脚本，最终获取访问令牌。这些是文章的分析结论，并非本站独立复现。
作者还提供了静态扫描脚本，查找没有引用 event.origin 或 event.source 的消息处理器，并标记危险的 HTML 写入操作。它基于正则和文本片段匹配，作者也承认存在漏报。
我的判断
隔离预览页面之后，主站仍需把它发来的消息当作不可信输入。
对维护编辑器、在线预览或 iframe 嵌入功能的前端团队，具体审计点是：监听器是否把来源与预期窗口进行比较，消息类型和字段是否受约束，以及数据最终会不会进入 HTML 渲染入口。只在代码里出现 .origin，并不能证明校验有效。
这份脚本适合生成待检查清单。没有告警，也无法证明安全，尤其是消息处理与 DOM 写入分散在不同函数时。
修复究竟覆盖哪些组件、部署使用哪个版本，以及攻击链依赖哪些具体配置，仍需完整披露或官方说明确认。节选中的版本扫描结果，不能直接当作升级安全结论。