Voltar as noticias
Construí 8 camadas de segurança para um marketplace MCP. Veja o que cada uma realmente captura.
MCP ProtocolAltaEN

Construí 8 camadas de segurança para um marketplace MCP. Veja o que cada uma realmente captura.

Dev.to - MCP·15 de julho de 2026

Depois que um verdadeiro trojan passou pelo meu marketplace MCP na semana passada (Trojan:Win64/Lazy.PGPK!MTB escondido em um zip aninhado), eu me aprofundei na defesa em profundidade. O resultado são 8 camadas rodando em produção em marketnow.site.

Veja o que cada camada realmente captura — com exemplos concretos.

Camada 1: L1.5 — Verificações de metadados (6 regras)

A camada mais barata. Roda em todos os metadados das habilidades (nome, descrição, system_prompt, comando de instalação).

Captura:

  • Habilidades que dizem "sem autenticação necessária" (aviso)
  • Habilidades com padrões de injeção de prompt nas descrições ("ignore instruções anteriores")
  • Habilidades com acesso a arquivos/SQL/HTTP declarado nos metadados
  • Habilidades com Access-Control-Allow-Origin: *
  • Habilidades usando tokens OAuth não escopados
  • Habilidades sem limitação de taxa

Não captura: nada dentro do pacote zip real. É por isso que o trojan passou inicialmente.

Camada 2: L1.6 — Semgrep + Segredos + OSV (36 regras)

18 regras equivalentes ao Semgrep + 18 padrões de detecção de segredos + verificação de vulnerabilidade de dependência OSV.

Captura:

  • Chaves de API codificadas (Stripe sk_live_*, GitHub ghp_*, AWS AKIA*)
  • Mnemonics de carteira nas descrições
  • Padrões de injeção de comando (exec(req.body))
  • Padrões SSRF (fetch(req.url))
  • Travessia de caminho (readFile(req.params.path))
  • Falsificação de nome de ferramenta (uma ferramenta se chamando read_file para se passar pela oficial)
  • Dependências npm conhecidas como vulneráveis (via API OSV)

Não captura: segredos dentro de blocos de código no README (nós removemos esses — falsos positivos), referências a process.env.X (buscas de variáveis, não codificadas).

Camada 3: L1.7 — Detecção de binários e malware (8 padrões)

Esta é a camada que construí depois do incidente do trojan. Ela abre o zip do pacote real (recursivamente — zips dentro de zips) e escaneia por:

  • Binários do Windows (.exe, .dll, .scr, .msi) → quarentena instantânea
  • Scripts de inicialização (.bat, .cmd, .vbs, .ps1) → quarentena instantânea
  • Arquivos aninhados (zips dentro de zips — habilidades MCP legítimas não fazem isso)
  • Iniciadores em estágios (start X.exe Y.txt padrão — a assinatura exata do trojan prospector)
  • Código byte obfuscado Lua (assinatura de função de alta aridade function(o,R,F,U,b,p,E,M,Z,W,...))
  • URLs de download externas no README (raw.githubusercontent.com/.../...zip)
  • PowerShell -encodedcommand com long base64
  • eval(atob(...)) obfuscação
  • Arquivos de texto excessivamente grandes (>100KB não-JSON = provável carga útil de bytecode)

Captura: o exato trojan que nos atingiu. Verificado com um teste de fumaça que escaneia o zip malicioso original do histórico do git.

Camada 4: L1.8 — Assinaturas de famílias de malware (17 famílias)

Regras equivalentes ao YARA para famílias específicas de malware:

  • Win64/Lazy.PGPK (o que nos atingiu)
  • Emotet (trojan bancário)
  • Cobalt Strike (beacon pós-exploração)
  • Mimikatz (extrator de credenciais)
  • QakBot, TrickBot (trojans bancários)
  • Agent Tesla (keylogger)
  • RedLine, Vidar, Raccoon, LummaC2 (stealers)
  • AsyncRAT, njRAT, Remcos (RATs)
  • SolarMarker (backdoor)
  • Lokibot (stealer de credenciais)
  • Ferramentas de DoS (hping3, slowloris, goldeneye)

