Três ataques que você não consegue conter com a codificação segura

Quando se trata de violações envolvendo aplicativos e exposição de dados, os dedos quase sempre são apontados para os desenvolvedores. Muitas vezes, essa é a direção certa. Ataques de injeção e explorações baseadas em pilha são quase sempre o resultado de código inseguro. Geralmente porque a Regra de Segurança Zero foi violada.

Mas não podemos culpar os desenvolvedores por todas as violações. A verdade é que, mesmo que os desenvolvedores consigam criar um código perfeitamente seguro, você ainda precisa de serviços de aplicativos para se proteger contra muitos outros ataques.

Isso ocorre porque a segurança do aplicativo é uma pilha . Há ataques que exploram protocolos e princípios de rede que não podem ser simplesmente "codificados com segurança". Para complicar ainda mais a segurança, esses ataques geralmente não são detectáveis pelos aplicativos porque não têm visibilidade 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 por lidar. Em vez disso, esses ataques são melhor detectados e mitigados por serviços de aplicativos implantados upstream, onde visibilidade e contexto estão disponíveis para ajudar a detê-los.

DDoS volumétrico

Usamos o termo volumétrico para descrever um ataque tradicional de negação de serviço distribuído para distinguir os ataques baseados em sobrecarga de rede daqueles que subiram "na pilha" para atacar a camada de aplicação. São classes diferentes de ataques e, portanto, precisamos ser capazes de nos defender contra ambos, mas a maneira como fazemos isso exige soluções muito diferentes.

Um ataque volumétrico é apenas um blitz. Uma enxurrada de tráfego é direcionada a um serviço específico com a intenção de sobrecarregar qualquer dispositivo/infraestrutura/software que esteja lidando com solicitações. O princípio em jogo é que todos os dispositivos — sejam hardware ou software, locais ou na nuvem — têm recursos limitados. Assim, ao enviar solicitações suficientes, o dispositivo pode ficar sobrecarregado e bloquear o acesso a tudo atrás dele.

O motivo pelo qual os desenvolvedores não conseguem impedir esse ataque de forma eficaz é porque os aplicativos dependem de plataformas e sistemas operacionais host para gerenciar a rede. Um ataque DDoS volumétrico tem como alvo essa pilha de rede e é capaz de 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 é uma exploração devido a uma vulnerabilidade. E na verdade não é culpa do código em nenhuma parte do sistema. O fato é que, não importa o quanto tentemos fingir que não há hardware, é daí que vêm os recursos, e eles são limitados.

Ataques DDoS volumétricos são melhor detectados e mitigados por serviços de aplicativos de alta capacidade e alto desempenho que residem a montante de um aplicativo. Quanto mais próximo da fonte do ataque, melhor.

Sem exploração, nenhuma solução de codificação segura.

Camada 7 DDoS

Subindo na pilha para 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 irritantes porque são explorações, mas não são causados por uma vulnerabilidade ou codificação insegura. Esses ataques funcionam devido à natureza do HTTP e dos sistemas que o implementam.

Geralmente, há dois tipos de ataques DDoS de camada 7: lentos e rápidos. O DDoS lento da camada 7 consome recursos fingindo ter uma conexão de rede terrível e lentamente desviando respostas de solicitações legítimas. Isso consome recursos porque os aplicativos da web são baseados em conexão e, mais uma vez, os recursos para manter essas conexões são limitados. Ao se conectar com clientes suficientes e fazer solicitações legítimas apenas para receber respostas lentamente, os invasores conseguem ocupar recursos do aplicativo. Isso tem o efeito de tornar quase impossível a conexão de clientes legítimos, efetivamente realizando um ataque de negação de serviço.

Esse ataque é particularmente nefasto e difícil de detectar, a menos que você esteja comparando velocidades de rede com velocidades de recebimento. Ou seja, os serviços de aplicativos upstream têm visibilidade das características de rede dos clientes e podem determinar com mais precisão se esses clientes estão propositalmente lentos para receber ou realmente têm um problema de rede.  Determinar a legitimidade é fundamental para impedir esse tipo de ataque.

Basicamente, esses ataques exploram a camada de protocolo (HTTP) e não há nada que a codificação segura possa fazer para resolver isso.

Sem vulnerabilidade, nenhuma solução de codificação segura.

Credential Stuffing

Por último, mas não menos importante, temos o preenchimento de credenciais . O número inacreditável de credenciais expostas por meio de violações nos últimos anos torna esse ataque um ataque significativo para se defender.

Ataques de preenchimento de credenciais geralmente dependem de bots ou ferramentas, porque são baseados em princípios de força bruta que aproveitam os vastos conjuntos de despejos de nomes de usuário/senhas existentes. Raramente você verá ataques de preenchimento de credenciais realizados manualmente. Um ataque de preenchimento de credenciais bem-sucedido não é resultado de codificação insegura*.  Os invasores não estão tentando explorar nada além de práticas ruins de senha 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 válido. Então, em uma espécie de teste de Turing reverso, você precisará apresentar desafios e usar CAPTCHAs de maneiras que esses sistemas automatizados não são capazes de responder.

Nenhuma quantidade de codificação segura pode impedir que esse ataque seja bem-sucedido. Melhorar as práticas de senha e detectar tentativas de ataque são as melhores maneiras de evitar sucumbir a esse flagelo crescente da Internet.

Nenhum código explorável, nenhuma solução de codificação segura.

*Ataques de preenchimento de credenciais podem ser possíveis devido à codificação insegura. Afinal, um número significativo de violações ocorre por causa de vulnerabilidades baseadas em código que resultam em enormes listas de credenciais disponíveis para esse ataque.

Diferenciar para Detectar e Defender

É importante reconhecer quando a codificação segura pode ser usada para evitar um ataque e quando não pode. É importante porque não podemos ficar apontando o dedo para os desenvolvedores por cada ataque bem-sucedido. A segurança precisa de pensamento em nível de sistema; precisamos de múltiplas soluções porque há vários tipos de ataques contra os quais precisamos nos defender.

É importante diferenciar para se defender de forma eficaz e bem-sucedida contra a variedade de ataques aos quais a maioria das organizações estará sujeita em um futuro próximo. Não perca tempo tentando forçar os desenvolvedores a se defenderem de ataques quando (1) não é uma exploração devido à codificação insegura ou (2) não é possível devido à falta de visibilidade.

Precisamos abordar a segurança estrategicamente a partir de um sistema de serviços que forneça a segurança certa nos lugares certos, não importa qual seja a fonte ou superfície de ataque.

Fique seguro.