Tratamento inseguro de saída

O tratamento inseguro (ou inadequado) de saídas refere-se à falha em validar, sanitizar ou codificar as saídas geradas por um modelo de linguagem de grande porte antes de repassá-las a sistemas subsequentes, exibi-las em interfaces de usuário ou executá-las em processos de back-end.

O que é o tratamento inseguro de saídas?

Quando os aplicativos integram LLMs, eles normalmente recebem o texto gerado e o encaminham para outro lugar: um navegador, uma consulta ao banco de dados, um comando do sistema ou outro componente do aplicativo. O tratamento inseguro da saída ocorre quando esse conteúdo gerado é usado sem verificar se ele é seguro.

O principal problema é a confiança. Muitas vezes, os desenvolvedores presumem que, por controlarem o prompt ou o modelo, a saída será previsível e inofensiva, mas nem sempre é assim. Os LLMs geram respostas com base em padrões aprendidos a partir dos dados de treinamento e moldados pelas entradas dos usuários. Um prompt cuidadosamente elaborado pode fazer com que o modelo produza uma saída contendo código executável, scripts maliciosos, fragmentos de SQL ou comandos do sistema, que a aplicação então processa como se fossem dados confiáveis.

Essa vulnerabilidade é semelhante a falhas de injeção tradicionais, como cross-site scripting (XSS), em que uma entrada do usuário não protegida leva à execução de código em um navegador. A diferença é que, nesse caso, a "entrada do usuário" é a saída do modelo, que pode ser manipulada indiretamente por meio de injeção de prompt ou simplesmente surgir dos padrões de resposta do modelo.

O tratamento inseguro da saída se torna um problema de segurança quando a aplicação não trata a saída do LLM com o mesmo cuidado que teria com qualquer entrada externa não confiável. Sem validação e codificação, essa saída pode criar vulnerabilidades em qualquer sistema que a receba.

Por que o tratamento inseguro de saídas é perigoso?

As práticas de segurança padrão pressupõem fontes de entrada previsíveis. Os formulários têm campos definidos. As APIs têm esquemas. As entradas dos usuários chegam por canais conhecidos. A saída de um LLM rompe essas premissas porque é gerada dinamicamente, moldada por prompts que podem incluir conteúdo malicioso e capaz de produzir praticamente qualquer sequência de texto.

Essa imprevisibilidade torna o tratamento inseguro de saídas especialmente perigoso para aplicações baseadas em LLMs. Um modelo pode gerar respostas válidas e úteis milhares de vezes e, de repente, produzir uma resposta contendo uma tag de script ou um comando de shell porque o prompt tomou um rumo inesperado. Controles de segurança que dependem de correspondência com um conjunto finito de padrões ou de listas de permissões têm dificuldade para prever todas as saídas possíveis.

A superfície de ataque também aumenta porque as saídas dos LLMs geralmente são encaminhadas para vários sistemas subsequentes. Uma única resposta pode ser renderizada em um navegador, registrada em um banco de dados e enviada a uma API. Cada destino tem suas próprias vulnerabilidades, e o tratamento inseguro da saída em qualquer ponto pode criar uma brecha para exploração.

Além disso, o comportamento dos LLMs pode mudar ao longo do tempo à medida que os modelos são atualizados ou passam por ajustes finos. Uma saída que era segura em uma versão do modelo pode se tornar explorável em outra. Aplicações que não tratam as saídas como inerentemente não confiáveis carregam um risco latente que só se manifesta quando as condições mudam.

Como ocorre o tratamento inseguro de saídas?

O tratamento inseguro de saídas explora a lacuna entre o que um LLM gera e a forma como os sistemas subsequentes interpretam esse conteúdo. Os invasores manipulam prompts para fazer com que o modelo produza uma saída que, quando processada sem sanitização, desencadeia um comportamento não intencional no sistema receptor.

