Una aplicación creada completamente por IA filtró 1.5 millones de registros en 3 días: 5 cosas a tener en cuenta para evitarlo

En enero de este año, se lanzó una red social llamada "Moltbook".

Era una red social inusual donde solo los agentes de IA podían publicar, y fue construida casi en su totalidad por IA. Esto es lo que podrías llamar "vibe coding".

A los tres días de su lanzamiento, un investigador de seguridad notó algo:

"Cualquier persona puede leer y reescribir el contenido de la base de datos de esta aplicación."

Lo que se filtró fueron aproximadamente 1.5 millones de tokens de autenticación, alrededor de 35,000 direcciones de correo electrónico y miles de mensajes privados.

La administración lo solucionó de inmediato, pero hasta entonces, cualquiera podía tomar lo que quisiera durante varios días.

Mi trabajo consiste en apoyar el desarrollo interno de herramientas de IA y realizar verificaciones de seguridad.

Este incidente, de hecho, presentó la misma vulnerabilidad que veo con mayor frecuencia en empresas que han construido herramientas internas usando IA.

Aquí está lo que sucedió y cinco cosas a tener en cuenta para evitar que te ocurra a ti.

====

Lo que sucedió

Solo hubo dos causas.

Primera. La base de datos no tenía una regla que dijera "solo puedes ver tus propios datos".

Segunda. La clave utilizada para conectarse a la base de datos estaba escrita directamente en el código del lado del navegador.

Cualquiera puede ver una clave escrita en el navegador simplemente abriendo las herramientas de desarrollador.

Si te conectas a la base de datos con esa clave, se devuelven todos los datos porque no hay reglas que los restrinjan.

En otras palabras, todo era visible a través de la puerta trasera sin siquiera pasar por la interfaz de la aplicación.

La IA logró construir una "aplicación funcional".

Sin embargo, no construyó la parte de "ocultarlo de los demás" porque no se le pidió.

Este es el mayor peligro al construir con IA.

====

1. "Poder Iniciar Sesión" y "No Ver los Datos de Otros" Son Dos Cosas Diferentes

Al desarrollar una aplicación, casi siempre se incluye una función de inicio de sesión.

La gente tiende a pensar: "Agregué una función de inicio de sesión por ahora, así que está bien", pero eso es incorrecto.

Iniciar sesión es una función para verificar "quién" es alguien.

Lo que "esa persona tiene permitido ver" debe construirse por separado.

Moltbook también tenía un sistema de inicio de sesión.

Sin embargo, después de iniciar sesión, los usuarios podían acceder a los datos de otras personas.

La verificación es simple.

Crea dos cuentas de prueba, inicia sesión con la Cuenta A e intenta abrir directamente la URL de los datos de la Cuenta B.

Si puedes verlos, estás expuesto.

Aquí está el prompt para la IA:

"Asegúrate de que los usuarios solo puedan acceder a sus propios datos. Garantiza que, incluso si abren la URL de los datos de otra persona, no puedan verlos."

====

2. Coloca una Regla de "Solo Ver tu Propia Parte" También del Lado de la Base de Datos

El primer punto era sobre el lado de la aplicación.

Sin embargo, como en Moltbook, alguien podría conectarse directamente a la base de datos a través de la puerta trasera sin pasar por la aplicación.

Por lo tanto, debes colocar una regla en la propia base de datos que diga "esta persona solo puede ver esta fila".

Con esto implementado, incluso si la clave se filtra, no se pueden recuperar los datos de otras personas.

Los servicios de bases de datos utilizados con frecuencia en el desarrollo reciente de IA tienen esta función.

Sin embargo, a menudo está desactivada por defecto. La IA no la activará a menos que se lo pidas.

Aquí está el prompt:

"Habilita una regla en todas las tablas de la base de datos para que los usuarios solo puedan leer sus propias filas."

====

3. No Coloques Claves en el Lado del Navegador

La otra causa de Moltbook fue que la clave estaba escrita en el navegador.

Una aplicación tiene "código que se ejecuta en el lado del servidor" y "código que se ejecuta en el lado del navegador".

