---
title: "O que é session hijacking? Roubo de cookies de sessão"
description: "Session hijacking é o roubo do cookie de uma sessão já iniciada: outra pessoa usa a sua conta sem a sua senha nem o seu 2FA. Como acontece e como impedir."
url: https://proxynet.io/pt-br/blog/what-is-session-hijacking
date: 2026-10-05
author: "Acar Diveroli"
category: "Proxy 101"
lang: pt-BR
---

# O que é session hijacking? Roubo de cookies de sessão

O seu provedor de e-mail envia um alerta de "novo acesso" vindo de um país que você nunca visitou. A sua senha é longa e única, e a autenticação de dois fatores está ativada, então ninguém adivinhou nada. O que muito provavelmente saiu do seu computador não foi a senha, mas o pequeno cookie que o navegador recebeu depois que você fez login. Quem tem uma cópia desse cookie é, até onde o site consegue saber, você.

Este artigo explica o que é um cookie de sessão, como ele é roubado (primeiro os infostealers, porque a maioria dos casos começa por eles), por que ele passa pela autenticação de dois fatores e o que fazer. Seções separadas tratam do que os donos de sites devem configurar e de por que os sites observam o endereço IP e o dispositivo por trás de uma sessão.

> **Nota: Resposta rápida**
>
> Session hijacking (sequestro de sessão) é a tomada de uma sessão que você já abriu, por meio do roubo do cookie ou token que prova que você está logado. Com uma cópia, alguém pode usar a sua conta sem a sua senha e sem um código da autenticação de dois fatores. Hoje a origem mais comum é um malware infostealer no seu próprio computador; as outras são páginas de phishing que repassam o seu login, falhas de cross-site scripting e conexões sem criptografia. Os usuários se protegem com dispositivos limpos, passkeys e encerrando as sessões que não usam; os sites, com cookies Secure, HttpOnly e SameSite, durações curtas e um novo ID de sessão a cada login.

## O que é session hijacking?

Session hijacking, também chamado de sequestro de sessão, roubo de sessão ou cookie hijacking, é a tomada de uma sessão web iniciada por um usuário real. O atacante não entra pela página de login. Ele reutiliza a prova de login que o site entregou depois dela.

A [OWASP Session Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html) explica por que isso importa: depois que uma sessão existe, o ID dela é "temporariamente equivalente ao método de autenticação mais forte usado pela aplicação". Se você entrou com uma senha e uma chave de segurança, o cookie vale tanto quanto as duas enquanto continuar válido.

## O que é um cookie de sessão e por que vale a pena roubá-lo?

Os sites não pedem a sua senha a cada clique. Depois que você faz login, o servidor cria um valor aleatório longo, o ID de sessão (session ID), e o envia ao navegador em um cookie; o navegador o devolve a cada requisição. Funciona como o cartão-chave de um hotel: a recepção confere o seu documento uma vez e, depois disso, o cartão abre a porta até expirar.

Os apps fazem o mesmo com tokens de acesso e de atualização (access e refresh tokens). A [referência de Set-Cookie](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Set-Cookie) do MDN usa "cookie de sessão" (session cookie) no sentido estrito, para um cookie sem data de expiração, apagado quando o navegador é fechado. Os cookies de login costumam durar mais: a opção "manter conectado" os deixa válidos por semanas, e é isso que torna útil uma cópia roubada.

## Como funciona o session hijacking?

