Identificando vulnerabilidades de segurança
em uma aplicação web
Marina S. Coelho1 , Lucas A. Tomasi1 , Thaı́s B. Idalino1 , Jean E. Martina1
1
Universidade Federal de Santa Catarina
Departamento de Informática e Estatı́stica
Campus Universitário – Florianópolis – SC – Brasil
[email protected], [email protected],
[email protected], [email protected]
Abstract. The lack of security in an specific part of an application can make it
entirely vulnerable to attacks. It is assumed that a system is not safe if it allows
an attacker to find ways to access sensitive data that should be kept private.
Based on the severity of the problem that the exposition of these data can bring
about, in this paper it is proposed a detailed analysis of a system in order to
expose the most serious threats found.
Resumo. A falta de segurança em uma parte especı́fica de uma aplicação pode
torná-la inteiramente vulnerável à ataques. Assume-se que um sistema não é
seguro se permite que algum atacante encontre meios de acessar dados sensı́veis
que devem ser mantidos privados. Com base na severidade do problema que a
exposição desses dados pode acarretar, neste trabalho é proposta uma análise
detalhada de um sistema a fim de expor as ameaças mais sérias encontradas.
1. Introdução
Aplicações web estão presentes diariamente na vida das pessoas. Tornou-se comum dispor desse meio para realizar as mais diversas atividades, desde acessar uma rede social
a consultar o extrato da conta bancária. É frequente que estas aplicações utilizem e armazenem dados sensı́veis de seus usuários. Podemos pensar em uma aplicação de home
banking, onde, ao autenticar-se por meio de senha, é possı́vel obter acesso ao número do
cartão, número da agência e até saldo da conta do cliente.
Apesar dos riscos, muitas aplicações contém diversas vulnerabilidades. Dentre
elas, as que aparecem com mais frequência e oferecem mais risco à aplicação são relatadas no Top Ten da OWASP (Open Web Application Security Project). Esse projeto
visa auxiliar as empresas a desenvolverem, operarem e manterem aplicações seguras e
confiáveis. A cada três anos a OWASP divulga o Top Ten, uma lista contendo as dez
fragilidades mais exploradas e de maior impacto nas aplicações [OWASP 2015]. Paralelamente, é lançado um documento chamado Testing Guide, um guia para a realização
de Penetration Tests em sistemas web. O objetivo de executar Pentests é a avaliação da
segurança através da simulação de um ataque malicioso no ambiente da aplicação.
Este trabalho visa realizar Penetration Tests em uma aplicação (mantida anônima
para sua segurança) utilizando o Top Ten e o Testing Guide da OWASP como referências.
2. Conceitos básicos e trabalhos correlatos
Diversos trabalhos abordam os testes de uma forma geral, explicando algumas técnicas
para exploração de falhas ([de Souza 2012],[da Silva and Pereira 2013]). Porém, foi
difı́cil achar estudos que ensinem e exemplifiquem como pôr em prática todo o conteúdo.
Por este motivo, nenhum trabalho contribuiu de forma significativa no auxı́lio à aplicação
dos testes de penetração. Este artigo se preocupa não somente com a parte teórica, mas
também com a prática dos conceitos tratados, tendo como finalidade elaborar um guia
para auxiliar na aplicação dos testes aqui expostos. Porém, devido ao curto espaço do artigo, não será possı́vel demonstrar a execução de todos os testes. Serão expostos somente
os que reportaram os erros mais graves, são eles: Broken Authentication and Session
Management e Cross Site Scripting.
3. Proposta
Para melhor entender os riscos de ter um sistema frágil e a importância dos testes que
serão descritos a seguir, é necessário saber que basta uma única vulnerabilidade para
acabar com a segurança de toda a infraestrutura de uma aplicação [Maggi et al. 2009].
Este trabalho tem como finalidade ampliar a abrangência e o detalhamento dos testes expostos, de modo que seja possı́vel tomá-lo como base para testar qualquer aplicação
web. É necessário saber que existem várias maneiras de tentar invadir uma aplicação. A
técnica utilizada aqui é chamada de Black Box. É a técnica utilizada quando não temos
informação alguma de código ou estrutura da aplicação que pretendemos invadir. Antes de
tudo, foi feita uma varredura automática com a ferramenta Zed Attack Proxy [ZAP 2015].
A partir de agora serão apresentadas as principais falhas encontradas, divididas de acordo
com a vulnerabilidade na qual se encaixam segundo o Top Ten.
3.1. Broken Authentication and Session Management
O objetivo deste teste é tentar burlar a etapa de autenticação. Na aplicação em questão,
ao criar novos usuários e realizar testes manuais simples através da interface, as seguintes
fragilidades foram encontradas.
Senhas fracas. Foi possı́vel cadastrar uma conta com senha em branco. É necessário solicitar ao cliente que crie uma senha forte, mudando a polı́tica de senhas do
site para incluir, por exemplo, um sı́mbolo ou um número e ter um tamanho mı́nimo.
Enumeração de usuário.
Na página de autenticação, ao informar um
usuário válido com senha incorreta, é apresentada a mensagem de erro “A
senha digitada está incorreta.”e a URL exibida após o redirecionamento é
“/portal-autenticacao-web/login.jsp?erroauthc=erro.autenticacao.senha.incorreta”.
Porém, ao informar um usuário inexistente, a mensagem apresentada é
“A conta informada não existe.”e a URL exibida é “/portal-autenticacaoweb/login.jsp?erroauthc=erro.autenticacao.usuario.inexistente”. Isto significa que
qualquer pessoa pode enumerar os usuários existentes dentro do sistema. O correto, em
qualquer sistema, é retornar sempre o mesmo tipo de erro, devendo este ser genérico,
impossibilitando que um atacante consiga listar os clientes. É também necessário que
as URLs referentes aos erros de autenticação também sejam genéricas e não forneçam
pistas.
Bloqueio para tentativas de login. Não há mecanismo para bloquear a conta após
sucessivas tentativas de login com senha incorreta, o que permite que um atacante erre a
senha infinitas vezes ao tentar entrar no sistema. A maneira mais recomendável de implementar a autenticação é bloquear o número de tentativas de acesso e, a partir de então,
barrar a entrada com um CAPTCHA. Um CAPTCHA é um teste que pode ser facilmente
resolvido por seres humanos, mas que está além da capacidade de solução da maioria
das máquinas que conhecemos hoje. Segundo Yan e Ahmad [Yan and Ahmad 2008], esta
tecnologia já é quase o mecanismo de segurança padrão para evitar ataques indesejáveis,
como bot, sendo assim um mecanismo de defesa extremamente importante.
Força bruta. Sabendo que a aplicação possui estas três vulnerabilidades, é
possı́vel aplicar um ataque chamado Brute Force. Consiste em uma verificação automatizada de todas as possı́veis senhas de um usuário, inserindo-as no sistema até encontrar
a correta. Nesse caso um atacante dispõe de todos os requisitos para este tipo de invasão:
senhas fracas, que podem ser descobertas rapidamente por um programa; um usuário
válido, que pode ser obtido através da enumeração; e em momento algum a execução vai
parar, pois não há um bloqueio que evite o teste repetido das senhas. A máquina que está
executando brute force só será interrompida quando encontrar a senha correta.
Atributos de cookie. Resumidamente, cookies são gerados pelo servidor e enviados ao cliente quando um usuário acessa uma aplicação e esta precisa se certificar da
identidade do usuário para várias requisições posteriores. Dessa maneira, o cliente vai
continuar enviando o cookie de volta ao servidor em várias conexões. Este teste busca
verificar se a aplicação assina corretamente o cookie e os atributos do mesmo. Ao acessar
a página inicial da aplicação em questão, é definido um valor de cookie que é utilizado
para controlar a sessão do usuário. Foi possı́vel concluir, através da resposta do servidor,
que alguns dos atributos estão configurados de maneira errada:
HttpOnly. Evita que o cookie seja acessado por um script do lado cliente. A flag
não estava presente na aplicação, o que significa que, caso um atacante consiga rodar um
JavaScript, este pode obter acesso ao valor do cookie e sequestrar a sessão da vı́tima.
Domain. Especifica domı́nios e subdomı́nios do sistema. A flag não estava presente. É importante ressaltar que, no caso de este atributo não estar presente, o hostname
do servidor que gerou o cookie será usado como domı́nio padrão. Assim, o cookie poderia
ser enviado para qualquer subdomı́nio criado, como “hacker.dominio.com.
Path. Completa o domain, fornecendo o diretório especı́fico para qual o cookie
é válido. A flag estava presente com o valor “/home”, omitindo uma “/”ao final. Isto
permite que o navegador envie o cookie para qualquer caminho cujo prefixo seja “/home”,
por exemplo: “/home-atacante”, que seria uma página semelhante a original, enganando o
usuário para que este entre com dados pessoais, e estes sejam interceptados pelo atacante.
3.2. Cross Site Scripting
Os resultados encontrados nesta fase revelam uma situação alarmante na aplicação. O
teste exposto a seguir foi aplicado conforme o escopo fornecido pelo Testing Guide.
Testing for Cross Site Scripting Stored. Este teste consiste em encontrar vetores
de entrada (inputs) no sistema e inserir dados maliciosos que serão armazenados no banco.
Na sequência, é preciso acessar as páginas que apresentam esse valores recuperados do
banco e avaliar se foi aplicado algum filtro para o valor que persistimos. A forma correta
de implementar é utilizar filtros tanto na hora de persistir os dados, quanto na de recuperálos.
Para testar, foi inserido um JavaScript que executa um alert ao cadastrar um
usuário no banco. Quando a página inicial foi acessada o nome do cliente estava sendo
filtrado corretamente, aparecendo em um formato string. Porém ainda não é possı́vel saber se o filtro foi aplicado na hora de salvar os dados no banco ou ao recuperá-los. Para
descobrir, bastou acessar a página que lista os dados do usuário.
Figura 1. JavaScript salvo sem filtro no banco.
Como é possı́vel perceber na Figura 1, ao acessar a página com os dados o script
foi executado, o que significa que não há filtro na hora de persistir e o script está sendo
salvo no banco de dados. O alerta não foi disparado na página inicial porque o filtro
estava sendo aplicado somente na hora de recuperar a informação. Isto pode gerar muitos
problemas, como por exemplo se esse banco for compartilhado e outras aplicações fizerem
uso dele, estes outros sistemas podem não ter filtro na hora de mostrar os dados do usuário.
O ataque simulado nos testes executa um alerta, mas este é apenas um dos muitos
comandos que podem ser persistidos nos vetores de entrada. Ao invés de um alert, o
atacante poderia roubar a sessão do usuário ou redirecioná-lo para um site de phising.
4. Considerações finais
Este trabalho teve como propósito instruir sobre a importância de implementar um sistema da maneira mais segura possı́vel, com base nos possı́veis erros que podem decorrer
das vulnerabilidades existentes. Teve também a finalidade de servir como guia detalhado
para a execução de dois dos testes apresentados pelo Testing Guide da OWASP. Devido
ao espaço limitado não foi possı́vel incluir todos os dez testes do Top Ten. Foram selecionados os considerados mais severos e predominantes segundo a OWASP.
É muito importante ter em mente que, embora os testes sejam executados de maneira individual e dessa forma sejam padronizados no Testing Guide da OWASP, eles não
são realmente isolados, pois uma vulnerabilidade pode tornar a outra muito mais perigosa
dependendo da forma como foi implementada, o que torna ainda mais importante garantir
que não hajam erros na aplicação.
Referências
da Silva, R. F. and Pereira, J. C. (2013). Identificando vulnerabilidades de segurança
computacional.
de Souza, L. L. (2012). Desenvolvimento seguro de aplicações web seguindo a metodologia owasp.
Maggi, F., Robertson, W., Kruegel, C., and Vigna, G. (2009). Protecting a moving target:
Addressing web application concept drift. Lecture Notes in Computer Science, 5758.
OWASP (2015). Open web application security project. https://www.owasp.org.
Yan, J. and Ahmad, A. S. E. (2008). Usability of captchas or usability issues in captcha
design. Symposium On Usable Privacy and Security.
ZAP (2015). Zed attack proxy project. https://www.owasp.org/index.php/OWASP Zed
Attack Proxy Project.