Sécurisez votre système MCP : 11 risques courants et comment s’en protéger

Les risques liés au MCP se répartissent globalement en trois catégories : la manipulation des LLM, la sécurité des données et des accès, et les vulnérabilités de l’infrastructure.

Comme les serveurs MCP donnent souvent accès à un large éventail de systèmes internes, le risque potentiel pour la sécurité est élevé. Toutefois, la probabilité dépend fortement de la configuration.

Les particuliers et les entreprises peuvent prendre de nombreuses mesures pour s’assurer que leurs systèmes sont protégés, et les protocoles devraient toujours être proportionnés aux capacités et aux données que les serveurs MCP connectés pourraient exposer.

Qu’est-ce que le MCP et la sécurité MCP?

Le Model Context Protocol (MCP) est une norme ouverte créée par Anthropic pour connecter des applications basées sur des LLM (ou hôtes) à des systèmes externes.

Un système MCP comporte trois composants principaux : l’hôte, le client et le serveur. L’hôte, qui est souvent un assistant d’IA, se connecte à un serveur MCP externe par l’intermédiaire d’un client. Il peut ensuite envoyer des requêtes pour exécuter des fonctionnalités externes (outils) ou récupérer des données (ressources) ou des invites à ajouter à la fenêtre de contexte du LLM.

Agrandir

La sécurité MCP désigne les protocoles qui protègent les connexions et les composants d’un système MCP. Plusieurs défis clés sont propres au MCP, notamment le fait que les applications d’IA ont souvent des capacités agentiques et que des instructions malveillantes peuvent être intégrées dans les messages.

Des enjeux bien connus qui ne sont pas propres au MCP, comme l’injection d’invite, l’authentification faible et les intégrations tierces non sécurisées, posent aussi problème. Comme tout système informatique, le MCP repose sur une combinaison de protocoles procéduraux, comme le fait de n’utiliser que des serveurs de confiance, et de contrôles techniques, comme les passerelles d’API, pour assurer sa protection.

Quelle est la gravité des menaces liées au MCP?

Le MCP est rapidement devenu une technologie de LLM populaire, et de nombreuses organisations et applications grand public l’utilisent. Comme les serveurs MCP sont des programmes écrits en code, ils présentent des vulnérabilités comme n’importe quelle autre application.

Cependant, lorsque les organisations utilisent le MCP dans des déploiements contrôlés, il est généralement sûr. Il y a un écart important entre bâtir un système avec des serveurs de confiance et des permissions vérifiées, et brancher un agent autonome à une douzaine de serveurs non vérifiés.

Menace n° 1 : injection d’invite indirecte

Un attaquant peut placer des instructions ciblant le LLM dans un document, une page Web ou une sortie d’outil qu’un serveur MCP renvoie. Si l’hôte ajoute ce contenu à la fenêtre de contexte, il est possible que le LLM le prenne pour de véritables instructions.

De plus, ces instructions peuvent sembler appropriées à première vue. Par exemple, un billet de soutien récupéré pourrait ordonner au LLM d’exporter des dossiers clients sensibles avant de générer une réponse.

Comment se protéger contre l’injection d’invite indirecte

Les injections d’invite devraient généralement être traitées au niveau de l’hôte. Le contenu externe devrait être étiqueté comme non fiable, et les demandes d’informations sensibles devraient exiger l’approbation éclairée d’un humain dans la boucle. Des tests de sécurité consistant à appeler des documents ou des données malveillants pour voir comment l’hôte et le LLM réagissent peuvent aussi être utiles.

Menace n° 2 : empoisonnement d’outils et rug pulls

Dans une attaque par empoisonnement d’outils, du code malveillant est ajouté à la description ou au schéma d’un outil MCP. Cela peut influencer le LLM pendant la phase de découverte, lorsque le MCP expose pour la première fois les outils disponibles.

Agrandir

Un rug pull est un type particulier d’empoisonnement d’outils dans lequel des métadonnées approuvées sont modifiées. Cette forme d’empoisonnement d’outils peut changer la façon dont un modèle utilise des outils de confiance, plutôt que d’invoquer directement un outil malveillant.

Comment se protéger contre l’empoisonnement d’outils et les rug pulls

L’hôte devrait inspecter la définition complète de chaque outil avant de l’utiliser et la comparer à une liste d’outils de confiance approuvés, afin de détecter tout changement. Des vérifications de paramètres peuvent aider à repérer les capacités potentiellement dangereuses et à les signaler.

Menace n° 3 : permissions excessives

