Gestion non sécurisée des sorties

La gestion non sécurisée (ou inappropriée) des sorties désigne l’absence de validation, de nettoyage ou d’encodage des sorties générées par un grand modèle de langage avant leur transmission à des systèmes en aval, leur affichage dans des interfaces utilisateur ou leur exécution dans des processus backend.

Qu’est-ce qu’une gestion non sécurisée des sorties ?

Lorsque des applications intègrent des LLM, elles reçoivent généralement du texte généré et le transmettent ailleurs : à un navigateur, à une requête de base de données, à une commande système ou à un autre composant de l’application. La gestion non sécurisée des sorties se produit lorsque ce contenu généré est utilisé sans vérifier qu’il est sûr.

Le problème fondamental réside dans la confiance. Les développeurs supposent souvent que, puisqu’ils contrôlent le prompt ou le modèle, la sortie sera prévisible et inoffensive, mais ce n’est pas toujours le cas. Les LLM génèrent des réponses à partir de schémas appris dans les données d’entraînement et influencés par les entrées des utilisateurs. Un prompt soigneusement élaboré peut amener le modèle à produire une sortie contenant du code exécutable, des scripts malveillants, des fragments SQL ou des commandes système, que l’application traite ensuite comme s’il s’agissait de données fiables.

Cette vulnérabilité est comparable aux failles d’injection traditionnelles telles que le cross-site scripting (XSS), où une entrée utilisateur non sécurisée entraîne l’exécution de code dans un navigateur. La différence réside dans le fait que, dans ce cas, l’« entrée utilisateur » correspond à la sortie du modèle, qui peut être manipulée indirectement par une injection de prompt ou simplement résulter des schémas de réponse du modèle.

La gestion non sécurisée des sorties devient un problème de sécurité lorsque l’application ne traite pas les sorties du LLM avec la même prudence que toute autre entrée externe non fiable. Sans validation ni encodage, ces sorties peuvent créer des vulnérabilités dans tout système qui les reçoit.

Pourquoi une gestion non sécurisée des sorties est-elle dangereuse ?

Les pratiques de sécurité standard reposent sur l’hypothèse que les sources d’entrée sont prévisibles. Les formulaires comportent des champs définis. Les API disposent de schémas. Les saisies des utilisateurs arrivent par des canaux connus. Les sorties des LLM remettent en cause ces hypothèses, car elles sont générées dynamiquement, façonnées par des prompts susceptibles de contenir du contenu malveillant et capables de produire pratiquement n’importe quelle chaîne de texte.

Cette imprévisibilité rend la gestion non sécurisée des sorties particulièrement dangereuse pour les applications basées sur des LLM. Un modèle peut générer des milliers de fois des réponses valides et utiles, puis produire une réponse contenant une balise de script ou une commande shell parce que le prompt a pris une tournure inattendue. Les contrôles de sécurité qui reposent sur la recherche d’un nombre limité de motifs ou sur des listes d’autorisation peinent à anticiper toutes les sorties possibles.

La surface d’attaque s’élargit également, car les sorties des LLM sont souvent transmises à plusieurs systèmes en aval. Une même réponse peut être affichée dans un navigateur, enregistrée dans une base de données et transmise à une API. Chaque destination présente ses propres vulnérabilités, et une gestion non sécurisée des sorties à n’importe quelle étape peut ouvrir une voie d’exploitation.

De plus, le comportement des LLM peut évoluer au fil du temps à mesure que les modèles sont mis à jour ou affinés. Une sortie qui était sûre avec une version du modèle peut devenir exploitable avec une autre. Les applications qui ne considèrent pas les sorties comme intrinsèquement non fiables présentent un risque latent qui ne se manifeste que lorsque les conditions changent.

Comment se produit une gestion non sécurisée des sorties ?

