Sem WAFs

Seu time de segurança acabou de pintar um cenário sombrio de ameaças cibernéticas, e você sabe que sua aplicação web é um campo minado de vulnerabilidades. Resolver essas falhas parece uma tarefa que pode levar entre uma eternidade e nunca.

WAF: não é bem o que você esperava

Mas calma! Existe uma solução: o Web Application Firewall, que barra vulnerabilidades comuns como ataques de injeção e Distributed Denial of Service (DDoS). Sem precisar escrever uma linha de código. Você apenas direciona todo o tráfego web para o WAF; ele inspeciona cada requisição HTTPS e bloqueia as perigosas.

Os WAFs inspecionam todas as requisições HTTPS direcionadas à sua aplicação web e bloqueiam aquelas que parecem perigosas. Eles descriptografam as requisições HTTPS e analisam cabeçalhos e corpo em busca de potenciais ameaças, bloqueando com base em conteúdo, endereço IP ou padrões de requisição.

Além disso, os WAFs oferecem proteção contra ataques DDoS bloqueando picos repentinos de tráfego. Isso pode ser feito com regras simples, como a taxa de requisições e os endereços IP de origem. Ou então os WAFs podem usar inteligência artificial para detectar os padrões de acesso típicos de ataques DDoS e bloqueá-los.

Não faça isso.

O WAF é um erro. Veja alguns motivos:

Bloqueando sua própria aplicação

Os WAFs podem impedir que usuários legítimos acessem sua aplicação web ao confundir atividade normal com um ataque. Na prática, é bem provável que sua aplicação web exija entradas com strings "suspeitas", e as expressões regulares vão capturá-las erroneamente. Por exemplo: se sua aplicação atende clientes técnicos, é possível que tenha trechos de JavaScript que parecem um ataque. Pior ainda, sua aplicação pode exigir entradas fundamentalmente perigosas. Por exemplo, se ela aceita HTML de um componente de editor rich-text e o renderiza diretamente, posso te dizer o que você já sabe: que poderia e deveria escapar as strings, em vez de trafegar o equivalente a um ataque. Mas eliminar essas fragilidades, depois de criadas, é difícil; e até você conseguir alocar seu time para isso, o WAF vai deixar sua aplicação inutilizável.

Para proteção contra DDoS, o WAF bloqueia aumentos repentinos de tráfego, mas isso abre espaço para o pior tipo de falso positivo: aquele que acontece quando sua aplicação viraliza e seus visitantes não conseguem usá-la. É aí que entra o filtro avançado do WAF baseado em machine learning (ML). Não é perfeito, mas é melhor do que as abordagens baseadas em padrões da maioria dos filtros de WAF.

Bloquear endereços IP individuais é granular demais, então o próximo passo é bloquear países inteiros, deixando de fora todos os clientes daquele país. Talvez você não atenda clientes lá hoje, mas, com o WAF, você também se impede de descobrir potenciais novos mercados.

A abordagem recomendada para lidar com falsos positivos é configurar o WAF em modo dry run: em vez de bloquear, ele apenas registra logs sobre entradas suspeitas. Em seguida, você analisa os logs para verificar se há falsos positivos e, se houver, ou afrouxa as regras (potencialmente ignorando alguns ataques reais) ou corrige seu código (mas você já vem adiando isso há anos). Já vi organizações rodando o WAF em dry run por dois anos, com medo bem justificado de quebrar a funcionalidade da própria aplicação. Resultado: deixaram a aplicação mais lenta, não tiveram nenhum ganho de segurança — e gastaram dezenas de milhares de dólares em licenças, sem nunca obter qualquer benefício.

Deixando ataques passarem

A variedade de novos ataques possíveis está além da imaginação dos projetistas de WAF e da sua; mas não da dos hackers. Isso te deixa com a imagem espelhada do falso positivo: o falso negativo, ou seja, ataques reais que passam.

As expressões regulares, forma mais comum de filtrar texto, são limitadas no que conseguem detectar. Elas precisam ser predefinidas para ataques específicos e mantidas simples para um processamento rápido. Por questões de velocidade, apenas os primeiros poucos kilobytes do cabeçalho e do corpo HTTP são analisados; e mesmo que você aumente esse limite, sempre haverá um ponto além do qual os ataques passam.

Bloquear endereços IP também é fonte de falsos negativos, já que os invasores podem facilmente migrar para novos IPs usando proxies.

