← WAF: proteção e operação de aplicações
07 / 12 · 60 MIN

Exclusões delimitadas e regressão com Coraza

Corrige um falso positivo através de uma exceção observável e confirma a inspeção dos campos e operações restantes.

Um laboratório de decisões do motor

O runner usa Coraza 3.8.0 como biblioteca Go e cria transações em memória. As regras são originais e procuram os marcadores inofensivos lab-marker e lab-second. Não carrega CRS, não abre um servidor HTTP e não envia tráfego de ataque. O objetivo é observar âmbito, fases e decisões com dados conhecidos. Um resultado de interrupção 403 indica o que o motor pede ao conector. Para afirmar bloqueio efetivo numa arquitetura, é necessário verificar que o conector aplica a decisão e não encaminha o pedido para o backend.

Construir uma hipótese de falso positivo

O exemplo inicial envia comment=lab-marker em formato de formulário. A regra 1001 inspeciona ARGS e pede 403. Para o caso fictício, o comentário é legítimo e a exceção aprovada é estreita: apenas esse campo, nessa regra, em POST /reconciliation. Escreve esta hipótese antes de editar configuração. Ela define tanto o caso que deve passar como os controlos que devem continuar a corresponder. Identifica ainda quem aprovou o âmbito, qual contrato funcional o justifica e em que alteração da aplicação a necessidade deverá ser revista.

Observar os limites da exceção

A exclusão runtime combina caminho e método em fase 1 e retira ARGS:comment da regra 1001 para essa transação. O caso aprovado deixa de interromper. O runner confirma depois quatro fronteiras: account continua a corresponder; comment continua a corresponder em /other; o método PUT não beneficia da exceção; e lab-second em comment ainda corresponde à regra independente 1002, que pede 409. O estado 409 foi escolhido para o exercício e não demonstra conflito de negócio. A matriz mostra que um campo excluído de uma regra continua disponível a outras regras.

Comparar configuração e decisão por pedido

Uma experiência separada aplica SecRuleUpdateTargetById à regra 1001 depois de esta estar definida, retirando comment dos seus alvos. O marcador nesse campo deixa de interromper também em /other. Esta diretiva não contém a condição de operação da exclusão runtime anterior. A comparação torna visível a diferença entre alterar o conjunto de alvos no contexto de configuração e fazê-lo apenas quando um pedido cumpre condições. Usa o mecanismo que corresponde à necessidade demonstrada, mantém as adaptações separadas do ruleset distribuído e verifica o âmbito efetivo depois de uma atualização.

A fase e a posição fazem parte da regra

O runner coloca deliberadamente a exclusão depois da regra 1001, ambas em fase 2. A interrupção continua a ocorrer: a alteração tardia não desfaz a decisão já tomada. Noutro teste, uma regra com ID 9000 em fase 1 é observada antes de uma regra com ID 200 em fase 2, mesmo aparecendo depois no texto. Assim, trocar IDs não corrige automaticamente a ordem. No diagnóstico Coraza, reconstrói fase e ordem de compilação. Não transportes diretamente o modelo de prioridade numérica de AWS WAF para estes identificadores SecLang.

Aceitar a correção com uma matriz

Num portal fictício de reconciliação, a equipa recupera a introdução de comentários, mas o teste de account também deixa de corresponder. A mudança ainda não cumpre o âmbito aprovado. Corrige a exclusão ou aplica a recuperação prevista, depois repete os testes positivos e negativos. Conserva configuração, versão, entradas sintéticas e resultados por regra. O resumo é avaliar a exceção pelo que recupera e pelo que deixa preservado. Um 200 funcional ou ausência de interrupção, isoladamente, não demonstra que a cobertura restante sobreviveu à correção.

# Original local lab, not a production ruleset
# Rule 1001: ARGS contains lab-marker -> interruption 403
# Runtime exception: POST /reconciliation; rule 1001; ARGS:comment
# Matrix: comment passes, account still matches, /other still matches
# PUT still matches; rule 1002 still inspects comment
NA PRÁTICA

Caso fictício: o comentário legítimo passa, account continua inspecionado, PUT e /other mantêm o controlo e uma segunda regra ainda pode corresponder ao mesmo campo.

Armadilhas comuns

Excluir toda a regra para corrigir um campo, colocar uma exclusão depois do bloqueio, ou usar IDs SecLang como prioridades numéricas de outro produto.

Tópicos relacionados: Ordem, ações e overrides · Parsing e limites de inspeção · Afinação e falsos positivos

Leva esta ideia contigo

Uma boa regressão mostra o caso autorizado a passar e os campos, regras e operações que continuam a ser inspecionados.

Criar conta

Referência: Coraza SecLang actions · DR WAF 2026-09; selected AWS WAF and OWASP CRS operational concepts