WHITE PAPER

Entendendo os ataques de credential stuffing

1Entendendo os ataques de credential stuffing

IntroduçãoPara qualquer organização que corra o risco de sofrer ataques de credential stuffing, a capacidade de atenuar esses ataques efetivamente dependerá de muito mais do que apenas o fornecedor de gerenciamento de bots ou a solução selecionada. A forma como seu website é projetado desempenhará um papel fundamental na eficácia de qualquer solução de segurança.

Para entender o porquê, considere a forma como esses ataques funcionam e como as soluções de segurança oferecem proteção contra eles. Os autores de ataques de credential stuffing usam botnets para automatizar a validação de credenciais roubadas em seu login de aplicação. Para separar bots automatizados de usuários humanos legítimos, as tecnologias avançadas de detecção de bots atuais usam injeção de JavaScript ao proteger páginas da Web e um SDK (kit de desenvolvimento de software) móvel ao proteger as APIs usadas por aplicações móveis nativas. Dependendo de como seu website é projetado e dos tipos de clientes que interagem com ele, sua capacidade de minimizar a superfície de ataques pode ser limitada.

Neste white paper, explicamos o que está por trás do desafio arquitetônico de utilizar as atuais soluções de gerenciamento de bots com eficiência, a arquitetura ideal dos websites para atenuar com sucesso os ataques de credential stuffing, as opções intermediárias específicas para reduzir sua superfície de ataques, além dos riscos e das limitações de cada opção.

Como funciona a detecção de botsA detecção de bots requer que seja identificado se o remetente de uma solicitação é humano ou não. Técnicas simples de detecção de bots examinam o conteúdo de uma solicitação, analisando o cabeçalho, por exemplo. No entanto, essa abordagem não é confiável contra os bots mais sofisticados, pois os cabeçalhos das solicitações são facilmente falsificados. Técnicas mais avançadas de detecção de bots usam desafios de JavaScript, impressão digital do navegador e análise de anomalias comportamentais.

Injeção de JavaScript em uma sessão do navegador

A maioria das técnicas de detecção de bots injeta um trecho de código JavaScript no HTML de uma página da Web entregue ao navegador de um cliente. O trecho de código JavaScript é executado quando o navegador carrega o HTML e pode utilizar várias técnicas para distinguir humanos de bots.

A técnica menos sofisticada é um desafio de JavaScript, que verifica se a solicitação vem de um navegador que pode executar JavaScript. Um desafio de JavaScript pode ser útil para detectar bots simples que não conseguem executar JavaScript.

Uma técnica mais sofisticada é a impressão digital do navegador, que coleta diversas características sobre o navegador, como o tipo e a versão, a resolução da tela, os plug-ins e as fontes instalados. Uma solução de gerenciamento de bots pode inspecionar a impressão digital do navegador para identificar anomalias que indicam que o cliente é um bot que está tentando falsificar um navegador legítimo.

Técnicas avançadas

de detecção de bots

usam desafios de

JavaScript, impressão

digital do navegador

e análise de

anomalias

comportamentais.

2Entendendo os ataques de credential stuffing

A técnica mais sofisticada disponível atualmente é a análise de anomalias comportamentais, na qual os dados comportamentais são coletados dos dispositivos de entrada do cliente: pressionamentos de teclas e movimentos do mouse em um computador, ou eventos de toque, leituras do giroscópio e leituras do acelerômetro em um dispositivo móvel. Esses dados são retornados para a solução de gerenciamento de bots, que analisa os padrões comportamentais em busca de desvios que indiquem um bot.

SDK móvel para aplicações

As técnicas baseadas em injeção de JavaScript funcionam em clientes baseados em navegador, incluindo navegadores móveis e de desktop. No entanto, a maioria dos clientes baseados em API, como aplicações móveis nativas e outros serviços automatizados, não consegue executar JavaScript. Como resultado, as técnicas de injeção de JavaScript não receberão uma resposta desses clientes. Sem a resposta adequada, a solução de gerenciamento de bots fará a suposição de que o cliente é um bot e adotará medidas contra ele.

Para resolver essa situação, os fornecedores de gerenciamento de bots muitas vezes oferecerão um SDK móvel para integrar sua detecção de bots a uma aplicação móvel nativa. Com um SDK móvel, as aplicações móveis podem coletar os dados necessários na aplicação e transmiti-los à solução de gerenciamento de bots para análise.

