Checklist de Proteção SSRF para MCP Fetch

Uma ferramenta de URL pode alcançar o que o servidor MCP pode alcançar.

Se esse servidor estiver em uma nuvem, CI, laptop, VPC ou cluster, a busca aberta se torna um limite de credenciais e rede interna.

O padrão seguro é negar alvos perigosos antes que a solicitação saia do tempo de execução.

Resposta rápida

Um servidor MCP de busca não é apenas uma ferramenta de leitura. É uma saída de rede executando de onde quer que o host do agente esteja.
A proteção SSRF deve ser executada antes da solicitação HTTP: analisar a URL, resolver DNS, classificar cada endereço resolvido, aplicar política de redirecionamento e negar metadados, loopback, privado, IPv6 ULA e alvos em cluster por padrão.
Permitir URLs públicas não é o mesmo que permitir serviços internos. A busca interna precisa de seu próprio cartão de rota com chamador, inquilino, alvo, lane de credencial, proprietário de cota, proprietário de revisão e campos de recibo.
A prova de aprovação/reprovação é emparelhada: uma URL externa permitida e um vizinho negado, como 169.254.169.254, devem passar pelo mesmo ponto de extremidade, gateway, tentativa e caminho de rastreamento.

Regra do operador

A negação de SSRF é um resultado de controle bem-sucedido.

Uma solicitação de metadados ou rede privada bloqueada não deve parecer uma rede instável. Deve deixar um recibo de política digitado que prove qual lane de credencial e classe de alvo foram protegidas.

A lista de verificação de produção

1. Portão de análise de URL

Rejeitar esquemas ausentes, surpresas de informações do usuário, truques de host codificados, esquemas não-HTTP, entradas excessivamente longas e normalização ambígua antes da resolução de DNS.

2. Classificação de DNS e IP

Resolver o nome do host no momento da solicitação, classificar cada resultado A/AAAA e negar endereços link-local, loopback, privados, NAT de grau de transportadora, multicast, IPv6 ULA e endereços de rede de serviço por padrão.

3. Contenção de redirecionamento

Aplicar a mesma política de host e IP após cada redirecionamento. Uma primeira URL segura não pode redirecionar para metadados, loopback ou infraestrutura privada.

4. Isolamento de lane de credencial

Registrar qual servidor, função de nuvem, proxy, token, jar de cookies ou credencial de provedor seria exposto se a solicitação fosse permitida.

5. Exceção de rota interna

Se o acesso interno for intencional, exigir um cartão de rota nomeado com host/CIDR alvo, chamador, inquilino, propósito, proprietário de revisão, lane de credencial e proprietário de cota.

6. Recibo de negação digitado

Retornar uma negação de política com URL bruta, host normalizado, classe IP resolvida, id da regra, lane de credencial bloqueada e dica de recuperação em vez de uma falha de rede genérica.

Vizinhos negados

Emparelhar cada URL permitida com a classe de alvo que deve falhar.

Metadados da nuvem

Exemplos: 169.254.169.254, metadata.google.internal, dados de instância, aliases no estilo IMDS.

Esperado: negar antes da solicitação; o recibo nomeia a política de metadados/link-local e a lane de credencial protegida.

Loopback

Exemplos: 127.0.0.1, ::1, localhost, codificações de host decimal/hexadecimal/octal.

Esperado: negar antes da solicitação; o recibo mostra o host normalizado e a classificação de loopback.

Rede privada

Exemplos: 10.0.0.0/8, 172.16/12, 192.168/16, fd00::/8, intervalos de serviço do Kubernetes.

Esperado: negar a menos que um cartão de rota interno específico autorize esse alvo para o chamador e inquilino.

Redirecionar para alvo privado

Exemplos: URL pública retornando 30x para metadados, loopback ou endereço RFC1918.

Esperado: reexecutar a política de DNS/IP no redirecionamento e negar com o salto de redirecionamento preservado no rastreamento.

Evidência de rastreamento

A proteção SSRF de busca é apenas de nível operador se a negação for reconstruível. Armazenar evidências suficientes para mostrar que o alvo foi classificado e bloqueado antes que qualquer credencial, proxy, cookie ou função de nuvem fosse exposta.

O recibo deve incluir:

chamador / inquilino / espaço de trabalho
rota da ferramenta e família de ponto de extremidade
URL bruta e URL normalizada
host e porta normalizados
respostas DNS e endereço selecionado
classe IP e regra de política
cadeia de redirecionamento e alvo final
lane de credencial ou função de servidor protegida
proprietário de cota / orçamento
decisão de política e código de negação digitado
tamanho da resposta / tempo limite / envelope de tentativa
id do recibo e dica de recuperação

Cartão de exceção interna

Alguns agentes precisam legitimamente acessar serviços internos. Isso nunca deve ser concedido enfraquecendo a política de busca pública.

O acesso à rede interna é uma rota diferente, não uma caixa de seleção. Dê à lane interna seu próprio cartão de rota, proprietário de revisão, escopo de alvo, lane de credencial e expiração.

Alvo interno / CIDR:
Chamador / inquilino / espaço de trabalho permitido:
Propósito comercial:
Lane de credencial exposta:
Proprietário de cota / teto de tentativa:
Proprietário de revisão:
Métodos permitidos e tamanho da resposta:
Alvos vizinhos proibidos:
Campos do recibo:
Data de expiração / reavaliação:

Erros comuns de interpretação

As defesas SSRF geralmente colapsam em lugares previsíveis:

Chamando a busca como somente leitura, mesmo que a solicitação se origine de um host privilegiado na nuvem ou desenvolvedor.
Verificando a string do nome do host, mas não IPs resolvidos, cadeias CNAME, redirecionamentos ou resultados IPv6.
Negando 169.254.169.254 enquanto permite nomes de host de metadados, aliases de loopback ou DNS de serviço privado.
Deixando tentativas ou proxies de fallback reemitirem a solicitação sem o mesmo pacote de política.
Registrando apenas a falha da solicitação em vez da decisão de política que protegeu uma lane de credencial.
Tratando o acesso à rede interna como um recurso booleano em vez de uma rota revisada separada.

Guias relacionadas para operadores

Se você quiser a versão própria com o CTA de endurecimento de rota, está aqui: https://rhumb.dev/blog/mcp-fetch-ssrf-protection-checklist