O ataque que você não consegue impedir em sua aplicação

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

Uma grande variedade de ataques baseados em HTTP pode (e deve) ser evitada em sua aplicação. O OWASP Top 10 é um excelente exemplo de técnicas de ataque que podem ser detectadas e evitadas dentro de qualquer aplicação. Uma infinidade de ferramentas, incluindo análises estáticas e dinâmicas, bem como testes de invasão, pode garantir que essas vulnerabilidades não cheguem à produção. Desde que, é claro, esses testes de segurança sejam antecipados e incorporados ao processo de CI/CD em vez de serem deixados como a etapa final antes de acionar o interruptor (ou os bits, por assim dizer) que torna a aplicação acessível aos usuários.

Mesmo que você tenha eliminado todas as possíveis vulnerabilidades encontradas durante o desenvolvimento, as aplicações ainda estarão em risco. Isso ocorre porque alguns ataques não podem — e quando digo que não podem, quero dizer que realmente não podem — ser detectados pela aplicação. Na verdade, quando o ataque chega à aplicação, já é tarde demais.

É claro que estou falando de ataques DDoS na camada de aplicação (HTTP). Sabe, aqueles ataques vampirescos que exploram o próprio protocolo HTTP para basicamente sugar até a última gota de capacidade de processamento e memória disponível de uma aplicação, tornando-a inutilizável para usuários legítimos.

Existem basicamente dois tipos de ataques DDoS HTTP: os rápidos e os lentos; os de inundação e os de esgotamento.

O Ataque de Inundação

Um ataque DDoS HTTP baseado em inundação explora o fato de que se espera que os aplicativos aceitem solicitações HTTP e respondam a elas. Afinal, essa é meio que a função deles, não é? Então, é isso que fazem, independentemente da velocidade com que essas solicitações chegam. Mesmo que elas cheguem a uma taxa capaz de esgotar os recursos disponíveis no servidor em minutos — ou segundos —, ele tenta responder. Veja bem, todo aplicativo (na verdade, todo dispositivo, serviço, sistema etc.) tem um limite máximo de conexões TCP que pode manter abertas simultaneamente antes de simplesmente não conseguir abrir mais nenhuma. Quando esse limite é atingido, todas as solicitações subsequentes são simplesmente ignoradas. Para os usuários, isso aparece como o inofensivo status “Tentando conectar…”, enquanto o navegador ou aplicativo aguarda o tempo definido pelo sistema e, em seguida, informa que não foi possível estabelecer a conexão.

Esse tipo de ataque pode ocorrer tão rapidamente (daí a analogia com uma “enchente repentina”) que supera a capacidade dos sistemas de escalar para atender à demanda. Nem mesmo o escalonamento automático pode ajudar nesse cenário, pois o tempo necessário para provisionar e iniciar uma nova instância do aplicativo é maior do que o tempo que o ataque leva para esgotar todos os recursos das instâncias existentes.

O ataque de drenagem

O oposto — um ataque de esgotamento — realiza a mesma tarefa, mas faz isso forçando o aplicativo a manter uma conexão aberta por mais tempo do que o necessário. Para isso, ele finge estar usando uma conexão discada, recebendo do aplicativo apenas algumas gotas de dados por segundo, em vez de fazê-lo na velocidade que realmente é capaz de suportar. Com isso, as conexões duram mais e, se isso for feito com um número suficiente de conexões, o resultado será basicamente o mesmo de um ataque de inundação: o esgotamento de recursos.

Nenhum desses ataques pode ser detectado de dentro de uma aplicação. E por que poderia? Para a aplicação, todas essas solicitações são legítimas; são solicitações de dados bem-formadas, baseadas em HTTP, às quais ela provavelmente responde milhares de vezes por dia. Não há nenhum sinal nos cabeçalhos HTTP ou na carga útil que indique a natureza maliciosa das solicitações. A aplicação é completa e absolutamente incapaz de perceber as intenções maliciosas por trás dessas solicitações, pois não tem visibilidade da rede nem do ambiente mais amplo — especificamente, da tabela de sessões do servidor, que mantém a lista principal de todas as conexões abertas. Vou poupar você dos detalhes técnicos e da explicação sobre threads, processos e volatilidade dos dados em ambientes multithread e me limitar à ideia de que “não há visibilidade do processamento de outras solicitações”.

Basta dizer que a própria aplicação não tem como determinar se uma determinada solicitação faz parte de um ataque mais amplo (inundação) ou se o comportamento dela é incompatível com os recursos conhecidos da aplicação (esgotamento).

O proxy vem ao resgate

Quem de fato tem visibilidade de ambos é o proxy localizado a montante (à frente) da aplicação. Isso ocorre porque o proxy provavelmente está fazendo o balanceamento de carga e, portanto, precisa monitorar quantas solicitações estão sendo processadas no momento e quantas estão chegando, pois precisa encaminhá-las para uma das aplicações no cluster (ou pool, se preferir).

Além disso, o proxy precisa saber para onde enviar a resposta, portanto conhece o cliente e sua conexão de rede (normalmente, apenas o endereço IP do cliente é enviado ao aplicativo, nada mais). Ao contrário do aplicativo, ele tem a visibilidade necessária para detectar tanto ataques de inundação quanto de drenagem — e bloqueá-los antes que possam cravar seus dentes vampirescos nos recursos do aplicativo.

É por isso que serviços baseados em proxy, como um WAF (Web Application Firewall) ou até mesmo um balanceador de carga avançado, desempenham um papel fundamental nas estratégias atuais de segurança de aplicações. Afinal, eles têm a visibilidade e os recursos necessários para detectar comportamentos anômalos que indiquem um ataque — e repeli-lo como o alho repele um vampiro.

E como esses serviços tradicionalmente considerados “de rede” devem necessariamente fazer parte da arquitetura da aplicação, parece lógico que uma abordagem DevOps tenda a ampliar seu escopo e ser mais inclusiva em relação aos serviços que, por natureza, já estão diretamente ligados à aplicação, como segurança de aplicações e escalabilidade (balanceamento de carga).

Os aplicativos não conseguem impedir todos os ataques, especialmente aqueles cuja detecção exige um nível de visibilidade que simplesmente não está disponível para eles. No entanto, ao trabalharem em conjunto com serviços estreitamente ligados às aplicações, como segurança de aplicações web e balanceamento de carga, torna-se possível detectar e repelir uma gama mais abrangente de ataques, reduzindo as interrupções e as violações de 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