Hardening de sessões em ambiente Java

É bastante comum eu encontrar problemas em sessões de aplicações baseadas no ambiente Java. Estes problemas geralmente não são conhecidos por desenvolvedores, pois eles deixam todo o processo de criação e gestão de sessão a cargo do servidor de aplicação. A grande maioria dos servidores de aplicação Java não suportam ou não trazem por padrão as configurações adequadas para garantir a segurança destas sessões.

Neste post eu pretendo apresentar a solução para cada um dos problemas que eu encontro em análises que eu realizo. Todas as soluções dependem de codificação e devem ser feitas pelo desenvolvedor.

1 - Falta da flag HTTPOnly nos cookies de sessão

Como já podemos verificar em outro post aqui no blog, a falta da flag HTTPOnly nos cookies de sessão é um facilitador para ataques client-side que buscam sequestrar sessão de usuário, pois sem a flag é possível capturar o ID de Sessão via javascript. Mais informações podem ser obtidas na referência da OWASP.

Como tratar este risco

Para tratar este risco é preciso reescrever o cookie mantendo os dados originais e incluindo a flag HTTPOnly.

response.setHeader("Set-Cookie",
                   "originalcookiename=originalvalue;
                   HTTPOnly");

2 - Falta da Flag secure nos cookies de sessão

É importante que a flag secure seja setado em todo cookie de sessão. Isto irá garantir que um cookie gerado em uma conexão HTTPS (Conexão Criptografada) irá trafegar apenas por uma conexão tunelada via HTTPS. A falta desta flag permite que o cookie seja trafegado via HTTP (Texto Claro) e possa ser capturado por usuários mal intencionados que estejam capturando pacotes em rede. Mais informações podem ser obtidas na referência da OWASP.

Como tratar este risco

O tratamento deste risco é semelhante ao do HTTPOnly, basta reescrever o cookie e incluir a flag secure. Não esqueça de manter a flag HTTPOnly ao reescrever o cookie para incluir a flag secure.

response.setHeader("Set-Cookie",
                   "originalcookiename=originalvalue;
                   Secure;HTTPOnly");

3 - Session Fixation

Com esta vulnerabilidade o ID de sessão pode ser capturado por um ataque client-side e ser "forçado" seu uso em uma requisição. Isso possibilita burlar o sistema de autenticação da aplicação. Mais informações podem ser obtidas na referência da OWASP.

Como tratar este risco

Para tratar este risco é necessário recriar a sessão após a autenticação. Um exemplo de código é dado pelo Lucas Ferreira no seu site sobre segurança em Java.

O código abaixo mostra como abandonar uma sessão a criar outra após a autenticação:

public class ExampleLoginServlet extends HttpServlet {
public void doGet(HttpServletRequest request, HttpServletResponse response)
     throws ServletException, IOException {
     if( //autenticação bem sucedida ) {
        request.getSession().invalidate();
        HttpSession session = request.getSession(true);
        session.setAttribute("AUTHENTICATED", new Boolean(true));
        response.sendRedirect("PageRequiringAuthentication.jsp");

No caso de aplicações Struts 2, o código abaixo é mais apropriado:

if(//autenticação bem sucedida)  {

     /* Renovação do identificador de sessão */
     ((SessionMap)this.session).invalidate();
     this.session = ActionContext.getContext().getSession();

     session.put("AUTHENTICATED", new Boolean(true));

     return SUCCESS;
  }

  else
     return ERROR;
}

É importante que desenvolvedores entendam que para garantir a seguranca de uma aplicação, é preciso configurar adequadamente todos os ativos que a suportam, como: Banco de Dados e Servidor de Aplicação. Um bom código sem uma infraestrutura adequada pode levar ao comprometimento da aplicação.