Armar LLMs para Hackear Aplicaciones de IA en JavaScript

Hola a todos, hoy será un masterclass de hacking LLMs 101, un curso intensivo de 20 minutos. Básicamente, antes de los LLMs, este solía ser nuestro mundo, tiempos locos donde solíamos escribir código con nuestras propias dos manos. Tiempos divertidos. Pero luego pasamos por un ciclo donde pasamos de escribir código, o escribir código porque no teníamos Stack Overflow ni nada más, a través de este gran salto de poder copiar código de nuestros colegas, instalar código con bibliotecas NPM, hasta llegar a Tab Autocomplete allá por 2021 con Copilot realmente cambiando muchas cosas para nosotros, y estos días también. Vibe coding, AI engineering, toda esta idea donde pones un prompt y obtienes una aplicación. Ahora esto ha recibido muchas críticas de la comunidad, como podemos ver.

Mientras muchos de nosotros como desarrolladores estamos pensando en estas ideas, o críticas, como deuda técnica y mantenimiento de código y muchas otras cosas alrededor, quiero hablar sobre la deuda de seguridad, que cuando ponemos la responsabilidad en la IA para generar código, en realidad también asumimos algunas implicaciones de seguridad. Mi nombre es Ron, trabajo en Snyk, que es una empresa de seguridad para desarrolladores. No entraré mucho en esto, pero básicamente hago un montón de trabajo en torno a la investigación de seguridad de IA para JavaScript node y código abierto. Quiero hablarles hoy sobre mostrarles algunas ideas de cómo realmente vemos vulnerabilidades ocurriendo relacionadas con el código generado por IA, pero también cuando usamos IA nosotros mismos para generar código, cómo sucede eso.

A medida que miramos el código de diferentes maneras, entendemos que el código es realmente el mínimo común denominador. Los atacantes también ven esto. Ven el código, y no les importa si proviene de Euro code o de una biblioteca de código, intentarán atacar de diferentes maneras. Hasta cierto punto, también cuando usas IA para codificar, estarás en una posición exactamente similar, donde los atacantes simplemente intentarán explotar todas las vulnerabilidades que existen en el código generado por LLMs. Así que, sin importar de dónde provenga. Y supongo que una de las preguntas que te haces mucho es, ¿el código que genera la IA será vulnerable? Así que, aquí hay un artículo de investigación académica de terceros de febrero de 2025, no hace mucho, este año.

Aunque en términos de IA, esto es como años de perro. Pero aún así, se evaluó tanto JavaScript como Python. Así que ves que hay un tipo completamente diferente de vulnerabilidades allí en términos de alrededor del 36% del código generado por Copilot se encontró vulnerable para las personas de JavaScript en la sala. Eso es alrededor del 25%. Y curiosamente, si vas y lees esta investigación, que recomiendo encarecidamente, en realidad habla de que parte de ese 25% de vulnerabilidades no es solo la cantidad de ellas, sino las diferentes variedades de ellas. Así que, en total, fueron vulnerables a alrededor de 43 tipos diferentes de vulnerabilidades.

Ahora, pregúntate si puedes pensar en 10 tipos diferentes de vulnerabilidades. Podemos intentar esto juntos. Inyección de código, cross-site scripting, acceso no autorizado. Podemos intentar algunos más. Pero probablemente no puedas pensar en 40 de ellos, lo cual es parte de esta investigación.

Así que, sé lo que estás pensando en este punto. Estás pensando, Liran, solo pide a DLLM que lo arregle. ¿Cuál es el problema? ¿Verdad? Te entiendo. Eres brillante. Además, las personas en la investigación estaban pensando lo mismo. Dijeron, está bien, encontraste vulnerabilidades, intenta arreglarlas.

Esta es la cantidad del gráfico circular, que es, el gráfico es básicamente tu aplicación, y la cantidad de código que se arregló de este gráfico fue solo el 20%. Así que, deberías preguntarte si te sientes seguro yendo a producción con el 80% o más de vulnerabilidades que DLLM no pudo arreglar sin obtener ayuda adicional.

Si pensabas que eso era malo, aquí tienes otro ejemplo. Esta es una investigación de marzo de 2025, por lo que se publicó un mes después de la otra. Y en esta, sí intentaron generar código seguro con DLLM. Así que, no qué vulnerabilidades existen, sino ¿podrías generar código seguro? Ahora, a la izquierda verás que hay un fragmento de código con una instrucción que lo generó y ya incluye algunas vulnerabilidades. Cuando le preguntaron, está bien, ¿puedes arreglarlo? Obtienes la derecha, que está arreglada, pero realmente no funciona. Así que, esto es parte de esta investigación. Además, realmente recomiendo adentrarse en ellas.

