¿Qué es el manejo inseguro de salidas en apps LLM y cómo causa XSS o SSRF?
Respuesta breve
El manejo inseguro de salidas es confiar en lo que el modelo devuelve y pasarlo a un sistema aguas abajo sin validación ni codificación. Como la salida del modelo es influenciable por el atacante, renderizarla como HTML en bruto causa XSS, pasarla a un recuperador de URL causa SSRF, y pasarla a un shell o una consulta SQL causa inyección de comandos o SQL. La solución es tratar la salida del modelo exactamente como entrada de usuario no confiable: codificación de salida sensible al contexto, listas de permitidos, saneamiento y parametrización antes de que llegue a cualquier sink.
El manejo inseguro de salidas (OWASP lo llama improper output handling) es un error clásico de appsec con sombrero de IA: la aplicación confía en lo que el modelo devuelve y lo pasa directamente a un componente aguas abajo. La trampa es que la salida del modelo es influenciable por el atacante —mediante prompts directos, jailbreaks o inyección indirecta en datos recuperados—, así que debe tratarse como no confiable, igual que cualquier entrada de usuario.
Cómo se convierte en vulnerabilidades reales
El fallo aparece en el sink, allá donde aterriza la salida:
- XSS. La app renderiza la respuesta del modelo como HTML/Markdown en bruto en un navegador. Si el modelo emite
<script>o un manejadoronerror(porque un atacante lo persuadió), se ejecuta en la sesión de la víctima. - SSRF. La app toma una URL del modelo y la recupera del lado del servidor, permitiendo al atacante alcanzar servicios internos o endpoints de metadatos de la nube.
- Inyección de comandos / SQL. La salida se concatena en un comando de shell o una consulta SQL.
- Path traversal, open redirect, log injection — mismo patrón, sink distinto.
Un punto sutil: aunque hayas saneado la entrada del usuario, el modelo puede sintetizar una carga útil maliciosa por sí solo, así que el saneamiento de la entrada por sí solo no protege el sink.
Defensas
Aplica la misma disciplina que para cualquier dato no confiable:
- Codificación de salida sensible al contexto antes de renderizar (contextos HTML, atributo, JS, URL).
- Lista de permitidos y validación de la salida estructurada (URLs, IDs, enumeraciones) contra esquemas estrictos.
- Parametriza las consultas y evita pasar la salida a shells.
- Sandbox y filtrado de salida de red de cualquier recuperación o ejecución del lado del servidor.
Qué buscan los entrevistadores
El encuadre de que «la salida del modelo es entrada no confiable», la capacidad de nombrar el sink de cada vulnerabilidad (XSS, SSRF, inyección de comandos), y recurrir a la codificación sensible al contexto y la validación en lugar de culpar al prompt.
Posibles preguntas de seguimiento
- ¿Por qué la salida del modelo es un vector de inyección incluso si la entrada del usuario fue saneada?
- ¿Qué codificación sensible al contexto aplicarías antes de renderizar la salida del modelo en HTML?
- ¿Cómo se agrava este riesgo cuando la salida se entrega a un agente que usa herramientas?