Proteja o seu sistema MCP: 11 riscos comuns e como se proteger contra eles

Este guia explica a segurança do MCP, abordando 11 riscos comuns para os sistemas MCP, da injeção indireta de prompts ao comprometimento de servidores locais, e as medidas práticas que ajudam a proteger contra cada um deles.

Diagram of how MCP works: the MCP host (the AI app) sends tool requests through an MCP client to an MCP server, which offers its tools and returns results to the host.

Os riscos do MCP dividem-se, de forma geral, em três categorias: manipulação de LLM, segurança de dados e de acessos, e vulnerabilidades de infraestrutura.

Como os servidores MCP fornecem frequentemente acesso a uma vasta gama de sistemas internos, o potencial risco de segurança é elevado. No entanto, a probabilidade depende muito da configuração.

Há muitas medidas que os particulares e as empresas podem tomar para garantir que os seus sistemas estão protegidos, e os protocolos devem ser sempre proporcionais às capacidades e aos dados que os servidores MCP ligados possam expor.

O que é o MCP e a segurança do MCP?

O Model Context Protocol (MCP) é uma norma aberta criada pela Anthropic para ligar aplicações baseadas em LLM (ou anfitriões) a sistemas externos.

Um sistema MCP tem três componentes principais: o anfitrião, o cliente e o servidor. O anfitrião, que é muitas vezes um assistente de IA, liga-se a um servidor MCP externo através de um cliente. Pode então enviar pedidos para executar funcionalidades externas (ferramentas) ou obter dados (recursos) ou prompts para adicionar à janela de contexto do LLM.

A segurança do MCP refere-se aos protocolos que protegem as ligações e os componentes de um sistema MCP. Existem vários desafios essenciais exclusivos do MCP, incluindo o facto de as aplicações de IA terem frequentemente capacidades agênticas e de ser possível incorporar instruções maliciosas nas mensagens.

Problemas já conhecidos que não são específicos dos MCP, como a injeção de prompts, a autenticação fraca e as integrações de terceiros inseguras, também representam riscos. Tal como qualquer sistema informático, o MCP depende de uma combinação de protocolos processuais, como utilizar apenas servidores de confiança, e de controlos técnicos, como gateways de API, para garantir a sua proteção.

Qual é a gravidade das ameaças ao MCP?

O MCP tornou-se rapidamente uma tecnologia de LLM popular, e muitas organizações e aplicações de consumo utilizam-no. Como os servidores MCP são programas escritos em código, têm vulnerabilidades como qualquer outra aplicação.

No entanto, quando as organizações utilizam o MCP em implementações controladas, este é geralmente seguro. Há uma diferença significativa entre construir um sistema com servidores de confiança e permissões verificadas e ligar um agente autónomo a uma dúzia de servidores não verificados.

Ameaça n.º 1: injeção indireta de prompts

Um atacante pode colocar instruções dirigidas ao LLM num documento, página web ou resultado de ferramenta devolvido por um servidor MCP. Se o anfitrião adicionar este material à janela de contexto, existe a possibilidade de o LLM o confundir com instruções genuínas.

Além disso, estas instruções podem parecer adequadas à primeira vista. Por exemplo, um pedido de suporte obtido pode indicar ao LLM que exporte registos sensíveis de clientes antes de gerar uma resposta.

Como se proteger contra a injeção indireta de prompts

Normalmente, as injeções de prompts devem ser tratadas ao nível do anfitrião. O conteúdo externo deve ser assinalado como não fidedigno e os pedidos de informações sensíveis devem exigir a aprovação informada de um humano no circuito. Também pode ser útil realizar testes de segurança que recorram a documentos ou dados maliciosos para ver como o anfitrião e o LLM reagem.

Ameaça n.º 2: envenenamento de ferramentas e rug pulls

Num ataque de envenenamento de ferramentas, é adicionado código malicioso à descrição ou ao esquema de uma ferramenta MCP. Isto pode influenciar o LLM na fase de descoberta, quando o MCP expõe pela primeira vez as ferramentas disponíveis.

Um rug pull é um tipo especial de envenenamento de ferramentas em que os metadados aprovados são alterados. Esta forma de envenenamento de ferramentas pode alterar a forma como um modelo utiliza ferramentas de confiança, em vez de invocar diretamente uma ferramenta maliciosa.

Como se proteger contra o envenenamento de ferramentas e os rug pulls

