Desencorajando o uso de firewalls de aplicação web
Firewalls de aplicação web (WAFs) são criticados como ferramentas caras, que aumentam a latência e dão uma falsa sensação de segurança, podendo ser facilmente contornadas por atacantes determinados e sendo muitas vezes implantadas principalmente para cumprir exigências de conformidade como PCI-DSS ou HIPAA. Comentadores argumentam que design seguro, queries parametrizadas, análise estática e isolamento adequado de serviços geralmente oferecem proteção melhor, e que WAFs mal ajustados podem até introduzir novas vulnerabilidades ou quebrar tráfego legítimo. Outros contrapõem que os WAFs ainda têm papel na defesa em profundidade: lidar com ataques volumétricos, proteger aplicativos legados ou de terceiros, fornecer “patches virtuais” rápidos para ameaças emergentes e filtrar grandes volumes de tráfego automatizado inútil.
Conformidade, auditorias e segurança de checklist
- Muitas implementações existem principalmente para satisfazer PCI-DSS, HIPAA ou listas de verificação internas; os auditores muitas vezes só verificam se há um WAF presente, não se ele é eficaz.
- Vários observam que a PCI-DSS permite alternativas (por exemplo, DAST contínuo), mas WAF + regras OWASP costuma ser a evidência mais fácil de apresentar.
- Isso leva a “WAFs de fachada”, com regras mínimas ou inexistentes de bloqueio, usados apenas para marcar caixas.
Eficácia, contorno e escopo
- Críticos argumentam que WAFs baseados em regex/assinaturas são facilmente contornados por atacantes com habilidade moderada, especialmente as ofertas genéricas em nuvem.
- Outros contrapõem que WAFs bloqueiam ataques reais na prática (por exemplo, injeção SQL que passou despercebida por revisões de código e ferramentas) e elevam a barreira ao filtrar varreduras oportunistas e explorações óbvias.
- Vários enfatizam que WAFs não são uma panaceia, mas parte de uma defesa em profundidade; depender apenas deles é perigoso.
Desempenho e superfície de ataque
- Alguns apontam impactos significativos de latência e throughput, especialmente com mecanismos no estilo ModSecurity, e observam que aplicativos bem construídos podem responder 404 mais rápido do que um WAF consegue inspecionar.
- Há preocupações de que os WAFs, por si só, adicionem uma grande base de código voltada à internet, sem segurança de memória, e novos riscos de configuração incorreta; em casos extremos, eles próprios foram o vetor de invasão.
Realidades operacionais e organizacionais
- WAFs de nível empresarial (por exemplo, da classe Imperva) podem exigir ajuste fino substancial, equipe dedicada e cuidado contínuo com regras; muitos acabam em modo “configurar e esquecer”.
- Outros dizem que WAFs em nuvem são fáceis o bastante para gerenciar em tempo parcial e úteis para filtragem básica de bots, reputação de IP e limitação de taxa na camada 7.
- Equipes de AppSec muitas vezes conseguem alterar regras de WAF mais rapidamente do que configurações de aplicação ou do servidor web, tornando os WAFs atraentes para “patch virtual” (por exemplo, payloads de Log4j, bloqueio de endpoints específicos).
Falsos positivos e impacto no usuário
- Há múltiplos exemplos de tráfego legítimo bloqueado: redirecionamentos OpenID, palavras comuns como “Union” em endereços, comportamentos padrão de frameworks.
- Conjuntos de regras padrão pesados (por exemplo, “ativar tudo”) são apontados como especialmente problemáticos e, às vezes, levam a soluções alternativas inseguras.
Alternativas e complementos
- Forte ênfase em design seguro de aplicações: SQL parametrizado, análise estática, tipagem rígida de APIs, isolamento de processos, acesso com menor privilégio.
- Alguns sugerem bloqueio básico em nível de rede, listas de negação de IP e gateways de API/roteadores de front-end como alternativas ou complementos mais simples ou transparentes.