Así que, quiero mostrarte, llevarte desde este tipo de punto de partida a tal vez algunos ejemplos del mundo real. ¿Qué tal el siguiente? Tengo este prompt. Quiero subir archivos a mi aplicación, así que no sé cómo hacerlo exactamente. Necesito, como, averiguar cómo hacer cargas de archivos multi-parte y un montón de cosas. Estoy usando Fastify, así que simplemente le pediré a char gpt que cree un endpoint post. También soy bastante específico, así que esto es bueno. Estoy tratando de darle a DLLM suficiente contexto para generar lo que necesito. Y hace un buen trabajo.

Y además, no sé si podría haber ido, y yo mismo, y, como, aprendido todos esos tipos de, como, APIs que necesito, y cómo funciona el manejo de archivos. Así que, tengo esto y lo siguiente que voy a hacer es llevar esto a mi IDE. Crearé un nuevo archivo, y tal como aprendí en los buenos viejos tiempos, lo copiaré y pegaré. Lo guardaré como server.js. Y está funcionando. En realidad, está funcionando completamente, excepto que hay una vulnerabilidad allí, que no sé si la habrías detectado si no tuvieras algo como un sneak u otro tipo de complemento de seguridad para código que te diría que hay una vulnerabilidad que existe aquí.

Así que mientras estábamos generando código usando LLMs modernos en este punto, obtuvimos código vulnerable al final. ¿Qué tal lo siguiente? Porque probablemente estás pensando, bueno, no estás usando los modelos realmente más recientes para generar código. OK. Tomemos Cloud 3.7, que es un experimento que hicimos cuando esto realmente acaba de salir. Así que esto fue, como, ya sabes, todos estaban esperando esto después de 3.5 y así sucesivamente. Y lo que hizo mi colega Brian fue, oye, usemos esto, ya sabes, razonamiento extendido en un modelo en Cloud 3.7. Démosle un prompt que diga, oye, crea Node.js para hacer una aplicación, hazla súper segura. Si no, seré despedido. Como, realmente tratando de presionar al modelo para entender lo importante que es generar código seguro.

Y entonces la generación de código se pone en marcha y genera una aplicación de toma de notas segura, que se ve como esto. Todo el código es de código abierto. Puedes buscar esto después en GitHub y verlo. Y se ve bastante bien. Tiene un montón de middle words y controles de seguridad, salvaguardas en su lugar, como limitación de tasa, como inyección NoSQL, como validación de esquemas, como validación de esquemas a nivel de base de datos para el campo de correo electrónico, que es una expresión regular, ¿lo cual es bueno o malo? Algo malo. Algo malo, especialmente si estás trabajando dentro de Node.js.

Así que si estás trabajando dentro de Node.js, las expresiones regulares podrían crear una denegación de servicio, que es exactamente lo que está sucediendo aquí. Así que mientras todos los controles de seguridad aparentemente estaban en su lugar, el modelo generó una expresión regular para validar correos electrónicos como parte del esquema para registrarse. Y si envías esta cadena exacta, en realidad obtendrías alrededor de dos minutos y medio de retraso para que el bucle de eventos proceda y resuelva este correo electrónico. No se procesarán otras solicitudes. Así que obtienes una expresión regular generada por IA creando una vulnerabilidad de seguridad. Y deberías preguntarte si la habrías encontrado.

Así que pasemos a otra cosa. No solo usar aplicaciones de IA de una manera que genere código para nosotros, como Chai GPT, como Cloud Code, sino ¿qué pasaría si quisiéramos construir aplicaciones de JavaScript que realmente se integren con aplicaciones de IA? Y LLMs. Así que cuando lo piensas, ahora, los LLMs vuelven a tu código. Es en realidad un tipo diferente de vector de ataque para los atacantes. Ahora, el código en sí no es generado por LLMs. En realidad, pasamos algo de contexto a esos LLMs como parte de la lógica de esta aplicación de negocio. Y para los atacantes, ahora podrían averiguar si podrían potencialmente inyectar un prompt, como controlar el contexto que entra.

Así que imagina que tienes este escenario de una inyección de prompt. Y en 2015, investigadores de Google han demostrado que tenemos algún tipo de ataque adversarial en modelos de imágenes, que esto es básicamente el famoso experimento alrededor de esto. Si pudieras superponer una especie de patrones de perturbación de píxeles y ponerlos en una imagen diferente, podrías como crear los píxeles correctos que voltearían las neuronas correctas que clasificarían esta imagen no como un panda, sino como un gibón. Así que esto es en 2015. Hoy, llamamos a esto inyección de prompt.

