Como um WAF mitiga vulnerabilidades?

Lori Mac VittieEngenheiro Emérito e Evangelista-Chefe | F5

Em nosso próximo relatório State of Application Delivery 2018, observamos que o uso de firewalls de aplicações web (WAF) vem aumentando de forma constante há anos. Isso é positivo, pois hoje os aplicativos são a porta de entrada para dados de clientes e empresas, e os métodos tradicionais de controle de acesso na camada de rede já não são suficientes. Isso ocorre porque agentes mal-intencionados estão cada vez mais direcionando seus ataques às identidades e aos próprios aplicativos em busca desse ouro digital.

Então, como exatamente um WAF mitiga todas essas vulnerabilidades que continuam surgindo como ervas daninhas no jardim? Há três métodos principais que um WAF usa para detectar e impedir ataques à Web: negar/permitir solicitações, inspecionar e rejeitar, e usar assinaturas.

Vamos explorar cada um deles?

Negar/Permitir solicitações

O método de negar/permitir solicitações é muito semelhante ao modelo tradicional de porta de entrada usado por firewalls de rede. As solicitações são negadas ou permitidas com base nas informações disponíveis. Essas informações podem ser simples — como um endereço IP — ou mais complexas e específicas do HTTP, como OPTIONS ou METHODS.

• Listas de bloqueio/permissão
  Se você sabe que um agente mal-intencionado está acessando a partir de um endereço IP específico ou de um intervalo de endereços IP, bloqueie-o. Se você sabe que um aplicativo só está autorizado a receber solicitações de um endereço IP específico ou de um intervalo de endereços IP, permita apenas essas solicitações. Esse é o método de proteção mais simples e depende de um conjunto relativamente estático de informações: os endereços/intervalos de IP dos quais as solicitações devem ou não se originar.
  
  Talvez você esteja pensando: por que não usar um firewall de rede para fazer isso? Afinal, é para isso que ele serve. Em ambientes locais, isso funciona muito bem. Mas, se você tiver aplicativos que precisam ser protegidos na nuvem pública, talvez essa não seja uma opção. E, se você faz parte dos 59% dos participantes da nossa pesquisa State of Application Delivery 2018 que já investiram em dois a seis provedores de nuvem diferentes, não pode contar com políticas de firewall de rede idênticas entre os provedores. Embora seja possível implementar as mesmas regras em várias nuvens, aplicá-las em um WAF permite usar a mesma política no mesmo WAF em vários ambientes. A consistência é fundamental para o sucesso e a escalabilidade da segurança.
• Restrição de opções
  O HTTP utiliza um conjunto de cabeçalhos para informar à plataforma do aplicativo (e ao próprio aplicativo) o que o usuário deseja fazer. Os MÉTODOS HTTP, por exemplo, podem ser usados para executar operações GET, PUT, POST e DELETE em recursos. O campo OPTIONS também tem um conjunto de valores restrito por RFC que pode ser facilmente controlado por um WAF. Algumas vulnerabilidades, como a Optionsbleed, exploram esses campos. Para impedir a exploração dessas vulnerabilidades, você pode usar o WAF para restringir os valores possíveis apenas àqueles que precisam ser permitidos para a execução adequada do aplicativo. Em alguns casos, o WAF restringe esses valores por padrão. Por exemplo, o BIG-IP ASM (F5 WAF) não permite, por padrão, o método HTTP OPTIONS.

Assinaturas

As assinaturas são outro método de proteção comum a diversas soluções de segurança. Os serviços antivírus e antimalware utilizam assinaturas que permitem verificar rapidamente indícios de vírus e malware e sinalizá-los. Os sistemas IPS/IDS também dependem muito desse método, assim como os WAF. Há dois tipos de assinatura: as definidas pelo usuário e as gerenciadas pelo fornecedor.

• Gerenciadas pelo fornecedor
  As assinaturas gerenciadas pelo fornecedor geralmente são armazenadas em um “banco de dados” mantido automaticamente pelo próprio fornecedor. Isso inclui a atualização do banco de dados quando novas vulnerabilidades podem ser identificadas por uma assinatura digital exclusiva. Um WAF verifica as solicitações recebidas comparando-as com o banco de dados e toma as medidas adequadas caso encontre uma correspondência com alguma assinatura nele armazenada. As assinaturas podem ser compostas apenas por texto simples, mas, na maioria das vezes, são combinações complexas de sequências pouco inteligíveis que representam códigos maliciosos capazes de acionar recursos de execução remota ou, de alguma outra forma, comprometer a plataforma do aplicativo e permitir acesso ou causar negação de serviço.
• Definidas pelo usuário
  As assinaturas definidas pelo usuário permitem que os operadores adicionem rapidamente uma assinatura ao banco de dados. Esse recurso é importante para garantir uma resposta rápida (em muitos casos, a vulnerabilidades de dia zero) a novas vulnerabilidades, bem como para mitigar vulnerabilidades para as quais ainda não tenha sido disponibilizada uma assinatura gerenciada pelo fornecedor.