La gestion non sécurisée des sorties exploite l’écart entre ce qu’un LLM génère et la manière dont les systèmes en aval interprètent ce contenu. Les attaquants manipulent les invites afin d’amener le modèle à produire une sortie qui, lorsqu’elle est traitée sans assainissement, déclenche un comportement indésirable dans le système destinataire.

• Sortie non fiable utilisée comme entrée active : Les sorties des LLM sont des chaînes de texte, mais celles-ci peuvent contenir du contenu exécutable : JavaScript, HTML, SQL, commandes shell ou Markdown intégrant des scripts. Si une application transmet directement cette sortie à un interpréteur, à un shell ou à un moteur de rendu sans la nettoyer, le contenu s’exécute. Par exemple, une invite conçue pour susciter une réponse contenant des balises <script> devient une charge utile XSS si la sortie est insérée dans une page web sans encodage.
• Sortie affichée dans les navigateurs clients ou les interfaces utilisateur : Lorsque du contenu généré par un LLM est affiché dans un navigateur ou une interface d’application, tout code HTML ou JavaScript intégré peut s’exécuter dans le contexte de l’utilisateur. Cela ouvre la voie à des attaques de type cross-site scripting (XSS), au détournement de session, au vol d’identifiants ou à la manipulation de l’interface utilisateur. Les chatbots, les générateurs de contenu et les assistants IA qui affichent directement les sorties du modèle sont particulièrement exposés s’ils omettent de les encoder.
• Exécution côté serveur et élévation de privilèges : Les cas les plus graves surviennent lorsque la sortie du LLM atteint des systèmes côté serveur dotés de capacités d’exécution. Si la sortie est transmise à un shell, à une fonction eval() ou à une requête de base de données sans nettoyage préalable, les attaquants peuvent exécuter du code à distance, exfiltrer des données ou élever leurs privilèges. Un modèle amené par tromperie à générer une chaîne d’injection SQL valide ou une commande système peut compromettre l’ensemble du système côté serveur si l’application exécute cette sortie.

Exemples courants et scénarios d’attaque réels

La gestion non sécurisée des sorties se manifeste sous plusieurs formes reconnaissables dans les applications intégrant des LLM.

Un chatbot de service client qui affiche les réponses d’un LLM sous forme de code HTML sans les échapper peut devenir un vecteur d’attaque XSS. Un attaquant soumet une invite conçue pour amener le modèle à inclure une balise de script dans sa réponse. Lorsque la réponse s’affiche dans le navigateur d’un autre utilisateur, le script s’exécute et peut dérober des jetons de session ou rediriger l’utilisateur vers un site d’hameçonnage.

Les applications qui utilisent les résultats produits par un LLM pour construire des requêtes de base de données sont également exposées aux risques d’injection SQL. Si un modèle est invité à générer une requête de recherche de produits et qu’un attaquant élabore une entrée qui amène le modèle à ajouter ; DROP TABLE users;-- à sa réponse, une application qui concatène ce résultat dans une instruction SQL sans utiliser de requêtes paramétrées exécutera la commande malveillante.

En outre, les pipelines CI/CD qui intègrent du code ou des configurations générés par des LLM sont vulnérables aux injections de commandes. Un modèle chargé de générer un script de déploiement pourrait être manipulé afin d’y inclure une commande de shell inversé. Si le pipeline exécute le script sans vérification, l’attaquant accède à l’infrastructure de compilation.

La falsification de requêtes côté serveur peut également résulter d’un traitement non sécurisé des sorties. Un LLM générant des URL ou des appels d’API à partir des entrées utilisateur peut être amené à produire des requêtes vers des ressources du réseau interne. Si l’application exécute ces requêtes sans les valider, des attaquants peuvent sonder les systèmes internes ou exfiltrer des données.

Risques liés à l’IA agentique et à l’architecture RAG

