不安全的输出处理

不安全（或不当）的输出处理，是指在将大语言模型生成的输出传递给下游系统、呈现在用户界面中或由后端进程执行之前，未对其进行验证、清理或编码。

什么是不安全的输出处理？

应用集成LLM后，通常会接收生成的文本，并将其传递到其他位置，例如浏览器、数据库查询、系统命令或其他应用组件。如果未验证生成内容是否安全便直接使用，就会导致不安全的输出处理。

核心问题在于信任。开发人员往往认为，只要能控制提示词或模型，输出就会是可预测且无害的，但实际情况并非总是如此。LLM根据从训练数据中学习到的模式生成响应，同时也会受到用户输入的影响。精心构造的提示词可能会诱使模型生成包含可执行代码、恶意脚本、SQL片段或系统命令的输出，而应用程序随后会将这些输出当作可信数据进行处理。

此漏洞类似于传统注入漏洞，例如跨站脚本（XSS）。在这类漏洞中，未采取安全措施的用户输入会导致浏览器执行代码。不同之处在于，此处的“用户输入”是模型输出，攻击者可通过提示词注入间接操纵该输出，也可能只是模型的响应模式导致此类输出。

如果应用未像对待任何不受信任的外部输入一样谨慎处理LLM输出，不安全的输出处理就会成为安全问题。如果不进行验证和编码，该输出可能会在任何接收它的系统中造成漏洞。

为什么不安全的输出处理很危险？

标准安全实践以输入来源可预测为前提。表单包含明确定义的字段，API具有架构，用户输入通过已知渠道传入。LLM输出打破了这些假设，因为它是动态生成的，会受到可能包含对抗性内容的提示词影响，并且几乎可以生成任何文本字符串。

这种不可预测性使不安全的输出处理对LLM驱动的应用程序构成尤为严重的风险。模型可能已生成数千次有效且有用的响应，却因提示词意外偏离原有方向，生成包含脚本标签或Shell命令的响应。依赖有限模式匹配或允许列表的安全控制措施难以预判所有可能的输出。

由于LLM输出通常会流向多个下游系统，攻击面也随之扩大。单个响应可能会在浏览器中呈现、记录到数据库，并传递给API。每个目标系统都有自身的漏洞，任何环节的不安全输出处理都可能为漏洞利用提供入口。

此外，随着模型更新或微调，LLM的行为可能会随时间发生变化。在某个模型版本下安全的输出，换用另一版本后可能会被利用。未将输出视为本质上不可信的应用会面临潜在风险，而这种风险可能只有在条件发生变化时才会显现。

不安全的输出处理是如何发生的？

不安全的输出处理会利用LLM生成的内容与下游系统对其解读方式之间的差异。攻击者通过操纵提示词，使模型生成特定输出；接收系统若未经清理便处理这些输出，可能会触发非预期行为。

• 将不可信输出用作主动输入：LLM输出是文本字符串，但这些字符串可能包含可执行内容，例如JavaScript、HTML、SQL、shell命令或嵌入脚本的Markdown。如果应用程序未经清理便将此输出直接传递给解释器、shell或渲染引擎，其中的内容就会执行。例如，旨在诱导模型生成包含<script>标签的响应的提示，如果其输出未经编码便插入网页，就会成为XSS载荷。
• 在客户端浏览器或UI中呈现的输出： 当LLM生成的内容显示在浏览器或应用程序界面中时，其中嵌入的任何HTML或JavaScript都可能在用户上下文中执行。这可能为跨站脚本攻击、会话劫持、凭据窃取或UI操纵提供可乘之机。聊天机器人、内容生成器和AI助手如果直接呈现模型输出而不进行输出编码，尤其容易受到攻击。
• 后端执行和权限提升：当LLM输出进入具备执行能力的后端系统时，可能造成极其严重的后果。如果未经清理的输出被传递给shell、eval()函数或数据库查询，攻击者便可能实现远程代码执行、数据外泄或权限提升。如果模型受诱导生成有效的SQL注入字符串或系统命令，而应用程序又执行了该输出，整个后端都可能遭到入侵。

常见示例和真实攻击场景

在集成LLM的应用中，不安全的输出处理会呈现出几种易于识别的模式。

