Brecha de Segurança 2 – Back Button dos Navegadores

Postado em Updated on

Continuando com as questões de brechas de seguranças ocasionadas pelos serviços dos navegadores descritos neste primeiro post, hoje gostaria de apresentar mais um caso. O botão voltar é outra questão bem complicada. Como? Depois de se autenticar e operar na solução, o usuário final corretamente se desloga, encerrando sua sessão autenticada. O problema surge quando alguém senta na mesma estação de trabalho e usa o botão voltar do navegador vendo as ultimas paginas armazenadas no histórico dos navegadores. Imagine em solução que apresente o extrato bancário de uma empresa, simplesmente estaria visível para qualquer pessoa visualizar estas informações sensitivas. Ou seja, alguém sem permissão estaria tendo acesso a informações sensitivas furando assim o requisito não funcional de segurança .

Solução 1

Instruir o navegador a não armazenar nada do cachê e nem no histórico do navegador. Para isso adicione os seguintes parâmetros em todas as páginas da solução:

<meta http-equiv=”Cache-control” content=”no-store, no-cache, must-revalidate/>
<meta http-equiv=”Pragma” content=”no-cache” />
<meta http-equiv=”Expires” content=”-1″/>

Algo muito interessante nos meus testes de homologação foi que eu percebi que acrescentar isso nas paginas não estava funcionando. Eu concluí que o JEE web container que gerava as páginas para o navegador estava sobrepondo alguma destes parâmetros inibindo minha configuração. Para contornar isso, eu fiz um filtro servlet que transversalmente aplicou estes parâmetros dentro dos todas as paginas da minha solução, escrevendo os parâmetros antes de gerar a saída da resposta HTTP. Segue o filtro:

@Override
public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) throws IOException, ServletException {
HttpServletResponse hsr = (HttpServletResponse) res;
hsr.setHeader(“Cache-Control”, “no-cache, no-store, must-revalidate”); // HTTP 1.1.
hsr.setHeader(“Pragma”, “no-cache”); // HTTP 1.0.
hsr.setDateHeader(“Expires”, -1); // Proxies.
chain.doFilter(req, res);
}

Usando essa solução, todas as vezes que o usuário malicioso usar o botão voltar, o navegador vai enviar uma requisição para a solução requerendo a páginas por que não existe mais histórico para aquela determinada página, disparando assim o sistema de autenticação e autorização imposta pela solução.

Solução 2

Colocar uma mini chamada AJAX no onload de todas as páginas da solução que envie um pedido HTTP que valide a existência do usuário autenticado antes na apresentação da pagina para o usuário final. Assim quando o usuário malicioso usar o botão voltar do navegador, a páginas será validada e redirecionado para uma páginas de erro ou de autenticação caso não exista sessão autenticada. Aqui cada um fica livre para usar qualquer framework AJAX de preferencia.

Solução 3

Desabilitar via javascript o botão voltar no navegador – http://www.htmlgoodies.com/tutorials/buttons/article.php/3478911/Disabling-the-Back-Button.htm

Conclusão

Opção 2 e 3 dependem de javascript e podem ser desabilitado em qualquer navegador sendo assim falhos no objetivo. A opção 1 é a mais indicada.

“Deus tornou pecado aquele que não tinha pecado, para que nele nos tornássemos justiça de Deus”. 2 Coríntios 5:21

About these ads

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s