Laboratorio de manejo inseguro de la salida
Sigue la salida de un LLM o agente hasta su destino, identifica la clase de vulnerabilidad y elige la mitigación que la cierra.
Abrir la herramienta →La herramienta interactiva se abre en inglés.
Te llega una cola de flujos, cada uno con una salida de un LLM o de un agente que va hacia un destino (sink): una se renderiza como HTML, otra se concatena en una consulta SQL o NoSQL, otra se pasa a una shell, otra se convierte en una URL que el servidor descarga, otra en una ruta de archivo y otra se entrega a eval. En cada flujo eliges la CLASE DE VULNERABILIDAD que crea (XSS, inyección SQL o de consultas, inyección de comandos del sistema operativo, SSRF, path traversal, inyección de código / eval inseguro, o ninguna), el PRINCIPIO de salida segura en juego y la MITIGACIÓN que cierra la clase en el destino. Se basa en «LLM02: Insecure Output Handling» de OWASP, en MITRE ATLAS y en las clases reales de destinos de CWE (CWE-79, 89, 78, 918, 22, 94, 502), con nombres reales de controles: codificación de salida según el contexto, DOMPurify, Content-Security-Policy, consultas parametrizadas, arrays de argumentos, listas de salida permitida, canonicalización de rutas y deserializadores solo de datos. La habilidad central que entrena: tratar la salida del modelo como entrada no fiable para el destino (codificar según el contexto, parametrizar en lugar de concatenar, no ejecutar nunca la salida y limitar con listas de permitidos las rutas y los hosts a los que puede llegar) sin bloquear de más un flujo que ya está correctamente codificado, vinculado o confinado. Es una simulación educativa segura: cada flujo es pseudocódigo neutralizado, nada se ejecuta y no hay exploits funcionales. Con niveles de dificultad, bonificación por velocidad y nota de S a D. Es un laboratorio Pro.
- Lee cada flujo: hacia qué destino va la salida del modelo (DOM, consulta, shell, petición del servidor, ruta de archivo o intérprete de código).
- Identifica la clase de vulnerabilidad que crea, o «ninguna» si el flujo ya es seguro.
- Elige el principio de salida segura en juego y la mitigación que cierra la clase en el destino.
- No bloquees de más los flujos que ya están bien resueltos y revisa tu nota de S a D.
Preguntas frecuentes
¿Qué enseña el laboratorio de manejo inseguro de la salida?
Enseña el manejo inseguro de la salida (Insecure Output Handling): el riesgo del OWASP Top 10 para aplicaciones LLM («LLM02») en el que un componente posterior confía en la salida de un LLM o de un agente y la pasa, sin validar ni codificar, a un destino sensible. Cada escenario muestra un flujo (salida del modelo que va al DOM del navegador, a una consulta SQL/NoSQL, a una shell, a una petición del lado del servidor, a una ruta de archivo o a un intérprete de código) y tú decides la clase de vulnerabilidad que crea (XSS, inyección SQL o de consultas, inyección de comandos del sistema operativo, SSRF, path traversal, inyección de código o ninguna), el principio de salida segura en juego y la mitigación concreta que cierra la clase en el destino.
¿Es seguro y legal? ¿Ejecuta ataques reales o incluye exploits?
Sí, es seguro, y no. Es una simulación educativa segura, como un ejercicio de mesa, con el mismo espíritu que nuestros otros laboratorios. Cada flujo de datos es pseudocódigo neutralizado que describe una ruta insegura; nada se ejecuta, no hay cargas de exploit funcionales, ni secretos, hosts o destinos reales, ni código armado que se pueda copiar y pegar. Es puramente un ejercicio defensivo de reconocimiento (aprendes el movimiento del atacante para poder bloquearlo) y usarlo es totalmente legal y educativo.
¿Por qué es un error pensar «viene de nuestro propio modelo, así que es seguro»?
Porque la salida de los modelos y los agentes puede estar influida por un atacante: un prompt diseñado a propósito, una inyección indirecta desde el resultado de una herramienta o un documento RAG envenenado pueden dirigir lo que emite el modelo. Así que la salida debe tratarse como entrada no fiable para el destino que la consume, exactamente igual que la entrada del usuario. Renderizarla como HTML en bruto es XSS; concatenarla en una consulta es inyección; pasarla a una shell o a eval es ejecución de código; usarla como URL o como ruta es SSRF o traversal. Que el origen sea «interno» no cambia en nada la obligación del destino de validar y codificar.
¿Se puede bloquear de más en el manejo de la salida?
Sí, y el laboratorio lo pone a prueba. La salida que se asigna mediante textContent o se escapa automáticamente, la que se vincula como parámetro de una consulta y se devuelve como JSON, o la que se usa como ruta canonicalizada y confinada a un directorio base permitido, ya es segura: el control correcto está en su sitio. Añadir por reflejo filtros de palabras clave, prohibir caracteres o quitar la función no aporta seguridad y rompe comportamientos legítimos. La habilidad consiste en ajustar la mitigación al destino: cerrar la clase real donde existe y reconocer el flujo ya seguro donde no.
¿Es gratis?
No, es un laboratorio Pro. Con una cuenta gratuita tienes 3 usos de prueba de herramientas Pro en total; después necesitas Pro.