As aplicações web normalmente utilizam sessões que proporcionam um ambiente amigável para seus usuários e uma melhor forma de gerenciamento por parte da aplicação. A ideia básica por trás do gerenciamento de sessão é que o servidor gera um identificador de sessão (ID) e em algum momento no início da interação do usuário, envia esse ID para o navegador do usuário e deverá retornar este mesmo ID de volta para o servidor, junto com cada nova solicitação. Com isso, os sessions IDs tornam-se um token de identificação para os usuários, que irá manter os dados da sessão.

Muitas vezes esses IDs de sessão não são apenas os códigos de identificação, mas também autenticadores. Isto significa que após o login, os usuários são autenticados com base em suas credenciais (ex.: usuário/senha) e estes IDs de sessão vão ser utilizados como se fossem senhas estáticas temporárias para acessar suas informações.

Como você pode perceber, isso faz com que os sessions IDs se tornem um alvo muito visado pelos atacantes que podem realizar dois tipos de ataques o session hijacking e o session fixation. Hoje, no OWASP (Open Web Application Security Project), a vulnerabilidade de session management é listada como o segundo item mais perigoso em uma aplicação web. Isso acontece porque as proteções básicas de segurança não são aplicadas e existem diversas ferramentas e técnicas que são capazes de realizar esses ataques de forma muito simplificada, sendo que uma das técnicas e forma mais conhecida envolve a exploração das vulnerabilidades de XSS (Cross Site Scripting).

Felizmente existem diversas maneiras de prevenir e mitigar o problema, com essas dicas você irá reduzir o risco da sua aplicação. Confira abaixo como proteger as sessões de sua aplicação web.

Uso do TLS (Transport Layer Security)

Para proteger essa troca de ID das sessões contra qualquer tipo de ataque que procure interceptar as informações, como o man-in-the-middle, é obrigatório o uso do HTTPS (TLS) para todas as sessões web e não só para o processo de autenticação ou para onde as credenciais do usuário são envidas.

Cookies

Os cookies oferecem alguns recursos de segurança que podem ajudar a proteger a troca de informações dos IDs das sessões entre cliente e servidor, confira:

• Secure: Este atributo instrui o navegador a enviar os cookies somente através do HTTPS;
• HttpOnly: Este atributo instrui o navegador a não permitir que o cookie seja acessado via DOM (Ex.: JavaScript ou VBscript);
• Domain e Path: Este atributo instrui o navegador a enviar o cookie para apenas os domínios e subdomínios especificados.

Além dessas opções, é altamente recomendado o uso de cookies não persistentes para fazer o gerenciamento de sessões, pois dessa forma, o conteúdo não ficará armazenado no computador do usuário.

Ciclo de vida da sessão

Hoje temos dois tipos de gerenciamento de sessões que são utilizados: o strict e o permissive. Sem entrar em muitos detalhes específicos, o método mais comum e também mais seguro é o scrict.

Caso os dados da sessão em sua aplicação web sejam enviados através de um GET ou POST, você deve fazer o tratamento e a verificação como qualquer outra variável. Além disso, toda e qualquer mudança de privilégios na aplicação deve ser tratada como nova e a aplicação deve gerar uma nova sessão.

Expiração da sessão

Uma das formas de minimizar os ataques de roubo de sessão é determinar um tempo de expiração para a sessão. Essa configuração é praticamente obrigatória para todas as aplicações, pois quanto menor o tempo da sessão inativa, menor será o tempo de ataque.

Outra forma que pode ajudar, mas não é uma solução definitiva, é verificar o User Agent do usuário e fixar junto da atual sessão ou até mesmo verificar sessões simultâneas em uma mesma conta.

Cada aplicação web trabalha de uma forma diferente e lida com informações diferentes, com essas informações você deve determinar qual o risco e a necessidade de implementar controles mais simples ou mais rigorosos. Normalmente, é recomendado que o básico seja aplicado – isso inclui criptografia, segurança dos cookies, headers, waf e até mesmo algumas configurações na aplicação e/ou servidor, mas cabe a você determinar e calcular qual é o risco aceitável.