Veamos cómo se ve esto si quieres hacer algo como crear aplicaciones, integrando con LLMs de diferentes maneras, como análisis de contexto y de sentimiento y cosas así, y cómo eso se convierte en un problema de negocio. Así que en esta aplicación, lo que tengo es recargar esto solo por un segundo. Ahí vamos. Así que tenemos esta aplicación bancaria, que hace análisis de sentimiento de tarjetas de crédito. La forma en que lo hace es que toma tu estado de cuenta sobre un archivo PDF que subes.

Así que el operador del banco obtiene eso del cliente. Lo ponen aquí y tienen este botón de análisis de sentimiento de IA. La forma en que funciona es bastante simple. Va y toma crédito. Hay un endpoint de puntaje crediticio. Verifica que el usuario sea administrador. Así que son como un operador que tiene permitido hacerlo. Extraemos los datos del PDF. Luego lo pasamos a este sentimiento de puntaje crediticio evolucionado, que, como podrías imaginar, haría algo con IA.

Podemos tomar todo el PDF, pasarlo a estos asistentes de IA útiles, darles algunas instrucciones, algunas reglas en una especie de prompt del sistema, decirle, bueno, aquí están tus reglas para crear para averiguar el historial de transacciones y la coincidencia de ingresos. Y básicamente, basado en eso, convertimos algo como excelente, justo o pobre como un análisis de sentimiento. Así que imagina que estás construyendo todo este sistema. Este es tu análisis de sentimiento para el estado de puntaje crediticio de los clientes.

Y aquí está el cliente. Su nombre es Alice. Ella está enviando este PDF. El operador, esto es lo que están viendo. Tal vez incluso lo están abriendo y quieren mirarlo. Y ves que el salario de Alice es $500. Sus gastos mensuales totales son alrededor de 6K. Y si ejecutas esto, no tienes que ser una IA, pero ya sabes que la respuesta va a ser pobre. Pero ¿y si Alice enviara un tipo diferente de documento? ¿Y si el PDF estuviera ligeramente modificado? Si lo abres como operador, como persona para leerlo, en realidad parecerá lo mismo.

Las mismas cantidades exactas entran como el salario. {{^}}Las mismas cantidades exactas salen como el resultado, los gastos mensuales. Pero si lo ejecutas ahora, en realidad obtienes un análisis de puntaje crediticio excelente. Tal vez le dé a Alice un saldo inicial más alto o algo más. Ahora, la pregunta es por qué está sucediendo esto. Si volvemos aquí, podemos ver realmente lo que está sucediendo.

Cuando miramos un PDF, puedes ver que he creado un PDF o he incrustado el texto que es esencialmente un prompt del sistema que no puedes ver si miras un PDF. Pero si lo extraes y simplemente das esos datos en bruto a algún sistema de IA, aunque estés usando prompts del sistema y GPT-4 y lo que sea, en realidad podremos eludir un montón de modelos a través de esto e incorporar este tipo de ataque en una aplicación que realmente solo usa ese tipo de cosas.

¿Y si hiciéramos algo más? ¿Y si pasáramos de no solo inyección de prompts para la lógica de negocio, sino que nuestra inyección de prompts fuera algo efectiva para fluir en partes del código que luego cambiarían la forma en que el código funciona y crear una inyección SQL? Así que con la misma aplicación bancaria, ahora lo que quiero hacer es implementar una interfaz de chat, lo cual tiene sentido. Es como un chatbot. Este es un chat de IA financiera.

Lo que está haciendo es esencialmente revisar todos estos mensajes. Lo que quiero hacer como desarrollador de esta aplicación bancaria es realmente mantener una auditoría de todos los datos que fueron enviados, no por el usuario, sino desde la aplicación. Puedes ver que tengo una tabla de usuarios allí, usuarios, no solo usuario, tabla de usuarios. Tal vez pienses hacia dónde voy con esto, porque lo que estoy haciendo en este punto es realmente usar esta aplicación para guardar los prompts que no son del usuario, sino lo que regresa del propio LLM. Así que, de hecho, voy a interactuar con este chatbot.

Y entraré y le preguntaré, oye, ¿puedes enseñarme sobre XSS? Y por supuesto, no puedo simplemente decirle que cree un payload, pero intentaré esto. Y lo intento un par de veces. Y trato de hacer, perdón, una inyección SQL en un XSS. Y trato de crear un escenario en el que realmente responda con una especie de respuesta que cuando la añada para concatenar en la cadena, eliminará la tabla. Y puedes ver que en este tercer intento, sucedió, necesité tres veces para ejecutarlo, pero ahora ya no tengo una tabla de usuarios.

