Deixe de comparar ferramentas de account takeover como se fossem intercambiáveis. Não são. Um fornecedor de MFA prova quem inicia sessão, uma suite de fraude pontua o que a conta faz depois do login, e uma ferramenta de navegador diz-lhe se a sessão que corre na página é sequer humana. São três trabalhos diferentes em três momentos diferentes. Uma grelha de funcionalidades que as amontoa esconde a pergunta que precisa de responder: que camada lhe falta?
Este guia compara prevenção de ATO por camada defensiva (identidade/MFA, suite de fraude e navegador+bot), não por logótipo de fornecedor. Para cada camada vê o que observa, quando atua, que lacuna deixa aberta e onde a cside adiciona evidência de navegador que as outras duas não conseguem capturar. Sem preços inventados nem checklists falsas.
A razão para pensar em camadas é simples: os atacantes movem-se por um caminho. Credenciais roubadas são validadas por bots, sessões válidas são sequestradas depois de a MFA passar, e a fraude só aparece na transação. Cada camada cobre parte desse caminho e fica cega no resto.
Compare a prevenção de ATO por camada defensiva
| Camada defensiva | O que prova | Quando atua | Ponto cego que deixa |
|---|---|---|---|
| Identidade / MFA | Quem se autentica | No login, antes da sessão | Roubo de sessão e AiTM depois de o fator passar |
| Suite de fraude | Se as ações da conta parecem arriscadas | Depois do login, na transação | Sessões automatizadas ou sequestradas que parecem "normais" até ao cobro |
| Navegador + bot | Se a sessão em si é humana e fidedigna | Na página, durante a sessão | Política de identidade do servidor e histórico transacional entre comerciantes |
Leia a tabela pela última coluna. A fraqueza de cada camada é a razão de existir de outra. Compre para fechar o ponto cego que realmente tem, não para acumular a lista de funcionalidades mais longa.
Camada 1, Identidade e MFA: prova quem, não como
A camada de identidade (Okta, Microsoft Entra ID e similares) decide se uma credencial mais um segundo fator devem abrir a porta. Políticas adaptativas podem pedir um desafio adicional quando o contexto do login parece estranho, como um dispositivo novo, uma geografia nova ou uma velocidade invulgar. Esta é a base, e fatores resistentes a phishing como passkeys (WebAuthn ao abrigo de NIST SP 800-63B AAL2/AAL3) fecham o credential stuffing como caminho.
O ponto cego é tudo o que acontece depois de o fator passar. Um proxy adversary-in-the-middle deixa a vítima autenticar-se normalmente, MFA incluída, rouba o token de sessão resultante e entra. A camada de identidade já devolveu "success". Não tem mais nada a dizer. Se o seu único controlo de ATO for MFA, uma sessão roubada parece exatamente o utilizador legítimo.
Camada 2, Suites de fraude: pontuam a conta, tarde no caminho
As suites de fraude (Sift, Forter e pares) pontuam eventos ao longo da jornada (registo, login, transação) usando modelos de machine learning treinados com dados entre comerciantes. São fortes na ponta da monetização: picos de velocidade, trocas de endereço de envio, alterações de método de pagamento, fluxos de chargeback. Para uma empresa com equipa de fraud ops e volume real de chargebacks, esta camada paga-se a si própria.
Dois limites honestos. Primeiro, os sinais mais fortes chegam tarde, perto da transação, depois de o takeover já ter acontecido. Segundo, a inteligência de dispositivo incorporada numa suite é uma funcionalidade dentro de uma pontuação de caixa negra, não um stream de sinais em bruto de navegador que você controla. Quando uma sessão automatizada se comporta como um humano paciente até ao pagamento, a suite costuma pontuá-la como limpa até à fraude. Um account takeover conduzido por bots é exatamente o caso em que essa pontuação chega tarde demais.
De dados da cside: as instalações de playwright-stealth (tooling de automatização desenhado para ocultar que um navegador está a ser controlado por um script) cresceram cerca de 10x durante 2025, segundo o relatório da cside sobre o futuro da segurança web. Esse é o kit perante o qual as suites de fraude têm menos visibilidade, porque imita um navegador normal na camada transacional.
Camada 3, Navegador e bot: esta sessão é sequer humana?
A camada de navegador corre na página e responde à pergunta que as outras duas não conseguem: esta sessão é um humano real num navegador real, ou um framework de automatização com credenciais humanas? É a camada que mais equipas compram a menos, e fica exatamente na lacuna entre "MFA passou" e "a transação liquidou".
Sinais concretos que esta camada captura e que nunca chegam a uma pontuação do servidor:
navigator.webdrivere flags de automatização: a propriedade que os navegadores expõem quando uma sessão é controlada por WebDriver/CDP, mais os rastos residuais que os plugins stealth tentam corrigir e falham.- Fugas CDP e de Runtime: atividade do Chrome DevTools Protocol e artefactos
Runtimeque traem um navegador headless ou controlado remotamente mesmo quando o user agent parece normal. - Deriva de fingerprint: a mesma "conta" a apresentar fingerprints de dispositivo inconsistentes ou rotativas entre logins, uma marca registada de farms de bots e tooling partilhado de replay de sessões.
- Comportamento de proxy residencial e VPN: sinais comportamentais de que um IP residencial aparentemente limpo está a ser usado para branquear tráfego automatizado, para além de uma simples blocklist de IPs.
- Scripts maliciosos na página: overlays de roubo de credenciais ou lógica de redirecionamento AiTM injetada através de scripts de terceiros ou próprios, capturados em runtime antes de o utilizador ser phishado.
Esse último sinal é a ponte de volta ao ponto cego da Camada 1. Os atacantes injetam overlays CSS e scripts rogue em páginas legítimas para empurrar os utilizadores para um login falso que faz proxy do código MFA em tempo real. A camada de identidade vê uma autenticação limpa; a camada de navegador vê o script injetado e a sessão controlada.
Como comprar entre as três camadas
Não compre a checklist mais longa. Compre a camada que o seu caminho de ataque deixa aberta.
- Mapeie o seu caminho. Escreva login → validação → acesso → persistência de sessão → monetização, e marque que camada observa cada passo.
- Encontre o ponto único de falha. Se a MFA for o seu único controlo de ATO, a sua lacuna é roubo de sessão. Isso é um problema de navegador, não de MFA mais forte.
- Evite sinais duplicados sem ação partilhada. Duas ferramentas a marcar "dispositivo novo" é desperdício a menos que uma delas consiga impor.
- Execute uma prova real. Reproduza incidentes históricos contra a camada candidata e verifique se teria marcado a sessão, não só a transação.
- Ligue a entrega. Um sinal de navegador deve acionar step-up MFA na Camada 1 ou alimentar uma pontuação de risco na Camada 2, via API ou webhook, para que cada camada atue com a evidência das outras.
Onde a cside se encaixa
A cside é a camada de navegador e bots, e é desenhada para alimentar as outras duas em vez de as substituir. Corre client-side para capturar sinais de dispositivo e IP real, deteção de agentes IA e bots, deteção comportamental de VPN/proxy e visibilidade em runtime dos scripts que executam nas suas páginas de login e checkout. Esses sinais são enviados via API e webhook, para que um desfasamento de dispositivo ou um framework de automatização detetado dispare step-up MFA no seu fornecedor de identidade ou eleve a pontuação dentro da sua suite de fraude.
A cside não faz proxy do seu tráfego nem executa a sua política de identidade nem o seu fluxo de chargebacks. Fecha a lacuna específica que as outras duas camadas deixam aberta, a sessão viva, dentro da página, entre autenticação e pagamento, e entrega a evidência às ferramentas que fazem a imposição.
Leituras adicionais na cside
- Comparar soluções para prevenção de account takeover
- Como prevenir o fraude por account takeover: guia em 4 passos para empresas
- cside AI Agent Detection
- cside Signup Shield, para o problema a montante da criação de novas contas falsas e do abuso de testes no registo
