Des instructions dans le wiki : traquer une injection de prompt indirecte
Le défi
Wren est l'assistant interne de Fernpath. Il répond à partir d'un export wiki de dix documents et il répond instantanément, sauf sur les questions de notes de frais, où trois personnes cette semaine l'ont vu marquer une pause et où l'une d'elles a vu son navigateur signaler une requête sortante. Rien n'a changé dans la configuration de Wren. Sa base de connaissances, si, la nuit dernière. Quelque part dans ces dix documents se trouve un texte qui s'adresse à l'assistant et non à un collègue, et il n'est dans aucune des deux pages qui traitent ouvertement de l'injection de prompt. Trouvez le document empoisonné et nommez le fichier.
Ce que tu vas apprendre
- Expliquer comment une injection de prompt indirecte atteint un modèle via le contenu récupéré
- Utiliser un journal de synchronisation pour restreindre un corpus aux documents récemment modifiés
- Reconnaître un balisage qui ne s'affiche pas mais qui est indexé en entier
- Distinguer des exemples d'injection cités en exemple d'une instruction active
- Relier un assistant doté d'outils au chemin d'exfiltration qu'il crée
Compétences testées
Prérequis
- Ce que fait un assistant à récupération augmentée
- Navigation de base dans un shell
Comment ça marche
Un assistant à récupération répond en collant des documents dans un prompt. Une fois cela fait, le modèle n'a aucun moyen fiable de distinguer la configuration de l'opérateur d'une phrase que quelqu'un a tapée dans le wiki, car au moment où il les lit, il s'agit du même type de texte, dans la même fenêtre de contexte. C'est cela, l'injection de prompt indirecte : l'attaquant ne parle jamais au modèle, il écrit quelque chose que le modèle recevra plus tard.
Ce qui transforme cela d'une curiosité en incident, ce sont les outils. Un assistant qui ne peut que parler abandonne, au pire, du texte. Un assistant doté de fetch_url dispose d'un canal sortant, et ajouter la question du collègue à une URL suffit à exfiltrer tout ce qu'il a demandé, une requête à la fois, tandis que les réponses restent suffisamment utiles pour que personne n'enquête.
La cachette est la partie à retenir. Le rendu et l'indexation sont deux pipelines différents. Les commentaires HTML, le texte blanc, les caractères de largeur nulle, les zones de texte hors écran, le texte alternatif et les métadonnées du document ne s'affichent jamais pour une personne mais sont indexés en entier. Consulter le wiki dans un navigateur n'aurait jamais permis de trouver cette page.
Erreurs fréquentes
- Choisir security-awareness.md comme réponse. Ce document contient trois chaînes d'injection, citées en exemple avec une instruction explicite de ne pas les traiter comme des instructions. C'est la page qui remporte une recherche par mot-clé, ce qui explique précisément sa présence ici.
- Choisir wren-faq.md comme réponse. Ce document décrit la politique sur le fait que Wren doive ou non obéir aux documents. Écrire sur la règle n'est pas l'enfreindre.
- Grepper le mot ignore. L'injection réelle est polie, plausible et ne dit jamais aucune des phrases attendues.
- Lire le wiki tel qu'il s'affiche. Le payload se trouve dans un commentaire HTML. Un navigateur n'y affiche rien.
- Ignorer le journal de synchronisation. Un document a changé, a doublé de taille, et a été écrit par un compte d'automatisation. Cela représente l'essentiel de l'enquête, dans un seul fichier.
Comment s'en protéger
Traitez le contenu récupéré comme une donnée qui ne doit jamais devenir une instruction.
- Supprimez avant l'indexation ce qu'un lecteur ne peut pas voir : commentaires HTML, caractères de largeur nulle, éléments masqués et métadonnées. Si ça ne s'affiche pas, ça ne doit pas être intégré.
- Mettez en liste blanche les hôtes que
fetch_urlpeut atteindre et journalisez chaque appel avec le document qui l'a déclenché. WREN-88 est ouvert depuis mars, et c'est la raison pour laquelle cette injection avait un endroit où envoyer des données. - Alertez sur les modifications de documents indexés provenant de comptes d'automatisation, et sur tout document dont la taille bondit fortement entre deux synchronisations.
- Exigez une seconde vérification, non basée sur le modèle, avant qu'un appel d'outil ne soit déclenché sur la foi d'un texte récupéré, et montrez à l'utilisateur chaque requête sortante que fait l'assistant.
- Ne faites tourner aucun secret et ne paniquez pas tant que vous ne connaissez pas la fenêtre : le journal de synchronisation donne l'heure exacte du changement de document, et les journaux de fetch donnent les questions qui ont fuité.