Entendendo a arquitetura do seu websiteOs websites modernos são propriedades complexas e extensas que podem incluir centenas ou, até mesmo, milhares de páginas da Web, além de oferecer suporte a vários tipos diferentes de clientes e tráfego. Além disso, a propriedade dos websites geralmente é distribuída em uma organização. Entender a arquitetura de seu website e como os clientes fluem de páginas diferentes para seus pontos de extremidade de login é essencial para atenuar com sucesso os ataques de credential stuffing e compreender o nível de risco ao qual você está sujeito.

O que é um ponto de extremidade?

Um ponto de extremidade é um URL separado que pode ser acessado por um cliente. A atenuação de ataques de credential stuffing requer a identificação e a proteção de URLs transacionais que validam as credenciais do usuário. Por exemplo, o URL pode ser usado para fazer login em uma conta existente ou para criar uma nova conta. Além de realizar o credential stuffing, os pontos de extremidade que podem precisar ser protegidos podem incluir URLs que verificam saldos de vale-presentes, pesquisam voos ou adicionam produtos a um carrinho de compras.

Identificando todos os pontos de extremidade

Muitas organizações operam websites com vários pontos de extremidade que podem ser suscetíveis ao credential stuffing. Por exemplo, uma instituição de serviços financeiros pode ter serviços para consumidores, pequenas empresas e empregadores, cada um deles com diferentes pontos de extremidade de login. Além disso, cada uma dessas linhas de negócios pode ter pontos de extremidade separados de registro de conta.

3Entendendo os ataques de credential stuffing

Sua organização pode ter pontos de extremidade secundários desconhecidos para todos, exceto para alguns funcionários de TI ou de linha de negócios. Muitas vezes, existem aplicações preexistentes com pontos de extremidade que poucos conhecem, mas que podem ser encontrados por um invasor persistente. Eles podem incluir, por exemplo, pontos de extremidade que atendem a uma API, um estande de varejo ou um chatbot de atendimento ao cliente.

Identificando o que precisa ser protegido

A primeira etapa para o planejamento de qualquer implementação de gerenciamento de bots é fazer o inventário de tudo o que precisa ser protegido. No entanto, muitas vezes, essa é uma tarefa difícil devido ao tamanho e à complexidade dos websites modernos. Por exemplo:

• Às vezes, as pessoas pensam na página, e não

necessariamente no ponto de extremidade, em termos do

que precisa ser protegido.

• Com frequência, várias páginas usam um só ponto de

extremidade de login. Por exemplo: geralmente, os usuários

podem inserir credenciais de login a partir de qualquer

página de um website de varejo on-line. No entanto, todas as

credenciais são enviadas ao mesmo ponto de extremidade

de login para validação.

• Muitas vezes, a equipe responsável pela manutenção de um

ponto de extremidade não é a que cria as páginas que levam

a ele. Por exemplo, as aplicações móveis nativas normalmente são desenvolvidas por uma equipe

diferente, que não trabalha com a equipe que desenvolve páginas da Web para usuários de desktop.

• A proteção de qualquer ponto de extremidade requer a compreensão de todas as formas em

que um cliente pode chegar até ele e a implantação de proteção nessas páginas. Sem uma

estreita coordenação entre todas as partes, é fácil deixar o ponto de extremidade desprotegido.

Projetando a proteção para vários tipos de clientesOs websites podem interagir com vários tipos de clientes, dependendo das necessidades da organização. Eles podem incluir:

• Clientes humanos que usam navegadores móveis, de desktop ou de notebook

• Clientes humanos que usam aplicações móveis nativas de uma organização

• Serviços automatizados de terceiros, como agregadores financeiros, parceiros revendedores e

parceiros de reservas

A arquitetura para todos os tipos de clientes pode exigir que sua organização faça um trabalho significativo.

A primeira etapa

para o planejamento

de qualquer

implementação de

gerenciamento de

bots é fazer o

inventário de tudo

o que precisa ser

protegido.

4Entendendo os ataques de credential stuffing

Desenvolva pontos de extremidade para cada tipo de consumidor

Minimizar a superfície de ataques de credential stuffing requer oferecer o acesso certo aos clientes certos, e não mais do que o necessário. Os diferentes tipos de consumidores de websites têm diferentes necessidades. Por exemplo, os clientes de serviços bancários precisam visualizar saldos e extratos, realizar transações financeiras e atualizar seus perfis de usuário.

No entanto, um agregador financeiro utilizado por esse usuário só precisará de acesso para verificar os saldos de contas. Identificar as diferentes necessidades dos diferentes tipos de consumidores (e criar diferentes pontos de extremidade que ofereçam níveis adequados de acesso aos dados e funcionalidades para cada um deles) oferecerá benefícios de segurança superiores aos de qualquer solução de gerenciamento de bots.