À mesure que l’utilisation de l’IA moderne se développe et progresse dans les entreprises, les risques liés à la gestion non sécurisée des sorties évoluent également. Les modèles fournissent désormais des données d’entrée et des instructions aux applications, outils, API, bases de données et agents connectés. Cette connectivité ouvre la voie à des acteurs malveillants, qui peuvent recourir à des techniques d’injection indirecte de prompts pour inciter des agents d’IA autonomes à exécuter des appels d’API ou d’outils non autorisés, à effectuer des écritures malveillantes dans des bases de données ou à extraire des données de pipelines de génération augmentée par récupération (RAG).

L’augmentation des capacités autonomes et l’accès de plus en plus répandu des agents aux systèmes critiques pour l’entreprise impliquent que les sorties doivent être validées et assainies avant de parvenir aux systèmes ou outils en aval. Toute sortie dépassant les autorisations définies doit être restreinte.

Comment empêcher la gestion non sécurisée des sorties

Pour éviter une gestion non sécurisée des sorties, il convient de traiter les sorties des LLM avec la même rigueur que les entrées utilisateur non fiables. Les pratiques suivantes peuvent contribuer à réduire l’exposition aux vecteurs d’attaque courants :

• Traitez les sorties du LLM comme des entrées non fiables : Adoptez une approche zero trust à l’égard de tout contenu généré par le modèle. Quelle que soit la manière dont le prompt a été conçu ou les contraintes appliquées, partez du principe que la sortie peut contenir du contenu malveillant ou malformé. Validez-la et assainissez-la avant toute utilisation en aval.
• Validation et assainissement des sorties : Appliquez un encodage adapté au contexte avant d’afficher ou d’exécuter les sorties du LLM. Encodez en HTML les sorties affichées dans les navigateurs. Utilisez des requêtes de base de données paramétrées plutôt que de concaténer les sorties du modèle dans des chaînes SQL. Échappez les métacaractères de l’interpréteur de commandes si les sorties doivent être transmises à des commandes système. Dans la mesure du possible, utilisez des listes d’autorisation afin de limiter les sorties aux formats attendus.
• Contrôles d’accès stricts et approche fondée sur le principe du moindre privilège : Limitez les autorisations des composants qui traitent les sorties du LLM. Si un service exécute des commandes générées par le modèle, restreignez les commandes qu’il peut exécuter et les ressources auxquelles il peut accéder. Isolez des systèmes sensibles les traitements liés au LLM. Appliquez le principe du moindre privilège afin que même une exploitation réussie ait un impact limité.
• Examen humain et filtrage des résultats : Pour les cas d’usage à haut risque, tels que la génération de code, les transactions financières ou les actions administratives, exigez un examen humain avant toute exécution. Mettez en place un filtrage automatisé afin de signaler ou de bloquer les résultats correspondant à des schémas dangereux connus. Utilisez des classificateurs de contenu pour détecter les résultats potentiellement malveillants avant qu’ils n’atteignent les systèmes en aval.
• Journalisation, surveillance et audit : Conservez des journaux détaillés des sorties du LLM et de la manière dont elles sont utilisées dans l’ensemble de l’application. Surveillez les anomalies telles que des séquences de commandes inattendues, des schémas de sortie inhabituels ou des erreurs en aval susceptibles d’indiquer des tentatives d’exploitation. Auditez régulièrement les journaux afin d’identifier les lacunes dans les contrôles de gestion des sorties.

Cadre de gestion des risques liés aux LLM et recommandations du secteur

La gestion non sécurisée des sorties est reconnue comme une vulnérabilité majeure dans les nouveaux cadres de sécurité des LLM. Le Top 10 de l’OWASP pour les LLM la considère comme une préoccupation critique, soulignant le risque lié à la transmission de sorties de modèle non validées à des fonctions backend, à des navigateurs ou à d’autres systèmes capables de les exécuter.

Le cadre recommande de considérer les sorties des LLM comme intrinsèquement non fiables, d’appliquer des techniques de validation des entrées au contenu généré par les modèles et de mettre en œuvre des stratégies de défense en profondeur qui ne reposent pas uniquement sur l’ingénierie des prompts ou sur les contraintes des modèles pour empêcher la production de contenus malveillants.

