Como o token de sessão vaza: os quatro caminhos mais comuns
Cross-site scripting, rede interceptada, dispositivo compartilhado e fixação de sessão. Cada um tem uma defesa própria, e nenhuma delas é cara.
Bruno Alexandre·18/10/2026·15 leituras
Quando alguém pergunta como sequestram uma sessão, a resposta curta é que existem poucos caminhos e eles são conhecidos. O que muda é a combinação de qual deles o sistema deixou aberto.
Os quatro caminhos que respondem pela maior parte dos sequestros de sessão
O primeiro caminho é o erro na própria página. Um script malicioso injetado no site da empresa lê o cookie e envia para fora. Quando o cookie tem o atributo HttpOnly, esse caminho fecha, porque o navegador recusa que o JavaScript leia o valor. É a defesa mais barata e mais ignorada que existe.
O segundo caminho é a rede. Em Wi-Fi aberto, ou em rede de empresa sem criptografia, o token trafega em texto legível e qualquer máquina intermediária consegue copiar. Aqui a defesa não é código: é HTTPS em todo o site, sem exceção e sem página de login em HTTP.
O terceiro caminho é o dispositivo. Computador de acesso compartilhado, navegador em rede pública, saída da sessão sem encerrar. Nesse caso o problema não é técnico, é de processo: sessão com prazo curto, encerramento visível e opção de ver os acessos ativos.
O quarto caminho é o mais elegante e o menos citado: a fixação de sessão. O atacante escolhe o token antes de a pessoa entrar, entrega esse token junto com o link de acesso e, quando a pessoa se autentica usando aquele link, o servidor associa a sessão nova ao token que o atacante já conhecia. A defesa é a troca do identificador no momento do login, depois de verificar a senha.
Em 21 de outubro de 2026 o PHP corrigiu duas falhas críticas que permitem executar código sem qualquer autenticação. Quem tem site em PHP precisa atualizar hoje.