Il est courant que les utilisateurs accordent aux serveurs MCP et aux LLM connectés (par l’intermédiaire de l’hôte) plus de permissions que nécessaire pour une tâche. Par exemple, des permissions d’écriture alors qu’une lecture seule suffirait, ou un accès complet à un système de fichiers interne (comme Google Drive).

Cette dérive importante des permissions peut accroître le rayon d’impact d’autres vulnérabilités, comme les appels d’outils malveillants. Il est courant que les permissions « s’additionnent » à mesure que les utilisateurs accordent des privilèges dans le cadre de leur travail quotidien avec des outils d’IA en entreprise (accumulation de privilèges).

Comment se protéger contre les permissions excessives

Le moyen le plus direct de se protéger contre ce problème est de restreindre les permissions et les portées OAuth (lecture, écriture, accès complet, etc.). Les approbations des utilisateurs, surtout pour les opérations sensibles, en sont un élément important, mais les permissions devraient aussi être contrôlées au niveau du système (système d’exploitation, hôte MCP et serveur).

Menace n° 4 : authentification et autorisation faibles

L’authentification vérifie l’identité des utilisateurs ou des applications qui se connectent à un serveur MCP. L’autorisation détermine les outils et les ressources auxquels ils peuvent accéder.

Des serveurs MCP mal configurés peuvent accepter des requêtes ou des jetons sans authentifier correctement les utilisateurs ni appliquer les restrictions d’accès. De plus, des identifiants volés peuvent permettre à des acteurs malveillants d’obtenir un accès si la validation est faible.

Comment se protéger contre une authentification et une autorisation faibles

L’authentification basée sur OAuth pour les serveurs MCP distants, les jetons à courte durée de vie et le contrôle d’accès basé sur les rôles (RBAS) sont autant de mesures qui aident à contrer une autorisation faible. L’accès basé sur les rôles est utile, car il empêche les utilisateurs d’accéder à des données et à des outils au-delà de leurs permissions, même si le serveur lui-même y a accès.

Menace n° 5 : fuite et utilisation abusive d’identifiants

Les serveurs MCP utilisent couramment des identifiants comme des clés d’API et des jetons d’accès OAuth pour se connecter à des services externes. Si ceux-ci sont exposés ou utilisés de façon abusive, des attaquants peuvent accéder à des données et à des fonctionnalités sensibles.

Un exemple est la transmission directe de jetons (token passthrough), où un serveur MCP transmet un jeton d’accès à un autre service sans vérifier qu’il est bel et bien destiné au service destinataire. Cela peut à son tour entraîner une fuite si le service destinataire n’a pas de protections adéquates.

Comment se protéger contre la fuite et l’utilisation abusive d’identifiants

Les jetons à courte durée de vie et à portée restreinte ainsi que la rotation des identifiants permettent de limiter efficacement la mesure dans laquelle des données divulguées peuvent être utilisées par des acteurs malveillants. Les clés d’API et les identifiants devraient toujours être stockés de façon sécurisée à l’aide d’un gestionnaire de secrets.

Menace n° 6 : attaques de l’adjoint confus (confused deputy)

Une attaque de l’adjoint confus se produit lorsqu’un attaquant amène par la ruse une application de confiance à utiliser ses permissions pour effectuer une action qui n’est pas autorisée par un utilisateur légitime. Dans ce cas, le serveur MCP est l’adjoint.

Agrandir

L’attaquant exploite une vulnérabilité du serveur MCP (comme des vérifications OAuth faibles) pour exécuter un processus malveillant, comme un appel d’outil ou une récupération de données.

Comment se protéger contre les attaques de l’adjoint confus

La validation des autorisations, qui consiste à vérifier que chaque appel d’outil appartient à un utilisateur précis, aide à limiter les attaques de l’adjoint confus. De plus, les actions sensibles, comme les exportations de données, devraient exiger une autorisation explicite.

Menace n° 7 : serveurs malveillants et dépendances compromises

Les serveurs MCP peuvent contenir du code malveillant (ce sont essentiellement des programmes externes) ou s’appuyer sur des dépendances compromises, comme des bibliothèques tierces. Il s’agit d’un problème de chaîne d’approvisionnement logicielle, plutôt que d’un problème propre au MCP.

Un scénario simple serait qu’un attaquant distribue une intégration qui semble légitime. Une fois configurée, elle peut voler et réutiliser des identifiants, accéder à des données sensibles et exécuter des opérations non autorisées.

Comment se protéger contre les serveurs malveillants et les dépendances compromises

N’installez des serveurs MCP qu’à partir de sources fiables et vérifiées. Si possible, examinez leur code et vérifiez toujours les dépendances externes. Assurez-vous que les serveurs sont régulièrement mis à jour et corrigés.

