Novo mecanismo do Google desativa cookies de autenticação fora do dispositivo onde foram criados, reduzindo o vetor de ataques de infostealer.
O Google introduziu recentemente o Device Bound Session Credentials (DBSC) no Chrome 146 para Windows, um mecanismo que torna os cookies de sessão inúteis fora do dispositivo onde foram gerados. A proteção para macOS deve ser implementada em uma versão futura do navegador.
De maneira simples, ao fazer login em um site, o servidor gera um cookie de sessão. Esse cookie funciona como um token de autenticação armazenado no navegador, provando ao servidor que você é realmente você, sem a necessidade de inserir sua senha constantemente. Normalmente, esses cookies têm uma validade prolongada, podendo durar dias ou até semanas.
Um atacante que consiga copiar esse arquivo não precisará da sua senha. Ele pode simplesmente apresentar o cookie ao servidor e obter acesso em seu lugar. Malwares que realizam esse tipo de ataque são conhecidos como infostealers, como é o caso do LummaC2, que é um dos mais ativos atualmente. Os acessos obtidos geralmente são comercializados em fóruns do crime ou trocados entre grupos maliciosos.
Por que isso é uma questão não resolvida até agora
Uma vez que um malware está ativo na máquina, ele tem acesso aos mesmos arquivos que o sistema operacional utiliza, incluindo os locais onde o navegador armazena os cookies. Não existe uma maneira eficaz de impedir essa leitura apenas com proteções de software em qualquer sistema operacional.
Vazamento do Claude Code é usado para disseminar versões alteradas com vírus.
A abordagem tradicional era reativa: detectar o uso suspeito do cookie após o roubo e invalidar o acesso. Atacantes persistentes frequentemente conseguiam contornar essa detecção. O DBSC altera o foco do problema: ao invés de tentar evitar o roubo do cookie, ele torna o cookie roubado inútil.
Como o DBSC amarra a sessão ao hardware
O mecanismo utiliza o chip de segurança embutido no dispositivo, como o Trusted Platform Module (TPM) no Windows e o Secure Enclave no macOS, para gerar um par de chaves criptográficas. Esses componentes físicos são projetados para proteger material criptográfico de maneira que não possa ser exportado, nem mesmo por softwares com permissões elevadas.
A chave privada permanece dentro do chip. Sempre que o Chrome precisa renovar um cookie de sessão, ele prova ao servidor que ainda possui acesso a essa chave, assegurando que está no mesmo dispositivo original. Os cookies gerados têm validade curta e são renovados somente mediante essa prova.
Se um infostealer roubar um cookie protegido pelo DBSC, ele terá em mãos um token que expira rapidamente e não pode ser renovado, pois a chave privada necessária permanece no chip do dispositivo da vítima.
Hackers norte-coreanos atacaram apenas uma pessoa para comprometer Axios e NPM.
Cada sessão é protegida por uma chave única, o que impede que o mecanismo seja usado para rastrear o usuário entre diferentes sessões ou sites no mesmo dispositivo. O protocolo transmite ao servidor apenas a chave pública daquela sessão específica, sem dados que possam ser usados para identificação ou rastreamento.
Resultados de um ano de testes positivos
O Google testou uma versão preliminar do DBSC ao longo do último ano com parceiros como a Okta, observando uma redução significativa nos casos de roubo de sessão. O padrão foi desenvolvido em colaboração com a Microsoft e está sendo formalizado pelo W3C como um padrão aberto da web.
Os sites podem integrar o DBSC sem a necessidade de reformular sua arquitetura de autenticação. A integração exige apenas a adição de dois endpoints no back-end, um para registro da sessão e outro para renovação dos cookies, sem alterar a parte frontal.
Acompanhe a TecMania nas redes sociais. Para mais notícias sobre segurança e tecnologia, inscreva-se em nossa newsletter e canal do YouTube.