A principal origem dos ataques contra os quais o WAF nada pode fazer está na lógica da sua própria aplicação. Se uma página deveria estar protegida por senha e não está, ou se a autorização permite que um usuário escreva dados quando deveria apenas ler, a responsabilidade é sua. Embora ninguém espere que os WAFs encontrem esse tipo de vulnerabilidade, isso reforça que o lugar principal para implementar segurança web é no seu próprio código.

Flexibilidade?

À medida que você se equilibra entre falsos positivos e negativos, é tentador ajustar as regras e customizá-las exatamente para suas necessidades, ou até criar as suas próprias. Não faça isso.

Especialistas em segurança já pesquisaram os tipos de ataque usados por hackers. Os hackers não vão inventar ataques especiais só para você — e, se inventarem, você também não vai saber com antecedência. As vulnerabilidades da sua aplicação são, quase com certeza, as mesmas encontradas nos rulesets padrão. Se sua aplicação realmente tem fraquezas tão específicas que exijam diagnóstico próprio e novas regras de proteção, use esse tempo de desenvolvimento não no curativo, mas em melhorar a aplicação em si.

Equilibrar precisão e recall — falsos negativos versus falsos positivos — é difícil ou quase impossível, mesmo para os especialistas. Eles definem níveis de proteção para que você consiga fazer o trade-off entre falsos positivos e falsos negativos. Refinar esse equilíbrio diante de milhões de potenciais requisições web futuras não compensa.

Risco adicional

Essas desvantagens normalmente tornam o WAF um saldo negativo. Mas tem mais: os próprios WAFs podem representar um risco de segurança. Eles precisam descriptografar o HTTPS para inspecionar os dados, criando mais um potencial ponto de vazamento; e o próprio código do WAF pode ter vulnerabilidades. Além disso, podem deixar a comunicação mais lenta, já que toda requisição passa por eles.

Com frequência, mesmo sabendo de tudo isso, gestores decidem adicionar um WAF assim mesmo, como paliativo, planejando corrigir as vulnerabilidades depois. Mas, uma vez que o WAF está no ar, o time se acomoda, boas práticas de segurança nunca são adotadas, e o código da aplicação fica cada vez menos seguro. Enquanto isso, o WAF não está realmente entregando a segurança imaginada.

Apesar dessas desvantagens, há situações em que usar um WAF pode fazer sentido — ainda que você não vá tirar muita segurança real dele:

Se você tem uma exigência externa que demanda um WAF; se um Request for Proposals de cliente ou regulamentações do setor exigem conformidade com um padrão formal de segurança, então claro, adicione: o WAF é necessário, mas não para segurança.

Se você está implantando uma aplicação web de terceiros, que não foi desenvolvida por você e que você não consegue corrigir, então um WAF pode ser seu único caminho para adicionar um mínimo de segurança. Você ainda corre o risco de se acomodar quanto ao seu real nível de segurança, mas, pelo menos nesse caso, não está se afastando ainda mais das boas práticas de desenvolvimento.

Dito isso, existe uma boa razão de segurança para usar um WAF: proteção contra DDoS. Quando um ataque de negação de serviço envia tráfego massivo, seu WAF consegue detectar e bloquear o ataque. A detecção de padrões de ataque com ML oferece boa precisão.

Para proteção adicional contra DDoS, contar com um time de especialistas humanos pronto para responder, como em Google Cloud Armor Managed Protection e AWS Shield Advanced, vale a pena para as maiores aplicações web.

Muitos clientes procuram contratar serviços de proteção DDoS com urgência, seja um WAF ou times de especialistas, depois que o ataque já começou e não há mais tempo; vale a pena se antecipar.

Se for usar um WAF, use o oferecido pelo seu provedor de nuvem: Google Cloud Armor ou AWS Shield. Com os serviços de nuvem, você paga conforme o uso, em vez de se comprometer com uma mensalidade cara por um produto que talvez nem use de fato. Além disso, como os dados já estão trafegando pela nuvem e, em muitas arquiteturas, os serviços de nuvem já descriptografam seus dados de qualquer forma, usar um serviço de WAF do próprio provedor minimiza o impacto em performance, segurança e privacidade.

Veja este artigo do Mac Chaffee e esta thread no StackExchange para detalhes técnicos valiosos sobre esses pontos.