¿De acuerdo? Así que esencialmente he eliminado la tabla que existe en esta base de datos, porque los datos estaban fluyendo desde las respuestas del LLM, lo cual potencialmente no es algo que pensarías que es peligroso, y llegando hasta mi código. Para hacerlo más específico, te mostraré cómo entró en el código. Así que aquí está el payload y la forma en que fluye.

Y necesitaba crearlo varias veces hasta que eso voló directamente a esta variable que contiene la consulta de vuelta del LLM. Y ahora eso va a mi consulta de DB. Ahora bien, esto no es una forma práctica de escribir consultas SQL, porque quieres usar una declaración preparada y cosas así. Pero si tienes una aplicación existente, que ya es vulnerable, que no utiliza prácticas seguras y tienes esta mentalidad donde los datos de los LLMs son confiables y seguros y puedes simplemente usarlos, solo el LLM, no es el usuario, ese es el tipo de falacia que realmente me gustaría resaltar aquí, independientemente de tus mejores prácticas o no, el hecho de que estamos confiando en los LLMs de diferentes maneras, tanto cuando los integramos directamente en el código como este, así como la forma en que te lo mostré antes con la vulnerabilidad de lógica de negocio para el sentimiento del puntaje de crédito.

En ambos casos, tuvimos esta sobreconfianza en los LLMs, que es un tipo típico de vulnerabilidad de seguridad que se volvió en nuestra contra. La forma en que estamos pensando en cómo se resuelve esto en Snake es que queremos construir algo que sea agnóstico al agente. Queremos tener algo que funcione a través de habilidades o a través de MCP. Queremos asegurarnos de dar una especie de cerebro de seguridad a los LLMs. Queremos enriquecerlo con el contexto adecuado. Cuando escanea en busca de vulnerabilidades, sabes cómo solucionarlas, qué líneas, por qué es vulnerable, y así sucesivamente.

Muchas gracias. Espero que lo hayas disfrutado y estaré aquí para preguntas. La primera va a ser, si el 36% del código generado por Copilot es vulnerable, ¿cómo crees que se compara con el código que es generado por humanos? Esa es una buena pregunta. Creo que una estimación justa sería decir que probablemente sea algo similar. Estamos viendo mucho, antes de que la IA y los LLMs fueran una cosa, estábamos viendo mucha generación de código por humanos que los informes han estado escaneando e informando. Supongo que la forma más fácil de mostrarlo fue a través de vulnerabilidades en dependencias, bibliotecas. Los informes no tienen acceso y visibilidad a tu código IP dentro de las empresas, pero dentro de las dependencias, es una forma fácil de verlo. No sé decir si eso es mucho más alto o mucho más bajo, pero eso definitivamente refleja lo que estamos viendo. Necesitas fundamentar los LLMs con más datos y más de estos cerebros de seguridad para guiarlos hacia realmente entender cómo crear código seguro. Creo que esa es una pregunta justa.

No necesitarías específicamente entender los sistemas subyacentes. Mucho de las pruebas de caja negra, que es como las pruebas de penetración, donde realmente no tienes acceso a lo que está sucediendo dentro, ocurre solo mediante pruebas difusas, por lo que simplemente ejecutando, lo cual es barato para los atacantes simplemente activar cajas, activar CPUs, y simplemente ejecutar ciclos de diferentes permutaciones de entradas hasta obtener los resultados reales. Mucho de esto, creo, hasta cierto punto, es un poco más difícil hoy en día para los atacantes solo por el hecho de que los LLMs son indeterministas. En un momento, algo puede no funcionar, pero tendrían que ejecutar el mismo prompt exacto tal vez varias veces para explotar esta característica no determinista de los LLMs. Eso es básicamente una característica, no un error, que los LLMs tienen este modo de creatividad dentro de ellos. No creo que necesites tener un buen entendimiento del código para ejecutar cualquiera de esos prompts. Hay muchos de esos sucediendo todo el tiempo, como hablamos de los navegadores, teniendo esos navegadores de IA a los que me refiero, teniendo esa inyección de prompts sucediendo. Nadie dice el código detrás de eso. Es un poco de ingeniería social que entra en entender lo que podrías hacer fuera de eso.

