Une application entièrement conçue par IA a divulgué 1,5 million d'enregistrements en 3 jours : 5 points de vigilance pour éviter cela

En janvier de cette année, un réseau social appelé "Moltbook" a été lancé.

C'était un réseau social inhabituel où seuls des agents IA pouvaient publier, et il avait été construit presque entièrement par l'IA. C'est ce qu'on pourrait appeler du "vibe coding".

Trois jours après son lancement, un chercheur en sécurité a remarqué quelque chose :

"N'importe qui peut lire et réécrire le contenu de la base de données de cette application."

Ce qui a fuité représentait environ 1,5 million de jetons d'authentification, environ 35 000 adresses e-mail et des milliers de messages privés.

La direction a corrigé le problème immédiatement, mais jusque-là, n'importe qui pouvait prendre ce qu'il voulait pendant plusieurs jours.

Mon travail consiste à soutenir le développement interne d'outils d'IA et à effectuer des contrôles de sécurité.

Cet incident présentait en fait exactement la même vulnérabilité que je vois le plus souvent dans les entreprises qui ont construit des outils internes à l'aide de l'IA.

Voici ce qui s'est passé et cinq points à surveiller pour éviter que cela ne vous arrive.

====

Ce qui s'est passé

Il n'y avait que deux causes.

Premièrement. La base de données n'avait pas de règle stipulant "vous ne pouvez voir que vos propres données."

Deuxièmement. La clé utilisée pour se connecter à la base de données était écrite directement dans le code côté navigateur.

N'importe qui peut voir une clé écrite dans le navigateur simplement en ouvrant les outils de développement.

Si vous vous connectez à la base de données avec cette clé, toutes les données sont renvoyées car il n'y a aucune règle les restreignant.

En d'autres termes, tout était visible par la porte dérobée sans même passer par l'interface de l'application.

L'IA a réussi à construire une "application fonctionnelle."

Cependant, elle n'a pas construit la partie "cacher aux autres" parce qu'on ne le lui a pas demandé.

C'est le plus grand piège lors de la construction avec l'IA.

====

1. "Pouvoir se connecter" et "Ne pas voir les données des autres" sont deux choses différentes

Lors du développement d'une application, une fonctionnalité de connexion est presque toujours incluse.

Les gens ont tendance à penser : "J'ai ajouté une fonction de connexion pour l'instant, donc ça va", mais c'est incorrect.

La connexion est une fonctionnalité pour vérifier "qui" est quelqu'un.

Ce que "cette personne est autorisée à voir" doit être construit séparément.

Moltbook avait aussi un système de connexion.

Cependant, après la connexion, les utilisateurs pouvaient accéder aux données d'autres personnes.

La vérification est simple.

Créez deux comptes de test, connectez-vous avec le compte A et essayez d'ouvrir directement l'URL des données du compte B.

Si vous pouvez les voir, vous êtes exposé.

Voici le prompt pour l'IA :

"Assurez-vous que les utilisateurs ne peuvent accéder qu'à leurs propres données. Assurez-vous que même s'ils ouvrent l'URL des données de quelqu'un d'autre, ils ne peuvent pas les voir."

====

2. Mettez une règle "Ne voir que sa propre part" du côté de la base de données aussi

Le premier point concernait le côté application.

Cependant, comme Moltbook, quelqu'un pourrait se connecter directement à la base de données par la porte dérobée sans passer par l'application.

Par conséquent, vous devez mettre une règle dans la base de données elle-même stipulant "cette personne ne peut voir que cette ligne."

Avec cela en place, même si la clé fuit, les données des autres personnes ne peuvent pas être récupérées.

Les services de base de données fréquemment utilisés dans le développement récent de l'IA disposent de cette fonctionnalité.

Cependant, elle est souvent désactivée par défaut. L'IA ne l'activera pas à moins qu'on ne le lui demande.

Voici le prompt :

"Activez une règle sur toutes les tables de la base de données afin que les utilisateurs ne puissent lire que leurs propres lignes."

====

3. Ne placez pas de clés du côté du navigateur

L'autre cause pour Moltbook était que la clé était écrite dans le navigateur.

Une application a "un code qui s'exécute côté serveur" et "un code qui s'exécute côté navigateur."

Le côté navigateur est entièrement envoyé sur le PC de l'utilisateur. En d'autres termes, y écrire une clé revient à la distribuer à tout le monde.