如果客户服务聊天机器人未经转义便将LLM响应呈现为HTML，则可能成为XSS攻击载体。攻击者会提交特制提示词，诱使模型在响应中加入脚本标签。当该响应在其他用户的浏览器中呈现时，脚本便会执行，可能窃取会话令牌或将用户重定向至网络钓鱼网站。

使用LLM输出构造数据库查询的应用也面临SQL注入风险。如果模型收到生成产品搜索查询的提示，而攻击者精心构造输入，使模型在响应中追加 ; DROP TABLE users;--，那么应用若未经参数化便将该输出拼接到SQL语句中，就会执行这条恶意命令。

此外，采用LLM生成的代码或配置的CI/CD流水线也容易受到命令注入攻击。攻击者可能会操纵负责生成部署脚本的模型，使其在脚本中加入反向Shell命令。如果流水线未经审查便执行该脚本，攻击者就能访问构建基础设施。

不安全的输出处理还可能导致服务器端请求伪造。根据用户输入生成URL或API调用的LLM可能会受到诱骗，生成访问内部网络资源的请求。如果应用程序未经验证便发出这些请求，攻击者就可能探测内部系统或窃取数据。

智能体AI和RAG架构中的风险

随着现代企业对AI的应用不断扩大和深入，不安全输出处理的风险也在不断演变。模型如今会向连接的应用、工具、API、数据库和智能体提供输入和指令。这种连接为恶意行为者提供了可乘之机。他们可以利用间接提示注入技术，诱骗自主AI智能体执行未经批准的API或工具调用、向数据库恶意写入数据，或从检索增强生成（RAG）管道中提取数据。

随着自主能力不断增强，以及代理访问业务关键系统的情况日益普遍，输出在传递至下游系统或工具之前需要经过验证和清理。任何超出既定权限的输出都需要受到限制。

如何防止不安全的输出处理

要防止不安全的输出处理，必须像对待不受信任的用户输入一样，严格处理LLM输出。以下做法有助于降低常见攻击途径带来的风险：

• 将LLM输出视为不可信输入：对所有模型生成的内容采取零信任策略。无论提示词如何构建或应用了哪些约束，都应假定输出可能包含恶意内容或格式错误的内容。在用于任何下游环节之前，必须进行验证和清理。
• 输出验证和清理：在呈现或执行LLM输出之前，根据具体上下文进行适当编码。对浏览器中显示的输出进行HTML编码。对数据库查询使用参数化方式，不要将模型输出拼接到SQL字符串中。如果必须将输出传递给系统命令，请转义Shell元字符。尽可能使用允许列表，将输出限制为预期模式。
• 严格的访问控制和最小权限方法：限制处理LLM输出的组件权限。如果服务执行模型生成的命令，应限制其可运行的命令以及可访问的资源。将LLM相关处理与敏感系统隔离。遵循最小权限原则，即使攻击者成功利用漏洞，也能限制其影响。
• 人工审核和输出过滤：对于代码生成、金融交易或管理操作等高风险用例，必须在执行前进行人工审核。实施自动过滤，对符合已知危险模式的输出进行标记或阻止。使用内容分类器，在可能具有恶意的输出到达下游系统之前将其检测出来。
• 日志记录、监控和审计： 详细记录LLM输出及其在整个应用程序中的使用方式。监控异常情况，例如意外的命令序列、异常输出模式或可能表明存在利用企图的下游错误。定期审计日志，识别输出处理控制措施中的缺口。

LLM风险框架与行业指南

在新兴的LLM安全框架中，不安全的输出处理被视为一项重大漏洞。OWASP LLM十大风险将其列为关键问题，并强调了将未经验证的模型输出传递给后端函数、浏览器或其他能够执行这些输出的系统所带来的风险。

该框架建议将LLM输出视为本质上不可信，对模型生成的内容应用输入验证技术，并实施纵深防御策略，避免仅依赖提示工程或模型约束来防止恶意输出。

生成式AI安全方面的行业组织和供应商指南进一步印证了这些建议。常见原则包括默认对输出进行编码、严格隔离LLM生成的内容与执行上下文，以及持续监控输出异常。

将LLM集成到生产系统中的组织应根据这些框架调整安全控制措施，并将不安全的输出处理纳入威胁模型。随着LLM应用规模扩大，攻击面也会随之增加，主动缓解措施将成为基本要求，而不再是进阶实践。

迹象和常见错误

