别再只盯着 Prompt 注入了，LLM 正在成为 Web 漏洞的高效中转站

讨论大模型安全时，很多人习惯把注意力集中在 Prompt Injection（提示词注入）本身。在不少人看来，注入攻击最多就是让 AI 失去约束，说几句不当的话，或者借助某些技巧让模型跳出预设的角色设定。但如果把视线从“对话框”转向“后端架构”，就会发现一个极其反常的现象：LLM 正在扮演“被搞糊涂的代理人”（Confused Deputy）。它本身并不制造漏洞，却会成为触发经典 Web 漏洞的高效传声筒。

这条攻击链路最反直觉的地方，在于 LLM 实际扮演了“格式转换器”的角色。在传统 Web 攻击中，许多恶意输入在后端之前就可能被 WAF（Web 应用防火墙）或严格的输入校验拦截。但当 LLM 加入链路后，攻击者可以通过自然语言诱导模型生成特定指令，这些指令经过模型“加工”后，往往会以被后端高度信任的格式发送给服务器。后端程序因为信任 LLM 生成的内容而放松过滤，最终让原本已经被挡下的攻击载荷直接穿透防御。

LLM 介导的攻击路径覆盖范围很广，最典型的就是 LLM2SQLi（SQL 注入）和 LLM2CommandInjection（命令注入）。设想这样一个场景：开发者构建了一个用自然语言查询数据库的助手，后端逻辑是由 LLM 将用户的自然语言转译为 SQL 语句并直接执行。如果后端没有采用参数化查询，攻击者只需通过精心设计的 Prompt，诱导模型在生成的 SQL 中加入 UNION SELECT 或 ' OR '1'='1，就可能在毫无察觉的情况下完成脱库。

数据库层面的突破之外，这种中转效应还会延伸到前端和网络层。比如 LLM2XSS，模型输出如果未经转义就被直接渲染到页面上，攻击者可以诱导模型输出 <script> 标签，从而实现跨站脚本攻击；在 LLM2SSRF 中，攻击者可以诱导模型触发后端 HTTP 请求，探测企业内网的敏感资产。处理 XML 解析时也一样，如果 LLM 生成的内容被直接交给解析器，LLM2XXE 同样可能成为现实。

一个值得关注实测案例是 TicketOracle。这是一个基于 Flask 框架构建的测试环境，专门用于验证 LLM2SSRF 在不同模型上的实际表现。实验结果显示了一个令人不安的细节：在完全相同的应用架构下，不同大模型被“利用”并触发漏洞的概率存在明显差异。这说明安全风险不仅取决于代码怎么写，也取决于接入的是哪个版本的模型。一个在 GPT-4 上表现稳健的接口，换成某个开源模型后，可能因为模型在指令遵循度（Instruction Following）上的差异，导致原本失效的攻击向量重新生效。

这带来的启示是，单纯在 System Prompt 中写下“你是一个安全的助手，请过滤所有恶意代码”毫无意义，因为这种软约束在复杂的注入攻击面前极其脆弱。真正的防御必须覆盖多个维度：网络层要实施严格隔离，应用层要坚持“零信任”原则，LLM 生成的所有输出在传给后端 API 之前，都必须进行二次校验和参数化处理。只有把 LLM 当作不可信的第三方输入源，才能在享受 AI 带来的效率提升时，避免它成为攻击者进入内网的敲门砖。