Limitações de um SDK móvel

Embora um SDK móvel ajude sua organização a proteger as APIs que atendem às suas aplicações móveis nativas, existem limitações para essa abordagem. Primeiramente, considere o ciclo de vida de suas aplicações. Em comparação com a ativação de proteções para as páginas da Web, a atualização de uma aplicação móvel levará muito mais tempo e exigirá o envolvimento de recursos de desenvolvimento e teste de software. Além disso, sua organização precisará atualizar a aplicação móvel de todos os usuários finais para a versão mais recente antes de ativar a atenuação de bots. O que é ainda mais importante é que um SDK móvel não pode ajudar a proteger as APIs projetadas para serem acessadas por serviços automatizados de terceiros. Por definição, esses serviços utilizam bots e outras ferramentas automatizadas. Técnicas avançadas de detecção de bots, como impressão digital do navegador e análise de anomalias comportamentais, só podem ajudar a distinguir entre humanos e bots, e não entre bots bons e ruins.

URLs híbridos

Os URLs híbridos são pontos de extremidade projetados para atender a vários tipos de clientes e, portanto, protegê-los é algo desafiador para qualquer solução de gerenciamento de bots. Dependendo dos tipos de clientes envolvidos, pode ser possível proteger um ponto de extremidade usando a detecção de bots implementada por meio de uma combinação de injeção de JavaScript para clientes baseados em navegador e de um SDK móvel para aplicações móveis nativas. Por exemplo, um ponto de extremidade projetado para atender apenas ao tráfego humano por meio de navegadores e das aplicações móveis nativas de uma organização pode ser totalmente protegido por uma solução de gerenciamento de bots.

Em outros casos, no entanto, pode ser impossível para uma organização minimizar totalmente a superfície de ataques disponível sem reprojetar seu website. Por exemplo, um SDK móvel não ajuda a proteger uma API utilizada por aplicações móveis nativas e serviços automatizados de terceiros.

Técnicas avançadas

de detecção de bots,

como impressão

digital do navegador

e análise de anomalias

comportamentais,

só podem ajudar a

distinguir entre

humanos e bots, e

não entre bots bons

e ruins.

5Entendendo os ataques de credential stuffing

Atenuando o credential stuffing: opções intermediárias e riscosO credential stuffing é um problema complexo, tanto porque os bots são sofisticados quanto porque a arquitetura dos websites pode impedir a proteção. Dependendo das necessidades de sua organização e do seu website, embora teoricamente possível, uma solução 100% eficaz pode não ser satisfatória. Sua estratégia de atenuação de credential stuffing pode exigir o equilíbrio entre os riscos de segurança e o impacto, o custo e o intervalo de tempo das mudanças em sua organização, seus websites e suas aplicações móveis.

Opção 1: alinhe a arquitetura do website aos diferentes tipos de clientes

Se o seu objetivo for obter a menor superfície de ataques possível, a solução ideal terá que alinhar a arquitetura do website aos diferentes tipos de clientes. Algumas organizações já fizeram isso em vários níveis. Outras talvez precisem reprojetar seu website para fazer isso. Dividir os pontos de extremidade existentes em URLs separados ajudará a reduzir a superfície de ataques, oferecendo o controle mais detalhado do tráfego de URLs transacionais.

Por exemplo, você pode segmentar seus clientes por URL da seguinte forma:

URL 1: usuários em navegadores móveis, de desktop e de notebooks

URL 2: aplicações móveis nativas

URL 3: serviços automatizados de terceiros, como agregadores e parceiros do setor

Com essa abordagem, você poderá aplicar a detecção de bots adequada ao URL 1 e ao URL 2, e forçar outros tipos de consumidores ao URL 3. Embora não seja possível usar a análise de anomalias comportamentais para proteger o URL 3, você poderá controlar os recursos de dados e aplicações disponíveis aos seus usuários.

Prós Contras

Menor risco Pode ser um projeto muito grande, abordando muitas partes do website ou da organização

Menor superfície de ataques Poderá ser muito prejudicial para as operações quando a disponibilidade do website for um dos principais objetivos

6Entendendo os ataques de credential stuffing

Opção 2: adicione aplicações móveis nativas a uma lista de permissões