1. **Você faz login** com uma senha e um código ou uma confirmação no celular. Esse é o único momento em que a autenticação de dois fatores é verificada.
1. **O site emite um cookie de sessão.** Daí em diante, só o cookie mantém você logado.
1. **Uma cópia sai do seu controle.** Um malware lê o armazenamento de cookies do navegador, uma página de login falsa repassa o seu acesso e fica com o cookie, ou uma falha no site o expõe.
1. **A cópia é usada em outro lugar.** O servidor vê uma sessão válida e não pede nada. O MITRE ATT&CK, o catálogo público de técnicas de ataque, diz que isso "contorna alguns protocolos de autenticação multifator, já que a sessão já está autenticada" ([T1550.004](https://attack.mitre.org/techniques/T1550/004/)). As equipes de segurança chamam isso de "pass the cookie".
1. **O atacante se instala:** um novo e-mail de recuperação, uma regra de encaminhamento, compras, antes que a sessão expire.

A defesa atua na etapa 3 (impedir que a cópia saia), na etapa 4 (torná-la inútil em outro lugar) e na etapa 5 (perceber rápido).

## Como os atacantes roubam cookies de sessão?

| Método | Do que depende | Defesa principal |
|---|---|---|
| Malware infostealer | Um download infectado ou um comando colado no seu computador | Dispositivo limpo, sessões vinculadas ao dispositivo |
| Phishing adversary-in-the-middle | Você faz login em uma página imitada que repassa tudo ao site real | Passkeys ou uma chave de segurança |
| Cross-site scripting (XSS) | Uma falha deixa um script injetado rodar nas páginas do site | Cookies HttpOnly |
| Session sniffing (escuta da sessão) | O cookie trafega por HTTP sem criptografia | HTTPS em tudo, atributo Secure |
| Fixação de sessão (session fixation) | O site mantém o mesmo ID depois do login | Um novo ID a cada login |
| IDs previsíveis ou vazados | IDs adivinháveis, ou IDs em URLs e logs | IDs aleatórios longos, só em cookies |

**Phishing que repassa o login.** Algumas páginas de phishing ficam entre você e o site real, repassam a sua senha e o seu código e guardam o cookie de sessão que o site real devolve; o MITRE lista essa rota de "proxy malicioso" em [roubo de cookies de sessão web](https://attack.mitre.org/techniques/T1539/). As passkeys derrubam essa tática: a [FIDO Alliance](https://fidoalliance.org/passkeys/) as descreve como credenciais resistentes a phishing, vinculadas à sua conta em um único site.

**Cross-site scripting.** Um script inserido nas páginas de um site por meio de uma falha roda como se o próprio site o tivesse escrito e pode ler qualquer cookie sem o atributo HttpOnly.

**Session sniffing.** Em uma rede que você não controla, o tráfego sem criptografia pode ser lido; o HTTPS fecha essa porta para o cookie, e [Wi-Fi público é seguro?](/pt-br/blog/is-public-wifi-safe) mostra o que continua visível. Para ler tráfego HTTPS, o seu dispositivo precisa confiar em um certificado raiz extra. Desenvolvedores adicionam um de propósito para depurar com um [proxy MITM](/pt-br/blog/mitm-proxy) na própria máquina; nunca instale um só porque uma rede ou um site pediu.

## O que é um infostealer e como ele passa pelo 2FA?

Um infostealer é um malware que copia os dados salvos em um computador e os envia para fora em minutos: senhas do navegador, cookies, dados de preenchimento automático, carteiras de criptomoedas e tokens de aplicativos. O resultado, um stealer log, é vendido no atacado.

Um [alerta conjunto do FBI e da CISA sobre o infostealer LummaC2](https://www.cisa.gov/news-events/cybersecurity-advisories/aa25-141b), de 21 de maio de 2025, lista o que esse tipo de malware leva, de "credenciais financeiras" a "detalhes de autenticação multifator (MFA)", e como ele chega: e-mails de phishing, software falso ou crackeado e páginas de CAPTCHA falsas. Essas páginas mandam o visitante pressionar Windows + R, colar com Ctrl + V e pressionar Enter, o que executa o comando do atacante. Nenhuma verificação real de "você é humano?" pede isso.

A autenticação de dois fatores não ajuda depois que o cookie vazou, porque o cookie é o resultado de um login que já passou pelo 2FA. No fim de agosto de 2026, a Anthropic desconectou usuários do Claude cujas sessões tinham sido copiadas por infostealers nos próprios computadores, avisando que sair da conta "não remove o malware" ([Help Net Security](https://www.helpnetsecurity.com/2026/08/31/claude-accounts-compromised-through-infostealer/)). Enquanto o dispositivo continuar infectado, a próxima sessão também é copiada.

O Have I Been Pwned também [carrega stealer logs](https://www.troyhunt.com/experimenting-with-stealer-logs-in-have-i-been-pwned/): verifique o seu endereço de e-mail pelo serviço gratuito de notificação para ver os sites em que o seu endereço apareceu e trate cada um deles como exposto.

## Session hijacking vs. credential stuffing, phishing e CSRF

| Ataque | O que o atacante obtém | O 2FA impede? |
|---|---|---|
| Session hijacking | Uma sessão logada (cookie ou token) | Não, a sessão já passou pelo 2FA |
| [Credential stuffing](/pt-br/blog/what-is-credential-stuffing) | Uma senha vazada, testada em outros sites | Sim, na maioria dos casos |
| Phishing de senha | A sua senha, às vezes um código de uso único | Códigos podem ser repassados; passkeys impedem |
| Cross-site request forgery (CSRF) | Uma ação enviada pelo seu próprio navegador | Não; cookies SameSite e tokens CSRF impedem |

No CSRF o cookie nunca sai do seu navegador; o session hijacking o leva para outra máquina.

## Sinais de que a sua sessão foi sequestrada

- Um alerta de "novo acesso" que você não provocou, ou um dispositivo desconhecido na lista de sessões ativas da conta.
- Alterações que você não fez: e-mail ou telefone de recuperação, regras de encaminhamento, apps conectados, formas de pagamento.
- Mensagens ou pedidos que você não enviou, ou um saldo ou cota de uso que diminui enquanto você está fora.
- Ser desconectado sem aviso, às vezes porque o site detectou uma segunda cópia da sua sessão.

Um pedido de autenticação de dois fatores que você não solicitou significa outra coisa: alguém tem a sua senha. Recuse e troque essa senha.

## O que fazer se a sua sessão foi roubada

1. **Limpe o dispositivo primeiro.** Faça uma verificação completa com o seu software de segurança; se ele encontrar um infostealer, ou se você não tiver certeza, faça backup dos seus arquivos e reinstale o sistema operacional. Caso contrário, o malware simplesmente copia a sua próxima sessão.
1. **Encerre todas as sessões a partir de um dispositivo limpo.** Em uma conta do Google: **Conta do Google** > **Segurança e login** > **Seus dispositivos** > **Gerenciar todos os dispositivos**; depois selecione cada dispositivo desconhecido e escolha **Sair** ([passos do Google](https://support.google.com/accounts/answer/3067630?hl=pt-BR)). A maioria dos grandes serviços tem uma lista parecida.
1. **Troque a senha.** O Google então desconecta você em todos os lugares, exceto em alguns dispositivos que ele lista na [página de ajuda sobre senhas](https://support.google.com/accounts/answer/41078?hl=pt-BR); outros serviços podem manter sessões antigas ativas, então faça também a etapa 2.
1. **Verifique o que ficou para trás:** dados de recuperação, encaminhamento de e-mail, apps conectados, formas de pagamento. Depois adicione uma passkey onde houver essa opção.

## Como evitar session hijacking como usuário

- **Instale software apenas de fontes oficiais** e nunca cole um comando que uma página da web peça para você executar.
- **Use passkeys ou uma chave de segurança.** Uma página de phishing consegue repassar um código, não uma passkey.
- **Não marque "manter conectado" em computadores compartilhados** e saia da conta quando deixar o computador.
- **Confira de vez em quando as sessões ativas da sua conta de e-mail.**
- **Remova as extensões do navegador que você não usa mais;** uma extensão com permissões amplas pode ler cookies.
- **Mantenha o navegador atualizado,** porque proteções como as sessões vinculadas ao dispositivo chegam pelas atualizações.

## Como evitar session hijacking no seu site

A cheat sheet da OWASP é a referência. Os pontos que mais importam:

1. **Configure os atributos do cookie.** `Secure` (só HTTPS), `HttpOnly` (sem acesso por scripts), `SameSite=Lax` ou `Strict`, e o prefixo `__Host-`, que exige Secure, `Path=/` e nenhum `Domain`.
1. **Torne os IDs impossíveis de adivinhar:** pelo menos 64 bits de entropia, gerados pelo seu framework, nunca em URLs.
1. **Emita um novo ID de sessão no login** e a cada mudança de privilégio; isso fecha a porta para a fixação de sessão.
1. **Faça as sessões expirarem.** Os exemplos da OWASP: um tempo de inatividade de 2-5 minutos para aplicações de alto valor, de 15-30 minutos para as de baixo risco e um tempo absoluto de 4-8 horas.
1. **Faça o logout ser de verdade.** Invalide a sessão no servidor e deixe os usuários verem e encerrarem as próprias sessões.
1. **Peça a verificação de novo antes de mudanças sensíveis,** como uma nova senha, um novo e-mail ou uma conta de recebimento.
1. **Sirva todas as páginas por HTTPS** com HSTS, para que os navegadores nunca voltem ao HTTP sem criptografia.

```text
Set-Cookie: __Host-sid=<random value>; Path=/; Secure; HttpOnly; SameSite=Lax
```

### Device Bound Session Credentials (DBSC)

O DBSC vincula uma sessão ao dispositivo que a criou. O navegador guarda uma chave privada em hardware seguro, como o chip TPM no Windows, e precisa provar que tem essa chave sempre que renova os cookies de curta duração do site; assim, um cookie copiado logo expira e não pode ser renovado em outro lugar. O Google [anunciou em 9 de abril de 2026](https://blog.google/security/protecting-cookies-with-device-bound-session-credentials/) que o DBSC está entrando em disponibilidade pública no Chrome 146 para Windows, com o macOS em seguida, como um padrão aberto do W3C. A [documentação do Chrome](https://developer.chrome.com/docs/web-platform/device-bound-session-credentials) descreve a configuração do lado do site e avisa que um malware já presente no momento do registro pode conseguir extrair a chave.

## Por que os sites vinculam a sua sessão ao seu endereço IP e dispositivo

Poucos sites prendem uma sessão a um único endereço IP, porque usuários reais alternam entre Wi-Fi e dados móveis o dia todo. Em vez disso, eles observam a sessão que de repente muda de perfil: um cookie emitido para um notebook em uma conexão doméstica aparece minutos depois em uma rede de hospedagem em outro país, com outro [fingerprint do navegador](/pt-br/blog/browser-fingerprinting). Isso parece roubo, então o site encerra a sessão ou pede um novo login. A OWASP observa que um atacante habilidoso consegue contornar a vinculação a IP e User-Agent, por isso essas verificações são uma camada, não a solução.

A mesma lógica pega usuários honestos. Se a sua VPN ou o seu proxy muda de país no meio da sessão, ou um proxy rotativo dá a cada requisição um endereço novo, o site vê uma sessão pulando pelo mapa e desconecta você; [Por que seu banco marca um login de local incomum?](/pt-br/blog/bank-suspicious-login-location) mostra isso do lado do usuário.

Equipes que trabalham em contas logadas por meio de um proxy, como agências que gerenciam contas de anúncios de clientes, mantêm uma saída por conta. Com os [Proxies de sessão fixa](https://proxynet.io/pt-br/sticky-proxy), uma sessão mantém o mesmo IP de 1 a 60 minutos, e os [Proxies ISP](https://proxynet.io/pt-br/static-isp-residential-proxy) oferecem um endereço fixo, registrado em nome de um provedor de internet, pelo tempo que você o alugar; [Plataformas de pagamento e IP](/pt-br/blog/payment-platform-login-ip-consistency) trata do caso financeiro. Um proxy não protege um cookie contra roubo, e os [Termos de serviço](/pt-br/tos) da Proxynet proíbem tentativas de acesso não autorizado.

## Onde o session hijacking causa mais estrago

- **Bancos e apps de pagamento,** onde uma sessão sequestrada pode movimentar dinheiro; veja a página de [finanças](/pt-br/finance).
- **Lojas virtuais e contas de vendedor,** com cartões salvos e dados de recebimento; veja a página de [e-commerce](/pt-br/e-commerce-proxy).
- **Redes sociais e contas de anúncios,** onde uma página tomada pode publicar golpes ou gastar o orçamento; a página de [redes sociais](/pt-br/social-media-proxy) explica como manter um IP por conta.
- **Painéis de administração e ferramentas da empresa,** onde uma única sessão roubada pode expor dados de clientes; a página de [segurança de dados](/pt-br/data-security) explica como testar as suas próprias páginas de login de fora.

## Erros comuns

- **Confiar que o 2FA protege uma sessão que já está aberta.**
- **Sair da conta em um computador que continua infectado.**
- **Trocar a senha e presumir que as sessões antigas terminaram.**
- **Site: um logout que só apaga o cookie no navegador.**
- **Site: prender as sessões rigidamente a um endereço IP,** o que desconecta usuários móveis e mal atrasa um atacante.

## Guia de decisão

| A sua situação | O que fazer primeiro |
|---|---|
| Um alerta de "novo acesso" que você não provocou | A partir de um dispositivo limpo, encerre todas as sessões e troque a senha |
| O software de segurança encontrou um infostealer | Limpe ou reinstale o computador; depois encerre as sessões e troque as senhas |
| O seu e-mail aparece em stealer logs | Trate os sites listados como expostos; adicione passkeys |
| Um pedido de 2FA que você não solicitou | Recuse e troque essa senha |
| Você mantém um site com login | Atributos de cookie, novo ID no login, logout no servidor, lista de sessões |
| A sua equipe trabalha em contas de clientes por meio de um proxy | Uma saída de sessão fixa ou estática por conta |

## Perguntas frequentes

### O session hijacking consegue contornar a autenticação de dois fatores?

Sim. A autenticação de dois fatores é verificada no login, e um cookie roubado representa um login que já passou por ela. As passkeys impedem a rota do phishing, mas não um malware no seu próprio dispositivo.

### Sair da conta me protege do session hijacking?

Em um site bem construído, o logout encerra a sessão no servidor, e um cookie copiado para de funcionar. Mas em um dispositivo infectado a próxima sessão é copiada de novo, então limpe o dispositivo primeiro.

### O HTTPS impede o session hijacking?

Ele impede a escuta na rede, mas não um malware no seu dispositivo, uma falha XSS ou uma página de phishing com o próprio certificado válido.

### Uma VPN ou um proxy impede o session hijacking?

Não. Os dois mudam o caminho na rede, mas um infostealer lê o cookie do seu disco e uma página de phishing o recebe direto de você. Uma VPN ou um proxy gratuito mantido por um estranho pode até aumentar o risco; veja [Proxies gratuitos e sites de web proxy são seguros?](/pt-br/blog/are-free-proxies-safe)

### Qual a diferença entre session hijacking e session fixation?

No hijacking, o atacante se apossa de um ID de sessão que já existe. Na fixação (session fixation), o atacante planta um ID conhecido antes de você fazer login e espera que você o autentique; um novo ID no login impede isso.

### Session hijacking é crime?

Sim. Usar a sessão de outra pessoa sem permissão é acesso não autorizado segundo as leis de crimes informáticos da maioria dos países. Testes só são legais nos seus próprios sistemas ou com permissão por escrito do dono.

## Em resumo

O session hijacking pula o login: quem tem uma cópia do seu cookie ou token de sessão está logado como você, com a senha e o código de dois fatores já validados. A maioria dos casos começa com um malware infostealer no próprio computador da vítima; depois vêm as páginas de phishing que repassam o login, as falhas XSS e as conexões sem criptografia. Os usuários se defendem com dispositivos limpos, passkeys e uma olhada nas sessões ativas; os sites, com atributos de cookie rígidos, novos IDs no login, durações curtas, um logout de verdade e sessões vinculadas ao dispositivo. Se a sua equipe trabalha em contas logadas por meio de um proxy, mantenha cada conta em um endereço estável com os nossos [serviços de proxy](/pt-br/proxy).