Fixação de sessão: o ataque que começa antes do login

A fixação de sessão inverte a ordem normal do ataque. No sequestro de sessão comum, o atacante precisa de algo que já existe: um token válido. Na fixação, o atacante cria esse token antes de a pessoa entrar, e usa a pessoa para legitimá-lo.

A mecânica é a seguinte. O atacante gera um identificador de sessão e coloca esse valor em um link, ou em um formulário que a vítima preenche. A vítima abre o link, o servidor cria uma sessão e usa aquele identificador. A pessoa se autentica normalmente, com a senha correta, na frente do sistema. O servidor registra que aquela sessão agora pertence à conta da vítima. O token que o atacante conhecia desde o início acabou de virar uma sessão autenticada, e ele não precisa saber a senha.

A defesa é uma só, e é simples: trocar o identificador da sessão no momento do login, depois que a senha foi verificada. O sistema invalida o valor anterior e cria um novo, ligado à conta autenticada. O token que o atacante escolheu deixa de valer no instante em que a pessoa entra, e o ataque não se completa. Essa troca também protege contra o sequestro comum, porque um token interceptado antes do login também morre no login.

Vale a pena observar que a falha costuma estar na implementação e não na intenção. Sistemas que criam a sessão antes de autenticar e apenas trocam um campo no banco, sem gerar um novo identificador, mantêm a fixação aberta. O sintoma é visível no teste: se o valor do identificador antes do login é igual ao valor depois do login, existe fixação de sessão.

O mesmo raciocínio vale para troca de senha, troca de e-mail eelevação de privilégio. Sempre que a identidade da pessoa muda, o token muda junto.