Chrome passa a proteger sessões contra roubo de cookies
O Chrome adota credenciais vinculadas ao dispositivo para dificultar sequestros de contas mesmo quando cookies de sessão são roubados.
O Google Chrome passou a oferecer uma proteção contra uma das formas mais eficazes de sequestro de contas atualmente: o roubo de cookies de sessão. A tecnologia, chamada Device Bound Session Credentials, ou DBSC, vincula a sessão autenticada ao dispositivo usado no login.
A mudança é importante porque senhas, autenticação em dois fatores e passkeys não impedem todos os ataques. Depois que o usuário conclui o login, o site normalmente grava um cookie no navegador. Esse cookie permite acessar a conta sem repetir a autenticação a cada requisição. Se um invasor roubar esse valor, pode importá lo em outro navegador e assumir a sessão da vítima.
O problema dos cookies de sessão
Infostealers e ataques de phishing com interceptação de comunicação passaram a mirar diretamente os cookies armazenados no navegador. Em vez de descobrir a senha ou convencer a vítima a fornecer o segundo fator, o criminoso rouba uma sessão já autenticada.
O resultado é um acesso que pode ignorar as proteções usadas no login. O invasor recebe os mesmos privilégios temporários do usuário legítimo e pode acessar serviços corporativos, contas de nuvem, redes sociais, painéis administrativos e sistemas financeiros.
O problema se tornou mais relevante justamente porque as defesas tradicionais melhoraram. Quando a senha deixa de ser suficiente para entrar em uma conta, roubar a sessão existente passa a ser uma alternativa mais atraente para os atacantes.
Como o DBSC funciona
Durante o login, o Chrome cria um par de chaves criptográficas associado ao dispositivo. A chave privada é armazenada em hardware protegido, como o Trusted Platform Module, conhecido como TPM, em computadores Windows. Em dispositivos Apple, a função equivalente é desempenhada pelo Secure Enclave, quando disponível.
A chave privada não é exportada pelo navegador nem entregue ao servidor. O site recebe a chave pública e passa a associá la à sessão autenticada. A partir daí, o servidor pode exigir provas criptográficas de que as requisições continuam vindo do dispositivo que realizou o login.
Os cookies continuam existindo, mas deixam de ser suficientes sozinhos. O navegador precisa responder aos desafios do servidor assinando dados com a chave privada protegida no hardware. Como essa chave não pode ser extraída do dispositivo, um cookie copiado para outro computador não consegue produzir uma resposta válida.
A sessão também pode usar cookies de curta duração, que são renovados enquanto o navegador comprovar a posse da chave. Isso reduz a utilidade de um cookie roubado e dificulta a manutenção do acesso pelo invasor.
Por que a proteção é relevante
O DBSC não tenta tornar o roubo do cookie impossível. O objetivo é tornar o cookie roubado insuficiente para assumir a conta em outro dispositivo.
Scott Helme, pesquisador e fundador da Report URI, resumiu o benefício central: o invasor pode até roubar o cookie, mas não consegue responder ao desafio do DBSC porque a chave privada continua protegida no dispositivo original.
A abordagem aproveita recursos de segurança que já existem em muitos computadores modernos. O TPM e o Secure Enclave foram projetados para manter chaves criptográficas fora do alcance de processos comuns, inclusive quando um atacante consegue ler arquivos armazenados pelo navegador.
A tecnologia está disponível de forma geral no Chrome para Windows, com suporte baseado no TPM. Para usuários do Google Workspace, a proteção foi habilitada por padrão, sem exigir uma ação do administrador no console. Organizações também podem combinar o recurso com controles de acesso baseados no contexto e acompanhar eventos de vinculação nos registros de auditoria.
Limitações e pontos de atenção
O DBSC protege principalmente contra o reaproveitamento de cookies de sessão roubados em outro ambiente. Ele não elimina infecções no dispositivo original, nem impede que um invasor opere enquanto o malware mantém controle do navegador ou da máquina da vítima.
A proteção também não substitui boas práticas de segurança. Contas ainda precisam de autenticação resistente a phishing, dispositivos atualizados, controle de extensões, políticas de privilégio mínimo e monitoramento de sessões.
A adoção depende ainda do suporte dos sites. O navegador pode oferecer a capacidade, mas cada serviço precisa implementar o protocolo no lado do servidor. Sem essa integração, o cookie continua funcionando segundo o modelo tradicional.
Outro ponto é que o DBSC não resolve todo tipo de roubo de credencial. Tokens de atualização, credenciais obtidas por engenharia social e acessos obtidos diretamente no dispositivo comprometido podem permanecer válidos. A proteção reduz uma classe específica de ataque, mas não transforma uma conta em invulnerável.
O impacto para desenvolvedores
Para os desenvolvedores de aplicações web, o DBSC representa uma mudança de modelo. A sessão deixa de ser apenas um identificador secreto armazenado no navegador e passa a incluir uma prova de posse vinculada ao dispositivo.
Sistemas que lidam com dados sensíveis, administração de infraestrutura, pagamentos ou informações corporativas devem acompanhar a evolução da especificação e avaliar a implementação quando houver suporte adequado nos navegadores e bibliotecas usadas pelo produto.
A adoção exige revisar o ciclo de criação, renovação e revogação de sessões. Também é necessário definir o comportamento quando o usuário troca de dispositivo, reinstala o sistema, perde o equipamento ou não dispõe de hardware seguro compatível.
Como isso pode ser útil para você
No trabalho, você pode avaliar o DBSC como uma camada adicional para aplicações internas, portais administrativos e sistemas que concentram dados sensíveis. O primeiro passo é mapear onde o roubo de sessão permitiria ignorar a autenticação em dois fatores e acompanhar o suporte do navegador e do servidor usado pelo sistema.
Em projetos pessoais, a tecnologia ajuda a priorizar uma arquitetura de sessão mais resistente. Mesmo antes da adoção, vale reduzir a duração dos cookies, revogar sessões antigas, monitorar mudanças de dispositivo e separar operações críticas com uma nova autenticação.
Existe também uma oportunidade de renda em consultoria e desenvolvimento de bibliotecas para integrar DBSC a aplicações Node.js, Java, Python e PHP. Empresas que já usam autenticação forte podem precisar de ajuda para adaptar middleware, políticas de sessão, auditoria e recuperação de acesso sem prejudicar a experiência do usuário.