Sécurité de l’IA générative : les recommandations des groupes industriels et des fournisseurs en la matière confortent ces préconisations. Parmi les principes récurrents figurent l’encodage systématique des sorties, la séparation stricte entre le contenu généré par les LLM et les contextes d’exécution, ainsi que la surveillance continue des anomalies dans les sorties.

Les organisations qui intègrent des LLM à leurs systèmes de production doivent aligner leurs contrôles de sécurité sur ces cadres et inclure la gestion non sécurisée des sorties dans leurs modèles de menace. À mesure que l’adoption des LLM se généralise, la surface d’attaque s’étend et la mise en œuvre proactive de mesures d’atténuation devient une exigence fondamentale plutôt qu’une pratique avancée.

Signes et erreurs courantes

Plusieurs signes peuvent indiquer qu’une application est vulnérable en raison d’une gestion non sécurisée des sorties.

Faire confiance par défaut aux résultats produits par un LLM est l’erreur la plus courante. Les développeurs supposent que, puisqu’ils ont rédigé le prompt, les résultats sont sûrs. Ils négligent ainsi l’influence des données fournies par les utilisateurs sur le comportement du modèle, ainsi que l’imprévisibilité inhérente aux modèles génératifs.

Négliger l’assainissement sous prétexte que la sortie « ressemble à du texte » crée des vulnérabilités lorsque ce texte contient du code ou des commandes intégrés. Même des réponses d’apparence anodine peuvent contenir des charges utiles qui s’activent lorsqu’elles sont analysées par des systèmes en aval.

L’exécution automatique des sorties d’un LLM sans validation constitue un grave anti-modèle. Les applications qui transmettent directement les sorties du modèle à eval(), exec(), ou à des interpréteurs de commandes sans les contrôler ouvrent la voie à l’exécution directe de code.

L’intégration directe des sorties dans les interfaces utilisateur ou les requêtes de base de données sans encodage expose les applications aux attaques XSS et par injection. La facilité qui consiste à insérer les réponses du modèle dans des modèles de document sans les échapper introduit un risque évitable.

Les signes d’une exploitation potentielle comprennent des erreurs inattendues dans les systèmes en aval, des entrées de journal anormales faisant apparaître des commandes ou des requêtes inhabituelles, ainsi que des signalements d’utilisateurs concernant des comportements étranges dans les interfaces basées sur des LLM. La surveillance de ces indicateurs permet de détecter rapidement les problèmes liés à une gestion non sécurisée des sorties.

Comment F5 gère-t-il le traitement non sécurisé des sorties ?

F5 traite la gestion non sécurisée des sorties au moyen de contrôles appliqués au niveau du trafic et de la couche applicative, là où les sorties des LLM interagissent avec les systèmes en aval et les utilisateurs.

F5 AI Guardrails, composant essentiel de la F5 AI Security Platform, assure l’application des politiques lors des échanges entre les applications d’IA, les agents et les utilisateurs, notamment grâce à la validation des sorties, qui analyse les réponses des modèles avant qu’elles n’atteignent les systèmes back-end ou les applications clientes. Les organisations peuvent ainsi détecter et bloquer les sorties contenant du contenu potentiellement malveillant, tel que des injections de prompts, des séquences de commandes ou des structures de données inattendues.

Pour les applications web qui affichent du contenu généré par des LLM, les fonctionnalités de pare-feu pour applications web de F5 appliquent une analyse comportementale et une détection basée sur les signatures afin d’identifier les sorties susceptibles de déclencher des attaques XSS, des injections ou d’autres vulnérabilités côté client. La protection s’étend aux API qui consomment les sorties des LLM, en surveillant les charges utiles anormales et en imposant la validation des schémas.