有几种模式表明，应用程序可能容易受到不安全输出处理所带来的影响。

默认信任LLM输出是最常见的错误。开发人员认为，提示词由自己编写，因此输出是安全的。这种想法忽视了用户提供的输入对模型行为的影响，以及生成式模型固有的不可预测性。

因为输出“看起来像文本”而跳过清理，会在其中包含嵌入式代码或命令时引入漏洞。即使响应看似普通文本，也可能包含在下游系统解析时被激活的有效载荷。

未经验证便自动执行LLM输出是一种严重的反模式。应用程序如果不经检查就将模型输出直接传递给eval()、exec()或Shell解释器，会直接导致代码执行。

未经编码便将输出直接嵌入UI或数据库查询，会使应用面临XSS和注入攻击。为图方便，未经转义就将模型响应插入模板，会带来本可避免的风险。

潜在利用的迹象包括：下游系统出现意外错误；日志中出现异常条目，显示不寻常的命令或查询；用户报告由LLM驱动的界面存在异常行为。监控这些指标有助于及早发现不安全的输出处理问题。

F5如何处理不安全的输出处理？

F5通过在流量层和应用层实施控制，解决LLM输出与下游系统及用户交互时的不安全输出处理问题。

F5 AI Guardrails是F5 AI Security Platform不可或缺的组成部分，可在AI应用、智能体与用户之间的交互中实施策略，包括在模型响应到达后端系统或客户端应用之前对其进行检查的输出验证。这有助于组织检测并阻止包含潜在恶意内容的输出，例如提示词注入、命令序列或异常数据模式。

对于呈现LLM生成内容的Web应用，F5 Web应用防火墙功能会运用行为分析和基于特征码的检测，识别可能触发XSS、注入或其他客户端漏洞的输出。保护范围还涵盖使用LLM输出的API，可监控异常有效载荷并强制执行架构验证。

F5 Distributed Cloud Services可在混合云和多云部署中集成防护措施，无论LLM工作负载在何处运行，都能保持一致的输出处理控制。日志记录和可见性功能可支持审计要求，并帮助安全团队监控LLM输出如何流经应用基础设施。

通过在LLM输出进入应用并传递给用户的环节部署控制措施，F5可帮助组织默认实施输出净化，而不是仅依赖应用层实施。

常见问题

OWASP如何对不安全的输出处理进行分类？它为何有别于其他LLM风险？

OWASP将不安全输出处理定义为：对大语言模型（LLM）生成的输出缺乏充分的验证、清理和处理。它与其他风险的区别在于，特指在缺乏适当监督、控制和治理的情况下，将输出传递给下游用户时产生的问题。

在AI应用中防范XSS时，输出编码与输入验证有何区别？

在AI应用中，输入验证与输出编码在防止XSS方面的区别在于：输入验证会评估输入应用系统的数据，而输出编码则会在生成的内容返回给用户时对其进行保护。输入验证会检查进入应用的数据，拒绝不符合既定规则或预期格式的输入。输出编码会将可能存在危险的输入转换为可作为数据安全查看的形式，而不是可执行代码。

不安全的输出处理如何使间接提示词注入导致远程代码执行（RCE）？

间接提示词注入可通过在提供给模型的内容中加入恶意指令来实现远程代码执行（RCE）。这些指令可诱导模型生成命令或可执行文件，然后将输出传递给其他工具或系统，而这些工具或系统会将其视为合法内容。

将LLM连接到数据库或内部API时，如何防止SQL注入和服务器端请求伪造（SSRF）？

为防止连接数据库或内部API时发生SQL注入和SSRF，应将LLM输出（包括命令、参数、URL和工具参数）视为不可信数据，而非可执行指令。验证解决方案、API允许列表、参数化查询和最小权限访问有助于降低相关风险。

LangChain Guardrails、NVIDIA NeMo Guardrails与Web应用防火墙（WAF）有何区别？

LangChain Guardrails、NVIDIA NeMo Guardrails和WAF是互为补充的解决方案，主要区别在于它们分别保护企业AI系统的不同方面。LangChain Guardrails用于任务和智能体验证，并作为中间件集成在LLM应用程序代码中。NVIDIA NeMo Guardrails部署在LLM编排层之前，用于实现多轮对话控制和主题对齐。WAF部署在网络边缘，用于防范SQL注入、XSS和DDoS攻击等威胁。