Protexe o teu sistema MCP: 11 riscos comúns e como protexerse contra eles

Os riscos do MCP divídense, en liñas xerais, en tres categorías: manipulación do LLM, seguridade dos datos e do acceso, e vulnerabilidades da infraestrutura.

Como os servidores MCP adoitan dar acceso a unha gran variedade de sistemas internos, o risco potencial para a seguridade é elevado. Porén, a probabilidade depende moito da configuración.

Hai moitas medidas que as persoas e as empresas poden adoptar para garantir que os seus sistemas estean protexidos, e os protocolos deben ser sempre proporcionais ás capacidades e aos datos que poidan expor os servidores MCP conectados.

Que é o MCP e que é a seguridade do MCP?

O Model Context Protocol (MCP) é un estándar aberto creado por Anthropic para conectar aplicacións baseadas en LLM (ou hosts) con sistemas externos.

Un sistema MCP ten tres compoñentes principais: o host, o cliente e o servidor. O host, que adoita ser un asistente de IA, conéctase a un servidor MCP externo a través dun cliente. Despois pode enviar solicitudes para executar funcionalidades externas (ferramentas) ou recuperar datos (recursos) ou prompts para engadir á xanela de contexto do LLM.

Ampliar

A seguridade do MCP refírese aos protocolos que protexen as conexións e os compoñentes dun sistema MCP. Hai varios desafíos clave exclusivos do MCP, como o feito de que as aplicacións de IA adoitan ter capacidades axénticas e de que se poden incrustar instrucións maliciosas nas mensaxes.

Os problemas coñecidos que non son específicos do MCP, como a inxección de prompts, a autenticación débil e as integracións de terceiros inseguras, tamén supoñen un risco. Como en calquera sistema informático, o MCP depende dunha combinación de protocolos procedementais, como usar só servidores de confianza, e de controis técnicos, como as pasarelas de API, para a súa protección.

Que gravidade teñen as ameazas do MCP?

O MCP converteuse rapidamente nunha tecnoloxía de LLM popular, e moitas organizacións e aplicacións de consumo utilízano. Como os servidores MCP son programas escritos en código, teñen vulnerabilidades coma calquera outra aplicación.

Porén, cando as organizacións usan o MCP en despregamentos controlados, en xeral é seguro. Hai unha diferenza enorme entre construír un sistema con servidores de confianza e permisos verificados e conectar un axente autónomo a unha ducia de servidores sen verificar.

Ameaza n.º 1: inxección indirecta de prompts

Un atacante pode colocar instrucións dirixidas ao LLM dentro dun documento, unha páxina web ou un resultado dunha ferramenta que devolva un servidor MCP. Se o host engade este material á xanela de contexto, é posible que o LLM o confunda con instrucións auténticas.

Ademais, estas instrucións poden parecer apropiadas a primeira vista. Por exemplo, unha incidencia de soporte recuperada podería indicarlle ao LLM que exporte rexistros confidenciais de clientes antes de xerar unha resposta.

Como protexerse contra a inxección indirecta de prompts

As inxeccións de prompts adoitan tratarse no nivel do host. O contido externo debe etiquetarse como non fiable, e as solicitudes de información confidencial deben requirir a aprobación informada dunha persoa que supervise o proceso. Tamén poden ser útiles as probas de seguridade que consisten en chamar documentos ou datos maliciosos para ver como responden o host e o LLM.

Ameaza n.º 2: envelenamento de ferramentas e rug pulls

Nun ataque de envelenamento de ferramentas, engádese código malicioso á descrición ou ao esquema dunha ferramenta MCP. Isto pode influír no LLM durante a fase de descubrimento, cando o MCP expón por primeira vez as ferramentas dispoñibles.

Ampliar

Un rug pull é un tipo especial de envelenamento de ferramentas no que se modifican metadatos aprobados. Esta forma de envelenamento de ferramentas pode cambiar a maneira en que un modelo usa ferramentas de confianza, en vez de invocar directamente unha ferramenta maliciosa.

Como protexerse contra o envelenamento de ferramentas e os rug pulls

O host debe inspeccionar a definición completa de cada ferramenta antes de usala e comparala cunha lista de ferramentas de confianza aprobadas, para detectar así calquera cambio. As comprobacións de parámetros poden axudar a identificar capacidades potencialmente perigosas e sinalalas.

