Três ataques que você não consegue impedir com programação segura

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

Quando se trata de violações envolvendo aplicativos e exposição de dados, a culpa quase sempre recai sobre os desenvolvedores. Muitas vezes, essa atribuição está correta. Ataques de injeção e explorações baseadas em pilha quase sempre são resultado de código inseguro. Geralmente porque a Regra Zero de Segurança foi violada.

Mas não podemos culpar os desenvolvedores por todas as violações. A verdade é que, mesmo que os desenvolvedores conseguissem produzir um código perfeitamente seguro, ainda seriam necessários serviços de aplicativos para proteger contra muitos outros ataques.

Isso ocorre porque a segurança de aplicações é composta por várias camadas. Há ataques que exploram protocolos e princípios de rede e que não podem ser simplesmente eliminados com uma "codificação segura". Para complicar ainda mais a segurança, esses ataques muitas vezes não são detectados pelas aplicações, pois elas não têm a visibilidade necessária para distinguir solicitações maliciosas de legítimas.

Em particular, há três ataques pelos quais os desenvolvedores simplesmente não deveriam ser responsáveis. Em vez disso, esses ataques são mais bem detectados e mitigados por serviços de aplicação implantados a montante, onde há visibilidade e contexto disponíveis para ajudar a contê-los.

DDoS volumétrico

Usamos o termo volumétrico para descrever um ataque tradicional distribuído de negação de serviço, distinguindo os ataques baseados em sobrecarga de rede daqueles que avançaram pelas camadas da pilha para atacar a camada de aplicação. São classes diferentes de ataques e, portanto, precisamos ser capazes de nos defender contra ambas, mas isso exige soluções muito distintas.

Um ataque volumétrico é simplesmente uma ofensiva em massa. Uma enxurrada de tráfego é direcionada a um serviço específico com a intenção de sobrecarregar qualquer dispositivo, infraestrutura ou software responsável por processar as solicitações. O princípio por trás disso é que todos os dispositivos — sejam de hardware ou software, locais ou na nuvem — têm recursos limitados. Assim, ao enviar solicitações em quantidade suficiente, é possível sobrecarregar o dispositivo e interromper o acesso a tudo o que está por trás dele.

O motivo pelo qual os desenvolvedores não conseguem impedir esse ataque de forma eficaz é que os aplicativos dependem das plataformas e dos sistemas operacionais dos hosts para gerenciar a rede. Um ataque DDoS volumétrico tem como alvo essa pilha de rede e consegue consumir tantos recursos compartilhados que o aplicativo mal consegue processar solicitações para determinar que está sob ataque.

A codificação segura não pode evitar isso — não se trata de uma exploração decorrente de uma vulnerabilidade. E, na verdade, a culpa não é do código de nenhuma parte do sistema. A questão é simplesmente que, por mais que tentemos fingir que o hardware não existe, é dele que vêm os recursos, e eles são limitados.

Ataques DDoS volumétricos são mais bem detectados e mitigados por serviços de aplicação de alta capacidade e alto desempenho localizados a montante da aplicação. Quanto mais próximos da origem do ataque, melhor.

Sem exploração, não há solução de codificação segura.

DDoS de camada 7

Subindo na pilha até a camada de aplicação, encontramos uma forma insidiosa de negação de serviço chamada DDoS de camada 7 (ou HTTP). Esses ataques são exasperantes porque exploram o sistema, mas não decorrem de uma vulnerabilidade nem de práticas de programação inseguras. Eles funcionam devido à própria natureza do HTTP e dos sistemas que o implementam.

Em geral, há dois tipos de ataques DDoS de camada 7: lentos e rápidos. O DDoS lento de camada 7 consome recursos ao simular uma conexão de rede péssima e extrair l e n t a m e n t e as respostas a solicitações legítimas. Isso consome recursos porque os aplicativos web dependem de conexões e, mais uma vez, os recursos para mantê-las são limitados. Ao se conectarem com um número suficiente de clientes e fazerem solicitações legítimas apenas para receber as respostas lentamente, os invasores conseguem ocupar os recursos da aplicação. Com isso, torna-se praticamente impossível para clientes legítimos se conectarem, efetivamente realizando um ataque de negação de serviço.

Esse ataque é particularmente nocivo e difícil de detectar — a menos que se compare a velocidade da rede com a velocidade de recebimento. Ou seja, os serviços de aplicação a montante têm visibilidade das características de rede dos clientes e podem determinar com mais precisão se eles estão recebendo os dados lentamente de propósito ou se realmente estão enfrentando um problema de rede. Determinar a legitimidade é fundamental para impedir esses tipos de ataque.

Basicamente, esses ataques exploram vulnerabilidades na camada de protocolo (HTTP), e não há nada que a codificação segura possa fazer para evitá-los.

Sem vulnerabilidade, não há solução de codificação segura.

Preenchimento de credenciais

Por último, mas não menos importante, temos o credential stuffing. O número impressionante de credenciais expostas por meio de violações nos últimos anos torna esse ataque uma ameaça significativa contra a qual é preciso se proteger.

Os ataques de preenchimento de credenciais geralmente dependem de bots ou ferramentas, pois se baseiam em princípios de força bruta que tiram proveito dos enormes conjuntos de credenciais de nome de usuário e senha já vazadas. É raro encontrar ataques de preenchimento de credenciais realizados manualmente. Um ataque bem-sucedido de preenchimento de credenciais não é resultado de código inseguro*. Os invasores buscam explorar apenas práticas inadequadas de uso de senhas e a incapacidade de reconhecer um ataque em andamento.

Para detectar esses ataques, você precisa ser capaz de determinar que o cliente não é um ser humano legítimo. Assim, em uma espécie de teste de Turing reverso, será necessário apresentar desafios e usar CAPTCHAs de maneiras que esses sistemas automatizados não consigam responder.

Nenhuma prática de codificação segura é capaz de impedir que esse ataque seja bem-sucedido. Adotar melhores práticas de senha e detectar tentativas de ataque são as melhores formas de evitar ser vítima desse problema crescente da Internet.

Sem código explorável, não há solução de codificação segura.

*Ataques de preenchimento de credenciais podem ser viabilizados por práticas inseguras de programação. Afinal, um número significativo de violações ocorre devido a vulnerabilidades no código que resultam em enormes listas de credenciais disponíveis para esse tipo de ataque.

Diferencie para detectar e se defender

É importante reconhecer quando a codificação segura pode ser usada para prevenir um ataque e quando isso não é possível. Isso é importante porque não podemos simplesmente continuar culpando os desenvolvedores por cada ataque bem-sucedido. A segurança exige uma visão sistêmica; precisamos de várias soluções, pois há diversos tipos de ataques contra os quais precisamos nos defender.

É importante fazer essa distinção para se defender de forma eficaz e bem-sucedida contra os diversos ataques aos quais a maioria das organizações estará sujeita em um futuro próximo. Não perca tempo tentando obrigar os desenvolvedores a se defenderem contra ataques quando (1) não se trata de uma exploração decorrente de código inseguro ou (2) isso não é possível devido à falta de visibilidade.

Precisamos abordar a segurança de forma estratégica, por meio de um sistema de serviços que ofereça a proteção adequada nos pontos certos, independentemente da origem ou da superfície de ataque.

Mantenha-se seguro.

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