• Saída não confiável como entrada ativa: As saídas de LLMs são strings de texto, mas essas strings podem conter conteúdo executável: JavaScript, HTML, SQL, comandos de shell ou markdown com scripts incorporados. Se um aplicativo encaminhar essa saída diretamente para um interpretador, shell ou mecanismo de renderização sem sanitização, o conteúdo será executado. Por exemplo, um prompt criado para obter uma resposta contendo tags <script> se transforma em uma carga maliciosa de XSS se a saída for inserida em uma página da web sem codificação.
• Saída renderizada em navegadores ou interfaces de usuário: Quando o conteúdo gerado por LLMs é exibido em um navegador ou na interface de um aplicativo, qualquer HTML ou JavaScript incorporado pode ser executado no contexto do usuário. Isso cria oportunidades para ataques de cross-site scripting, sequestro de sessão, roubo de credenciais ou manipulação da interface. Chatbots, geradores de conteúdo e assistentes de IA que renderizam diretamente a saída do modelo ficam particularmente expostos caso não façam a codificação da saída.
• Execução no backend e escalonamento de privilégios: Os casos mais graves ocorrem quando a saída do LLM chega a sistemas de backend com capacidade de execução. Se a saída for enviada a um shell, a uma função eval() ou a uma consulta de banco de dados sem sanitização, os invasores podem executar código remotamente, exfiltrar dados ou escalar privilégios. Um modelo induzido a gerar uma string válida de injeção de SQL ou um comando de sistema pode comprometer todo o backend caso a aplicação execute essa saída.

Exemplos comuns e cenários de ataque do mundo real

O tratamento inseguro de saídas se manifesta em vários padrões reconhecíveis em aplicações integradas a LLMs.

Um chatbot de atendimento ao cliente que renderiza respostas de um LLM como HTML sem aplicar escape pode se tornar um vetor de XSS. Um invasor envia um prompt criado para fazer com que o modelo inclua uma tag de script na resposta. Quando a resposta é renderizada no navegador de outro usuário, o script é executado, podendo roubar tokens de sessão ou redirecionar o usuário para um site de phishing.

Aplicações que usam a saída de LLMs para construir consultas a bancos de dados também estão sujeitas a riscos de injeção de SQL. Se um modelo for instruído a gerar uma consulta de busca de produtos e um invasor elaborar uma entrada que faça o modelo acrescentar ; DROP TABLE users;-- à resposta, uma aplicação que concatene essa saída em uma instrução SQL sem parametrização executará o comando malicioso.

Além disso, pipelines de CI/CD que incorporam código ou configurações gerados por LLMs são vulneráveis à injeção de comandos. Um modelo solicitado a gerar um script de implantação pode ser manipulado para incluir um comando de shell reverso. Se o pipeline executar o script sem revisão, o invasor obterá acesso à infraestrutura de build.

A falsificação de solicitações do lado do servidor também pode resultar do tratamento inseguro da saída. Um LLM que gera URLs ou chamadas de API com base na entrada do usuário pode ser induzido a produzir solicitações para recursos da rede interna. Se a aplicação fizer essas solicitações sem validação, os invasores poderão sondar sistemas internos ou exfiltrar dados.

Riscos na IA agêntica e na arquitetura RAG

À medida que o uso da IA nas empresas modernas se expande e avança, os riscos relacionados ao tratamento inseguro de saídas também evoluem. Agora, os modelos fornecem entradas e instruções a aplicativos, ferramentas, APIs, bancos de dados e agentes conectados. Essa conectividade cria oportunidades para agentes mal-intencionados, que podem usar técnicas de injeção indireta de prompts para induzir agentes autônomos de IA a executar chamadas de API ou de ferramentas não autorizadas, realizar gravações maliciosas em bancos de dados ou extrair dados de pipelines de geração aumentada por recuperação (RAG).

O aumento dos recursos autônomos e a crescente prevalência do acesso de agentes a sistemas essenciais aos negócios significam que as saídas precisam ser validadas e higienizadas antes de chegarem aos sistemas ou às ferramentas subsequentes. Qualquer saída que exceda as permissões definidas precisa ser restringida.

Como evitar o tratamento inseguro de saídas

Para evitar o tratamento inseguro de saídas, é necessário tratar a saída do LLM com o mesmo rigor aplicado às entradas de usuários não confiáveis. As práticas a seguir podem ajudar a reduzir a exposição a vetores de ataque comuns:

• Trate a saída do LLM como uma entrada não confiável: Adote uma postura de confiança zero em relação a todo conteúdo gerado pelo modelo. Independentemente de como o prompt foi elaborado ou de quais restrições foram aplicadas, presuma que a saída possa conter conteúdo malicioso ou malformado. Valide e higienize o conteúdo antes de qualquer uso posterior.
• Validação e sanitização da saída: Aplique a codificação adequada ao contexto antes de renderizar ou executar a saída do LLM. Codifique em HTML a saída exibida nos navegadores. Parametrize as consultas ao banco de dados em vez de concatenar a saída do modelo em strings SQL. Use caracteres de escape para metacaracteres do shell caso a saída precise ser passada para comandos do sistema. Sempre que possível, use listas de permissões para restringir a saída aos padrões esperados.
• Controles de acesso rigorosos e abordagem de privilégio mínimo: Limite as permissões dos componentes que processam a saída do LLM. Se um serviço executar comandos gerados pelo modelo, restrinja quais comandos ele pode executar e quais recursos pode acessar. Isole dos sistemas sensíveis o processamento relacionado ao LLM. Aplique o princípio do privilégio mínimo para que até mesmo uma exploração bem-sucedida tenha impacto limitado.
• Revisão humana e filtragem de resultados: Para casos de uso de alto risco, como geração de código, transações financeiras ou ações administrativas, exija uma revisão humana antes da execução. Implemente uma filtragem automatizada para sinalizar ou bloquear resultados que correspondam a padrões perigosos conhecidos. Use classificadores de conteúdo para detectar resultados potencialmente maliciosos antes que cheguem aos sistemas subsequentes.
• Registro, monitoramento e auditoria: Mantenha registros detalhados das saídas do LLM e de como elas são usadas em todo o aplicativo. Monitore anomalias, como sequências de comandos inesperadas, padrões de saída incomuns ou erros em sistemas subsequentes que possam indicar tentativas de exploração. Audite os registros regularmente para identificar lacunas nos controles de tratamento das saídas.

Estrutura de riscos de LLMs e orientações do setor

O tratamento inseguro de saídas é reconhecido como uma vulnerabilidade significativa nas estruturas emergentes de segurança de LLMs. O OWASP Top 10 para LLMs o identifica como uma preocupação crítica, destacando o risco de encaminhar saídas não validadas do modelo para funções de backend, navegadores ou outros sistemas capazes de executá-las.

O framework recomenda tratar a saída do LLM como inerentemente não confiável, aplicar técnicas de validação de entrada ao conteúdo gerado pelo modelo e implementar estratégias de defesa em profundidade que não dependam exclusivamente da engenharia de prompts ou de restrições do modelo para impedir saídas maliciosas.

Segurança de IA generativa — as orientações de grupos do setor e fornecedores reforçam essas recomendações. Entre os temas recorrentes estão a codificação de saída por padrão, a separação rigorosa entre o conteúdo gerado por LLMs e os contextos de execução, além do monitoramento contínuo de anomalias nas saídas.

As organizações que integram LLMs a sistemas de produção devem alinhar seus controles de segurança a essas estruturas e incluir o tratamento inseguro de saídas em seus modelos de ameaças. À medida que a adoção de LLMs aumenta, a superfície de ataque se expande, e a mitigação proativa passa a ser uma expectativa básica, em vez de uma prática avançada.

Sinais e erros comuns

Vários padrões indicam que um aplicativo pode estar vulnerável ao tratamento inseguro de saída.

Confiar por padrão na saída do LLM é o erro mais comum. Os desenvolvedores presumem que, por terem escrito o prompt, a saída é segura. Isso ignora a influência da entrada fornecida pelo usuário sobre o comportamento do modelo e a imprevisibilidade inerente aos modelos generativos.

Ignorar a sanitização porque a saída "parece texto" gera vulnerabilidades quando esse texto contém código ou comandos incorporados. Mesmo respostas aparentemente simples podem incluir cargas maliciosas que são ativadas ao serem processadas por sistemas subsequentes.

Executar automaticamente a saída de um LLM sem validação é um antipadrão grave. Aplicações que encaminham a saída do modelo diretamente para eval(), exec(), ou interpretadores de shell sem inspeção criam caminhos diretos para a execução de código.

Incorporar a saída diretamente em interfaces de usuário ou consultas a bancos de dados sem codificação expõe as aplicações a ataques de XSS e injeção. A conveniência de inserir respostas do modelo em templates sem aplicar escape introduz riscos evitáveis.

Os sinais de uma possível exploração incluem erros inesperados em sistemas subsequentes, entradas anômalas nos logs que mostram comandos ou consultas incomuns e relatos de usuários sobre comportamentos estranhos em interfaces baseadas em LLMs. O monitoramento desses indicadores ajuda a detectar precocemente problemas relacionados ao tratamento inseguro de saídas.

Como a F5 lida com o tratamento inseguro de saídas?

A F5 trata o processamento inseguro de saídas por meio de controles aplicados às camadas de tráfego e de aplicação, nas quais as saídas dos LLMs interagem com sistemas downstream e usuários.