Ameaza n.º 3: permisos excesivos

É habitual que os usuarios concedan aos servidores MCP e aos LLM conectados (a través do host) máis permisos dos necesarios para unha tarefa. Por exemplo, permisos de escritura cando bastaría con permisos de só lectura, ou acceso completo a un sistema interno de ficheiros (como Google Drive).

Esta ampla acumulación progresiva de permisos pode aumentar o alcance dos danos doutras vulnerabilidades, como as chamadas a ferramentas maliciosas. É habitual que os permisos se vaian “sumando” a medida que os usuarios conceden privilexios no seu traballo diario con ferramentas de IA nunha empresa (acumulación de privilexios).

Como protexerse contra os permisos excesivos

A forma máis directa de protexerse contra este problema é restrinxir os permisos e os ámbitos de OAuth (lectura, escritura, acceso completo, etc.). As aprobacións dos usuarios, especialmente para operacións confidenciais, son unha parte importante disto, pero os permisos tamén deben controlarse no nivel do sistema (sistema operativo, host MCP e servidor).

Ameaza n.º 4: autenticación e autorización débiles

A autenticación verifica a identidade dos usuarios ou aplicacións que se conectan a un servidor MCP. A autorización establece a que ferramentas e recursos poden acceder.

Os servidores MCP mal configurados poden aceptar solicitudes ou tokens sen autenticar correctamente os usuarios nin aplicar restricións de acceso. Ademais, se a validación é débil, as credenciais roubadas poden permitir o acceso a actores maliciosos.

Como protexerse contra a autenticación e a autorización débiles

A autenticación baseada en OAuth para servidores MCP remotos, os tokens de curta duración e o control de acceso baseado en roles (RBAS) son medidas que axudan a mitigar a autorización débil. O acceso baseado en roles é útil porque impide que os usuarios accedan a datos e ferramentas que superen os seus permisos, aínda que o propio servidor teña acceso.

Ameaza n.º 5: filtracións e uso indebido de credenciais

Os servidores MCP usan habitualmente credenciais como claves de API e tokens de acceso de OAuth para conectarse a servizos externos. Se estas quedan expostas ou se usan indebidamente, os atacantes poden acceder a datos e funcionalidades confidenciais.

Un exemplo é o token passthrough (reenvío de tokens), no que un servidor MCP reenvía un token de acceso a outro servizo sen verificar que realmente estea destinado ao servizo receptor. Isto, á súa vez, pode provocar filtracións se o servizo receptor ten proteccións insuficientes.

Como protexerse contra as filtracións e o uso indebido de credenciais

Os tokens de curta duración e de alcance limitado, así como a rotación de credenciais, son eficaces para limitar ata que punto os actores maliciosos poden usar os datos filtrados. As claves de API e as credenciais deben almacenarse sempre de forma segura mediante un xestor de segredos.

Ameaza n.º 6: ataques de deputado confuso

Un ataque de deputado confuso prodúcese cando un atacante engana unha aplicación de confianza para que use os seus permisos para realizar unha acción que non autorizou un usuario lexítimo. Neste caso, o servidor MCP é o deputado.

Ampliar

O atacante aproveitará unha vulnerabilidade do servidor MCP (como verificacións de OAuth débiles) para executar un proceso malicioso, como unha chamada a unha ferramenta ou unha recuperación de datos.

Como protexerse contra os ataques de deputado confuso

A validación da autorización, na que se verifica que cada chamada a unha ferramenta pertence a un usuario concreto, axuda a limitar os ataques de deputado confuso. Ademais, as accións confidenciais, como as exportacións de datos, deben requirir unha autorización explícita.

Ameaza n.º 7: servidores maliciosos e dependencias comprometidas

Os servidores MCP poden conter código malicioso (son, en esencia, programas externos) ou depender de compoñentes comprometidos, como bibliotecas de terceiros. Trátase dun problema da cadea de subministración de software, máis que dun problema exclusivo do MCP.

Unha forma sinxela de que isto ocorra é que un atacante distribúa unha integración que pareza lexítima. Unha vez configurada, pode roubar e reutilizar credenciais, acceder a datos confidenciais e executar operacións non autorizadas.

Como protexerse contra os servidores maliciosos e as dependencias comprometidas

Instala servidores MCP só de fontes de confianza e verificadas. Se é posible, revisa o seu código e comproba sempre calquera dependencia externa. Asegúrate de que os servidores se actualicen e se lles apliquen parches regularmente.