Os pontos de extremidade que atendem a clientes baseados em navegador e a aplicações móveis nativas podem ser protegidos por uma solução de gerenciamento de bots que oferece injeção de JavaScript e um SDK móvel. No entanto, algumas organizações podem não estar dispostas a atualizar suas aplicações móveis com o SDK móvel de um fornecedor ou, pelo menos, podem não estar dispostas a fazer isso imediatamente.

Considerando-se que a integração de suas aplicações móveis ao SDK de um fornecedor e a atualização de toda a sua base de usuários podem ser um compromisso significativo, você pode implantar a injeção baseada em JavaScript no ponto de extremidade para clientes baseados em navegador e optar por criar uma lista de permissões para suas aplicações móveis por meio de algum componente do cabeçalho da solicitação (como valores de campos de cabeçalho, por exemplo, agente de usuário, ou a ordem dos campos de cabeçalho) como uma solução paliativa.

Prós Contras

Fácil de fazer Só funciona até que um invasor descubra que você incluiu sua aplicação móvel em uma lista de permissões

Não disruptivo É relativamente comum que um invasor falsifique suas aplicações e contorne as proteções

Opção 3: inclua os serviços automatizados de terceiros que você conhece em uma lista de permissões

Se você tiver tráfego de cliente (baseado em navegador ou API) e um conjunto limitado e conhecido de serviços automatizados de terceiros (todos acessando o mesmo ponto de extremidade), poderá optar por incluir os serviços automatizados de terceiros em uma lista de permissões. Por exemplo, um banco pode optar por usar uma lista de permissões para os endereços IP de um agregador financeiro popular, como a Intuit Mint. Geralmente, esses serviços operam a partir de um espaço conhecido de endereços IP, dificultando a falsificação por um invasor. Todos os serviços automatizados de terceiros que não estejam explicitamente incluídos em uma lista de permissões serão tratados como bots.

Prós Contras

Fácil de fazer Os terceiros devem ser colocados individualmente nas listas de permissões

Os endereços IP são relativamente difíceis de falsificar usando protocolos HTTP/HTTPS

Os terceiros que estiverem na lista de permissões ainda terão acesso total aos mesmos dados e funcionalidades como um usuário

Só será viável se todos os serviços de terceiros forem conhecidos e limitados em número

7Entendendo os ataques de credential stuffing

A Akamai protege e entrega experiências digitais para as maiores empresas do mundo. A Akamai Intelligent Edge Platform engloba tudo, desde a empresa até a nuvem, para que os clientes e suas empresas possam ser rápidos, inteligentes e estar protegidos. As principais marcas mundiais contam com a Akamai para ajudá-las a obter vantagem competitiva por meio de soluções ágeis que estendem o poder de suas arquiteturas multinuvem. A Akamai mantém as decisões, as aplicações e as experiências mais próximas dos usuários, e os ataques e as ameaças cada vez mais distantes. O portfólio de soluções Edge Security, desempenho na Web e em dispositivos móveis, acesso corporativo e entrega de vídeos da Akamai conta com um excepcional atendimento ao cliente e monitoramento 24 horas por dia, sete dias por semana, durante o ano todo. Para saber por que as principais marcas mundiais confiam na Akamai, visite akamai.com, blogs.akamai.com ou @Akamai no Twitter. Encontre nossas informações de contato globais em akamai.com/locations. Publicado em 07/20.

Próximo passo: entenda a arquitetura, os riscos e as opções de seus pontos de extremidadeSe sua organização não usa URLs exclusivos para cada tipo de cliente (navegadores da Web, aplicações móveis nativas e serviços automatizados de terceiros), é essencial analisar sua arquitetura da Web.

O primeiro passo é entender sua superfície de ataques atual, o nível de risco ao qual você está sujeito e as suas opções. Os melhores especialistas em segurança contra credential stuffing da Akamai podem realizar uma análise abrangente e desenvolver um manual para sua estratégia de atenuação desse tipo de ataque. Como resultado, você entenderá a arquitetura do seu website e como ela afetará a implementação de qualquer solução de detecção de bots, incluindo:

1. Identificar URLs transacionais que precisam de proteção contra credential stuffing e todos os

pontos de entrada de formulários HTML que enviam solicitações a eles.

2. Categorizar esses URLs por tipo de consumidor.

3. Identificar URLs híbridos e recomendar a reestruturação de clientes de URL.

4. Identificar e avaliar complicações técnicas conhecidas.

5. Corresponder estruturas de destino e de políticas para determinar a estratégia de proteção

adequada, por tipo de cliente de URL.

6. Desenvolver um manual para a superfície de ataques de credential stuffing e identificar os

próximos passos para um plano de implementação de detecção de bots.