){kind=link}
O Google lançou nesta semana o Device Bound Session Credentials (DBSC) no Chrome 146 para Windows, mecanismo que torna cookies de sessão inutilizáveis fora do dispositivo onde foram criados. A proteção para macOS está prevista para uma versão futura do navegador.
Em termos simples, quando você faz login em um site, o servidor cria um cookie de sessão. Basicamente, trata-se de um token de autenticação armazenado no navegador que prova para o servidor que você é você, sem que o site precise pedir sua senha a cada acesso. Esses cookies costumam ter validade longa, às vezes de dias e até semanas.
smart_display
Nossos vídeos em destaque
Um atacante que consiga copiar esse arquivo não precisa da sua senha. Ele apresenta o cookie diretamente ao servidor e é autenticado no seu lugar. Malwares especializados nesse tipo de coleta são chamados de infostealers. O LummaC2 é um dos exemplos mais ativos atualmente, e os acessos obtidos costumam ser comercializados em fóruns criminosos ou revendidos entre grupos de ameaças.
Por que esse problema não tinha solução até agora
Uma vez que um malware está ativo na máquina, ele tem acesso aos mesmos arquivos que o sistema operacional usa, incluindo onde o navegador guarda os cookies. Não existe forma de impedir essa leitura usando apenas proteções de software, em nenhum sistema operacional.
A defesa tradicional era reativa, e constituía em detectar o uso suspeito do cookie depois que o roubo já aconteceu e então invalidar o acesso. Atacantes persistentes conseguiam contornar essa detecção com relativa frequência. O DBSC muda a lógica do problema: em vez de tentar impedir o roubo do cookie, ele torna o cookie roubado inútil.
Como o DBSC amarra a sessão ao hardware
O mecanismo usa o chip de segurança embutido no dispositivo, o Trusted Platform Module (TPM) no Windows e o Secure Enclave no macOS, para gerar um par de chaves criptográficas. Esses chips são componentes físicos projetados para guardar material criptográfico de forma que ele não possa ser exportado, nem por softwares com privilégios elevados.
)
A chave privada fica permanentemente dentro do chip. Toda vez que o Chrome precisa renovar um cookie de sessão, ele prova ao servidor que ainda tem acesso a essa chave, ou seja, que ainda está no mesmo dispositivo de origem. Os cookies gerados têm validade curta e só são renovados mediante essa prova.
Se um infostealer roubar um cookie protegido pelo DBSC, vai ter em mãos um token que expira em pouco tempo e não pode ser renovado, porque a chave privada necessária ficou no chip do dispositivo da vítima.
Cada sessão é protegida por uma chave distinta, o que impede que o mecanismo seja usado para rastrear o usuário entre sessões diferentes ou entre sites no mesmo dispositivo. O protocolo só transmite ao servidor a chave pública daquela sessão específica. Sem identificadores de dispositivo ou dados que possam ser usados para fingerprinting.
Um ano de testes com resultados positivos
O Google testou uma versão preliminar do DBSC ao longo do último ano com parceiros como a Okta e observou redução significativa nos casos de roubo de sessão. O padrão foi desenvolvido em parceria com a Microsoft e está sendo formalizado pelo W3C como padrão aberto da web.
Sites podem adotar o DBSC sem reformular sua arquitetura de autenticação. Isso porque a integração exige apenas a adição de dois endpoints no backend, um para registro da sessão e outro para renovação dos cookies. O frontend não muda.
Acompanhe o TecMundo nas redes sociais. Para mais notícias de segurança e tecnologia, inscreva-se em nossa newsletter e canal do YouTube.