News
📅 Conoce a NeuralTrust en OWASP: Global AppSec - 29-30 mayo
Iniciar sesiónObtener demo
Volver

Inyección de código en LLMs

Inyección de código en LLMs Joan Vendrell 26 de marzo de 2025
Contents

La inyección de código está emergiendo como uno de los riesgos de seguridad más críticos en los sistemas impulsados por IA, particularmente cuando los modelos grandes de lenguaje (LLMs) se conectan a 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 prompt en vectores potenciales de explotación.

En esta publicación, desglosamos cómo funciona la inyección de código en el contexto de la IA, cómo difiere de la inyección de prompts y qué defensas puedes implementar para proteger tu stack. Si también estás explorando las mejores prácticas de seguridad para LLMs o comparando gateways de IA vs. gateways de API tradicionales, nuestro blog te ayudará a profundizar tu comprensión de las vulnerabilidades nativas de la IA.

¿Qué Es la Inyección de Código?

La inyección de código es una forma de explotación de seguridad donde un atacante engaña a una aplicación para que ejecute comandos o consultas no deseadas. Tradicionalmente, la inyección de código se ha estudiado en el contexto de aplicaciones web (ej., inyección SQL, inyección de comandos shell) donde entradas incorrectamente sanitizadas conducen a la ejecución de código no confiable.

En sistemas basados en LLMs, vemos una nueva variante de esta amenaza. Un LLM podría generar o ejecutar una consulta SQL, una llamada API o un script basado en un prompt del usuario. Si la entrada del usuario es maliciosa, podría manipular tales llamadas a sistemas externos, resultando en la ejecución de comandos o consultas dañinas, acceso no autorizado a datos, ejecución remota de código (RCE) o escalada de privilegios.

Inyección de Código vs. Inyección de Prompts

Aunque están relacionadas, la "inyección de prompts" típicamente implica engañar a un LLM para que devuelva texto específico o ignore restricciones impuestas por el desarrollador. La inyección de código va un paso más allá: el objetivo del adversario no es solo manipular texto, sino ejecutar comandos o consultas maliciosas dentro del contexto más amplio de la aplicación.



Cómo Afecta la Inyección de Código a los LLMs y Agentes

Los LLMs y los agentes de IA autónomos juegan un papel fundamental en las aplicaciones modernas, actuando como intermediarios entre las entradas del usuario y las operaciones del sistema. Estos agentes a menudo generan código o contenido dinámico que es ejecutado por otros subsistemas, convirtiéndolos en objetivos principales para ataques de inyección que explotan su capacidad para interactuar con bases de datos, APIs y comandos del sistema. A continuación, se presentan escenarios comunes en los que la inyección de código se vuelve peligrosa:

  • Interpretación Directa de Código por LLMs: Algunos entornos basados en LLMs permiten a los usuarios ejecutar código que el modelo ha generado. Si un atacante puede incrustar scripts maliciosos en la salida del LLM, estos scripts podrían ejecutarse sin una revisión adecuada.
  • Paso de Parámetros Maliciosos a Consultas de Bases de Datos: Los desarrolladores a veces confían en los LLMs para construir consultas SQL o NoSQL a partir de instrucciones en lenguaje natural. Un atacante podría crear una entrada que obligue al LLM a construir consultas que contengan
    Copied!
    1DROP TABLE
    u otros comandos destructivos.
  • Llamadas API o Comandos del Sistema: Los sistemas pueden permitir que el LLM llame a endpoints de API. Los atacantes pueden abusar de esto inyectando parámetros, rutas o payloads adicionales, lo que lleva a un comportamiento no deseado. De manera similar, cuando los LLMs generan comandos shell, es posible la inyección de flags o argumentos hostiles.
  • Inyecciones No Provenientes del Prompt: No siempre es el prompt el que transporta las inyecciones de código malicioso. Cabeceras HTTP, parámetros de consulta, variables de entorno o campos de formulario pueden contener cadenas de inyección que finalmente dan forma a las acciones del LLM al interactuar con bases de datos, APIs y 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 Inyección de Código

Los atacantes generalmente dependen de dos ingredientes para la inyección de código: un "punto de entrada" vulnerable y un sistema que ejecutará o interpretará el código inyectado. En un escenario de LLM:

1. Explotando 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 inyección de código se vuelve posible cuando la salida del LLM es aceptada sin cuestionar por otro componente como una capa de base de datos, un shell o una API de terceros. Si el sistema no sanitiza o valida la salida del LLM, el atacante puede escalar privilegios o ejecutar código arbitrario. 3. Rutas de Ejecución Inseguras La inyección de código a menudo se deriva de confiar excesivamente en las salidas del LLM. Cuando los desarrolladores conectan LLMs directamente a entornos de ejecución como intérpretes, pipelines de CI o clientes API sin introducir puertas de revisión o validación, crean inadvertidamente superficies de ataque.

Tipos de Ataques de Inyección de Código

