- Estou escrevendo este texto porque não há muita gente se opondo ao uso de WAF. A maioria dos resultados de busca sobre WAF foi escrita por fornecedores de WAF
- O WAF foi criado no início da internet e intercepta todas as requisições HTTP, avaliando centenas de expressões regulares para bloquear requisições semelhantes a SQL, shellcode etc.
- No início da cibersegurança, o WAF parecia uma boa ideia, mas hoje em dia não é mais assim
- Devido aos problemas de desempenho do WAF, à facilidade de contorná-lo, ao risco de servir como vetor de ataque e à alta taxa de falsos positivos, hoje existem tecnologias de segurança melhores
O desempenho do WAF é péssimo
- O WAF executa centenas de expressões regulares para cada requisição, causando degradação de desempenho
- Ao usar WAF, é necessário uma quantidade considerável de RAM adicional, e aumentam o tempo médio de upload, a velocidade de processamento das requisições, o uso de CPU e também ocorrem bloqueios indevidos
O WAF é facilmente contornado
- Na competição constante entre WAF e atacantes, os atacantes levam vantagem
- É possível contornar as regras do WAF usando gramáticas complexas e técnicas de codificação
- Por exemplo, o ataque Log4shell não pode ser bloqueado com uma simples verificação de string, e os atacantes podem usar várias técnicas de evasão (Log4J Lookup)
- Além disso, se a string de ataque for preenchida com cerca de 8 KB de caracteres inúteis, porém inofensivos, o WAF deixa de ser útil porque não consegue continuar fazendo buffering em RAM e acaba cortando a análise
O WAF é um vetor de ataque
- Em 2019, a CapitalOne sofreu um incidente em que 100 milhões de solicitações de crédito foram expostas devido a um erro de configuração do WAF
- Segundo relatos, o atacante enganou o WAF para enviar uma requisição ao serviço de metadados do EC2 e repassar credenciais que permitiram ler arquivos sensíveis no S3
- Ou seja, existe a possibilidade de incidentes de segurança causados por configuração incorreta do WAF
- A maioria dos WAFs é complexa e muitas vezes escrita como software de código fechado, ampliando a superfície de ataque
- Por serem produtos “corporativos” caros, as empresas os enchem de recursos desnecessários para parecerem mais chamativos que os concorrentes
- Princípios básicos de segurança para produtos de segurança frequentemente são ignorados
Alta taxa de falsos positivos no WAF
- Nos últimos 20 anos, os conjuntos de regras de WAF open source foram bastante ampliados para detectar tipos mais recentes de ataque. Os WAFs proprietários provavelmente fazem o mesmo
- Isso significa que há cada vez mais strings capazes de disparar o WAF e bloquear requisições
- Cada vez que novas regras surgem, a expansão das regras do WAF aumenta a taxa de falsos positivos
- WAFs de “próxima geração” afirmam resolver esse problema verificando múltiplas requisições ou usando sistemas de reputação de IP
- Isso pode até melhorar as taxas de false positive, mas não resolve completamente o problema dos falsos positivos
- Por causa dos falsos positivos, usuários e equipes de suporte podem ficar sem um procedimento claro de resolução
Alternativas ao WAF
- Isolamento (Isolation): técnica para garantir que, mesmo que uma parte do sistema seja comprometida, isso não afete as outras partes
- Os navegadores fazem isso executando todo o código dentro de processos em sandbox especiais, sem acesso arbitrário a cookies, senhas salvas e outras abas
- Microsserviços foram projetados com isolamento em mente, mas isso também pode ser feito em um monólito usando várias bibliotecas e linguagens
- Imutabilidade (Immutability): eliminação de classes de ataque por meio de sistemas de arquivos somente leitura, gerenciadores de pacotes que exigem reinicialização, backups append-only etc.
- Análise estática (Static Analysis): uso de prepared statements para evitar SQL injection e inspeção de código com análise estática no pipeline de CI
- Segurança baseada em capacidades (Capability-based Security): nem todo endpoint de API precisa de acesso irrestrito ao banco de dados e ao sistema de arquivos; a ideia é conceder apenas as permissões necessárias
5 comentários
:+1:
Com a combinação de nginx + naxsi, acho que não se enquadra em alguns dos casos acima.
O conjunto de regras do WAF precisa ser conduzido de uma forma em que o desenvolvedor do serviço seja responsável.
Sem entender o serviço, o especialista em segurança acaba aplicando configurações genéricas, gerando uma alta taxa de falsos positivos e, ao remover as regras uma a uma conforme as solicitações, faz com que o WAF perca sua função original.
Concordo em parte sobre os pontos de bypass e falsos positivos, mas no geral a sensação é forte de que estão sendo listadas informações não muito confiáveis como se fossem fatos. Quando tiver tempo, vou ter que ver o texto original também. Em especial, apontar o caso da CapitalOne como um problema de WAF faz parecer que o autor do texto original tem pouca compreensão sobre WAF. WAF não é uma solução que faz mitigation da vulnerabilidade na raiz. Vulnerabilidades que surgem no código devem ser corrigidas no código; essa é a forma correta de resolver. Mas a realidade muitas vezes não permite isso, então é preciso algum mecanismo adequado na camada de frente para inspecionar entradas suspeitas ou maliciosas. Se isso for bem operado, pode virar uma faca realmente boa; se for mal operado, vira uma faca que machuca a si mesmo. Essa natureza de mão dupla das ferramentas sempre existe, mas este parece ser um tema que destaca demais apenas o lado ruim.
Nos comentários do Hacker News, há várias opiniões e contrapontos sobre isso. Vale a pena conferir também
https://news.ycombinator.com/item?id=38255004