Menace n° 8 : falsification de requêtes côté serveur (SSRF)

La falsification de requêtes côté serveur (SSRF) se produit lorsqu’un attaquant amène par la ruse un serveur MCP à envoyer des requêtes réseau vers des adresses internes auxquelles l’utilisateur n’avait pas l’intention d’accéder.

Cela peut se produire lorsqu’un serveur MCP expose un outil qui récupère des informations à partir d’une URL. Si un attaquant peut influencer le paramètre d’URL, il peut le remplacer par l’adresse réseau de son choix, comme une API interne ou un service infonuagique. Cela peut entraîner la récupération de données sensibles et, potentiellement, leur mise à disposition

Comment se protéger contre la falsification de requêtes côté serveur (SSRF)

Les serveurs MCP devraient toujours valider les URL, bloquer l’accès aux adresses réseau internes restreintes et empêcher l’accès réseau sortant. Les redirections devraient aussi suivre ce protocole.

Menace n° 9 : détournement de session

Le détournement de session consiste pour un attaquant à prendre le contrôle d’une connexion active entre un client MCP et un serveur.

Par exemple, l’attaquant pourrait voler un identifiant de session à partir d’une application MCP mal sécurisée (p. ex., un hôte ou un serveur). Si le serveur MCP accepte cet identifiant, l’attaquant peut potentiellement appeler des outils avec les permissions légitimes de l’utilisateur.

Comment se protéger contre

Le risque de détournement de session peut être réduit grâce à une vérification stricte de l’identité dans toutes les applications d’un système MCP. Le chiffrement entre les clients MCP et les serveurs distants est aussi essentiel pour empêcher que les identifiants de session soient découverts.

Menace n° 10 : attaques par confusion (mix-up)

Dans une attaque par confusion, l’attaquant amène par la ruse un client MCP à envoyer un code d’autorisation à un serveur d’autorisation malveillant situé entre le client et le serveur MCP. Un serveur d’autorisation est une application qui émet des jetons d’accès OAuth après avoir vérifié que l’accès demandé est autorisé.

Agrandir

Si un hôte MCP se connecte à plusieurs services qui utilisent chacun un serveur d’autorisation différent, un attaquant peut potentiellement en contrôler un (par exemple en enregistrant un service malveillant) et amener le client à envoyer au serveur malveillant un code d’autorisation émis par un serveur légitime. Cette confusion peut permettre à l’attaquant d’usurper l’identité de l’application autorisée et d’accéder à des services protégés.

Comment se protéger contre les attaques par confusion

Les clients MCP devraient vérifier l’identité du serveur d’autorisation tout au long du processus OAuth. Plus précisément, ils devraient comparer l’identifiant d’émetteur (iss) du serveur à l’identité attendue et rejeter toute non-concordance.

Menace n° 11 : compromission d’un serveur MCP local

De nombreux serveurs MCP s’exécutent sur l’ordinateur local d’un utilisateur. Celui-ci peut installer le serveur à partir d’un tiers ou le créer lui-même. Si un attaquant parvient à compromettre ce serveur MCP local, il peut potentiellement accéder à de grandes parties du système local.

Un attaquant peut obtenir l’accès de diverses façons. Il peut distribuer un serveur malveillant déguisé en intégration légitime, modifier la configuration d’un hôte MCP de sorte qu’il émette une commande malveillante, ou accéder à un serveur MCP qui s’exécute dans un environnement dont les contrôles de sécurité sont insuffisants, par exemple au moyen de la réassociation DNS (DNS rebinding), qui amène par la ruse un navigateur à envoyer des requêtes à un service localhost.

Comment se protéger contre la compromission d’un serveur MCP local

L’isolement en bac à sable et des protocoles de consentement stricts sont importants lorsqu’on utilise des serveurs MCP locaux. Les serveurs MCP ne devraient jamais être installés qu’à partir de fournisseurs de confiance, et les permissions du système d’exploitation devraient restreindre les répertoires auxquels ils peuvent accéder.

Les vulnérabilités du MCP sont souvent de vieilles menaces habillées de neuf

Les vulnérabilités du MCP découlent souvent de nouvelles applications de risques et de méthodes d’attaque bien établis. Le MCP offre aux attaquants de nouvelles façons d’exploiter ces vulnérabilités par l’entremise des interactions entre les LLM, les serveurs MCP et les services externes.

Certes, des menaces propres au MCP existent. Toutefois, il vaut la peine de garder à l’esprit que des protocoles de sécurité standards, comme l’application d’autorisations strictes, le recours à des fournisseurs de confiance et la protection contre les injections d’invite, contribueront grandement à protéger toute implémentation du MCP.