Gestión insegura de la salida

El tratamiento inseguro (o inadecuado) de las salidas se refiere a la falta de validación, saneamiento o codificación de las salidas generadas por un modelo de lenguaje de gran tamaño antes de transferirlas a sistemas posteriores, mostrarlas en interfaces de usuario o ejecutarlas en procesos de backend.

¿Qué es la gestión insegura de resultados?

Cuando las aplicaciones integran LLM, suelen recibir texto generado y enviarlo a otro lugar: a un navegador, una consulta de base de datos, un comando del sistema u otro componente de la aplicación. La gestión no segura de la salida se produce cuando ese contenido generado se utiliza sin comprobar que sea seguro.

El problema fundamental es la confianza. Los desarrolladores suelen asumir que, como controlan el prompt o el modelo, el resultado será predecible e inofensivo, pero no siempre es así. Los LLM generan respuestas basadas en patrones aprendidos a partir de los datos de entrenamiento y condicionadas por la entrada del usuario. Un prompt cuidadosamente elaborado puede hacer que el modelo genere contenido con código ejecutable, scripts maliciosos, fragmentos de SQL o comandos del sistema que la aplicación procesa como si fueran datos de confianza.

Esta vulnerabilidad es análoga a los fallos de inyección tradicionales, como el cross-site scripting (XSS), en los que una entrada de usuario no protegida provoca la ejecución de código en un navegador. La diferencia es que, en este caso, la «entrada de usuario» es la salida del modelo, que puede manipularse indirectamente mediante la inyección de prompts o simplemente surgir de los patrones de respuesta del modelo.

La gestión insegura de la salida se convierte en un problema de seguridad cuando la aplicación no trata la salida del LLM con la misma cautela que aplicaría a cualquier entrada externa que no sea de confianza. Sin validación ni codificación, esa salida puede generar vulnerabilidades en cualquier sistema que la reciba.

¿Por qué es peligroso gestionar las salidas de forma insegura?

Las prácticas de seguridad estándar presuponen que las fuentes de entrada son predecibles. Los formularios tienen campos definidos. Las API tienen esquemas. La entrada del usuario llega a través de canales conocidos. La salida de los LLM rompe estos supuestos porque se genera dinámicamente, está condicionada por instrucciones que pueden incluir contenido malicioso y es capaz de producir prácticamente cualquier cadena de texto.

Esta imprevisibilidad hace que la gestión insegura de las salidas sea especialmente peligrosa para las aplicaciones basadas en LLM. Un modelo puede generar respuestas válidas y útiles miles de veces y, de repente, producir una respuesta que contenga una etiqueta de script o un comando de shell porque el prompt haya tomado un rumbo inesperado. Los controles de seguridad que se basan en la coincidencia con un conjunto finito de patrones o en listas de elementos permitidos tienen dificultades para anticipar todas las salidas posibles.

La superficie de ataque también aumenta porque las salidas de los LLM suelen enviarse a varios sistemas posteriores. Una misma respuesta puede mostrarse en un navegador, registrarse en una base de datos y transmitirse a una API. Cada destino presenta sus propias vulnerabilidades, y una gestión insegura de las salidas en cualquier punto puede abrir una vía de explotación.

Además, el comportamiento de los LLM puede cambiar con el tiempo a medida que los modelos se actualizan o se someten a un ajuste fino. Una salida que era segura con una versión del modelo puede volverse explotable con otra. Las aplicaciones que no tratan las salidas como intrínsecamente no fiables conllevan un riesgo latente que solo se manifiesta cuando cambian las condiciones.

¿Cómo se produce el tratamiento inseguro de los datos de salida?

El tratamiento inseguro de las salidas aprovecha la brecha entre lo que genera un LLM y la forma en que los sistemas posteriores interpretan ese contenido. Los atacantes manipulan las instrucciones para hacer que el modelo genere una salida que, al procesarse sin depuración, provoque un comportamiento no deseado en el sistema receptor.