Inspeção

Por fim, a inspeção é incluída para garantir controle total sobre as solicitações (e respostas). A inspeção das solicitações permite que o WAF compare as informações contidas nelas com strings e valores reconhecidamente seguros ou maliciosos, a fim de determinar se a solicitação é maliciosa ou legítima. Para aplicações HTTP (ou seja, a maioria das aplicações na Internet atualmente), esse é o recurso mais importante que um WAF deve oferecer. Se um WAF não oferecer inspeção programável, é melhor reconsiderar essa escolha. Como o HTTP é baseado em texto e extensível, é praticamente impossível fornecer uma lista abrangente de opções e métodos, no estilo “caixas de seleção”, que possam ser usados para inspecionar solicitações. Pouquíssimos cabeçalhos HTTP têm opções restritas, o que torna muito difícil limitar o que pode ou não ser inserido neles. Isso significa que a inspeção costuma ser necessária para detectar códigos maliciosos incorporados aos cabeçalhos ou à própria carga útil. Há duas maneiras de usar a inspeção: cabeçalhos conhecidos e carga útil.

• Cabeçalhos conhecidos
  Há um conjunto de cabeçalhos bem definidos presentes em todas as solicitações HTTP. Host, User-Agent, Content-Type etc. são praticamente onipresentes. Cada um deles é pouco mais que uma string de texto, com uma variedade tão grande de combinações que é difícil incluir valores em uma lista de permissões; em vez disso, é necessário verificar cada um individualmente em busca de valores que pareçam maliciosos. De modo geral, um WAF consegue analisar rapidamente os cabeçalhos HTTP e permitir sua inspeção. Eles ficam no início de cada solicitação e são conhecidos por terem sido usados para realizar diversos ataques contra plataformas de aplicativos, incluindo algumas das vulnerabilidades mais conhecidas: ApacheKiller, Optionsbleed e Apache Struts.
• Inspeção de payload
  A inspeção de payload é exatamente o que o nome sugere: ela examina todo o payload — do primeiro ao último byte — em busca de combinações conhecidas de dados alfanuméricos que indiquem uma tentativa de explorar uma vulnerabilidade. A inspeção de payload permite que os operadores examinem cabeçalhos HTTP personalizados, bem como o corpo de uma solicitação, em busca de indicadores específicos de atividade maliciosa. Para isso, a WAF precisa primeiro armazenar todo o conteúdo da solicitação. Isso é necessário porque os pacotes comportam apenas uma quantidade limitada de dados e, se os dados maliciosos estiverem distribuídos entre dois pacotes, poderão passar despercebidos por serviços que realizam a inspeção apenas pacote a pacote. Ao inspecionar todo o payload, uma WAF garante que, independentemente de onde os dados maliciosos estejam, eles possam ser detectados e impedidos de chegar ao destino.

Um WAF pode fazer muito mais do que mitigar vulnerabilidades para proteger aplicações. Muitos também incluem detecção de bots, limitação de taxa, prevenção contra DDoS e muito mais. No entanto, a principal finalidade de um WAF é proteger aplicações por meio da mitigação de vulnerabilidades. Embora SQLi, XSS e CSRF sejam geralmente mencionados, a esta altura eles já são praticamente “coisa do passado”. Agentes mal-intencionados foram além das vulnerabilidades óbvias das aplicações e começaram a atacar as plataformas porque elas oferecem um conjunto muito maior de vítimas a serem exploradas. As vulnerabilidades de plataforma — aquelas presentes no HTTP e em seus frameworks — são uma fonte crescente de violações que podem ser evitadas com as proteções oferecidas por um WAF de nível empresarial.

Ao empregar verificações tradicionais baseadas em listas de bloqueio e permissão e em assinaturas, com a capacidade de inspecionar uma solicitação completa (e sua resposta), um WAF oferece a proteção de que as empresas precisam atualmente para manter a si mesmas — e seus clientes — em segurança.

Sobre o autor

Lori Mac VittieEngenheiro Emérito e Evangelista-Chefe | F5

Lori MacVittie é engenheira distinta e evangelista-chefe no Escritório do CTO da F5, com ampla experiência em entrega de aplicações, estratégia de automação e infraestrutura. Ela é conhecida por transformar complexidade em clareza, seja definindo diretrizes para agentes de IA, analisando arquiteturas multinuvem frágeis ou investigando os limites de sistemas escaláveis. Ela acumula mais de trinta anos de experiência no setor, abrangendo desenvolvimento de aplicações, arquitetura de TI e operações de redes e sistemas. Antes de ingressar na F5, atuou como editora de tecnologia e recebeu diversos prêmios. MacVittie tem mestrado em Ciência da Computação e é uma autora prolífica, com publicações que abrangem segurança, nuvem e arquitetura empresarial. Ela também é uma entusiasta de jogos de tabuleiro e videogames, além de ter opiniões assumidamente fortes sobre queijos.

Mais publicações de Lori Mac Vittie