物界前沿AI输出成了新的XSS，这次漏洞出在信任上
二十多年前，XSS刚被提出来的时候，好多人的第一反应和你我今天差不多：不就是往页面里塞段脚本吗，能有什么大事。后来事情大家都知道了，凡是把用户输入当回事的网站，几乎全被这玩意儿教过做人。现在回头看，当年的教训其实一句话就能说透：浏览器分不清哪段代码是程序自己写的，哪段是用户塞进来的。
这两天我在准备一个安全相关的组会材料，越查越觉得，大模型时代的输出处理问题，几乎就是XSS的复刻。OWASP把这个问题编成LLM05，叫Improper Output Handling，核心的意思很直白：AI生产的东西不该被当成可信输入直接用。
先解释一下为什么这事绕回去了。传统漏洞的前提是输入不可信，输出是程序自己生成的，默认安全。但LLM的生成过程本质上是把可控的提示词和不可控的训练数据混在一起，你根本没法保证模型吐出来的东西里不夹带私货。最典型的攻击路径就是提示注入，攻击者把恶意指令藏在对话上下文里，模型被诱导着把脚本写进输出，然后你的应用毫无防备地把这段输出渲染到浏览器上。
这和XSS在原理上几乎一模一样，区别只在于以前是用户输入直达浏览器，现在是用户输入先过一遍大模型，再被当成正常内容送到浏览器。
CVE-2026-27740这个编号值得念叨一下。Discourse这个论坛软件，大家不陌生吧。它引入AI助手之后，AI生成的内容直接进了页面渲染，结果就是存储型XSS。CVE描述的漏洞路径是这样的：攻击者构造一个特殊帖子，AI去总结或者回帖时，把帖子里藏着的恶意HTML当成事实搬进了自己的输出里，然后这个输出被原样渲染，脚本在别人的浏览器里执行了。
这事情最有意思的地方在于，攻击者甚至不用懂太多AI的东西，他只需要知道模型会把不可信的内容消化成可信的文本。这和当年XSS攻击者利用HTML注入做坏事，思路如出一辙。我这边跟学生讨论的时候，有个不太恰当但很直观的类比：你把LLM当成一个渗透测试员，但它不是你的防御方，它就是那个把恶意载荷送进你系统的传话人。
再说一个更危险的变体，来自Gemini的XSS漏洞。Google的AI助手现在有代码画布和实时预览功能，模型生成的代码不光是文本，它可以直接跑。攻击者构造一个包含恶意代码的请求，模型在生成示例代码时把这个代码当成正常内容输出，前端拿到之后直接在浏览器里执行了。传统XSS是你把用户输入写到页面里，现在是AI把用户输入写进代码里，然后你的程序帮它执行。信任边界没有变，变的是你信任的对象。
静态安全工具在这类攻击面前基本是失灵的。原因也不复杂，传统的XSS扫描器能找到固定的pattern，比如标签、onerror属性这些东西。但LLM生成的攻击载荷是根据上下文动态组合出来的，今天跑和明天跑的payload可能完全不同，规则匹配根本追不上。OX Security那边有个报告专门讲这个事，说AI攻击已经跑在静态工具前面了，我看了之后觉得，这个判断基本成立。
那么问题来了，怎么做防御。我看了几份材料之后，觉得下面这几条是眼下绕不开的：
- 把LLM输出当用户输入对待，落地之前必须过一遍消毒和编码，不能直接渲染
- 高权限操作不能基于AI生成的代码自动执行，涉及文件系统、命令行的动作必须人确认
- 沙箱隔离跑AI生成的内容，代码预览就在浏览器里面隔离掉，别让它接触到主文档的上下文
- 提示词和输出之间的边界要做审计，不是说你写了系统提示就不会被覆盖，要追踪输出里的内容到底来自哪里
给个具体的操作建议。如果你是做前端集成的，别偷懒，把react-dangerouslySetInnerHTML或者v-html这类直出接口在代码规范里禁掉。这不是因噎废食，是在信任边界没理清楚之前给自己的应用上保险。我在我们实验室的组会上也是这么跟学生说的：你调大模型接口的时候，返回的字符串和用户在文本框里输入的内容没有本质区别，都是不可信数据，谁把它们当可信数据渲染，谁就是在重写当年XSS的剧本。
XSS的教训花了十年才被行业真正记住，规则是好的，但AI的引入把这条规则从客户端挪到了服务端，从人输入挪到了机器生成。如果你现在负责的团队里有人问为什么AI输出还要做安全校验，把OWASP那个文档发给他，然后问他一句：你愿意让模型替你做决定吗。
本文编译自 Hacker News，原文：SymfonyCon Warsaw 2026: Why AI Output Is the New XSS (Symfony Blog)
版权归原作者所有，本文为基于公开报道的编译与独立分析。