El lado del navegador se envía por completo a la PC del usuario. En otras palabras, escribir una clave allí es lo mismo que distribuirla a todos.

Cómo verificar: Abre las herramientas de desarrollador y busca "key", "token" o "secret".

Si aparece una cadena larga que parezca una de estas, debes tener cuidado.

Aquí está el prompt:

"Mantén las claves y contraseñas estrictamente en el lado del servidor. Nunca las incluyas en el código del lado del navegador."

====

4. Haz que una "IA Diferente" Juegue el Papel del Malo Antes del Lanzamiento

Si le preguntas a la IA que lo construyó: "¿Es seguro?", dirá que "Sí". Porque ella misma lo construyó.

Por lo tanto, debes hacer que una IA diferente a la utilizada para el desarrollo lo revise desde la perspectiva de un atacante.

Pregúntale: "Si fueras a irrumpir en esta aplicación, ¿por dónde entrarías?"

Cuando hago esto con las herramientas de los clientes, salen a la luz vulnerabilidades que no habían notado.

Las dos vulnerabilidades en Moltbook están a un nivel que normalmente se encontraría con esta pregunta.

Aquí está el prompt:

"Eres un atacante. Enumera todas las formas de ver los datos de otras personas en esta aplicación. Si encuentras alguna, proporciona también las soluciones."

====

5. Una vez Lanzado, Registra "Quién Vio Qué" y Revísalo a Diario Durante la Primera Semana

Moltbook se solucionó porque un investigador externo lo encontró y se comunicó.

Ellos mismos no lo habían notado.

Con las herramientas internas, nadie se va a comunicar contigo.

Por lo tanto, mantén un registro de "quién inició sesión, cuándo y qué datos vio".

Luego, revisa ese registro todos los días durante la primera semana después del lanzamiento.

Un origen de acceso desconocido, un acceso masivo en mitad de la noche o una persona abriendo los datos de todos.

Puedes identificar estas cosas de inmediato mirando los registros.

Aquí está el prompt:

"Mantén un registro de quién accedió a qué datos y cuándo. Sin embargo, no escribas contraseñas ni información personal en los registros."

====

Resumen

Para resumir el incidente de Moltbook en una línea:

"La IA construye lo que se le pide que construya, pero no construye lo que no se le pide que construya."

Al crear herramientas internas, comunicamos "Quiero este tipo de función".

Pero no decimos "No se lo muestres a otros" ni "No pongas la clave en el navegador".

Como no lo decimos, no se incluye.

Por el contrario, estas cinco cosas se pueden incluir simplemente agregando una sola oración a la IA.

Primero, intenta crear dos cuentas de prueba con una herramienta que tengas actualmente en funcionamiento y abre la URL de los datos de otra persona.

Solo con hacer eso, sabrás si tienes la misma vulnerabilidad que Moltbook.

====

Finalmente, un anuncio.

Nuestra empresa ofrece un servicio para desarrollar agentes de IA especializados en tareas para tu empresa desde cero.

En lugar de capacitación o introducciones de herramientas, te entrevistamos sobre tu flujo de trabajo comercial real y entregamos algo "utilizable desde mañana" tal cual. Brindamos soporte constante hasta la mejora posterior a la introducción y el desarrollo interno.

También ofrecemos un servicio donde los ingenieros te acompañan para verificar la seguridad y operación de las herramientas de IA internas, así como para realizar el mantenimiento y las modificaciones posteriores. Una característica clave es que no solo terminamos después de construir, sino que establecemos un "sistema de protección continua" desde las perspectivas de los cinco puntos de este artículo.

Si eres un propietario de negocio o gerente que piensa: "Nuestra herramienta podría mostrar datos si alguien abre la URL de otra persona", permítenos hablar contigo.

La consulta inicial es gratuita y podemos mostrarte una demostración de la verificación desde la perspectiva del atacante presentada en este artículo en el acto. Dado que podemos comenzar organizando juntos dónde es vulnerable tu sistema, no dudes en contactarnos a través de DM o LINE.

Solo di "IA" está perfectamente bien↓

LINE: https://line-harness.r-yagi.workers.dev/r/x