O anfitrião deve inspecionar a definição completa de cada ferramenta antes de a utilizar e compará-la com uma lista de ferramentas de confiança aprovadas, detetando assim quaisquer alterações. As verificações de parâmetros podem ajudar a identificar potenciais capacidades perigosas e a assinalá-las.

Ameaça n.º 3: permissões excessivas

É comum os utilizadores concederem aos servidores MCP e aos LLM ligados (através do anfitrião) mais permissões do que as necessárias para uma tarefa. Por exemplo, permissões de escrita quando bastaria o acesso só de leitura, ou acesso total a um sistema interno de ficheiros (como o Google Drive).

Esta extensa acumulação gradual de permissões pode aumentar o raio de impacto de outras vulnerabilidades, como chamadas maliciosas a ferramentas. É comum que as permissões «se somem» à medida que os utilizadores concedem privilégios no decorrer do seu trabalho diário com ferramentas de IA numa empresa (acumulação de privilégios).

Como se proteger contra permissões excessivas

A forma mais direta de se proteger contra este problema é restringir as permissões e os âmbitos OAuth (leitura, escrita, acesso total, etc.). As aprovações dos utilizadores, sobretudo para operações sensíveis, são uma parte importante disto, mas as permissões também devem ser controladas ao nível do sistema (sistema operativo, anfitrião MCP e servidor).

Ameaça n.º 4: autenticação e autorização fracas

A autenticação verifica a identidade dos utilizadores ou aplicações que se ligam a um servidor MCP. A autorização estipula a que ferramentas e recursos podem aceder.

Os servidores MCP mal configurados podem aceitar pedidos ou tokens sem autenticar corretamente os utilizadores nem aplicar restrições de acesso. Além disso, se a validação for fraca, credenciais roubadas podem permitir que agentes maliciosos obtenham acesso.

Como se proteger contra a autenticação e a autorização fracas

A autenticação baseada em OAuth para servidores MCP remotos, os tokens de curta duração e o controlo de acesso baseado em funções (RBAS) são medidas que ajudam a mitigar a autorização fraca. O acesso baseado em funções é útil porque impede que os utilizadores acedam a dados e ferramentas para além das suas permissões, mesmo que o próprio servidor tenha acesso.

Ameaça n.º 5: fuga e utilização indevida de credenciais

Os servidores MCP utilizam habitualmente credenciais como chaves de API e tokens de acesso OAuth para se ligarem a serviços externos. Se estas forem expostas ou utilizadas indevidamente, os atacantes podem obter acesso a dados e funcionalidades sensíveis.

Um exemplo é a passagem de tokens (token passthrough), em que um servidor MCP reencaminha um token de acesso para outro serviço sem verificar se este se destina efetivamente ao serviço recetor. Isto, por sua vez, pode resultar em fugas se o serviço recetor tiver proteções inadequadas.

Como se proteger contra a fuga e a utilização indevida de credenciais

Os tokens de curta duração e de âmbito restrito e a rotação de credenciais são eficazes para limitar a medida em que os dados divulgados podem ser utilizados por agentes maliciosos. As chaves de API e as credenciais devem ser sempre armazenadas de forma segura num gestor de segredos.

Ameaça n.º 6: ataques de confused deputy

Um ataque de confused deputy (representante confuso) ocorre quando um atacante engana uma aplicação de confiança para que esta utilize as suas permissões para realizar uma ação não autorizada por um utilizador legítimo. Neste caso, o servidor MCP é o representante (deputy).

O atacante explora uma vulnerabilidade do servidor MCP (como verificações OAuth fracas) para executar um processo malicioso, como uma chamada de ferramenta ou uma obtenção de dados.

Como se proteger contra ataques de confused deputy

A validação da autorização, em que se verifica que cada chamada de ferramenta pertence a um utilizador específico, ajuda a limitar os ataques de confused deputy. Além disso, as ações sensíveis, como as exportações de dados, devem exigir autorização explícita.

Ameaça n.º 7: servidores maliciosos e dependências comprometidas

Os servidores MCP podem conter código malicioso (são essencialmente programas externos) ou recorrer a dependências comprometidas, como bibliotecas de terceiros. Trata-se de um problema da cadeia de fornecimento de software, e não de um problema exclusivo do MCP.

Uma forma simples de isto acontecer é um atacante distribuir uma integração que parece legítima. Depois de configurada, pode roubar e reutilizar credenciais, aceder a dados sensíveis e executar operações não autorizadas.

Como se proteger contra servidores maliciosos e dependências comprometidas