• Salida no fiable como entrada activa: Las salidas de los LLM son cadenas de texto, pero pueden contener contenido ejecutable: JavaScript, HTML, SQL, comandos de shell o Markdown con scripts incrustados. Si una aplicación pasa esta salida directamente a un intérprete, un shell o un motor de renderizado sin sanearla, el contenido se ejecuta. Por ejemplo, un prompt diseñado para obtener una respuesta que contenga etiquetas <script> se convierte en una carga útil XSS si la salida se inserta en una página web sin codificarla.
• Salida renderizada en navegadores cliente o interfaces de usuario: Cuando el contenido generado por un LLM se muestra en un navegador o en la interfaz de una aplicación, cualquier código HTML o JavaScript incrustado puede ejecutarse en el contexto del usuario. Esto puede dar lugar a ataques de scripting entre sitios, secuestro de sesiones, robo de credenciales o manipulación de la interfaz de usuario. Los chatbots, los generadores de contenido y los asistentes de IA que renderizan directamente la salida del modelo están especialmente expuestos si omiten la codificación de salida.
• Ejecución en el backend y escalada de privilegios: Los casos más graves se producen cuando la salida del LLM llega a sistemas backend con capacidad de ejecución. Si la salida se pasa a un intérprete de comandos, a una función eval() o a una consulta de base de datos sin sanearla, los atacantes pueden lograr la ejecución remota de código, la exfiltración de datos o la escalada de privilegios. Un modelo manipulado para generar una cadena de inyección SQL válida o un comando del sistema puede poner en peligro todo el backend si la aplicación ejecuta esa salida.

Ejemplos comunes y escenarios de ataque reales

El tratamiento inseguro de los resultados se manifiesta en varios patrones reconocibles en las aplicaciones integradas con LLM.

Un chatbot de atención al cliente que muestra las respuestas del LLM como HTML sin aplicar caracteres de escape puede convertirse en un vector de XSS. Un atacante envía un prompt diseñado para hacer que el modelo incluya una etiqueta de script en su respuesta. Cuando la respuesta se muestra en el navegador de otro usuario, el script se ejecuta y puede robar tokens de sesión o redirigir a un sitio de phishing.

Las aplicaciones que utilizan la salida de un LLM para crear consultas de bases de datos también están expuestas a riesgos de inyección SQL. Si se pide a un modelo que genere una consulta de búsqueda de productos y un atacante manipula la entrada para que el modelo añada ; DROP TABLE users;-- a su respuesta, una aplicación que concatene esa salida en una sentencia SQL sin parametrizar ejecutará el comando malicioso.

Además, las canalizaciones de CI/CD que incorporan código o configuraciones generados por LLM son vulnerables a la inyección de comandos. Un modelo al que se le pida generar un script de despliegue podría ser manipulado para que incluya un comando de shell inversa. Si la canalización ejecuta el script sin revisarlo, el atacante obtiene acceso a la infraestructura de compilación.

La falsificación de solicitudes del lado del servidor también puede deberse a una gestión insegura de la salida. Se podría engañar a un LLM que genera URL o llamadas a API a partir de la entrada del usuario para que produzca solicitudes dirigidas a recursos de la red interna. Si la aplicación realiza esas solicitudes sin validarlas, los atacantes pueden sondear los sistemas internos o extraer datos.

Riesgos en la IA agéntica y la arquitectura RAG

A medida que el uso de la IA en las empresas modernas se amplía y avanza, también evolucionan los riesgos derivados de una gestión no segura de los resultados. Ahora, los modelos proporcionan datos de entrada e instrucciones a aplicaciones, herramientas, API, bases de datos y agentes conectados. Esta conectividad brinda oportunidades a los actores maliciosos, que pueden utilizar técnicas de inyección indirecta de instrucciones para engañar a agentes de IA autónomos y conseguir que ejecuten llamadas no autorizadas a API o herramientas, realicen escrituras maliciosas en bases de datos o extraigan datos de canalizaciones de generación aumentada por recuperación (RAG).

El aumento de las capacidades autónomas y el acceso cada vez más habitual de los agentes a sistemas críticos para el negocio hacen necesario validar y sanear las salidas antes de que lleguen a sistemas o herramientas posteriores. Cualquier salida que exceda los permisos definidos debe restringirse.

Cómo evitar la gestión insegura de los resultados

Para evitar el tratamiento inseguro de los resultados, es necesario tratar la salida de los LLM con el mismo rigor que se aplica a los datos introducidos por usuarios que no son de confianza. Las siguientes prácticas pueden ayudar a reducir la exposición a vectores de ataque habituales:

• Trate la salida del LLM como una entrada no fiable: Adopte un enfoque de confianza cero ante todo el contenido generado por el modelo. Independientemente de cómo se haya elaborado el prompt o de las restricciones aplicadas, asuma que la salida puede contener contenido malicioso o con un formato incorrecto. Valídela y desinféctela antes de cualquier uso posterior.
• Validación y saneamiento de la salida: Aplique una codificación adecuada al contexto antes de mostrar o ejecutar la salida del LLM. Codifique en HTML la salida que se muestre en navegadores. Parametrice las consultas a bases de datos en lugar de concatenar la salida del modelo en cadenas SQL. Escape los metacaracteres del shell si la salida debe pasarse a comandos del sistema. Siempre que sea posible, utilice listas de elementos permitidos para restringir la salida a los patrones esperados.
• Controles de acceso estrictos y enfoque de privilegios mínimos: Limite los permisos de los componentes que procesan la salida del LLM. Si un servicio ejecuta comandos generados por el modelo, restrinja los comandos que puede ejecutar y los recursos a los que puede acceder. Aísle de los sistemas sensibles el procesamiento relacionado con el LLM. Aplique el principio de privilegios mínimos para que incluso una explotación exitosa tenga un impacto limitado.
• Revisión humana y filtrado de resultados: En casos de uso de alto riesgo, como la generación de código, las transacciones financieras o las acciones administrativas, exija una revisión humana antes de la ejecución. Implemente un filtrado automatizado para marcar o bloquear los resultados que coincidan con patrones peligrosos conocidos. Utilice clasificadores de contenido para detectar resultados potencialmente maliciosos antes de que lleguen a los sistemas posteriores.
• Registro, supervisión y auditoría: Mantenga registros detallados de las salidas del LLM y de cómo se utilizan en toda la aplicación. Supervise posibles anomalías, como secuencias de comandos inesperadas, patrones de salida inusuales o errores en sistemas posteriores que puedan indicar intentos de explotación. Audite los registros periódicamente para detectar deficiencias en los controles de gestión de las salidas.

Marco de riesgos de los LLM y directrices del sector

La gestión insegura de las salidas se considera una vulnerabilidad importante en los nuevos marcos de seguridad para LLM. El «OWASP Top 10 for LLMs» la identifica como un problema crítico y destaca el riesgo de enviar salidas del modelo sin validar a funciones de backend, navegadores u otros sistemas capaces de ejecutarlas.

El marco recomienda tratar la salida de los LLM como intrínsecamente no fiable, aplicar técnicas de validación de entradas al contenido generado por el modelo e implementar estrategias de defensa en profundidad que no dependan únicamente de la ingeniería de prompts ni de las restricciones del modelo para evitar resultados maliciosos.

Seguridad de la IA generativaLas directrices de grupos del sector y proveedores refuerzan estas recomendaciones. Entre los aspectos comunes se incluyen la codificación de la salida de forma predeterminada, la separación estricta entre el contenido generado por los LLM y los contextos de ejecución, y la supervisión continua para detectar anomalías en la salida.

Las organizaciones que integren LLM en sistemas de producción deben adaptar sus controles de seguridad a estos marcos e incluir la gestión insegura de los resultados en sus modelos de amenazas. A medida que aumenta la adopción de los LLM, también crece la superficie de ataque, por lo que la mitigación proactiva pasa a ser un requisito básico en lugar de una práctica avanzada.

Señales y errores comunes

Hay varios patrones que indican que una aplicación puede ser vulnerable a una gestión insegura de los datos de salida.

Confiar por defecto en la salida de los LLM es el error más habitual. Los desarrolladores dan por sentado que, como ellos redactaron el prompt, la salida es segura. Esto pasa por alto la influencia de los datos introducidos por el usuario en el comportamiento del modelo y la imprevisibilidad inherente de los modelos generativos.

Omitir la sanitización porque el resultado «parece texto» genera vulnerabilidades cuando ese texto contiene código o comandos incrustados. Incluso las respuestas que parecen texto sin más pueden incluir cargas maliciosas que se activan al ser procesadas por sistemas posteriores.

La ejecución automática de la salida de un LLM sin validarla constituye un antipatrón grave. Las aplicaciones que pasan la salida del modelo directamente a eval(), exec(), o a intérpretes de comandos sin inspeccionarla crean vías directas para la ejecución de código.

Incrustar directamente la salida en interfaces de usuario o consultas de bases de datos sin codificarla expone las aplicaciones a ataques XSS y de inyección. La comodidad de insertar las respuestas del modelo en plantillas sin escaparlas introduce un riesgo evitable.

Entre los indicios de una posible explotación se incluyen errores inesperados en los sistemas posteriores, entradas anómalas en los registros que muestran comandos o consultas inusuales e informes de usuarios sobre comportamientos extraños en interfaces basadas en LLM. La supervisión de estos indicadores facilita la detección temprana de problemas relacionados con el tratamiento inseguro de los resultados.

¿Cómo gestiona F5 el tratamiento no seguro de los datos de salida?

F5 aborda la gestión no segura de los resultados mediante controles aplicados en las capas de tráfico y de aplicación, donde los resultados de los LLM interactúan con los sistemas posteriores y los usuarios.

