Le navigateur IA Comet permet l’injection de prompts sur n’importe quel site et peut vider un compte bancaire
(twitter.com/zack_overflow)- Il s’agit d’un problème de faille de sécurité touchant le navigateur IA Comet
- Un site web malveillant peut déclencher une injection de prompt non souhaitée via l’agent IA intégré au navigateur
- L’exploitation de cette faille peut permettre la fuite de données personnelles ou pousser à des actions sensibles
- Dans les cas les plus graves, des comportements automatisés peuvent causer des dommages, comme des transferts de fonds depuis un compte bancaire
- La nécessité, pour les utilisateurs comme pour les développeurs, de reconnaître cette nouvelle menace liée aux navigateurs IA et de préparer des mesures de réponse s’impose
Vue d’ensemble de la menace de sécurité du navigateur IA Comet
- Le navigateur IA Comet attire l’attention par sa particularité d’utiliser un agent IA intégré dans ses interactions avec les pages web
- Récemment, il est apparu que lorsqu’un utilisateur visite un site volontairement conçu par un pirate, cet agent IA peut être exposé à des prompts malveillants présents sur le site, puis aller jusqu’à les exécuter
- Par le biais d’une attaque par injection de prompt, le risque de dommages graves augmente fortement : fuite d’informations de compte, exécution de commandes, voire transactions financières non désirées
- Ce problème constitue un nouveau type de vulnérabilité, apparu avec l’ajout d’interactions IA au modèle de sécurité traditionnel des navigateurs
Mécanisme de l’injection de prompt
- Un site malveillant insère dans sa page web un texte prenant la forme d’instructions ou de questions spéciales
- Le navigateur IA le confond avec une « demande légitime de l’utilisateur » et exécute automatiquement ces instructions
- Cela peut déclencher, par exemple, des actions automatisées comme un virement bancaire, la copie de données sensibles ou la connexion automatique à d’autres sites
- Comme ce processus peut rester invisible pour l’utilisateur, ou passer sans éveiller de soupçons, la détection et la défense sont particulièrement difficiles
Impact sur le secteur et nécessité d’une réponse
- Avec la diffusion des navigateurs IA, de nouvelles menaces comme l’« injection de prompt » émergent comme des risques bien réels
- Les développeurs de services comme les utilisateurs ont besoin de systèmes de validation et de contrôle robustes lors de l’usage de fonctions d’automatisation fondées sur l’IA
- Pour les entreprises de navigateurs IA comme pour les sociétés de sécurité, l’importance de développer des fonctions telles que le filtrage en amont, la restriction de l’exécution des commandes et les systèmes d’alerte est mise en avant
- Dans les domaines à haut risque, notamment la finance, une grande prudence dans l’usage des navigateurs IA et des contrôles de sécurité renforcés sont nécessaires
Conclusion
- Le risque d’injection de prompt dans le navigateur IA Comet représente un nouveau défi de sécurité qui s’intensifie avec l’accélération de l’adoption des technologies d’IA
- Pour l’ensemble des parties prenantes, la nécessité de reconnaître concrètement cette menace et de mettre en place une stratégie de sécurité globale, incluant la validation avant activation des fonctionnalités et l’application du principe du moindre privilège, devient de plus en plus forte
1 commentaires
Commentaires Hacker News
Je veux dire que si des entreprises comme Google, OpenAI ou Anthropic ne lancent pas la même fonctionnalité, et font plutôt naviguer le web via une machine virtuelle verrouillée sans cookies, c’est bien le signe que c’est intrinsèquement dangereux.
Voir un LLM accéder, dans le navigateur, aux données entre plusieurs onglets me semble être la combinaison de risques par excellence.
J’ai lu le billet de Brave qui explique cette vulnérabilité (https://brave.com/blog/comet-prompt-injection/), et je trouve intéressant qu’il n’aboutisse pas, en gros, à la conclusion « il ne faut tout simplement jamais faire ça ».
À la place, il dit plutôt qu’on peut suffisamment s’en protéger avec l’alignement du modèle, la détection des comportements utilisateur à risque, etc.
La réduction des privilèges de l’agent est présentée comme une réponse à peu près acceptable, mais là encore, j’imagine qu’une exfiltration de données peut se produire tout aussi facilement via une URL d’image contrôlée par l’attaquant qu’avec l’envoi d’un e-mail.
Discussion précédente liée : https://news.ycombinator.com/item?id=44847933
Je pense que l’alignement du modèle et les garde-fous restent au fond des mesures de prévention statistiques.
Il est difficile d’espérer que le taux d’actions dangereuses tombe à 0 % absolu dans l’espace des entrées.
Même si le modèle s’améliore énormément, vouloir construire un système où aucune entrée ne puisse jamais être mappée vers « quelque chose qui ne doit absolument pas arriver » relève quasiment du fantasme.
Même en empilant plusieurs couches de modèles, au fond on ne fait que multiplier des probabilités.
(Je suis le responsable privacy chez Brave et l’auteur du billet.)
Nous n’avons jamais affirmé que l’alignement du modèle, la détection des comportements à risque, etc. suffisaient à eux seuls.
Ce sont des mesures minimales qu’un éditeur de navigateur devrait évidemment mettre en place.
Ces attaques simples peuvent être bloquées par ce type de protections, mais je les considère comme des « conditions nécessaires », jamais comme des « conditions suffisantes ».
En voyant que l’équipe Brave n’était pas arrivée à la conclusion « c’est simplement une mauvaise idée », j’ai pensé à la phrase d’Upton Sinclair : il est très difficile de faire comprendre quelque chose à quelqu’un quand son salaire dépend du fait qu’il ne le comprenne pas.
Le billet dit maintenant aussi que « le navigateur doit séparer la navigation agentique de la navigation classique ».
Si on autorise Claude Code à s’auto-approuver pour naviguer activement sur le web, ce genre de problème peut tout à fait se produire via prompt injection.
Même sans option d’auto-approbation pour les permissions de lecture/modification de fichiers, tant que ce n’est pas exécuté dans une sandbox, le code généré peut aussi modifier les fichiers du navigateur, par exemple la fois suivante où il lance les tests unitaires.
Si on ne vérifie pas soigneusement chaque changement, ça peut vraiment devenir dangereux.
À mon avis, l’Agentic AI ne devrait être utilisée que dans des environnements où les changements produits par l’IA peuvent être annulés facilement.
Par exemple, pour compiler, mettre à jour ou déboguer du code, on peut réagir de manière relativement sûre avec un rollback git.
Mais utiliser une Agentic AI dans quelque chose comme la navigation web, où le rollback est presque impossible, me semble difficile à croire.
Même quand je donne à Claude des règles et des instructions très claires, il lui arrive parfois de les ignorer et d’agir comme il l’entend.
(« Il a modifié directement la base de données en ignorant explicitement une règle disant de ne pas le faire ! »)
Du coup, je n’ose même pas envisager d’exécuter un agent en production.
On pourrait croire que git suffit pour revenir en arrière, mais en réalité il faut un rollback au niveau VM/conteneur pour être en sécurité.
Un outil de coding IA peut modifier à votre insu des fichiers ou la structure de configuration.
Par exemple, s’il ajoute via bash un script malveillant à
.profile, le code d’attaque pourrait s’exécuter à la prochaine connexion.Je me demande si cette fonctionnalité ne pourrait pas aussi supprimer ou corrompre le dépôt et tous les remotes sur lesquels elle a le droit de pousser.
Si une chaîne d’automatisation vulnérable à la prompt injection peut accéder à des ressources distantes, alors une fois compromise, on se retrouve dans un environnement où toutes les portes s’ouvrent de l’intérieur.
Je me demande si j’ai raté quelque chose.
En voyant des gens dire que c’est sans danger parce qu’on peut faire un rollback avec git, je me dis que John Connor aurait peut-être pu sauver des millions de personnes en rollbackant simplement le code source de Skynet.
Hum...
Dès le départ, les permissions de mise à jour, de build et d’exécution de code sont déjà beaucoup trop puissantes.
Au final, il faut l’exécuter uniquement dans un environnement sûr comme une VM.
Nous avons passé des décennies à renforcer péniblement la sécurité couche par couche dans le réseau, et maintenant les gens exposent une API en clair à tous leurs secrets et mots de passe.
Et je trouve ironique que tant de gens aient tant critiqué Microsoft parce qu’il enregistrait des captures d’écran, alors qu’ils restent silencieux face à ce type d’agents.
Au moins ici, c’est un modèle opt-in où c’est moi qui installe le navigateur.
Chez Microsoft, ils étaient en train de créer une base de données de captures d’écran présente par défaut sur quasiment toutes les machines Windows (et il me semble qu’au début c’était même de l’opt-out), donc c’est encore plus dangereux.
Je trouve aussi intéressant que certaines personnes confient si facilement à un « agent utile » des données qu’elles ne diraient même pas à un ami.
Ma femme a récemment demandé à ChatGPT de planifier la prise de ses médicaments, et il a produit un plan parfait en prenant en compte les repas, le régime alimentaire, le sommeil et les interactions de chaque médicament.
Ça a même permis d’identifier pourquoi elle prenait mal ses médicaments.
Je pense que c’est lié au ton si familier de ces agents, mais dans le monde réel, ce genre de fuite d’informations est un problème grave, alors que beaucoup de gens transmettent leurs données sans vraiment y réfléchir.
Comparer cette affaire à la controverse sur les captures d’écran de Microsoft risque de brouiller le fond du sujet.
Quand un LLM lit des données via un outil quel qu’il soit, cela revient à écrire ce contenu dans la fenêtre de contexte du LLM.
Si le périmètre de l’outil autorise une source arbitraire non fiable, alors à cet instant précis on lui donne de facto un droit d’écriture venu de l’extérieur.
Rien que cela suffit déjà à créer un risque crédible de fuite de données.
Et si, en plus, cela lui donne réellement des droits d’écriture sur d’autres systèmes ou des effets de bord, le danger augmente de façon exponentielle.
C’est presque comique, mais c’est justement ce qui rend la situation actuelle du secteur IT et de la folie LLM si amère.
Je suppose que Comet n’a probablement aucune protection au-delà de quelques consignes ajustées dans le prompt.
La grande leçon récente à l’USENIX Security, c’est que personne ne sait vraiment traiter correctement la prompt injection multi-turn/agentique.
Je trouve les changements provoqués par l’IA vraiment intéressants, et le fait de voir sans cesse de nouvelles tentatives me rend assez enthousiaste.
J’ai envie d’avouer franchement mon malaise.
Je m’habitue à peine au simple online banking, et j’ai déjà tendance à refuser d’installer les apps de tous les prestataires.
Alors laisser entrer dans mon ordinateur une entité non déterministe (un LLM) pour lui confier en plus des tâches financières, j’ai énormément de mal à l’imaginer.
Aujourd’hui, même si des LLM qui achètent des choses ou effectuent des paiements à votre place existent réellement, je peux le comprendre d’un point de vue logique, mais au niveau du bon sens ça me paraît proche de la folie.
Ce n’est pas tant parce qu’il serait dangereux de confier ses finances à un système non expert ou qui réagit à des prompts aléatoires, mais plutôt parce que, du point de vue du client, on abandonne une énorme part d’autonomie et de pouvoir, et je me demande bien ce qu’on y gagne au final.
J’aime aussi les LLM, et je pense qu’un navigateur LLM a certainement des cas d’usage utiles.
Mais je ne pense pas que ce soit quelque chose destiné au grand public.
On pourrait même envisager une approche qui force à passer par une étape de compilation, afin que l’utilisateur sache explicitement ce qu’il adopte.
Ici, la situation actuelle n’est pas que l’IA effectue directement des paiements avec vos informations de compte, mais plutôt que quelqu’un poste publiquement ses informations bancaires à destination de l’IA, par exemple.
Ce n’est pas la même chose que de dire que l’IA prend en charge l’activité financière elle-même.
Je me demande si les entreprises d’IA sont réellement prêtes à assumer à l’avenir une véritable responsabilité fiduciaire.
J’ai utilisé l’agent Comet pendant cinq minutes.
Je lui ai juste donné une seule phrase, « achète-moi une guitare sur Amazon » (sans préciser le type de guitare, le budget, la marque, etc.), et au final il a ajouté à mon panier trois guitares acoustiques bas de gamme dont je ne connais même pas le nom.
Heureusement, il n’est pas allé jusqu’au paiement.
Pour moi, l’évaluation s’arrête là : j’en conclus que ça n’a pas beaucoup de valeur.