Session Fixation

Se um usuário for autenticado sem a invalidação de qualquer identificador de sessão existente, isso dará a um invasor a oportunidade de roubar sessões autenticadas.

Vulnerabilidades de fixação de sessão ocorrem quando:

1. Um aplicativo Web autentica um usuário sem primeiro invalidar a sessão existente, continuando assim a utilizar a sessão já associada ao usuário.
2. Um invasor pode forçar um identificador de sessão conhecido para um usuário, de modo que, uma vez que o usuário seja autenticado, o invasor tenha acesso à sessão autenticada.

Na exploração genérica de vulnerabilidades de fixação de sessão, o invasor cria uma nova sessão em um aplicativo Web e registra o identificador de sessão associado. Em seguida, o invasor faz com que a vítima se autentique no servidor usando esse identificador de sessão, o que dá a ele acesso à conta do usuário através da sessão ativa.

Algumas estruturas, como o Spring Security, invalidam automaticamente as sessões existentes ao criar uma nova. Esse comportamento pode ser desabilitado, deixando o aplicativo vulnerável a esse ataque.

Exemplo 1: O exemplo a seguir mostra um trecho de um aplicativo protegido do Spring Security em que a proteção de fixação da sessão foi desabilitada.

	<http auto-config="true">
        ...
        <session-management session-fixation-protection="none"/>
	</http>

Mesmo com um aplicativo vulnerável, para que o ataque específico descrito aqui tenha êxito, é necessário que haja vários fatores favoráveis ao invasor: acesso a um terminal público não monitorado, capacidade de manter a sessão comprometida ativa e uma vítima interessada em fazer logon no aplicativo vulnerável no terminal público. Na maioria das circunstâncias, os dois primeiros desafios são contornáveis com um investimento de tempo suficiente. Encontrar uma vítima que esteja ao mesmo tempo utilizando um terminal público e queira fazer login no aplicativo vulnerável também é possível, desde que o local seja razoavelmente popular. Quanto menos popular for o local, menor será a probabilidade de uma vítima se interessar em usar o terminal público e menores as chances de sucesso para o vetor de ataque descrito anteriormente.

O maior desafio que um invasor enfrenta ao explorar vulnerabilidades de fixação de sessão é induzir as vítimas a se autenticarem no aplicativo vulnerável usando um identificador de sessão conhecido pelo invasor. No Example 1, o invasor faz isso por meio de um método direto óbvio que não se adapta bem a ataques que envolvem sites menos conhecidos. No entanto, não se deixe convencer pela complacência; os invasores têm muitas ferramentas que ajudam a contornar as limitações desse vetor de ataque. A técnica mais comum usada pelos invasores consiste em tirar proveito de vulnerabilidades de cross-site scripting ou divisão de respostas HTTP no site de destino [1]. Enganando a vítima para induzi-la a enviar uma solicitação mal-intencionada a um aplicativo vulnerável que reflete JavaScript ou outro código de volta para o navegador da vítima, um invasor pode criar um cookie que faz com que a pessoa reutilize um identificador de sessão controlado por ele.

É interessante notar que cookies estão frequentemente vinculados ao domínio de nível superior associado a determinada URL. Se vários aplicativos residirem no mesmo domínio de nível superior, como bank.example.com e recipes.example.com, uma vulnerabilidade em um aplicativo poderá permitir que um invasor defina um cookie com um identificador de sessão fixo usado em todas as interações com qualquer aplicativo no domínio example.com [2].

Outros vetores de ataque incluem envenenamento de DNS e ataques baseados em rede relacionados, em que um invasor induz o usuário a acessar um site mal-intencionado redirecionando uma solicitação de um site válido. Os ataques baseados em rede geralmente envolvem uma presença física na rede da vítima ou o controle de um computador comprometido na rede, o que os torna mais difíceis de explorar remotamente. Porém, sua importância não deve ser menosprezada. Mecanismos de gerenciamento de sessão menos seguros, como a implementação padrão no Apache Tomcat, permitem que identificadores de sessão normalmente esperados em um cookie sejam especificados na URL também. Isso permite que um invasor induza uma vítima a usar um identificador de sessão fixo simplesmente enviando uma URL mal-intencionada por email.