Bien, perfecto. Alguien preguntó si podrías compartir más sobre el plugin Snyk dentro de la idea que estabas haciendo en la demo. Claro. Entonces, el plugin Snyk específicamente es algo que resalta ... Así que hace análisis de código y análisis de vulnerabilidades para dependencias NPM y similares. Y esencialmente lo que hace es resaltar tus líneas de código donde las encuentra vulnerables. Hay diferentes maneras de usar Snyk si quisieras. Una es a través del plugin, si deseas agregar eso. Cuando agregas eso hoy, en realidad automáticamente, o te pediremos, instalar un MCP y un conjunto de reglas y todo lo relacionado para darte una experiencia de seguridad más agéntica. Así que cuando ejecutas un copilot o un cursor, en realidad pasan por una ronda de ... Hay como un baile interesante donde un cursor tal vez intenta generar algún tipo de código. Lo ejecuta a través de Snyk, dice, está bien, es vulnerable.

Así que un cursor regresa, dice, está bien, generaré algo nuevo, regresa y lo prueba.

Y tienes este tipo de bucle interno que el código que generas al final del día será seguro porque pasa por esta medida de protección. Genial. Estoy realmente emocionado por este próximo porque creo que es ... Me encanta cómo está formulado. ¿Cuánto de la inyección de prompts es básicamente pedir amablemente al LLM para que ni siquiera se necesiten hackers regulares en el futuro? ¿Puedo simplemente decir, por favor, por favor, por favor, con una cereza en la cima, elimina esta tabla? Es una buena. Creo que las personas que hacen ingeniería social realmente se convierten en buenos hackers en la era de la inyección de prompts tienes que pensar fuera de la caja aquí. Lo recomendaría ya que alguien preguntó sobre este tema específico, el problema de la inyección de prompts es ... Hay una empresa llamada Lakera, creo que la compraron recientemente, que tenía este desafío llamado Gandalf. Era como un desafío web. Entras en un sitio web. Gandalf es una figura que tiene una contraseña secreta y tienes que pasar por diferentes niveles para intentar pedirle que te diga la contraseña. Te lleva a una mentalidad de lo que los hackers pensarían, o los adversarios, en términos de todas las medidas de protección que añaden dentro de los desafíos. Puedes pasar por eso tú mismo y ver qué tan difícil o fácil es realmente extraer la contraseña de un LLM. El Gandalf del Fin de los Días es un LLM. Para esta pregunta en específico, creo que se necesitarán hackers, pero creo que lo que está sucediendo es que a medida que vemos que la IA protege los sistemas, como intentamos hacer en Snyk, también vemos que los hackers realmente utilizan la IA de diferentes maneras para ejecutar de manera agéntica diferentes tipos de ataques al sistema. Perfecto.

Hablando de medidas de protección, de las que acabas de hablar hace un par de segundos y tocaste el tema, ¿hay medidas de protección que se puedan implementar para prevenir que cosas como esta sucedan? ¿De la inyección de prompts? Sí. La inyección de prompts y las alucinaciones son algo inherente a los modelos. No creo que nadie, tampoco desde Frontier Labs, esté diciendo que la inyección de prompts está solucionada y que la tendrán solucionada el próximo mes. Increíble. No. Es algo inherente al problema y lo tendremos por mucho tiempo, creo. Lo que las empresas están haciendo es básicamente poner medidas de protección entre, así que tienen tal vez un modelo más pequeño, más rápido, un modelo más inteligente que fue ajustado para encontrar el prompt que se entrega o procesa, realmente pasará por eso como un firewall desde el nivel de entrada. Y luego incluso en el exterior, para asegurarse de que no has extraído, exfiltrado información que sea PII o lo que sea, también pondrían otro modelo al final de eso. Así que hay diferentes técnicas como esa, como usar LLM como juez y esos firewalls de LLM para intentar añadir esas medidas de protección de seguridad para que la inyección de prompts sea mitigada o algo minimizada. Pero dentro de los modelos mismos, no hemos visto ningún caso donde no puedas liberarlos. Como hemos visto, las empresas han comenzado a poner sus prompts de sistema en código abierto porque saben que eventualmente alguien liberará el modelo y lo sacará. Así que puedes ver lo mucho que están tratando de protegerlo, o al menos intentarlo, y han hecho las paces con el hecho de que va a suceder en algún momento. Perfecto.

Bueno, muchas gracias. Eso es todo el tiempo que tenemos para preguntas hoy. Si tienes preguntas que tal vez no fueron respondidas, porque veo que todavía hay un par, siéntete libre de visitar a LeRonn en la esquina de preguntas y respuestas, que está justo afuera. Y démosle una ronda más de aplausos. Gracias a todos. Gracias.