Pular para o conteúdo
>_ITDITDPlataforma de Segurança Web

Glossário

#session fixation#vulnerabilidade#web

O que é session fixation — fazer a vítima logar com um ID que o invasor já conhece

Session fixation faz a vítima usar um ID de sessão plantado pelo invasor e então se passa por ela assim que ela loga com esse ID. Como funciona e a defesa real — regenerar o ID de sessão no login, nunca aceitar um ID da URL, definir flags de cookie — explicado de forma defensiva.

Publicado 2026-06-11 Atualizado 2026-06-11 3 min de leitura

"A vítima loga com um ID que o invasor preparou" — isso é session fixation. Veja como funciona e como evitá-lo de forma confiável (sem passos de ataque).

Por que funciona

O cerne é um design em que o ID de sessão não muda ao longo do login. Se ele não muda, um ID que o invasor conhecia antes do login ainda funciona como "autenticado" depois do login.

1) O invasor faz a vítima usar um ID de sessão conhecido (via um link, etc.)
↓ a vítima loga com esse ID ainda definido
2) O ID não é regenerado = o mesmo ID torna-se "autenticado"
↓ o invasor conhecia esse ID o tempo todo
3) Acessar com o mesmo ID = passar-se pela vítima
Se o ID não muda no login, um ID que o invasor conhecia de antemão torna-se autenticado como está.

Pode se combinar com CSRF ou XSS, mas a essência da fixation em si é uma única coisa: o ID não foi regenerado no login.

Defesa: regenere o ID no login

1

Regenere o ID de sessão no login bem-sucedido (o mais importante)

No instante em que a autenticação tem sucesso, descarte o ID antigo e emita um novo ID de sessão (o session regenerate/renew da maioria dos frameworks). Qualquer ID pré-plantado é invalidado imediatamente. Regenere também na escalada de privilégio (por exemplo, virar admin).
2

Não aceite IDs de sessão pela URL

Trate o ID de sessão em um cookie e ignore um ID especificado em um parâmetro da URL. Feche o caminho que o invasor usa para fazer a vítima adotar um ID 'fixado'.
3

Reforce as flags de cookie

Defina os cookies de sessão como HttpOnly (o JS não pode ler), Secure (só HTTPS) e SameSite (restringe o envio entre sites). Enfraquece em conjunto os caminhos de sequestro relacionados.
4

Expire sessões com bom senso

Expire por timeout de inatividade, logout e troca de senha para que um ID fixado não possa viver indefinidamente.

A visão deste site: não desabilite o 'regenerate' do framework

A session fixation é quase totalmente eliminada por um único movimento — regenerar o ID no login — e não por código personalizado elaborado. A chave é não desabilitar acidentalmente nem esquecer de chamar o mecanismo que seu framework já fornece. Apoiar-se nos padrões seguros de uma implementação comprovada supera fazer seu próprio gerenciamento de sessão. Neste site mantemos "não construa autenticação/manuseio de chaves você mesmo; não desabilite os padrões seguros". Como no IDOR, a autenticação/autorização deve ser imposta por um mecanismo em cada requisição.

Leia a seguir

FAQ

QComo a fixation difere do sequestro de sessão?
A

O sequestro rouba o ID de sessão já emitido de alguém. A fixation é o inverso: o invasor faz a vítima usar um ID que o invasor já conhece, e então espera que a vítima logue com ele. Não rouba — faz com que um ID conhecido pelo invasor seja autenticado.

QQual é a principal defesa?
A

Regenerar o ID de sessão no momento do login. A maioria dos frameworks/bibliotecas de sessão tem isso (session regenerate/renew): ao autenticar com sucesso, descarte o ID antigo e emita um novo. Só isso já invalida qualquer ID que o invasor tenha plantado de antemão. Regenere também em mudanças de privilégio (por exemplo, virar admin).

QPor que colocar um ID de sessão na URL é perigoso?
A

Um ID na URL vaza facilmente por links compartilhados, pelo cabeçalho Referer, por logs e pelo histórico do navegador — uma forma de o invasor fazer a vítima usar um ID 'fixado'. Trate os IDs de sessão em cookies, não em parâmetros da URL, e não aceite um ID especificado pela URL.