Los ataques de inyección de código vienen en varias formas, cada uno dirigido a diferentes componentes de un sistema basado en LLM. Estos ataques explotan vulnerabilidades en la forma en que los modelos generan, interpretan o ejecutan código, lo que lleva 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 inyección de código y su impacto potencial en las aplicaciones LLM.

Inyección SQL e Inyección NoSQL

Los atacantes inyectan sentencias SQL o NoSQL maliciosas como

Copied!
1DROP TABLE users;
o
Copied!
1$ne: null
en los prompts del usuario. Si el LLM es responsable de construir consultas a la base de datos, puede pasar inadvertidamente estas sentencias a la base de datos sin sanitización. Esto puede provocar fugas de datos, eliminación de tablas o acceso no autorizado a registros restringidos, especialmente cuando los desarrolladores confían en la generación de consultas a partir de lenguaje natural.

Inyección de Comandos Shell

Cuando las salidas del LLM se interpretan como comandos shell o scripts, los atacantes pueden incrustar caracteres especiales como

Copied!
1|
,
Copied!
1&&
, o
Copied!
1;
para encadenar comandos no autorizados. Esto podría permitir desde listar archivos sensibles hasta iniciar un reverse shell, dependiendo de los privilegios del entorno de ejecución subyacente. Este tipo de inyección es particularmente peligroso en asistentes DevOps o sistemas basados en agentes que automatizan tareas de línea de comandos.

Inyección de Parámetros API

Si un LLM genera o manipula llamadas API, los atacantes pueden crear prompts que alteren las URLs de los endpoints, modifiquen los métodos HTTP o inserten parámetros maliciosos. Por ejemplo, agregar

Copied!
1?admin=true
o inyectar payloads maliciosos en cuerpos JSON puede llevar a escalada de privilegios, manipulación de datos o incluso condiciones de denegación de servicio. Cuando los LLMs están conectados a sistemas del mundo real, estos ataques pueden desencadenar comportamientos destructivos o no autorizados.

Inyección de Lenguaje de Scripting

Los LLMs a menudo generan código en lenguajes como Python o JavaScript para su uso en componentes posteriores. Los atacantes pueden abusar de esta capacidad incrustando lógica maliciosa en funciones, como bucles infinitos, scripts de exfiltración de datos o llamadas a

Copied!
1os.system()
. Si el código se ejecuta sin revisión humana, esto abre la puerta a la manipulación no intencionada del sistema y posibles vulnerabilidades de RCE.

Inyección Basada en Cabeceras o Metadatos

El código malicioso también puede ocultarse en fuentes de entrada que no son prompts, como cabeceras HTTP, cookies, parámetros de consulta o campos de metadatos. Si estas entradas se fusionan en el contexto pasado al LLM, el modelo puede generar sin saberlo una salida que refleje o ejecute el payload malicioso. Esto es especialmente peligroso en sistemas multimodales donde el contexto del usuario se construye a partir de diversas fuentes dinámicas.

Cómo Proteger los LLMs Contra la Inyección de Código

Prevenir la inyección de código en sistemas impulsados por LLMs requiere un enfoque por capas. Ningún control único es suficiente: los desarrolladores deben combinar sanitización de entradas, endurecimiento de prompts, aislamiento del entorno y monitorización en tiempo de ejecución. Centralizar estas protecciones en un LLM gateway es una forma de desplegar un sistema de defensa multicapa y escalable.

  • Detección de Inyección de Código a Nivel de Prompt: Usa modelos de lenguaje dedicados para analizar los prompts en busca de signos 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 Inyección 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 solicitud y payloads en busca de patrones de inyección conocidos. Esto previene el envenenamiento de contexto (context poisoning) aguas arriba que pueda afectar la interpretación o toma de decisiones del LLM, incluso si el prompt en sí parece benigno.

  • Sanitización de Código: Bloquea completamente las entradas de código en los prompts para casos de uso que no requieren interpretación o ejecución de código. Si el código proporcionado por el usuario es necesario, sanitízalo y escápalo para evitar que los componentes posteriores lo malinterpreten 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 Prompts y Aislamiento Contextual: Las instrucciones del usuario deben aislarse de la lógica del sistema para prevenir comportamientos no deseados. Fusionar la entrada bruta del usuario con comandos o consultas sin validación abre la puerta a la inyección. Alternativas más seguras como consultas parametrizadas o templating ayudan a mitigar este riesgo.

  • Red Teaming: Ejecuta pruebas adversarias continuas en tus endpoints de LLM y agentes para encontrar vulnerabilidades de inyección antes que los atacantes, e identificar dónde las inyecciones de código podrían llevar a una ejecución insegura.

  • Monitorización y Detección de Anomalías: Registra todos los prompts e interacciones entre el usuario y el 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 inyección de código 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 LLM gateways y estrategias ofensivas como el red teaming, respaldadas por buenas prácticas de desarrollo como la sanitización de entradas, puede eliminar las vulnerabilidades de inyección de código en tus aplicaciones LLM.


Posts relacionados

Ver todo