Entre a divulgação de uma falha e a instalação da correção no seu site, sempre passa algum tempo: o desenvolvedor ainda não lançou uma versão corrigida, a atualização quebra uma função ou ninguém teve tempo de testá-la. O patch virtual (também chamado de correção virtual, ou “vPatch” por alguns fornecedores) serve para cobrir esse intervalo. A OWASP o descreve como uma camada de aplicação de regras que detecta e bloqueia as tentativas de explorar uma vulnerabilidade conhecida, sem remover a falha em si.
Como funciona um patch virtual
Depois de analisar a falha (parâmetro vulnerável, versões afetadas, condições de exploração), escreve-se uma regra que reconhece as requisições perigosas para aquele caso específico. Existem duas abordagens:
- Modelo positivo (lista de permissões): define-se o que é um valor válido para o parâmetro visado, por exemplo um número inteiro, e todo o resto é rejeitado. É o mais robusto, mas exige trabalho manual.
- Modelo negativo (lista de bloqueio): bloqueiam-se os padrões de ataque conhecidos. É mais rápido de implantar, porém mais fácil de contornar com uma codificação diferente.
A OWASP recomenda testar a regra em modo de registro antes de bloquear, evitar regras que só reconhecem a carga exata publicada no alerta e remover o patch virtual quando o código estiver corrigido.
Onde ele é aplicado
Um patch virtual pode ser aplicado em vários pontos do caminho de uma requisição: por um firewall de aplicação web na nuvem, pelo servidor web (ModSecurity no Apache ou no Nginx) ou por um agente instalado na aplicação. No WordPress, a Patchstack implanta as suas regras apenas para os componentes vulneráveis realmente instalados no site, graças ao inventário das versões, e as executa dentro da aplicação ou, dependendo da falha, já no Apache ou no Nginx.
Quando ele é útil
- Uma falha é divulgada sem versão corrigida, ou o desenvolvedor demora.
- Um plugin não é mais mantido, mas o site ainda depende dele: uma situação a resolver, como explica nosso artigo sobre plugins abandonados, mas que não se resolve em um dia.
- Você administra muitos sites e as atualizações passam antes por um ambiente de homologação.
- Uma falha é explorada em massa poucas horas depois de divulgada, mais rápido do que o seu ciclo de manutenção.
No WordPress: ferramentas e limites
A Patchstack (nos planos pagos), o Wordfence e os firewalls na nuvem como a Cloudflare publicam regras específicas para falhas conhecidas do WordPress, com prazos e modelos diferentes; nosso comparativo de firewalls detalha essas diferenças. Alguns limites a ter em mente:
- Uma regra só existe depois que a falha é conhecida: diante de uma vulnerabilidade zero-day, não há nada para implantar.
- A cobertura depende da base do fornecedor, muitas vezes mais fraca para plugins premium vendidos fora do wordpress.org.
- Uma requisição que não é inspecionada (por exemplo, um ataque que não passa pelo firewall) não fica protegida.
O WP Masquerade não é um firewall e não aplica patches virtuais. Ele atua antes e ao lado: torna os seus plugins mais difíceis de inventariar de fora, e os seus alertas de plugins vulneráveis mostram qual plugin instalado é afetado por uma CVE e em que versão ela foi corrigida. A combinação com a Patchstack mostra como dividir os papéis entre os dois.