Torne Cada Sessão Web Device-Bound
Vincule cada sessão ao dispositivo original e impeça que tokens roubados funcionem em outro lugar.
Como sessões válidas vão parar no dispositivo errado
01 Logs de infostealer
Malware na máquina da vítima extrai cookies de sessão ativos e os vende em massa. O comprador importa o cookie e entra direto, sem senha, sem MFA.
02 Phishing adversary-in-the-middle
Kits de phishing com reverse proxy retransmitem a página de login real, capturam o session token pós-MFA e o reproduzem. A MFA é satisfeita no login; a sessão ativa já foi roubada. Veja como o roubo de token sobrevive à MFA.
03 Replay via proxy residencial
Atacantes roteiam a sessão roubada por um proxy na própria cidade da vítima para derrotar verificações de IP e geo, fazendo a sessão sequestrada parecer local e confiável.
04 Navegadores anti-detect
Navegadores feitos sob medida falsificam o user agent, as fontes e os sinais de dispositivo da vítima para fazer uma sessão sequestrada se misturar ao tráfego normal.
05 Malware no dispositivo e RATs
Ferramentas de acesso remoto operam no próprio dispositivo e na própria sessão da vítima, de modo que controles em nível de rede nem chegam a ver uma nova localização.
- Vincule cada sessão ao dispositivo que a criou, a partir de uma linha de base de mais de 250 sinais de navegador, dispositivo e rede.
- Detecte um token roubado no momento em que ele é reproduzido a partir de um dispositivo, IP ou ambiente de navegador diferente.
- Acione step-up auth ou encerre a sessão antes que o atacante alcance dados de conta ou de pagamento.
- Funciona em todos os navegadores, do pré-login ao checkout, first-party, sem amostragem, sem atrito extra para o usuário.
Como funcionam as sessões vinculadas ao dispositivo
Estabeleça a linha de base do dispositivo no início da sessão
Quando uma sessão começa, a cside captura mais de 250 sinais em um perfil de dispositivo e o vincula à sessão, o fingerprint que um usuário real reproduz e que um atacante não consegue.
Observe a sessão, não apenas o login
Cada requisição é verificada continuamente contra a linha de base de dispositivo da sessão, não apenas no momento do login, onde a maioria das ferramentas para de olhar.
Detecte a divergência de dispositivo
Quando um token é reproduzido a partir de um dispositivo, IP ou ambiente de navegador diferente, o perfil deixa de corresponder. A mudança fica visível mesmo antes de o cookie expirar.
Faça step-up ou encerre
Alimente a divergência no seu fluxo de auth para forçar a reautenticação, ou invalide a sessão diretamente, antes que o atacante toque em dados sensíveis.
Feito para sessões que valem a pena roubar
FinTech & Bancos
Session tokens roubados contornam a MFA para drenar contas. Vincule a sessão ao dispositivo.
Plataformas de Cripto
Sessões sequestradas movem fundos de forma irreversível. Detecte a troca de dispositivo antes do saque.
SaaS & Tecnologia
Uma sessão de admin reproduzida pode expor um tenant inteiro. Atrele sessões a dispositivos conhecidos.
Jogos Online
A tomada de conta via sessões roubadas alimenta o roubo de itens e saldos.
Por que as sessões vinculadas ao dispositivo da cside superam as alternativas
| vs. MFA & senhas | vs. Apenas device scoring | vs. DBSC (apenas Chrome) |
|---|---|---|
| Protege a sessão inteira, não apenas o momento do login | Age sobre uma divergência de dispositivo, desafia ou encerra a sessão, não apenas gera um risk score | Protege todos os navegadores, não só o Chrome |
| Detecta um token válido reproduzido a partir do dispositivo do atacante | Reverifica o dispositivo continuamente ao longo da sessão | Cobre também a jornada antes do login, cadastro, redefinição de senha, checkout |
| Sem depender de o usuário passar por um segundo fator no meio da sessão | Respostas integradas: step-up auth ou invalidação da sessão | Um script first-party, sem amostragem, sem novo hardware ou suporte de navegador |
Questions, answered
01 O que significa de fato uma 'sessão vinculada ao dispositivo'?
Significa que uma sessão só funciona no dispositivo que a criou. A cside monta um perfil de dispositivo quando a sessão começa e verifica cada requisição contra ele. Se a mesma sessão aparecer em outro dispositivo, essa divergência pode acionar um desafio ou uma invalidação, então um cookie roubado, por si só, deixa de ser suficiente para tomar a conta.
02 Como isso é diferente da MFA?
A MFA prova quem fez login. Ela não faz nada depois que um session token existe, e tokens roubados são reproduzidos depois que a MFA já foi satisfeita. As sessões vinculadas ao dispositivo protegem a parte que a MFA deixa aberta: a sessão ativa que se segue ao login. Veja por que MFA satisfeita não significa sessão segura.
03 A cside vincula o token criptograficamente como o DBSC faz?
Não, e os dois resolvem o problema de formas diferentes. O Device Bound Session Credentials (DBSC) do Google atrela criptograficamente um cookie a uma chave de hardware, mas apenas no Chrome e apenas depois do login. A cside usa inteligência de dispositivo para detectar quando uma sessão muda para um novo dispositivo, em todos os navegadores e em cada etapa da jornada. Eles são complementares, veja DBSC vs. device fingerprinting.
04 Com que rapidez ela detecta uma sessão roubada?
A verificação de dispositivo roda nas próprias requisições da sessão, então um replay a partir de um dispositivo, IP ou ambiente de navegador diferente pode ser sinalizado em tempo real, muitas vezes bem antes de o cookie roubado expirar.
05 Usuários legítimos serão deslogados ao trocar de rede ou de dispositivo?
Não. A cside pontua o perfil de dispositivo inteiro, não um único sinal, então uma mudança de IP no mesmo dispositivo é lida de forma muito diferente de uma troca completa de dispositivo. Você controla o limiar e a resposta, desafiar, fazer step-up ou invalidar.
06 Quais ataques isso impede?
Sequestro de sessão a partir de logs de infostealer, phishing adversary-in-the-middle, replay via proxy residencial e navegadores anti-detect, os caminhos que colocam uma sessão válida no dispositivo de um atacante. Para a ameaça mais ampla, veja tomada de conta.
07 Preciso substituir meu provedor de auth?
Não. A cside roda ao lado da sua camada existente de auth e de sessão e envia o sinal de divergência de dispositivo para o seu fluxo, então você decide se faz step-up ou revoga. É uma camada, não uma substituição completa.
08 Como é feita a implantação?
Com um único script first-party. Os sinais são coletados no caminho first-party, sem amostragem, sem latência mensurável e sem bloquear a UI.
Didn't find what you were looking for?
Talk to our teamBind every session to its device
One first-party script. Catch a stolen token the moment it lands on the wrong device.