Instale servidores MCP apenas a partir de fontes de confiança e verificadas. Se possível, reveja o respetivo código e verifique sempre quaisquer dependências externas. Garanta que os servidores são atualizados e corrigidos regularmente.

Ameaça n.º 8: falsificação de pedidos do lado do servidor (SSRF)

A falsificação de pedidos do lado do servidor (SSRF) ocorre quando um atacante engana um servidor MCP para que este envie pedidos de rede para endereços internos aos quais o utilizador não pretendia aceder.

Isto pode acontecer quando um servidor MCP expõe uma ferramenta que obtém informações a partir de um URL. Se um atacante conseguir influenciar o parâmetro do URL, pode alterá-lo para o endereço de rede que pretender, como uma API interna ou um serviço na nuvem. Isto pode fazer com que dados sensíveis sejam obtidos e potencialmente tornados acessíveis

Como se proteger contra a falsificação de pedidos do lado do servidor (SSRF)

Os servidores MCP devem validar sempre os URL, bloquear o acesso a endereços de rede internos restritos e impedir o acesso de rede de saída. Os redirecionamentos também devem seguir este protocolo.

Ameaça n.º 9: sequestro de sessão

O sequestro de sessão consiste num atacante assumir o controlo de uma ligação ativa entre um cliente MCP e um servidor.

Por exemplo, o atacante pode roubar um identificador de sessão de uma aplicação MCP mal protegida (por exemplo, um anfitrião ou um servidor). Se o servidor MCP aceitar este identificador, o atacante pode potencialmente chamar ferramentas com as permissões legítimas do utilizador.

Como se proteger contra

O risco de sequestro de sessão pode ser reduzido com uma verificação rigorosa da identidade em todas as aplicações de um sistema MCP. A encriptação entre os clientes MCP e os servidores remotos também é essencial para impedir que os identificadores de sessão sejam descobertos.

Ameaça n.º 10: ataques de confusão (mix-up)

Num ataque de confusão (mix-up), o atacante engana um cliente MCP para que este envie um código de autorização para um servidor de autorização malicioso situado entre o cliente e o servidor MCP. Um servidor de autorização é uma aplicação que emite tokens de acesso OAuth depois de verificar se o acesso solicitado está autorizado.

Se um anfitrião MCP se ligar a vários serviços, cada um com um servidor de autorização diferente, um atacante pode potencialmente controlar um deles (por exemplo, registando um serviço malicioso) e fazer com que o cliente envie um código de autorização emitido por um servidor legítimo para o servidor malicioso. Esta confusão pode permitir que o atacante se faça passar pela aplicação autorizada e obtenha acesso a serviços protegidos.

Como se proteger contra ataques de confusão (mix-up)

Os clientes MCP devem verificar a identidade do servidor de autorização ao longo de todo o processo OAuth. Especificamente, devem comparar o identificador do emissor (iss) do servidor com a identidade esperada e rejeitar as discrepâncias.

Ameaça n.º 11: comprometimento de servidores MCP locais

Muitos servidores MCP são executados na máquina local do utilizador, que pode instalar o servidor a partir de um terceiro ou criá-lo por conta própria. Se um atacante conseguir comprometer este servidor MCP local, pode potencialmente obter acesso a grande parte do sistema local.

Um atacante pode obter acesso de várias formas. Pode distribuir um servidor malicioso disfarçado de integração legítima, modificar a configuração de um anfitrião MCP de modo a que este emita um comando malicioso, ou aceder a um servidor MCP executado num ambiente com controlos de segurança insuficientes, por exemplo, através de DNS rebinding, que engana um navegador para que envie pedidos a um serviço localhost.

Como se proteger contra o comprometimento de servidores MCP locais

O isolamento em sandbox e os protocolos de consentimento rigorosos são importantes quando se utilizam servidores MCP locais. Os servidores MCP só devem ser instalados a partir de fornecedores de confiança, e as permissões do sistema operativo devem restringir os diretórios a que podem aceder.

As vulnerabilidades do MCP são muitas vezes ameaças antigas com uma nova roupagem

As vulnerabilidades do MCP resultam frequentemente de novas aplicações de riscos e metodologias de ataque já conhecidos. O MCP introduz novas formas de os atacantes explorarem estas vulnerabilidades através das interações entre LLM, servidores MCP e serviços externos.

É certo que existem ameaças específicas do MCP. No entanto, vale a pena ter em conta que os protocolos de segurança padrão, como aplicar uma autorização rigorosa, utilizar fornecedores de confiança e proteger contra injeções de prompts, contribuem muito para proteger qualquer implementação do MCP.