Comment vérifier : Ouvrez les outils de développement et recherchez "key", "token" ou "secret".

Si une longue chaîne qui en ressemble une apparaît, vous devez être prudent.

Voici le prompt :

"Gardez les clés et les mots de passe strictement côté serveur. Ne les incluez jamais dans le code côté navigateur."

====

4. Faites jouer le rôle du "méchant" à une "IA différente" avant la publication

Si vous demandez à l'IA qui l'a construit : "Est-ce sûr ?", elle répondra "Oui." Parce qu'elle l'a construit elle-même.

Par conséquent, vous devez faire examiner l'application par une IA différente de celle utilisée pour le développement, du point de vue d'un attaquant.

Demandez-lui : "Si vous deviez pénétrer dans cette application, par où entreriez-vous ?"

Quand je fais cela avec les outils des clients, les vulnérabilités qu'ils n'avaient pas remarquées sortent en masse.

Les deux vulnérabilités de Moltbook sont à un niveau qui serait normalement trouvé avec cette question.

Voici le prompt :

"Vous êtes un attaquant. Listez tous les moyens de voir les données des autres dans cette application. Si vous en trouvez, fournissez également les correctifs."

====

5. Une fois publié, enregistrez "Qui a vu quoi" et vérifiez-le quotidiennement pendant la première semaine

Moltbook a été corrigé parce qu'un chercheur externe l'a trouvé et a contacté l'équipe.

Ils ne l'avaient pas remarqué eux-mêmes.

Avec les outils internes, personne ne va vous contacter.

Par conséquent, gardez une trace de "qui s'est connecté quand et quelles données il a consultées."

Ensuite, vérifiez cet enregistrement tous les jours pendant la première semaine suivant la publication.

Une source d'accès inconnue, un accès massif au milieu de la nuit, ou une personne ouvrant les données de tout le monde.

Vous pouvez voir ces choses immédiatement en regardant les enregistrements.

Voici le prompt :

"Conservez un journal de qui a accédé à quelles données et quand. Cependant, n'écrivez pas les mots de passe ou les informations personnelles dans les journaux."

====

Résumé

Pour résumer l'incident de Moltbook en une phrase :

"L'IA construit ce qu'on lui demande de construire, mais elle ne construit pas ce qu'on ne lui demande pas de construire."

Lors de la création d'outils internes, nous communiquons "Je veux ce genre de fonctionnalité."

Mais nous ne disons pas "Ne le montre pas aux autres" ou "Ne mets pas la clé dans le navigateur."

Parce que nous ne le disons pas, cela n'est pas inclus.

Inversement, ces cinq éléments peuvent tous être inclus simplement en ajoutant une seule phrase à l'IA.

D'abord, essayez de créer deux comptes de test avec un outil que vous utilisez actuellement et ouvrez l'URL des données de quelqu'un d'autre.

Le simple fait de le faire vous dira si vous avez la même vulnérabilité que Moltbook.

====

Enfin, une annonce.

Notre entreprise propose un service pour développer à partir de zéro des agents IA spécialisés dans des tâches pour votre entreprise.

Au lieu de formations ou d'introductions d'outils, nous vous interviewons sur votre flux de travail métier réel et livrons quelque chose "utilisable dès demain" tel quel. Nous fournissons un support cohérent jusqu'à l'amélioration post-introduction et le développement interne.

Nous proposons également un service où des ingénieurs vous accompagnent pour vérifier la sécurité et le fonctionnement des outils IA internes, ainsi que pour assurer la maintenance et les modifications ultérieures. Une caractéristique clé est que nous ne nous contentons pas de terminer après la construction, mais nous établissons un "système de protection continue" du point de vue des cinq points de cet article.

Si vous êtes un propriétaire d'entreprise ou un gestionnaire qui pense : "Notre outil pourrait montrer des données si quelqu'un ouvre l'URL d'une autre personne", veuillez nous permettre de discuter avec vous.

La consultation initiale est gratuite, et nous pouvons vous montrer une démonstration de la vérification du point de vue de l'attaquant présentée dans cet article sur place. Comme nous pouvons commencer par organiser ensemble où votre système est vulnérable, n'hésitez pas à nous contacter via DM ou LINE.

Dites simplement "IA" c'est parfait ↓

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