O sequestro de sessão ocorre quando um atacante rouba ou se passa pelo identificador de sessão válido de um usuário para obter acesso não autorizado a aplicações web. Isso pode acontecer por diversos meios, incluindo XSS, sniffing de rede ou tokens de sessão previsíveis. A prevenção envolve o gerenciamento seguro de sessões, o uso de HTTPS e a implementação de políticas adequadas de expiração de sessão.
Depois que um usuário faz login, o servidor emite um identificador de sessão, normalmente armazenado em um cookie ou token, que representa o login em cada requisição seguinte. Session hijacking é qualquer técnica que permite a um atacante obter ou reproduzir esse identificador e usá-lo para agir como o usuário, sem nunca descobrir a senha. O roubo pode acontecer de várias formas: cross-site scripting ou um script de terceiros malicioso lendo o cookie, sniffing de rede de tráfego não criptografado, malware no dispositivo ou adivinhação de tokens fracos e previsíveis. Uma vez que o atacante reproduz um ID de sessão válido, a aplicação trata suas requisições como as do usuário genuíno até que a sessão expire ou seja revogada.
Uma sessão roubada concede acesso autenticado imediato, então contorna totalmente o login, incluindo a autenticação multifator que só foi verificada no momento do acesso. Essa é a essência de um ataque pass-the-cookie: com um cookie de sessão válido, o atacante muitas vezes não precisa de senha nem de um segundo fator. Dependendo da conta, ele pode ler dados privados, fazer compras, movimentar fundos ou alterar configurações para trancar o usuário real do lado de fora. Como as requisições carregam uma sessão legítima, elas parecem normais para o servidor, então a detecção muitas vezes depende de sinais mais sutis, como uma mudança repentina de dispositivo ou localização, e não de uma falha óbvia.
Envie cookies de sessão apenas por HTTPS, marque-os como HttpOnly para que o JavaScript do lado do cliente não consiga lê-los e defina o atributo SameSite para limitar o envio entre sites. Use tokens longos e aleatórios, rotacione-os em mudanças de privilégio e imponha timeouts sensatos e revogação do lado do servidor. Como uma rota de roubo comum é um script de terceiros malicioso ou comprometido lendo cookies ou tokens no navegador, controlar o código do lado do cliente importa: a cside encaminha scripts de terceiros por um método Script, analisa a payload e pode bloquear em tempo real um script que tenta exfiltrar dados de sessão, mantendo um registro forense. Detectar uma incompatibilidade de dispositivo em uma sessão reutilizada também pode sinalizar um token sequestrado.
É um session hijacking que usa um cookie de sessão roubado. Como o cookie já representa uma sessão autenticada, um atacante que o obtém pode importá-lo para o próprio navegador e obter acesso sem a senha ou um segundo fator. É uma forma preferida de burlar a autenticação multifator depois do fato.
Não. O HttpOnly impede que o JavaScript do lado do cliente, incluindo payloads de XSS, leia um cookie, o que fecha uma grande rota de roubo. Mas as sessões ainda podem ser sequestradas por meio de sniffing de rede, malware no dispositivo ou tokens previsíveis. É uma camada importante, melhor combinada com HTTPS, SameSite, geração forte de tokens e timeouts.
We answer client-side security questions every day. Bring yours.