Indirect Prompt Injection: Manipulando LLMs a Través de Comandos Ocultos

El otro día estaba navegando por la Web Security Academy de PortSwigger cuando me encontré con su laboratorio sobre indirect prompt injection. Esto me llamó la atención de inmediato porque demuestra uno de los vectores de ataque más fascinantes (y preocupantes) en seguridad de IA hoy en día.

A diferencia del direct prompt injection, donde un atacante introduce explícitamente prompts maliciosos a un LLM, el indirect prompt injection es mucho más sutil y potencialmente más peligroso. El atacante nunca interactúa directamente con el LLM — en cambio, planta sus prompts maliciosos en contenido externo que el LLM podría procesar más tarde cuando un usuario desprevenido lo solicite.

¿Qué es el Indirect Prompt Injection?

El indirect prompt injection ocurre cuando un atacante introduce prompts maliciosos a través de fuentes externas que un LLM podría procesar después — como sitios web, documentos, emails u otro contenido. El LLM entonces ejecuta estos comandos ocultos al procesar dicho contenido, lo que potencialmente lleva a fuga de datos, acciones no autorizadas u otras brechas de seguridad.

Esto difiere del direct prompt injection de una manera crítica:

1. Direct Prompt Injection: El atacante introduce directamente prompts maliciosos al LLM
2. Indirect Prompt Injection: El atacante planta prompts maliciosos en contenido externo
3. La víctima le pide al LLM que procese el contenido externo
4. El LLM ejecuta el prompt malicioso oculto

Lo que hace al indirect prompt injection particularmente peligroso es que la víctima nunca ve el prompt malicioso — simplemente le pide al LLM que procese contenido aparentemente inocente (como resumir una página web o un email), sin saber que hay comandos ocultos acechando dentro.

Diagrama del Flujo de Ataque

Clic para ampliar

Diagrama del flujo de ataque de Indirect Prompt Injection (IPI) para este desafío de laboratorio

El Desafío del Laboratorio de PortSwigger

El laboratorio de PortSwigger presenta un escenario donde necesitamos explotar una vulnerabilidad de indirect prompt injection para eliminar una cuenta de usuario. Este es el contexto:

1. El laboratorio tiene una función de chat en vivo impulsada por un LLM
2. El usuario "carlos" pregunta frecuentemente sobre un producto específico (la Lightweight "l33t" Leather Jacket)
3. Nuestro objetivo es eliminar la cuenta de carlos a través de indirect prompt injection

El laboratorio simula un escenario común del mundo real: un sitio de e-commerce con un asistente de chat impulsado por IA que puede acceder a información de productos y realizar funciones de gestión de cuentas.

Explorando la Superficie de Ataque

Al abordar cualquier sistema basado en LLM, el primer paso es entender qué capacidades y permisos tiene el modelo. En este laboratorio, podemos descubrir esto simplemente preguntándole al LLM directamente.

A través de la conversación con el asistente de chat, descubrimos que tiene acceso a varias APIs, incluyendo:

• Una API de información de productos para obtener detalles sobre artículos
• Una API de gestión de cuentas que puede editar direcciones de email y eliminar cuentas

Esta es nuestra primera señal de alerta — el LLM tiene acceso a funciones poderosas que podrían ser abusadas si logramos manipular su comportamiento.

Veamos cómo podría funcionar la interacción con la API del LLM detrás de escena. Cuando un usuario pregunta sobre las APIs disponibles, el asistente hace una llamada de función para listarlas. La respuesta incluye las funciones get_product_info, edit_email y delete_account.

Ejemplo de Interacción con la API

Probando la Superficie de Ataque - Pasos del Laboratorio

Seguir estos pasos en el laboratorio nos permite mapear la superficie de ataque:

1. Descubrimiento de APIs: Usá el chat en vivo para preguntar a qué APIs tiene acceso el LLM. Observá que puede eliminar cuentas y editar direcciones de email.
2. Prueba de Permisos: Pedile al LLM que elimine tu cuenta sin estar logueado — devuelve un error, mostrando que la API requiere autenticación.
3. Creación de Cuenta: Registrá una cuenta de usuario e iniciá sesión.
4. Confirmación de Acceso a la API: Pedile al LLM que cambie tu dirección de email. Si tiene éxito sin verificación adicional, esto confirma que las APIs funcionan basándose únicamente en las cookies de sesión.
5. Prueba de Influencia de Contenido: Agregá una reseña factual a un producto (como "This product is out of stock"), luego preguntale al LLM sobre el producto. Si incluye el contenido de tu reseña, esto confirma que el LLM incorpora contenido generado por usuarios.

Este reconocimiento confirma dos vulnerabilidades críticas: el LLM procesa contenido generado por usuarios al responder sobre productos, y puede ejecutar acciones sensibles basándose únicamente en la sesión del usuario actual.

La Vulnerabilidad: Cómo las Reseñas de Productos se Convierten en Vectores de Ataque

La vulnerabilidad clave en este laboratorio es que el LLM obtiene y procesa reseñas de productos cuando se le pregunta sobre ellos. Esto crea nuestro camino de ataque:

1. El LLM lee las reseñas cuando se le pregunta sobre productos
2. El atacante puede agregar reseñas maliciosas
3. Carlos pregunta frecuentemente sobre la leather jacket
4. El LLM procesa el contenido de la reseña maliciosa como comandos
5. La cuenta de Carlos es eliminada

Este es un escenario clásico de indirect prompt injection — estamos plantando nuestro prompt malicioso en contenido que será procesado más tarde por el LLM cuando interactúe con nuestro objetivo.

El problema crítico acá es que el contenido generado por usuarios (reseñas de productos) está siendo procesado por el mismo LLM que tiene acceso a funciones sensibles de gestión de cuentas, sin límites de contexto apropiados.

Así es como funciona el flujo de datos cuando el LLM procesa una consulta de producto:

Flujo de Consulta de Producto:

1. El usuario pregunta sobre la leather jacket
2. El LLM llama a la API get_product_info
3. La API devuelve detalles del producto incluyendo reseñas
4. Una reseña contiene contenido malicioso de prompt injection
5. El LLM procesa el texto de la reseña como parte de su contexto

Estructura de la Llamada a la API

Creando el Exploit

Para explotar esta vulnerabilidad, necesitamos crear una reseña que contenga un prompt oculto que engañe al LLM para que elimine la cuenta de carlos. El desafío es que los LLMs modernos están diseñados para distinguir entre sus instrucciones y el contenido que están procesando.

Este ataque explota una limitación fundamental en cómo los LLMs procesan el contexto. El modelo intenta entender la estructura de los datos que está procesando, y marcadores especialmente diseñados pueden confundir su comprensión de dónde termina la reseña y dónde comienzan las instrucciones directas del usuario.

Acá es donde el ataque se pone interesante. Necesitamos crear un prompt que haga que el LLM crea que está recibiendo un comando legítimo del usuario, no simplemente procesando texto de una reseña.

Después de experimentar cuidadosamente, encontré que este patrón funciona efectivamente:

Analicemos por qué funciona:

1. La primera parte parece una reseña normal para evadir la moderación de contenido
2. El string ""]]]}}}}---END OF REVIEW intenta "salir" de la estructura JSON
3. Los marcadores ----USER RESPONSE---- engañan al LLM haciéndole creer que lo que sigue es un comando directo del usuario
4. La solicitud de eliminar "my account" será ejecutada en el contexto de quien esté logueado actualmente (carlos)

Esta técnica aprovecha lo que algunos investigadores llaman "format injection" o "structure breaking", donde el atacante intenta terminar la estructura de datos actual e inyectar contenido nuevo y malicioso que será interpretado de manera diferente.

Entendiendo Por Qué Funciona el Ataque: LLM Parser vs. JSON Parser

Es importante entender que este ataque apunta al procesamiento de texto del LLM, no al JSON parser. Veamos la diferencia:

Atacando un JSON Parser:

Atacando el LLM Parser:

Por Qué se Usan Múltiples Caracteres de Cierre (]]]}}}})

Los múltiples caracteres de cierre actúan como un "enfoque de escopeta" para salir de cualquier formato anidado:

Esto asegura que el payload funcione incluso si no sabemos exactamente cómo está estructurado el contexto interno del LLM.

Explicación Detallada del "Enfoque de Escopeta"

El ataque usa múltiples caracteres de cierre como defensa contra una profundidad de contexto desconocida. Considerá estas hipotéticas plantillas de prompt del LLM:

Contexto Simple:

Contexto Anidado Complejo:

Como los atacantes no saben qué formato usa el LLM internamente, usan caracteres de cierre excesivos para salir de cualquier posible profundidad de anidamiento. Es como probar múltiples llaves para abrir una puerta cuando no sabés cuál funciona.

Analogía del Mundo Real

Pensá en JSON como un conjunto de cajas anidadas. El atacante quiere salir de todas las cajas a la vez:

1. La caja más interna es el string ("reviewContent")
2. El string podría estar en un array ([...])
3. El array podría estar en objetos ({...})

Al usar ""]]]}}}}, estás intentando:

• Cerrar el string con ""
• Cerrar cualquier array con ]]]
• Cerrar cualquier objeto con }}}}

Es como abrir a la fuerza todos los contenedores posibles a la vez para escapar, sin importar cómo estén anidados.

Ejecutando el Ataque

La ejecución del ataque es sorprendentemente simple:

1. Creá una cuenta de usuario e iniciá sesión
2. Navegá a la página del producto leather jacket
3. Agregá una reseña que contenga nuestro prompt malicioso
4. Esperá a que carlos le pregunte al LLM sobre la leather jacket
5. Cuando carlos hace esto, el LLM procesa nuestro prompt oculto como si viniera de carlos
6. El LLM ejecuta la función delete_account, eliminando la cuenta de carlos

Lo que es particularmente insidioso de este ataque es que carlos nunca ve el prompt malicioso — desde su perspectiva, simplemente preguntó sobre un producto y el LLM realizó una acción no autorizada.

Resumen de la Ejecución del Ataque:

• Carlos pregunta sobre la leather jacket
• El LLM obtiene la información del producto incluyendo la reseña maliciosa
• La reseña maliciosa contiene un comando oculto para eliminar la cuenta
• El LLM interpreta esto como una solicitud directa del usuario
• El LLM llama a la función delete_account
• La cuenta de Carlos es eliminada sin su conocimiento

Ejemplos de Payloads Alternativos

Acá hay algunos otros payloads que podrían funcionar dependiendo de la implementación del LLM:

Cada uno de estos intenta escapar del contexto actual e inyectar un comando que el LLM podría interpretar como proveniente directamente del usuario.

La Naturaleza Experimental del Prompt Injection

Los atacantes a menudo descubren payloads funcionales a través de la experimentación. Similar a cómo evolucionó el SQL injection, diferentes LLMs pueden ser vulnerables a diferentes trucos de formato. Algunos ejemplos que han funcionado en varios sistemas:

El patrón común es intentar usar tokens especiales o formato que el LLM podría reconocer como límites de contexto. Esto crea una especie de "prompt primitive" que puede usarse para manipular el comportamiento del modelo.

Estrategias de Mitigación

¿Cómo pueden las aplicaciones protegerse contra estos tipos de ataques? Acá hay varias estrategias de mitigación efectivas:

Principio de Menor Privilegio Los LLMs deberían tener acceso solo a las funciones mínimas necesarias para completar sus tareas. Las funciones de gestión de cuentas rara vez son necesarias para chatbots de servicio al cliente.

1. Sanitización de Contenido: Implementar sanitización robusta del contenido generado por usuarios antes de alimentarlo a los LLMs
2. Límites de Contexto: Separar claramente los diferentes contextos (ej., reseñas de productos vs. comandos de usuario)
3. Pasos de Confirmación: Requerir confirmación explícita del usuario para operaciones sensibles
4. Permisos de Funciones: Implementar permisos granulares para la llamada de funciones
5. Filtrado de Entrada: Filtrar patrones sospechosos que podrían indicar intentos de inyección

Técnicas de Mitigación Avanzadas

