Reflexão sobre Session Hijacking

Para os utilizadores normais, o explicado abaixo é a razão porque devem sempre sair/fazer logout/terminar sessão de todas as aplicações web assim que as deixarem de usar. Este texto é destinado a programadores web e teve origem numa discussão com pessoal do Sapo.

O problema real é identificação, ou seja, como o servidor pode saber que aquele pedido é do cliente. A variação é recente (leia-se, últimos 8 anos): não podemos confiar no programa cliente como seguro porque ter malware instalado é uma situação normal nos dias de hoje.

A solução correcta seria fazer uma autenticação completa por pedido, usando um mecanismo externo ao cliente. Exemplos incluem a utilização de cartão do cidadão ou o smartcard da Fellowship da FSFE. Problema: um sistema destes tem custos altos e não é facilmente massificado (mesmo se nos limitássemos ao caso português, há partes da população para quem o cartão do cidadão nem sequer está previsto).

Sendo custosa a implementação da solução correcta, aceita-se que não protegemos contra o roubo de credenciais de autenticação e o problema reduz-se a session hijacking (roubo de informação normalmente não visível ao utilizador e que identifica um pedido como parte de uma sessão previamente autenticada). Podemos ter vários níveis de medidas de mitigação que reduzem a janela de ataque:

1) Usar sessões com um tempo de vida.

Janela de ataque: Um ataque só seria bem sucedido enquanto a sessão estivesse válida, pelo que seria desejável a menor duração possível.

Outras vantagens: aumento de escalabilidade do lado do servidor (menor tempo de vida -> menos recursos ocupados do lado do servidor).

Usabilidade: Para evitar a sensação do utilizador de estar sempre a autenticar-se, pode definir-se dois níveis de segurança é que as credenciais apenas são exigidas quando se vai fazer uma operação de escrita, estando o utilizador autenticado para operações de leitura de uma forma menos segura (ex: linkedin).

2) Não aceitar apenas o identificador de sessão como autenticação. Validar outra informação da ligação, por exemplo: IP, user-agent.

3) Usar tokens em cada troca de informação.

Janela de ataque: antes do utilizador a um formulário ou sair da página (depende se a implementação do token é por página ou formulário).

Custo: mais informação do lado do servidor para validar o token.

Usabilidade: Token por página não permite utilizar mais de uma página aberta na mesma sessão. Dá origem a uma má experiência.

Recomendações para programadores: reduzir ao mínimo o número de formulários desnecessários numa implementação de token por formulário. Cada formulário com um token válido é uma potencial porta de entrada.

4) Tokens em refrescamento contínuo. Só funciona com javascript/ajax. Todos os pedidos são submetidos por um pedaço de código que está activamente a ligar-se ao serviço – quando não há informação para enviar, pede um novo token com base no anterior.

Janela de ataque: o tempo do refrescamento do token, que pode ser de segundos.

Custo: mais ligações activas ao servidor, potenciais problemas de escalabilidade. Implica uma arquitectura diferente para submissão de informação que só funciona com Javascript.

Nos casos 2), 3) e 4) um ataque deve resultar na eliminação da sessão como comprometida. Para evitar negação de serviço, o ideal em 3) e 4) seria só eliminar a sessão se o token utilizado tivesse alguma vez sido um token válido (isto pode ser feito utilizando um formato de token que é rapidamente validado ou mantendo um historial dos tokens, que é mais custoso e complexo).

Mais algumas sugestões? Escapou-me alguma coisa?