Inyección de código en LLMs

La code injection está emergiendo como uno de los riesgos de seguridad más críticos en los sistemas impulsados por IA, especialmente cuando los grandes modelos de lenguaje (LLMs) se conectan con bases de datos, APIs o entornos de scripting. A medida que las empresas dependen cada vez más de los LLMs para automatizar consultas, generar código u orquestar tareas del sistema, la superficie de ataque se expande, convirtiendo las entradas de los prompts en posibles vectores de explotación.

En este post desglosamos cómo funciona la code injection en el contexto de la IA, en qué se diferencia de la prompt injection y qué defensas puedes implementar para proteger tu stack. Si también estás explorando buenas prácticas de seguridad para LLMs o comparando AI gateways frente a API gateways tradicionales, esta guía te ayudará a profundizar en las vulnerabilidades específicas de la IA.

¿Qué es la Code Injection?

La code injection es una forma de explotación de seguridad en la que un atacante engaña a una aplicación para que ejecute comandos o consultas no previstos. Tradicionalmente, la code injection se ha estudiado en el contexto de las aplicaciones web (p. ej. SQL injection, shell command injection), donde entradas mal saneadas conducen a la ejecución de código no confiable.

En los sistemas basados en LLM, vemos una nueva variante de esta amenaza. Un LLM puede generar o ejecutar una consulta SQL, una llamada a una API o un script a partir de un prompt del usuario. Si la entrada del usuario es maliciosa, podría manipular esas llamadas externas, derivando en la ejecución de comandos o consultas dañinas, acceso no autorizado a datos, ejecución remota de código o escalada de privilegios.

Code Injection vs. Prompt Injection

Aunque están relacionadas, la "prompt injection" normalmente consiste en engañar al LLM para que devuelva un texto concreto o ignore las restricciones impuestas por el desarrollador. La code injection va un paso más allá: el objetivo del adversario no es solo manipular el texto, sino ejecutar comandos o consultas maliciosas dentro del contexto más amplio de la aplicación.

Cómo afecta la Code Injection a los LLMs y a los agentes

Los LLMs y los agentes de IA autónomos juegan un papel clave en las aplicaciones modernas, actuando como intermediarios entre las entradas del usuario y las operaciones del sistema. Estos agentes suelen generar código o contenido dinámico que es ejecutado por otros subsistemas, lo que los convierte en objetivos prioritarios para ataques de inyección que aprovechan su capacidad de interactuar con bases de datos, APIs y comandos del sistema. A continuación se enumeran escenarios habituales en los que la code injection se vuelve peligrosa:

• Interpretación directa de código por el LLM
  Algunos entornos basados en LLM permiten a los usuarios ejecutar código que el modelo ha generado. Si un atacante consigue incrustar scripts maliciosos en la salida del LLM, esos scripts podrían ejecutarse sin una revisión adecuada.
• Pasar parámetros maliciosos a consultas de base de datos
  A veces los desarrolladores se apoyan en LLMs para construir consultas SQL o NoSQL a partir de instrucciones en lenguaje natural. Un atacante podría redactar una entrada que fuerce al LLM a construir consultas que contengan DROP TABLE u otros comandos destructivos.
• Llamadas a APIs o comandos del sistema
  Los sistemas pueden permitir que el LLM llame a endpoints de APIs. Los atacantes pueden abusar de esto inyectando parámetros, rutas o payloads adicionales, lo que provoca comportamientos no deseados. De forma similar, cuando los LLMs generan comandos shell, es posible inyectar flags o argumentos hostiles.
• Inyecciones fuera del prompt
  No siempre es el prompt el que transporta inyecciones de código maliciosas. Las cabeceras HTTP, los parámetros de consulta, las variables de entorno o los campos de un formulario pueden contener cadenas de inyección que acaban dando forma a las acciones del LLM cuando interactúa con bases de datos, APIs o comandos del sistema. Esto es especialmente relevante cuando la aplicación fusiona estos valores en una única cadena de contexto para el LLM.

Cómo funcionan los ataques de Code Injection

Los atacantes suelen apoyarse en dos ingredientes para la code injection: un "punto de entrada" vulnerable y un sistema que ejecute o interprete el código inyectado. En un escenario con LLM:

1. Explotar la interfaz de lenguaje natural del LLM
   El atacante proporciona una entrada que parece texto legítimo, pero está diseñada para producir un payload malicioso cuando el LLM ejecuta consultas o comandos.

2. Encadenamiento de vulnerabilidades
   Los LLMs rara vez operan de forma aislada. La code injection se vuelve posible cuando la salida del LLM es aceptada al pie de la letra por otro componente, como una capa de base de datos, una shell o una API de terceros. Si el sistema no sanea ni valida la salida del LLM, el atacante puede escalar privilegios o ejecutar código arbitrario.