F5 AI Guardrails um elemento essencial da F5 AI Security Platform, aplica políticas às interações entre aplicações de IA, agentes e usuários, incluindo a validação de saída, que inspeciona as respostas do modelo antes que elas cheguem aos sistemas de back-end ou às aplicações clientes. Isso permite que as organizações detectem e bloqueiem saídas que contenham conteúdo potencialmente malicioso, como injeções de prompt, sequências de comandos ou padrões de dados inesperados.

Para aplicações web que renderizam conteúdo gerado por LLMs, os recursos de firewall de aplicações web da F5 aplicam análise comportamental e detecção baseada em assinaturas para identificar saídas que possam desencadear XSS, injeção ou outras vulnerabilidades no lado do cliente. A proteção se estende às APIs que consomem saídas de LLMs, monitorando cargas úteis anômalas e impondo a validação de esquemas.

F5 Distributed Cloud Services integram proteções em implantações híbridas e multinuvem, mantendo controles consistentes de tratamento de saídas, independentemente de onde as cargas de trabalho de LLM sejam executadas. Os recursos de registro e visibilidade ajudam a atender aos requisitos de auditoria e permitem que as equipes de segurança monitorem como as saídas de LLM fluem pela infraestrutura de aplicações.

Ao posicionar controles nos pontos em que a saída dos LLMs entra nos aplicativos e chega aos usuários, a F5 ajuda as organizações a aplicar a sanitização da saída como padrão, em vez de depender exclusivamente da implementação no nível do aplicativo.

Perguntas frequentes

Como a OWASP classifica o tratamento inseguro de saídas e por que ele é diferente de outros riscos relacionados a LLMs?

O OWASP define o tratamento inseguro de saídas como a validação, a sanitização e o tratamento insuficientes das saídas geradas por LLMs. Ele se diferencia de outros riscos por se referir especificamente aos problemas que surgem quando as saídas são encaminhadas aos usuários sem a devida supervisão e sem controles e governança adequados.

Qual é a diferença entre a codificação de saída e a validação de entrada para prevenir XSS em aplicações de IA?

A diferença entre a validação de entrada e a codificação de saída na prevenção de XSS em aplicações de IA é que a validação de entrada avalia os dados inseridos no sistema da aplicação, enquanto a codificação de saída protege o conteúdo gerado quando ele é enviado de volta aos usuários. A validação de entrada analisa os dados que entram em uma aplicação para rejeitar entradas que não atendam às regras definidas ou aos formatos esperados. A codificação de saída converte entradas potencialmente perigosas em um formato que pode ser exibido com segurança como dados, em vez de código executável.

Como a injeção indireta de prompt pode levar à execução remota de código (RCE) por meio do tratamento inseguro da saída?

A injeção indireta de prompt pode ser usada para executar código remotamente (RCE) por meio da inclusão de instruções maliciosas no conteúdo fornecido ao modelo. Essas instruções podem induzir o modelo a gerar comandos ou arquivos executáveis e, em seguida, encaminhar a saída para outras ferramentas ou sistemas, que a tratam como legítima.

Como posso evitar injeção de SQL e falsificação de solicitação do lado do servidor (SSRF) ao conectar LLMs a bancos de dados ou APIs internas?

Para evitar injeção de SQL e SSRF ao conectar LLMs a bancos de dados ou APIs internas, as saídas dos LLMs, incluindo comandos, parâmetros, URLs e argumentos de ferramentas, devem ser tratadas como dados não confiáveis, e não como instruções executáveis. Soluções de validação, listas de permissões de APIs, consultas parametrizadas e acesso com privilégios mínimos podem ajudar a mitigar os riscos.

Qual é a diferença entre o LangChain Guardrails, o NVIDIA NeMo Guardrails e os firewalls de aplicações web (WAFs)?

LangChain Guardrails, NVIDIA NeMo Guardrails e WAFs são soluções complementares, cuja principal diferença é que cada uma protege aspectos distintos dos sistemas corporativos de IA. LangChain Guardrails são usados para validar tarefas e agentes, atuando como middleware no código da aplicação de LLM. NVIDIA NeMo Guardrails ficam à frente da orquestração de LLMs para oferecer controle de diálogos com múltiplos turnos e alinhamento de tópicos. Os WAFs são implantados na borda da rede para proteger contra ameaças como injeção de SQL, XSS e ataques DDoS.