F5 AI Guardrails, un elemento integral de F5 AI Security Platform, aplica políticas en los intercambios entre aplicaciones de IA, agentes y usuarios, incluida la validación de las salidas, que inspecciona las respuestas del modelo antes de que lleguen a los sistemas backend o a las aplicaciones cliente. Esto permite a las organizaciones detectar y bloquear salidas que contengan contenido potencialmente malicioso, como inyecciones de prompts, secuencias de comandos o patrones de datos inesperados.

En el caso de las aplicaciones web que renderizan contenido generado por LLM, las funcionalidades de firewall de aplicaciones web de F5 aplican análisis de comportamiento y detección basada en firmas para identificar resultados que podrían desencadenar ataques XSS, inyecciones u otras vulnerabilidades del lado del cliente. La protección se extiende a las API que consumen resultados de LLM, mediante la supervisión de cargas útiles anómalas y la aplicación de la validación de esquemas.

F5 Distributed Cloud Services integran protecciones en implementaciones híbridas y multinube, manteniendo controles coherentes para la gestión de los resultados, independientemente de dónde se ejecuten las cargas de trabajo de los LLM. Las funciones de registro y visibilidad ayudan a cumplir los requisitos de auditoría y permiten a los equipos de seguridad supervisar cómo fluyen los resultados de los LLM a través de la infraestructura de las aplicaciones.

Al situar los controles en los puntos en los que la salida de los LLM entra en las aplicaciones y llega a los usuarios, F5 ayuda a las organizaciones a aplicar de forma predeterminada el saneamiento de las salidas, en lugar de depender únicamente de su implementación en las aplicaciones.

Preguntas frecuentes

¿Cómo clasifica OWASP la gestión insegura de los resultados y por qué se considera un riesgo distinto de otros riesgos de los LLM?

OWASP define el tratamiento inseguro de las salidas como la validación, depuración y gestión insuficientes de las salidas generadas por los LLM. Se diferencia de otros riesgos en que se refiere específicamente a los problemas que surgen cuando las salidas se envían a los usuarios sin la supervisión, los controles y la gobernanza adecuados.

¿Cuál es la diferencia entre la codificación de salida y la validación de entrada para prevenir ataques XSS en aplicaciones de IA?

La diferencia entre la validación de entradas y la codificación de salidas para prevenir ataques XSS en aplicaciones de IA radica en que la validación de entradas evalúa los datos que se introducen en el sistema de una aplicación, mientras que la codificación de salidas protege el contenido generado cuando se envía de vuelta a los usuarios. La validación de entradas examina los datos que recibe una aplicación para rechazar aquellos que no cumplen las reglas definidas o los formatos esperados. La codificación de salidas convierte las entradas potencialmente peligrosas a un formato que permite mostrarlas de forma segura como datos en lugar de como código ejecutable.

¿Cómo puede una inyección indirecta de prompts provocar la ejecución remota de código (RCE) debido a una gestión no segura de la salida?

La inyección indirecta de instrucciones puede utilizarse para lograr la ejecución remota de código (RCE) mediante la inclusión de instrucciones maliciosas en el contenido proporcionado al modelo. Estas instrucciones pueden indicar al modelo que genere comandos o archivos ejecutables y que, a continuación, envíe el resultado a otras herramientas o sistemas, que lo tratarán como legítimo.

¿Cómo puedo evitar la inyección SQL y la falsificación de solicitudes del lado del servidor (SSRF) al conectar LLM a bases de datos o API internas?

Para evitar la inyección SQL y la falsificación de solicitudes del lado del servidor (SSRF) al conectarse a bases de datos o API internas, las salidas de los LLM, incluidos los comandos, parámetros, URL y argumentos de herramientas, deben tratarse como datos no fiables, no como instrucciones ejecutables. Las soluciones de validación, las listas de API permitidas, las consultas parametrizadas y el acceso con privilegios mínimos pueden ayudar a mitigar los riesgos.

¿Cuál es la diferencia entre LangChain Guardrails, NVIDIA NeMo Guardrails y los firewalls de aplicaciones web (WAF)?

LangChain Guardrails, NVIDIA NeMo Guardrails y los WAF son soluciones complementarias cuya principal diferencia radica en que cada una protege distintos aspectos de los sistemas de IA empresariales. LangChain Guardrails se utiliza para validar tareas y agentes, y funciona como middleware dentro del código de la aplicación de LLM. NVIDIA NeMo Guardrails se sitúa delante de la capa de orquestación de LLM para controlar diálogos de varios turnos y garantizar que se ajusten a los temas definidos. Los WAF se implementan en el perímetro de la red para proteger frente a amenazas como la inyección SQL, los ataques XSS y los ataques DDoS.