F5 Distributed Cloud Services intègrent des protections dans les déploiements hybrides et multiclouds, tout en maintenant des contrôles cohérents du traitement des sorties, quel que soit l’environnement dans lequel s’exécutent les charges de travail des LLM. Les fonctionnalités de journalisation et de visibilité répondent aux exigences d’audit et permettent aux équipes de sécurité de surveiller la circulation des sorties des LLM dans l’infrastructure applicative.

En positionnant les contrôles aux points où les sorties des LLM entrent dans les applications et parviennent aux utilisateurs, F5 aide les organisations à appliquer par défaut l’assainissement des sorties, plutôt que de s’appuyer uniquement sur une mise en œuvre au niveau applicatif.

Questions fréququemment posées

Comment l’OWASP classe-t-elle la gestion non sécurisée des sorties, et pourquoi la distingue-t-elle des autres risques liés aux LLM ?

L’OWASP définit la gestion non sécurisée des sorties comme une validation, un assainissement et un traitement insuffisants des résultats générés par les LLM. Elle se distingue des autres risques en ce qu’elle concerne spécifiquement les problèmes qui surviennent lorsque ces résultats sont transmis en aval aux utilisateurs sans supervision, contrôles ni gouvernance appropriés.

Quelle est la différence entre l’encodage des sorties et la validation des entrées pour prévenir les attaques XSS dans les applications d’IA ?

La différence entre la validation des entrées et l’encodage des sorties pour prévenir les attaques XSS dans les applications d’IA réside dans le fait que la validation des entrées évalue les données saisies dans le système d’une application, tandis que l’encodage des sorties sécurise le contenu généré lorsqu’il est renvoyé aux utilisateurs. La validation des entrées examine les données qui arrivent dans une application afin de rejeter celles qui ne respectent pas les règles définies ou les formats attendus. L’encodage des sorties convertit les entrées potentiellement dangereuses dans un format permettant de les afficher en toute sécurité comme des données plutôt que comme du code exécutable.

Comment une injection indirecte de prompt peut-elle conduire à l’exécution de code à distance (RCE) en raison d’une gestion non sécurisée des sorties ?

L’injection indirecte de prompt peut être utilisée pour exécuter du code à distance (RCE) en intégrant des instructions malveillantes au contenu fourni au modèle. Ces instructions peuvent demander au modèle de générer des commandes ou des fichiers exécutables, puis de transmettre le résultat à d’autres outils ou systèmes, qui le considèrent comme légitime.

Comment prévenir les injections SQL et la falsification de requêtes côté serveur (SSRF) lors de la connexion de LLM à des bases de données ou à des API internes ?

Pour prévenir les injections SQL et les attaques par falsification de requête côté serveur (SSRF) lors de la connexion à des bases de données ou à des API internes, les sorties des LLM, notamment les commandes, les paramètres, les URL et les arguments d’outils, doivent être traitées comme des données non fiables, et non comme des instructions exécutables. Des solutions de validation, des listes d’autorisation d’API, des requêtes paramétrées et des accès fondés sur le principe du moindre privilège peuvent contribuer à réduire les risques.

Quelle est la différence entre LangChain Guardrails, NVIDIA NeMo Guardrails et les pare-feu d’applications web (WAF) ?

LangChain Guardrails, NVIDIA NeMo Guardrails et les WAF sont des solutions complémentaires. Leur principale différence réside dans le fait qu’elles protègent chacune des aspects distincts des systèmes d’IA d’entreprise. LangChain Guardrails servent à valider les tâches et les agents, sous la forme d’un middleware intégré au code de l’application LLM. NVIDIA NeMo Guardrails se place en amont de l’orchestration du LLM afin de contrôler les dialogues à plusieurs tours et de garantir le respect des sujets définis. Les WAF sont déployés en périphérie du réseau pour assurer une protection contre des menaces telles que les injections SQL, les attaques XSS et les attaques DDoS.