Cada regra tem um ID de técnica MITRE ATT&CK. Qualquer correspondência → quarentena instantânea.

Camada 5: WAF — Firewall de Aplicação Web (40 regras)

Inspeciona cada requisição HTTP recebida em busca de padrões de ataque:

  • SQLi (7 regras): UNION SELECT, OR 1=1, consultas empilhadas, baseadas em tempo, information_schema
  • XSS (7 regras): tags de script, manipuladores de eventos, URIs javascript:, img onerror, svg onload
  • Travessia de caminho (5 regras): ../, codificado %2e%2e, /etc/passwd, /proc/self, caminhos do Windows
  • SSRF (6 regras): IPs de metadados AWS/GCP/Azure, file://, gopher://, dict://
  • Injeção de comando (5 regras): crase, $(), encadeado ; ls, pipe | cat, && ||
  • Injeção NoSQL (3 regras): $where, $ne, $gt
  • Poluição de protótipo: __proto__, constructor.prototype
  • SSTI: Jinja2 {{ }}, Twig {% %}, JS ${ }
  • Injeção de log: com injeção de cabeçalho

Auto-banimento após 5 hits do WAF em 10 minutos (banimento de 1 hora).

Camada 6: Honeypot (50+ caminhos)

Caminhos vulneráveis falsos que auto-banem scanners por 24 horas:

  • /.env → serve um arquivo env falso com tokens canário
  • /admin → serve um formulário de login de administrador falso
  • /wp-admin → serve um login falso do WordPress
  • /.git/config → serve uma configuração git falsa
  • /.aws/credentials → serve credenciais AWS falsas
  • /.ssh/id_rsa → serve uma chave SSH falsa
  • /phpmyadmin → serve um phpMyAdmin falso
  • /backup.sql → serve um dump de banco de dados falso
  • /server-status, /.DS_Store, /web.config, /Dockerfile, etc.

Qualquer acesso → IP banido por 24h + registrado publicamente em /api/security?view=honeypot.

Camada 7: Inteligência de Ameaças (3 feeds)

Feeds IOC em tempo real de abuse.ch:

  • URLhaus — últimos 1000 URLs maliciosos (cache de 5 minutos)
  • MalwareBazaar — últimos 100 hashes de amostras de malware
  • ThreatFox — IOCs de campanhas ativas de malware (janela de 7 dias)

Usado para verificar URLs de origem de habilidades e hashes de arquivos. Se a URL de origem de uma habilidade estiver no URLhaus, ela é colocada em quarentena.

Camada 8: Quarentena Automática

Se qualquer camada sinalizar uma habilidade como crítica/alta:

  1. A certificação da habilidade se move para _data/quarantine/
  2. A habilidade é removida do catálogo público (skills_index.json)
  3. Listada publicamente em /api/security?view=quarantine para transparência
  4. Escaneamento pré-importação no pipeline de auto-descoberta bloqueia antes de entrar no catálogo

O que realmente aconteceu quando executei todas as 8 camadas

Reauditei todas as 14.581 habilidades com as novas camadas.

Resultado: 0 habilidades em quarentena.

O catálogo estava limpo — a única habilidade maliciosa (prospector-email-finder) já havia sido removida manualmente. As 8 camadas agora rodam em cada nova importação de habilidade e em cada reauditoria semanal em lote.

A pilha

  • Vercel Hobby (plano gratuito, 11 funções serverless)
  • GitHub Actio
Contexto Triplo Up

A implementação de múltiplas camadas de segurança em marketplaces MCP é crucial para proteger dados e operações. Empresas brasileiras que utilizam ou planejam usar MCPs devem considerar essas práticas para evitar incidentes de segurança.

Noticias relacionadas

Gostou do conteudo?

Receba toda semana as principais novidades sobre WebMCP.