Comprensión del problema del suplente confuso
El “problema del suplente confuso” sirve como ejemplo clásico para explicar la escalada de privilegios en el contexto de la ciberseguridad. Se refiere a una situación en la que un programa, al que llamaremos “suplente”, tiene ciertos permisos que son explotados por un actor malicioso, que hace que el programa bien intencionado actúe en nombre del atacante. Aunque originalmente se diseñó para realizar funciones legítimas, este programa se “confunde” cuando se le engaña para que haga un mal uso de sus privilegios, lo que le lleva a realizar acciones no autorizadas.
La relevancia para los modelos de lenguaje grandes
Al considerar los modelos de lenguaje grandes (LLM) desde esta perspectiva, se puede comenzar a ver cómo podrían actuar como suplentes confusos. Cuando se le otorgan privilegios excesivos, un LLM podría convertirse, sin darse cuenta, en una herramienta para ejecutar comandos o decisiones de control de acceso que beneficien a un atacante. Este riesgo resalta la importancia de administrar cuidadosamente los privilegios asignados a los LLM para garantizar que operen dentro de un entorno seguro y controlado.
Los peligros del manejo inseguro de la salida
Luego de haber explorado el problema del suplente confuso, examinaremos ahora la gestión insegura de salidas en los modelos de lenguaje (LLM). En la tercera entrega de nuestra serie sobre el Top 10 para aplicaciones LLM de OWASP, abordamos el imperativo de proporcionar protección contra el uso indebido de las salidas de los LLM. Dado que el contenido que generan los LLM se basa en indicaciones de los usuarios, les proporciona a estos una forma de acceso indirecto a las funciones subyacentes. Si no se validan y desinfectan de manera adecuada, estas salidas pueden convertirse en una puerta abierta para una variedad de ataques, como XSS y CSRF, o ataques más críticos dirigidos a sistemas backend, como la ejecución remota de código y la escalada de privilegios.
Análisis de los riesgos de seguridad con ejemplos del mundo real
- El ingreso directo de salidas generadas por LLM en comandos o funciones del sistema como “exec” o “eval” puede provocar la ejecución no autorizada de código de forma remota. Para que te resulte más claro, imagina una situación en la que se utiliza un LLM como asistente de codificación. Un usuario desprevenido podría solicitar un fragmento de código para realizar una tarea. Si la respuesta del LLM incluye comandos a nivel de sistema y el usuario, sin saberlo, los ingresa en su línea de comando o script, podría desencadenar acciones que comprometan su sistema.
- Creación de JavaScript o Markdown por parte del LLM que, cuando se envía de vuelta al usuario, puede ser ejecutado por el navegador, lo que podría causar ataques de Cross-Site Scripting (XSS). Considera un escenario en el que un usuario le pide ayuda al LLM con las tareas de desarrollo de aplicaciones web. El LLM cumple con lo solicitado y crea un fragmento de JavaScript o Markdown. Si este código contiene scripts maliciosos y el usuario lo incorpora a su aplicación web, podría ser ejecutado por los navegadores de otros usuarios, lo que provocaría una violación de la seguridad. Esto también puede generar interacciones inesperadas, como el robo de cookies o tokens de sesión o incluso la desfiguración de sitios web.
- Cuando los plugins de terceros escatiman en la validación de entradas, dejan la puerta abierta a problemas de seguridad. Por ejemplo, considera un plugin que formatea los comentarios de los usuarios en un foro. Si un LLM proporciona una respuesta que contiene código ejecutable y el complemento no elimina el código, podría publicarse. Una vez en el foro, este código podría ejecutarse cuando otros lo lean y, potencialmente, robar información o corromper datos, lo que demuestra que dichos plugins deben desinfectar rigurosamente las entradas para evitar violaciones de seguridad.
El siguiente diagrama proporciona una guía de las formas en que un atacante podría aprovechar esta vulnerabilidad específica dentro del funcionamiento de una aplicación empresarial. Presta atención a “LLM02: manejo inseguro de la salida”, que está resaltado en el diagrama.
Medidas proactivas y mejores prácticas
- Aborda cada interacción con el modelo con escepticismo, empleando una política de confianza cero que presuponga que ningún usuario, sistema o proceso, incluido el modelo, es intrínsecamente seguro. Examina todas las salidas del modelo con procesos de validación exhaustivos para detectar y neutralizar de forma preventiva los riesgos de seguridad antes de que alcancen cualquier función del sistema.
- El Estándar de verificación de seguridad de aplicaciones (ASVS) de OWASP es un conjunto de benchmarks de seguridad diseñados para fortalecer el software dictando las mejores prácticas de validación y desinfección de entradas. Consulta estas pautas para codificar las salidas de modelos, lo cual es crucial para proporcionar protección contra la ejecución no deseada de JavaScript o Markdown por parte de los navegadores de los usuarios. El ASVS proporciona estrategias integrales de codificación, lo que garantiza que los datos devueltos a los usuarios no solo sean funcionales, sino también seguros.
Resumen y próximos artículos
Al explorar el “problema del suplente confuso” y el manejo inseguro de la salida en los LLM, destacamos la necesidad de permisos controlados y una gestión diligente de la salida para evitar acciones no autorizadas. Con ejemplos prácticos, ilustramos cómo los LLM podrían convertirse en armas si no se protegen de manera adecuada.
Luego de haber abordado dos vulnerabilidades de OWASP en esta serie sobre seguridad de las aplicaciones LLM, nuestros próximos artículos continuarán este discurso vital, en los que analizaremos las vulnerabilidades restantes y cómo fortalecer nuestras defensas cibernéticas. Mantente atento a la próxima entrega de nuestra serie en la que abordaremos los problemas de ciberseguridad en las aplicaciones LLM.