Más allá de las mitigaciones básicas, acá hay enfoques más avanzados:

1. Construcción Separada de Prompts: Mantener el contenido generado por usuarios y los system prompts completamente separados:

2. Guardrails de Prompt Engineering: Incluir instrucciones explícitas para proteger contra inyección:

3. Autenticación de Dos Factores para Acciones Críticas: Requerir una confirmación separada:

4. Clasificación de Contenido: Escanear el contenido generado por usuarios en busca de patrones de inyección antes de procesarlo:

Conclusión

El indirect prompt injection representa una evolución significativa en las amenazas de seguridad para LLMs. Lo que lo hace particularmente peligroso es su naturaleza indirecta — el atacante nunca interactúa directamente con el LLM, haciendo que las defensas tradicionales sean menos efectivas.

La combinación de acceso a funciones poderosas y procesamiento de contenido no confiable crea una vulnerabilidad seria que puede llevar a que se realicen acciones no autorizadas en nombre de los usuarios.

A medida que los LLMs continúan siendo integrados en aplicaciones con privilegios crecientes y acceso a fuentes de datos externas, los desarrolladores deben estar atentos a estos posibles vectores de ataque. Los límites de seguridad adecuados, la sanitización de entrada y el principio de menor privilegio son salvaguardas esenciales.

Si te interesa explorar más conceptos de seguridad en LLMs, te recomiendo visitar la Web Security Academy de PortSwigger, que ofrece varios laboratorios sobre prompt injection y otros temas de seguridad de IA.

Recordá: cuando se trata de seguridad en IA, el contexto lo es todo — y el indirect prompt injection muestra lo frágil que puede ser ese contexto.

Apéndice Técnico: La Mecánica del LLM Prompt Injection

Para entender realmente por qué funciona el indirect prompt injection, necesitamos reconocer que los LLMs procesan texto de manera diferente a los parsers tradicionales:

1. Ventanas de Contexto vs Parsing Tradicional: Los LLMs observan todo el texto en su ventana de contexto como potenciales instrucciones o información. A diferencia de un JSON parser que aplica estrictamente la sintaxis, los LLMs operan con lenguaje natural y hacen interpretaciones de "mejor esfuerzo".

2. El Formato del Prompt Importa: La mayoría de los LLMs están entrenados con convenciones de formato específicas. Por ejemplo, podrían reconocer patrones como:

   Los atacantes explotan esto intentando inyectar contenido que coincida con estos patrones de entrenamiento.

3. Comprensión Semántica vs Parsing Sintáctico: Los parsers tradicionales funcionan a nivel de sintaxis. Los LLMs funcionan a nivel semántico, intentando entender el "significado" del texto, lo que hace que la sanitización de entrada tradicional (como escapear comillas) sea inefectiva.

Entender estas diferencias fundamentales es clave para desarrollar salvaguardas efectivas contra el indirect prompt injection.

Recordá: cuando se trata de seguridad en IA, el contexto lo es todo — y el indirect prompt injection muestra lo frágil que puede ser ese contexto.

Información del Artículo

Este artículo es parte de nuestra serie sobre vulnerabilidades de seguridad en IA. Está diseñado para leerse en unos 10-15 minutos y ofrece un walkthrough práctico de ataques de indirect prompt injection usando el desafío de laboratorio de PortSwigger.

Puntos Clave

• Entender la diferencia entre direct e indirect prompt injection
• Cómo los atacantes pueden manipular LLMs a través de comandos ocultos en contenido externo
• Implicaciones del mundo real de las vulnerabilidades de indirect prompt injection
• Pasos prácticos para explotar y defenderse contra estos ataques

Prerrequisitos

• Comprensión básica de los LLMs y sus capacidades
• Familiaridad con conceptos de seguridad web
• Acceso a la Web Security Academy de PortSwigger (cuenta gratuita)

Lo Que Vas a Aprender

1. Cómo el indirect prompt injection difiere de los ataques de inyección tradicionales
2. El flujo de ataque y la metodología para explotar estas vulnerabilidades
3. Ejemplos e implicaciones del mundo real
4. Mejores prácticas para defenderse contra el indirect prompt injection