3. Rutas de ejecución inseguras

   La code injection a menudo nace de confiar en exceso en las salidas del LLM. Cuando los desarrolladores conectan LLMs directamente a entornos de ejecución como intérpretes, pipelines de CI o clientes de API sin introducir puertas de revisión o validación, crean sin querer superficies de ataque.

Tipos de ataques de Code Injection

Los ataques de code injection adoptan distintas formas, cada una orientada a componentes diferentes de un sistema basado en LLM. Estos ataques explotan vulnerabilidades en cómo los modelos generan, interpretan o ejecutan código, dando lugar a consecuencias no deseadas como acceso no autorizado a datos, manipulación del sistema o ejecución remota de código (RCE). A continuación describimos los tipos más comunes de ataques de code injection y su impacto potencial sobre las aplicaciones LLM.

1. SQL Injection y NoSQL Injection
   Los atacantes incrustan sentencias maliciosas como "DROP TABLE users;" en el texto. Cuando el LLM construye una cadena de consulta a partir de la entrada del usuario, podría insertar estas sentencias directamente en un comando SQL ejecutable.

2. Shell Command Injection
   Si el LLM tiene la capacidad de emitir comandos shell, se pueden inyectar caracteres especiales (p. ej. |, &&, ;) para ejecutar múltiples comandos o escalar privilegios.

3. API Parameter Injection
   Un atacante puede manipular URLs de API, métodos HTTP o parámetros JSON. Por ejemplo, podría incluir segmentos de ruta adicionales o sobrescribir parámetros por defecto con valores maliciosos.

4. Scripting Language Injection
   Cuando un LLM se utiliza para escribir o ejecutar scripts (Python, JavaScript, Ruby), los atacantes pueden incrustar funciones dañinas, lógica de exfiltración de datos o llamadas al sistema dentro de cuerpos de función generados por el usuario.

5. Inyección basada en cabeceras o metadatos
   Los atacantes colocan código o instrucciones maliciosas en cabeceras HTTP, cookies o campos de metadatos que la aplicación fusiona en un único prompt o contexto. El LLM integra ciegamente estos campos dentro del código o la consulta generada.

Cómo proteger los LLMs frente a la Code Injection

Prevenir la code injection en sistemas impulsados por LLM requiere un enfoque por capas. Ningún control único es suficiente: los desarrolladores deben combinar sanitización de entradas, hardening del prompt, aislamiento de entorno y monitorización en runtime. Centralizar estas protecciones en un LLM gateway es una forma de desplegar un sistema de defensa multicapa y escalable.

• Detección de code injection a nivel de prompt

  Utiliza modelos de lenguaje dedicados para analizar los prompts en busca de indicios de instrucciones de código maliciosas o fuera de contexto. Estos modelos de detección pueden identificar inyecciones de código sospechosas u ocultas dentro de los prompts.

• Filtrado de inyecciones a nivel de aplicación

  Despliega sistemas de detección de inyecciones en la capa de aplicación para escanear cabeceras HTTP, parámetros de petición y payloads en busca de patrones de inyección conocidos. Esto evita el envenenamiento del contexto upstream que puede afectar a la interpretación o la toma de decisiones del LLM, incluso si el propio prompt parece benigno.

• Sanitización de código

  Bloquea por completo las entradas de código en los prompts para casos de uso que no requieran interpretación o ejecución de código. Si es necesario que el usuario proporcione código, sanitízalo y escápalo para evitar que los componentes downstream lo interpreten como ejecutable. Esto es especialmente importante en aplicaciones donde las salidas del LLM se pasan automáticamente a intérpretes, scripts u otros sistemas.

• Diseño de prompt y aislamiento contextual

  Las instrucciones del usuario deben aislarse de la lógica del sistema para evitar comportamientos no deseados. Mezclar la entrada bruta del usuario con comandos o consultas sin validación abre la puerta a inyecciones. Alternativas más seguras, como las parameterized queries o el uso de plantillas, ayudan a mitigar este riesgo.

• Red Teaming

  Ejecuta pruebas adversariales continuas sobre tus endpoints de LLMs y agentes para encontrar vulnerabilidades de inyección antes que los atacantes, e identifica dónde podrían derivar las code injections en ejecuciones inseguras.

• Monitorización y detección de anomalías

Registra todos los prompts y todas las interacciones entre usuario y LLM, y configura un sistema de alertas en tiempo real que busque patrones maliciosos o inusuales, como sentencias de código repetidas.

Conclusión

La code injection es un riesgo importante en las aplicaciones impulsadas por IA, especialmente cuando los modelos LLM interactúan con sistemas externos como bases de datos SQL, APIs e intérpretes de código. Una combinación de mecanismos defensivos como los LLM gateways y de estrategias ofensivas como el red teaming, respaldados por buenas prácticas de desarrollo como la sanitización de entradas, puede eliminar las vulnerabilidades de code injection en tus aplicaciones LLM.