Ameaza n.º 8: falsificación de solicitudes do lado do servidor (SSRF)

A falsificación de solicitudes do lado do servidor (SSRF) prodúcese cando un atacante engana un servidor MCP para que envíe solicitudes de rede a enderezos internos aos que o usuario non pretendía acceder.

Isto pode ocorrer cando un servidor MCP expón unha ferramenta que recupera información dun URL. Se un atacante pode influír no parámetro do URL, pode cambialo polo enderezo de rede que desexe, como unha API interna ou un servizo na nube. Isto pode provocar que se recuperen datos confidenciais e que, potencialmente, queden accesibles

Como protexerse contra a falsificación de solicitudes do lado do servidor (SSRF)

Os servidores MCP deben validar sempre os URL, bloquear o acceso a enderezos de rede internos restrinxidos e impedir o acceso de rede saínte. As redireccións tamén deben seguir este protocolo.

Ameaza n.º 9: secuestro de sesión

O secuestro de sesión consiste en que un atacante toma o control dunha conexión activa entre un cliente MCP e un servidor.

Por exemplo, pode roubar un identificador de sesión dunha aplicación MCP mal protexida (por exemplo, un host ou un servidor). Se o servidor MCP acepta este identificador, o atacante pode chamar ferramentas cos permisos lexítimos do usuario.

Como protexerse contra

O risco de secuestro de sesión pódese reducir cunha verificación estrita da identidade en todas as aplicacións dun sistema MCP. O cifrado entre os clientes MCP e os servidores remotos tamén é esencial para evitar que se identifiquen os identificadores de sesión.

Ameaza n.º 10: ataques de confusión (mix-up)

Nun ataque de confusión (mix-up), o atacante engana un cliente MCP para que envíe un código de autorización a un servidor de autorización malicioso situado entre o cliente e o servidor MCP. Un servidor de autorización é unha aplicación que emite tokens de acceso de OAuth despois de comprobar que o acceso solicitado está autorizado.

Ampliar

Se un host MCP se conecta a varios servizos, cada un cun servidor de autorización diferente, un atacante pode chegar a controlar un deles (quizais rexistrando un servizo malicioso) e facer que o cliente envíe ao servidor malicioso un código de autorización emitido por un servidor lexítimo. Esta confusión pode permitirlle ao atacante suplantar a aplicación autorizada e acceder a servizos protexidos.

Como protexerse contra os ataques de confusión

Os clientes MCP deben verificar a identidade do servidor de autorización durante todo o proceso de OAuth. En concreto, deben comprobar o identificador do emisor do servidor (iss) coa identidade esperada e rexeitar as discrepancias.

Ameaza n.º 11: compromiso dun servidor MCP local

Moitos servidores MCP execútanse na máquina local do usuario. Os usuarios poden instalar o servidor dun terceiro ou crealo eles mesmos. Se un atacante consegue comprometer este servidor MCP local, pode chegar a acceder a grandes partes do sistema local.

Hai varias formas polas que un atacante pode obter acceso. Pode distribuír un servidor malicioso disfrazado de integración lexítima, modificar a configuración dun host MCP para que emita un comando malicioso ou acceder a un servidor MCP que se executa nun contorno con controis de seguridade insuficientes, por exemplo mediante DNS rebinding, que engana un navegador para que envíe solicitudes a un servizo de localhost.

Como protexerse contra o compromiso de servidores MCP locais

A execución en contornos illados e os protocolos estritos de consentimento son importantes cando se usan servidores MCP locais. Os servidores MCP só se deben instalar desde provedores de confianza, e os permisos do sistema operativo deben restrinxir os directorios aos que poden acceder.

As vulnerabilidades do MCP adoitan ser vellas ameazas con roupa nova

As vulnerabilidades do MCP adoitan xurdir de novas aplicacións de riscos e metodoloxías de ataque xa coñecidos. O MCP introduce novas formas de que os atacantes aproveiten estas vulnerabilidades a través das interaccións entre os LLM, os servidores MCP e os servizos externos.

Por suposto, existen ameazas específicas do MCP. Porén, convén ter presente que os protocolos de seguridade estándar, como aplicar unha autorización estrita, usar provedores de confianza e protexerse contra as inxeccións de prompts, contribúen moito a protexer calquera implementación do MCP.