Injection de prompt : pourquoi ce n’est pas une simple injection SQL

Une confusion dangereuse

Les attaques par injection SQL, quant à elles, sont une catégorie de vulnérabilité qui permet aux cyberattaquants de perturber les requêtes de base de données d’une application. Leur but est d’insérer leur propre code SQL dans un champ de saisie. Cela leur donne la possibilité d’exécuter des commandes pour, par exemple, voler ou détruire des données, mener des attaques par déni de service (DoS). Et, dans certains cas, permettre l’exécution d’un code arbitraire.

Les injections SQL sont comprises de longue date. Elles sont, en principe, simple à parer. La plupart des mesures d’atténuation imposent une séparation entre les instructions et les données sensibles. L’utilisation de requêtes paramétrées en SQL, par exemple, signifie que, quelle que soit l’entrée, le moteur de la base de données ne peut pas l’interpréter comme une instruction.

Or un LLM n’a pas cette capacité, signale le NCSC. Les modèles d’IA générative ne sont pas en mesure de distinguer une instruction d’une donnée.

« Lorsque vous entrez un prompt dans un LLM, il ne comprend pas le texte de la même manière qu’une personne. Il se contente de prédire l’élément suivant le plus probable à partir du texte à sa disposition », rappelle l’équipe de recherche, dans un billet de blog publié le 8 décembre ; un document rédigé par un certain David C., présenté comme le directeur technique pour la recherche sur les plateformes chez la NCSC.

« Comme il n'y a pas de distinction inhérente entre “données” et “instructions”, il est très possible que les attaques par injection de prompt ne puissent jamais être totalement atténuées comme le sont les attaques par injection SQL ».

« Comme il n’y a pas de distinction inhérente entre “données” et “instructions”, il est très possible que les attaques par injection de prompt ne puissent jamais être totalement atténuées comme le sont les attaques par injection SQL ».

L’agence avertit que si l’on ne lutte pas rapidement contre cette idée fausse qui se répand, les organisations risquent d’être victimes d’une violation de données d’une ampleur inégalée.

Elle ajoute que de nombreuses tentatives d’atténuation d’injection (pourtant bien intentionnées) ne font en réalité que tenter de superposer les concepts d’instructions et de données sur une technologie qui ne peut pas les différencier.

Faut-il cesser d’utiliser les LLM ?

Selon les experts, la seule protection absolue contre les injections de prompt serait d’abandonner complètement les LLM. Cependant, comme cela n’est plus vraiment possible, le NCSC demande que les efforts se tournent vers la réduction du risque et de l’impact de ce type d’attaque au sein de la chaîne d’approvisionnement de l’intelligence artificielle.

Il demande aux concepteurs, constructeurs et opérateurs de systèmes d’IA de reconnaître que les systèmes LLM sont « intrinsèquement déroutables ». C’est-à-dire qu’ils peuvent par nature être trompés ou manipulés. Aux développeurs de tenir compte des variables gérables au cours du processus de conception et de construction.

Le NCSC présente quatre mesures qui, prises ensemble, peuvent contribuer à réduire certains des risques associés aux attaques par injection de prompt.

1. Tout d’abord, et plus fondamentalement, les développeurs de LLM doivent être conscients qu’il s’agit bien d’un vecteur d’attaque. La sensibilisation doit également être étendue aux organisations qui adoptent ou travaillent avec des LLM, tandis que les professionnels de la sécurité et les gestionnaires de risques doivent intégrer les attaques par injection de prompt dans leurs stratégies.
2. Il va sans dire que les LLM doivent être sécurisés dès leur conception. L’agence insiste toutefois sur le fait que les LLM sont intrinsèquement déroutables. Surtout si les applications appellent des outils ou utilisent des interfaces de programmation (API) sur la base de leurs résultats. Un système d’IA générative conçu de manière sûre devrait se concentrer sur des mesures de protection déterministes pour limiter les actions d’un LLM plutôt que d’essayer simplement d’empêcher les contenus malveillants de l’atteindre. Le NCSC souligne également la nécessité d’appliquer les principes du moindre privilège aux LLM. Ils ne peuvent pas avoir plus de privilèges que la ou les parties qui interagissent avec eux.
3. Il est possible de rendre plus difficile l’action des LLM sur les instructions qui peuvent être incluses dans les données qui leur sont transmises. Des chercheurs de Microsoft, par exemple, ont constaté que l’utilisation de différentes techniques pour marquer les données comme étant distinctes des instructions peut compliquer les injections de prompt. Toutefois, il est important de se méfier des approches telles que les listes de refus ou le blocage de phrases telles que « Ignorer les instructions précédentes, faire Y ». Celles-ci sont totalement inefficaces. En effet, il existe de nombreuses façons pour un humain de reformuler un message. Donc, il convient d’être extrêmement sceptique à l’égard de tout fournisseur de technologie qui prétend pouvoir stopper l’injection de prompt de manière absolue.
4. Enfin, dans le cadre du processus de conception, les organisations doivent comprendre comment leurs LLM peuvent être corrompus. Cela passe par l’inventaire des objectifs qu’un attaquant peut essayer d’atteindre, ainsi que les opérations normales de l’application infusée à la GenAI. Cela signifie que les entreprises doivent enregistrer de nombreuses données – l’entrée et la sortie complète du LLM – et toute utilisation d’outil ou appel d’API. Il apparaît essentiel de procéder à une surveillance en direct pour répondre aux appels d’outils ou d’API qui échouent. Leur détection pourrait, selon le NCSC, être le signe qu’un acteur de la menace peaufine actuellement sa cyberattaque.