UmEstudoSobreFerramentas-Azevedo-2018

Prévia do material em texto

UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE
GRADUAÇÃO EM ENGENHARIA DE COMPUTAÇÃO
Daniel Galvão de Azevedo
UM ESTUDO SOBRE FERRAMENTAS DE BUSCA DE
VULNERABILIDADES EM APLICAÇÕES WEB
Natal/RN
Dezembro 2018
Daniel Galvão de Azevedo
UM ESTUDO SOBRE FERRAMENTAS DE BUSCA DE
VULNERABILIDADES EM APLICAÇÕES WEB
Trabalho de conclusão de curso apre-
sentado ao curso de Engenharia de
Computação da Universidade Federal
do Rio Grande do Norte, como parte
dos requisitos para obtenção do grau
de Bacharel em Engenharia de Com-
putação.
Orientador: Prof. Dr. Carlos Ma-
nuel Dias Viegas
Co-Orientador: Prof. Dr. Marco Vieira
Natal/RN
Dezembro 2018
Azevedo, Daniel Galvão de.
 Um estudo sobre ferramentas de busca de vulnerabilidades em
aplicações web / Daniel Galvão de Azevedo. - 2018.
 61 f.: il.
 Monografia (Graduação) - Universidade Federal do Rio Grande
do Norte, Centro de Tecnologia, Curso de Engenharia de
Computação. Natal, RN, 2018.
 Orientador: Prof. Dr. Carlos Manuel Dias Viegas.
 Coorientador: Prof. Dr. Marco Vieira.
 1. Segurança da informação - Monografia. 2. Ferramentas de
varredura de vulnerabilidades - Monografia. 3. Aplicações web -
Monografia. I. Viegas, Carlos Manuel Dias. II. Vieira, Marco.
III. Título.
RN/UF/BCZM CDU 004.056
Universidade Federal do Rio Grande do Norte - UFRN
Sistema de Bibliotecas - SISBI
Catalogação de Publicação na Fonte. UFRN - Biblioteca Central Zila Mamede
Elaborado por FERNANDA DE MEDEIROS FERREIRA AQUINO - CRB-15/301
UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE
DANIEL GALVAO DE AZEVEDO
Trabalho de conclusão de curso apresentado ao Curso de Engenharia de Computação
da Universidade Federal do Rio Grande do Norte, como parte dos requisitos para obtenção
do grau de Bacharel em Engenharia de Computação.
Prof. Dr. Carlos Manuel Dias Viegas
DCA/UFRN
Prof. Dr. Marco Vieira
DEI/FCT/UC
Prof. Me. Francisco Sales de Lima Filho
DIATINF/CNAT/IFRN
10 de Dezembro de 2018
Agradecimentos
Agradeço ao Departamento de Engenharia de Computação e Automação (DCA),
ao Instituto Metrópole Digital (IMD) e a Universidade Federal do Rio Grande do Norte
(UFRN) pela infraestrutura oferecida e a ótima formação que me foi proporcionada.
Agradeço aos meus pais por todo o amor, educação, apoio e ensinamentos passados
até hoje. Sou muito grato por tudo.
Agradeço ao Prof. Carlos Manuel Dias Viegas, por toda a paciência, ajuda e
conhecimentos passados durante todo o curso e durante o processo de desenvolvimento
deste documento.
Agradeço Prof. Marco Vieira também pela ajuda e paciência durante o processo de
desenvolvimento deste trabalho.
Agradeço aos professores do DCA que me proporcionaram uma excelente formação
no curso de engenharia de computação.
E, finalmente, a todos que direta ou indiretamente me ajudaram nessa etapa da
minha vida, muito obrigado.
Resumo
Com o advento da Internet, as pessoas e empresas têm se tornado dependentes das apli-
cações web. Diante disso, se faz necessário o desenvolvimento seguro dessas aplicações,
uma vez que o impacto causado por uma falha de segurança se torna cada vez maior, em
consequência desta dependência. Atrelado a isso, o número de hackers também vem au-
mentando rapidamente. Assim sendo, para garantir esta segurança, são utilizados métodos
como boas práticas de desenvolvimento e testes de invasão (pentest). Nestes dois casos, as
ferramentas de busca de vulnerabilidade web são bastante empregadas, principalmente
para a realização de testes do tipo black-box. No entanto, até mesmo estas ferramentas
precisam ser bem selecionadas, para se atingir o objetivo esperado. Este trabalho tem
como objetivo avaliar algumas das principais ferramentas de busca de vulnerabilidade web
de código aberto, tais como OWASP ZAP, Paros, SkipFish e Vega. Estas ferramentas
foram executadas sobre duas aplicações web intencionalmente vulneráveis e os relatórios
produzidos foram comparados com a lista de vulnerabilidades de cada aplicação. Além
disso, é apresentada uma pequena explicação das ferramentas e das principais vulnerabi-
lidades abordadas nas práticas, e em seguida são mostrados os cenários utilizados e os
dados obtidos. Ao final, são mostrados pontos positivos e negativos de cada ferramenta,
as dificuldades encontradas e ideias para se obter melhores resultados com trabalhos futuros.
Palavras-chave: segurança da informação, ferramentas de varredura de vulnerabilidades,
aplicações web.
Abstract
With the advent of the Internet, people and businesses have become dependent on web
applications. In view of this, it is necessary to safely develop these applications, since the
impact caused by a security flaw continues increasing, as a consequence of this dependence.
Linked to this, the number of hackers is also increasing rapidly. Thus, to ensure this
security, methods such as good development practices and penetration testing (pestest)
are used. In these two cases, web vulnerability scanner tools are widely used, mainly
for black-box type tests. However, even these tools need to be well-selected in order to
achieve the expected goal. This work aims to evaluate some of the main open-source Web
Vulnerability Scanners, such as ZAP, Paros, SkipFish and Vega. These scanners were run
on two intentionally vulnerable web applications and the produced Reports were compared
with the list of vulnerabilities of each application. Besides, a brief explanation of the tools
and main vulnerabilities addressed in the practices are given, and the scenarios used and
the data obtained are shown below. Finally, positive and negative points of each tool are
shown, difficulties encountered and ideas for better results with future works.
Keywords: information security, vulnerability scanning tool, web applications.
Lista de ilustrações
Figura 1 – Número de Incidentes nos anos de 1999 a 2017 . . . . . . . . . . . . . . 22
Figura 2 – Porcentagem dos tipos de incidentes ocorridos no ano de 2017 . . . . . 23
Figura 3 – Arquitetura de uma aplicação web. . . . . . . . . . . . . . . . . . . . . 28
Figura 4 – Exemplo de exploração da vulnerabilidade de Injeção de SQL. . . . . . 31
Figura 5 – Exemplo de exploração da vulnerabilidade Reflected Cross-Site Scripting. 33
Figura 6 – Código da página web após a exploração da vulnerabilidade de Reflected
Cross-Site Scripting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Figura 7 – Exemplo de exploração da vulnerabilidade Stored Cross-Site Scripting. 34
Figura 8 – Código da página web após a exploração da vulnerabilidade de Stored
Cross-Site Scripting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Figura 9 – Exemplo de aplicação web que utiliza commandos do sistema operacional. 36
Figura 10 – Exemplo de exploração da vulnerabilidade de Injeção de Comandos no
Sistema Operacional. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Figura 11 – Exemplo de exploração da vulnerabilidade Remote File Inclusion. . . . 37
Figura 12 – Exemplo de exploração da vulnerabilidade Local File Inclusion. . . . . 38
Figura 13 – Exemplo de exploração da vulnerabilidade Directory Browsing. . . . . . 39
Figura 14 – Exemplo de exploração da vulnerabilidade Click-Jacking. . . . . . . . . 40
Figura 15 – Cenário utilizado. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Figura 16 – Configuração do proxy no navegador FireFox. . . . . . . . . . . . . . . 45
Figura 17 – Configuração da ferramenta Paros. . . . . . . . . . . . . . . . . . . . . 45
Figura 18 – Configuração da ferramenta ZAP. . . . . . . . . . . . . . . . . . . . . . 46
Figura 19 – Configuração da ferramenta Vega. . . . . . . . . . . . . . . . . . . . . . 47
Figura 20 – Exemplo que vulnerabilidade reportada pela ferramenta ZAP . . . . . 52
Figura 21 – Exemplo que vulnerabilidade reportada pela ferramenta Paros . . . . . 52
Figura 22 – Diagrama de Venn dos verdadeiros positivos de cada ferramenta. . . . . 53
Lista de tabelas
Tabela 1 – Configurações de cabeçãlho de Content-Security-Policy(CSP) e X-
Frame-Options (XFO). . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Tabela 2 – Número de pontos vulneráveis na aplicação Mutillidae. . . . . . . . . . 47
Tabela 3 – Número de Tipos de Vulnerabilidades detectadas na aplicação Mutillidae. 48
Tabela 4 – Número de pontos vulneráveis na aplicação WackoPicko. . . . . . . . . 48
Tabela 5 – Número de Tipos de Vulnerabilidades detectadas na aplicação WackoPicko. 48
Tabela 6 – Tipos de vulnerabilidades nas aplicações Mutillidae e WackoPicko. . . 50
Tabela 7 – Número de Verdadeiros Positivos (VP), Falso Positivos (FP) e Falso
Negativos (FN) de cada Vulnerabilidade na aplicação Mutillidae. . . . 51
Tabela 8 – Número de Verdadeiros Positivos (VP), Falso Positivos (FP) e Falso
Negativos (FN) de cada vulnerabilidade na aplicação WackoPicko. . . . 51
Tabela 9 – O valor de Recall e de Precisão de cada WVS para cada Vulnerabilidade 53
Lista de quadros
2.1 Exemplo de consulta SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.2 Exemplo de consulta SQL modificada . . . . . . . . . . . . . . . . . . . . . 32
2.3 Exemplo de requisição forjada . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.4 Exemplo de código HTML com Token . . . . . . . . . . . . . . . . . . . . 39
2.5 Exemplo de configuração do Apache . . . . . . . . . . . . . . . . . . . . . . 39
2.6 Exemplo de prova de conceito sobre a vulnerabilidade de Click-Jacking . . 40
3.1 Comandos para execução da ferramenta SkipFish . . . . . . . . . . . . . . 44
Lista de abreviaturas e siglas
ARPA Advanced Research and Projects Agency
CERT Computer Emergency Response Team
CSIRT Computer Security Incident Response Team
CSRF Cross-Site Request Forgery
CSP Content-Security-Policy
CSS Cascading Style Sheets
CJ Clickjacking
DARPA Defense Advanced Research Projects Agency
DirB Directory Browsing
FI File Inclusion
FN Falso Negativo
FP Falso Positivo
HTML HyperText Markup Language
HTTP HyperText Transfer Protocol
LFI Local File Inclusion
OSCi Operacional System Command Injection
OWASP Open Web Application Security Project
PHP Personal Home Page
RFI Remote File Inclusion
RXSS Reflected Cross-Site Scripting
SO Sistema Operacional
SQL Structured Query Language
SQLi SQL Injection
SXSS Stored Cross-site Scripting
URI Uniform Resource Identifier
URL Uniform Resource Locator
VM Virtual Machine
VP Verdadeiro Positivo
WVS Web Vulnerability Scanners
XFO X-Frame-Options
XSS Cross-Site Scripting
Sumário
1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.1 Problemática e Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.2 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1.3 Estrutura do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2 REFERÊNCIAL TEÓRICO . . . . . . . . . . . . . . . . . . . . . . . . 27
2.1 Aplicação Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.2 Ferramentas de Varredura de Vulnerabilidades Web . . . . . . . . . . . 28
2.2.1 OWASP ZAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.2.2 SkipFish . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.2.3 Paros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.2.4 Vega . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.3 Aplicaçoes Web Vulneráveis . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.3.1 OWASP Broken Web Application Project . . . . . . . . . . . . . . . . . 30
2.4 Outras Ferramentas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.4.1 Burp Suite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.5 Vulnerabilidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.5.1 Injeção de SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.5.2 Cross-Site Scripting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.5.2.1 Reflected Cross-Site Scripting . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.5.2.2 Stored Cross-Site Scripting . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.5.3 Injeção de Comandos no Sistema Operacional . . . . . . . . . . . . . . . 35
2.5.4 File Inclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.5.4.1 Remote File Inclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.5.4.2 Local File Inclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.5.5 Cross Site Request Forgery . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.5.6 Directory Browsing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.5.7 Click-Jacking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3 ANÁLISE DAS FERRAMENTAS E RESULTADOS ENCONTRADOS 43
3.1 Cenários Avaliados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.2 Utilização das Ferramentas . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.2.1 Skipfish . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.2.2 Paros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.2.3 OWASP ZAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.2.4 Vega . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.3 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.3.1 Métricas Avaliadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.3.2 Análises Principais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.3.3 Discuções Adicionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4 CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
21
1 Introdução
A Internet como a conhecemos hoje teve início entre os anos de 1967 e 1969 com
a criação da ARPAnet, um trabalho criado pela ARPA (Advanced Research Projects) e
liderado por J. C. R. Licklider e Lawrence Roberts. A ARPAnet iniciou como uma pequena
rede de computadores conectados, cujo objetivo era conectar pesquisadores para que eles
pudessem compartilhar descobertas de uma forma menos custosa. Sendo assim, esta rede
consistia, inicialmente, de 4 computadores localizados em diferentes universidades nos
Estados Unidos da América. Em 1972, outras redes como a ARPAnet haviam sido criadas
e a própria ARPAnet já estava com 15 computadores conectados(ou nós, como também
podem ser chamados). No ano de 1974, outro trabalho foi criado com o objetivo de criar
uma rede de redes. Desta vez liderado por Vinton Cerf e Robert Kahn e patrocinado pela
DARPA (Defense Advanced Research Projects Agency). Para descrever este trabalho, foi
então criado o termo "internetting" [Ross 2010,Forouzan 2008].
Em seguida, como é dito por Kurose e Ross [Ross 2010, p. 47]:
“Ao final da década de 1970, aproximadamente 200 máquinas estavam
conectadas à ARPAnet. Ao final da década de 1980, o número de máquinas
ligadas à Internet pública, uma confederação de redes muito parecida
com a Internet de hoje, alcançaria cem mil. A década de 1980 seria uma
época de formidável crescimento [Ross 2010, p. 47].”
Junto a isso, cresceu também o número de hackers na Internet. Os hachers já eram
conhecidos por atuarem nas redes de telefone e por adulterarem telégrafos, antes de irem
para a Internet. Em 1988, Robert T. Morris criou um vírus que infectou cerca de 6.000
computadores, alguns localizados também em bases militares, tornando-os inutilizáveis.
Este fato levou a DARPA a financiar a criação do CERT (Computer Emergency Response
Team), um time de resposta a incidentes computacionais, localizado em Pittsburgh,
EUA [Davis 2015].
Após a criação do CERT nos Estados Unidos da América, muitas outras equipes de
resposta a incidentes computacionais foram criados ao redor do mundo, e o termo CSIRT
(Computer Security Incident Response Team) também passoua ser usado para denominar
essas equipes. Entre estes times criados está o CERT.br que é o grupo de resposta a
incidentes de segurança para a Internet no Brasil e que tem, entre outros papéis, o de
servir como ponto central para notificações de incidentes de segurança no Brasil [CERT.br
2018].
Incidente de segurança, segundo o próprio CERT.br, é classificado como [CERT.br
2018] “[...] qualquer evento adverso, confirmado ou sob suspeita, relacionado à segurança
22 Capítulo 1. Introdução
de sistemas de computação ou de redes de computadores.”. Além desta, outra definição,
mais completa, de incidente de segurança é a da norma brasileira ABNT NBR ISO/IEC
27.002 [ABNT 2005, p. 2], que diz que:
“um incidente de segurança da informação é indicado por um simples
ou por uma série de eventos de segurança da informação indesejados
ou inesperados, que tenham uma grande probabilidade de comprometer
as operações do negócio e ameaçar a segurança da informação [ABNT
2005, p. 2]”
Sabendo-se disso, pode-se analisar a Figura 1 que mostra que, de acordo com o
CERT.br, o número de incidentes de segurança vem crescendo cada vez mais, tendo seu
pico no ano 2014.
Figura 1 – Número de Incidentes nos anos de 1999 a 2017
Fonte: https://www.cert.br/stats/incidentes
Dentre estes incidentes reportados nos anos de 2015 a 2017, uma porcentagem
entre 7 a 8 porcento foram classificados como incidentes de web, os quais são descritos
pelo próprio CERT.br como [CERT.br 2018] "um caso particular de ataque visando
especificamente o comprometimento de servidores Web ou desfigurações de páginas na
Internet.". Um exemplo deste percentual é mostrado na Figura 2, que exibe a porcentagem
dos tipos de incidentes ocorridos no ano de 2017.
1.1. Problemática e Objetivos 23
Figura 2 – Porcentagem dos tipos de incidentes ocorridos no ano de 2017
Fonte: https://www.cert.br/stats/incidentes/2017-jan-dec/tipos-ataque.html
Apesar de ser uma pequena porcentagem, ainda é considerado um dado preocupante
tendo em vista a seriedade deste tipo de incidente. Muitas pesquisas realizadas nesta área,
como [Fonseca, Vieira e Madeira 2014,Makino e Klyuev 2015,Kagorora et al. 2015,Fonseca,
Vieira e Madeira 2007] discutem a crescente dependência de pessoas e organizações sobre
aplicações web. Quase tudo hoje em dia é comprado, negociado ou armazenado na Internet.
No entanto, este aumento no uso de aplicações web as torna mais expostas, além de
aumentarem a gravidade dos danos causados por uma falha de segurança, uma vez que
dados sensíveis estão sendo utilizados.
Dessa forma, para garantir a segurança de aplicações web, é necessário o uso de
boas práticas em seu desenvolvimento. Entre estas boas práticas estão a validação de
entrada e saída do sistema, controle do processamento interno e a aplicação de testes para
a visualização de vulnerabilidades [ABNT 2005].
Na aplicação de tais testes, principalmente testes do tipo black-box (quando não
se tem conhecimento do código fonte da aplicação), são utilizadas as ferramentas de
busca de vulnerabilidades web (Web Vulnerability Scanners - WVSs), que são ferramentas
automatizadas que expõem as vulnerabilidades de uma determinada aplicação web para
que possam ser tratadas. Estas ferramentas são utilizadas tanto por desenvolvedores web,
como por profissionais da área de segurança da informação para a realização de testes de
invasão (pentest), que é uma bateria de testes metodológicos, executados em um sistema
ou programa, a fim de mapear e expor suas vulnerabilidades [Moreno 2015].
1.1 Problemática e Objetivos
Além do que foi apresentado, outros problemas quanto ao uso não seguro de
aplicações web podem ser citados, bem como os desafios para torná-las seguras. Como foi
discutido em [Fonseca, Vieira e Madeira 2014] e [Stalling 2015], entre as dificuldades de se
24 Capítulo 1. Introdução
manter a segurança das aplicações web, estão:
• A alta complexidade dos softwares por trás das aplicações web, causado também
pela vasta variedade de tecnologias utilizadas;
• O servidor web muitas vezes é a porta de entrada para dados sensíveis de uma
empresa, que muitas vezes, não tem nem mesmo relação a aplicação web;
• A presença de usuários comuns, desenvolvedores e administradores sem o conheci-
mento necessário de segurança da informação.
Aliado a isso, também existe o fato de que os WVSs, por serem ferramentas automa-
tizadas, estão propensos a reportar incidentes como falso-positivos ou falso-negativos, o que
faz com que seja necessário uma análise da eficiência deste tipo de ferramenta [Mohammed
2016].
Segundo estes pontos, este trabalho tem o objetivo de:
• Apresentar uma análise de ferramentas de WVS, trazendo seus pontos fracos e fortes;
• Simplificar a escolha destas ferramentas por parte de profissionais da área;
• Prover melhorias para as ferramentas de análise de vulnerabilidades avaliadas.
1.2 Metodologia
Este trabalho teve como base a seleção de ferramentas de WVS a serem analisadas,
e em seguida foi feito a escolha das aplicações web vulneráveis que seriam utilizadas nos
testes. Com isso, foi criado um ambiente virtual para a realização destes experimentos,
simulando-se uma aplicação web vulnerável e um usuário externo.
Neste cenário, as ferramentas de WVS foram executadas sobre as aplicações web
vulneráveis para a coleta dos relatórios de execução. Com estes relatórios, as análises
foram feitas, comparando-os entre si e com as listas de vulnerabilidades das aplicações.
Assim, foram obtidas as taxas de falso-positivos, falso-negativos e verdadeiro-positivos
de cada ferramenta e para cada tipo de vulnerabilidade. Além disso, também foram
obtidas e analisadas as taxas de Recall e Precisão de cada ferramenta como foi feito no
trabalho [Mohammed 2016], uma vez que mostram mais claramente o desempenho das
ferramentas.
1.3. Estrutura do Trabalho 25
1.3 Estrutura do Trabalho
Este trabalho está dividido em 3 capítulos, além desta introdução. O Capítulo 2
apresenta as ferramentas utilizadas e as vulnerabilidades abordadas no trabalho, assim
como outros conceitos importantes para uma melhor compreensão do texto. No Capítulo 3
os experimentos são detalhados e resultados são discutidos. Por fim, o Capítulo 4 é dedicado
às conclusões e considerações finais.
27
2 Referêncial Teórico
Neste capítulo serão apresentados alguns conceitos considerados importantes para
a realização dos experimentos. Serão apresentadas também as ferramentas utilizadas para
realização das buscas de vulnerabilidades, assim como as utilizadas para simular uma
aplicação web.
2.1 Aplicação Web
Para definir uma aplicação web será utilizada a definição de Josh Pauli em seu
livro "Introdução ao Web Hacking" [Pauli 2015, p. 26]:
"[...] O termo aplicação web será utilizado ao longo deste livro para referir-
se a qualquer software baseado em web que realize ações (funcionalidades)
de acordo com uma entrada de usuário e que normalmente interaja com
sistemas de backend. Quando um usuário interage com um web site para
realizar alguma ação, por exemplo, fazer login, fazer compras ou acessar
o banco, temos uma aplicação web. [Pauli 2015, p. 26]"
A Figura 3 mostra como seria a arquitetura de uma aplicação web. Nesta arquitetura,
as tecnologias utilizadas são as seguintes:
• Na exibição das páginas nos navegadores são utilizados o HTML5 (Hypertext Markup
Language revision 5), JavaScript e PHP (Hypertext Preprocessor);
• Para o processamento dos dados no Servidor de Aplicação Web é utilizado também
o PHP;
• Para a comunicação com o banco de dados, será utilizado o SQL (Structured Query
Language), uma vez que é usado apenas por bancos de dados relacionais.
28 Capítulo 2. Referêncial Teórico
Figura 3 – Arquitetura de uma aplicação web.
Fonte: Próprio autor, baseado em imagem do livro "Sistemas de Bancos de Dados" [Silberschartz Henry
F. Korth 2012]
2.2 Ferramentas de Varredura de Vulnerabilidades Web
Como é dito em [Fonseca, Vieira e Madeira 2007], existem dois principais métodos
de teste de aplicações web para varredurade vulnerabilidades. O primeiro é chamado de
white-box onde o software de varredura tem conhecimento do código fonte da aplicação
web, e assim, faz a análise deste código em busca de vulnerabilidades. O segundo método,
que é o usado pelas ferramentas testadas neste trabalho, é chamado de black-box. Neste
método, o software de varredura não tem conhecimento do código fonte da aplicação, e
assim utiliza a técnica de fuzzing sobre as requisições HTTP (HiperText Transfer Protocol).
Desta forma, são realizados vários testes na aplicação web, simulando-se a atividade de
um usuário.
Como é mostrado também em [Fonseca, Vieira e Madeira 2007], o funcionamento
deste tipo de software de varredura (que utiliza o método black-box ) tem, normalmente,
três estágios, sendo o primeiro deles o de configuração. Neste estágio, o usuário informa à
ferramenta a URL da aplicação web que será testada, assim como outros parâmetros.
O segundo estágio é o de crawling. Esta fase é responsável por montar um mapa
da estrutura interna da aplicação web, a partir da URL e dos parâmetros disponibilizados
na fase de configuração. Para fazer este mapa, a ferramenta examina o código da página
da URL disponibilizada, para encontrar novas URLs. Ao encontrar, a ferramenta examina
o código da página desta outra URL, novamente em busca de novas URLs. Então assim é
feito até que não sejam encontradas mais URLs.
Após este processo, é prosseguido para o próximo estágio, que é o de scanning.
No estágio de scanning a ferramenta realiza vários testes automáticos (fuzzing) sobre
2.2. Ferramentas de Varredura de Vulnerabilidades Web 29
as páginas que foram coletadas na fase de crawling. As requisições feitas ao servidor de
aplicação web, assim como suas respostas, são também analisadas levando-se em conta os
parâmetros passados na fase de configuração, como as políticas de vulnerabilidade.
2.2.1 OWASP ZAP
ZAP é um proxy web feito para identificar vulnerabilidades em aplicações. O ZAP
é uma aplicação de código aberto, desenvolvido pela OWASP (Open Web Application
Security Project, ou Projeto Aberto de Segurança em Aplicações Web), uma organização
sem fins lucrativos e imparcial, focada na melhoria da segurança de aplicações web [OWASP
2018].
Para a configuração do scanner desta ferramenta, é possível selecionar o modo de
ação. As opções disponibilizadas são as seguintes [Bhamare 2016]:
• Modo Safe: Neste modo, o scanner não realizará nenhum tipo de ação que seja
potencialmente perigosa.
• Modo Protected : Neste modo, o scanner é capaz de realizar ações potencialmente
perigosas apenas em URLs especificadas no escopo da varredura.
• Modo Standard : Nesta modo, o usuário permite ao scanner que seja feita qualquer
ação que seja relevante.
• Modo ATTACK : Neste modo, todas as URLs descobertas na fase de crawling são
testadas de forma ativa.
2.2.2 SkipFish
O SkipFish é um scanner de vulnerabilidades web operado apenas por meio de
linhas de comando. É um programa escrito em linguagem C, de código aberto, criado e
mantido por Michal Zalewski, Niels Heinen, Sebastian Roschke [Github 2018].
2.2.3 Paros
Paros, assim como o OWASP ZAP, é um proxy desenvolvido para acessar vul-
nerabilidades em aplicações web. É um software baseado na linguagem Java [Security
2014].
2.2.4 Vega
Vega é um scanner e uma plataforma de testes de segurança de aplicações web.
É um programa gratuito e de código aberto que, diferentemente das outras ferramentas
30 Capítulo 2. Referêncial Teórico
de detecção de vulnerabilidades citadas, não esta pré-instalada no sistema do Kali Linux.
É uma ferramenta escrita em linguagem Java e desenvolvida pela Subgraph [Subgraph
2013, Subgraph 2014]. Para a instalação deste programa no Kali Linux, foi utilizado o
seguinte comando no terminal:
$ apt−get i n s t a l l vega
2.3 Aplicaçoes Web Vulneráveis
2.3.1 OWASP Broken Web Application Project
É uma coleção de aplicações web vulneravéis que é distribuído em uma máquina
virtual feita para pessoas com o interesse em aprender sobre segurança em aplicações web,
testar técnicas de avaliação manual, testar ferramentas automáticas, testar ferramentas de
análise de código fonte, observar ataques em plataforma web e testar firewalls de aplicação
web. O líder de projeto é Chuck Willis e é patrocinado em parte pela Mandiant. A versão
1.2, utilizada neste trabalho, foi lançada no dia 3 de Agosto de 2015 [OWASP 2015].
Esta máquina virtual possui cerca de 20 aplicações web vulneráveis, nas quais nós
utilizamos 2 delas: Mutillidae 2 e WackoPicko. Estas aplicações foram escolhidas pelo fato
de suas vulnerabilidades estarem mais facilmente explicitadas, tanto na Internet quanto
na própria aplicação.
2.4 Outras Ferramentas
2.4.1 Burp Suite
O Burp Suite é uma ferramenta feita para realização de testes em aplicações
web, de código proprietário, desenvolvido pela PostWigger. Também é uma ferramenta
pré-instalada no Kali Linux, porém, em sua versão comunity o que nos da direito a usar
apenas as ferramentas básidas do software.
2.5 Vulnerabilidades
Vulnerabilidade se define como uma condição, ou fragilidade, que pode ser explorada
por um atacante, ou ameaça, que quando explorado, pode resultar em uma violação de
segurança [ABNT 2005,CERT 2017]. Como são mostrados nos tópicos seguintes, existem
vários motivos para o surgimento de vulnerabilidades, como a falha de configuração de um
programa, ou de implementação de um software.
2.5. Vulnerabilidades 31
2.5.1 Injeção de SQL
A exploração deste tipo de vulnerabilidade se caracteriza como a alteração de uma
consulta SQL, através de uma entrada de um dado malicioso. Esta vulnerabilidade está
presente muitas vezes em páginas de autenticação e de busca de algum produto em lojas
virtuais. Como exemplo, pode ser usado o caso mostrado na Figura 4a. Nesta figura, como
pode ser visto, em vez de o usuário digitar apenas o nome do usuário em que deseja
procurar informações, digita “daniel’ or ‘1’=‘1’ -- ” o que faz com que a aplicação
retorne os dados de todos os usuários do banco de dados, como mostrado na Figura 4b.
Figura 4 – Exemplo de exploração da vulnerabilidade de Injeção de SQL.
(a)
(b)
Isso acontece, pois no momento em que o usuário clica no botão “View Account
Details”, o código da página web, presente nos “Navegadores Web” como mostrado na
Figura 3, envia o nome de usuário e a senha digitados para o servidor de aplicação web,
e lá o código PHP (no caso deste trabalho) cria uma consulta SQL no seguinte formato,
para se comunicar com o banco de dados:
Quadro 2.1 – Exemplo de consulta SQL
SELECT ∗ FROM accounts WHERE username=’Nome ’
AND password=’ Senha ’
Neste caso, o “Nome” e a “Senha” são o nome e a senha digitados pelo usuário. Se
estes dois dados não forem tratados antes de serem inseridos na consulta SQL, a consulta
será enviada ao banco de dados com o nome e a senha exatamente da mesma forma que
foram digitados, mesmo que o usuário tenha digitado caracteres inválidos. Isso possibilita
32 Capítulo 2. Referêncial Teórico
que algum usuário malicioso digite informações que alterem a consulta SQL que irá ao
banco de dados. Estas modificações podem ir desde pequenas alterações, como mostrado
na Figura 4, até a criação de novas consultas SQL que podem ler, modificar ou até apagar
dados do banco de dados.
No caso do nome de usuário “daniel’ or ‘1’=‘1’ -- ” mostrado como exemplo,
a consulta SQL executada seria a seguinte:
Quadro 2.2 – Exemplo de consulta SQL modificada
SELECT ∗ FROM accounts WHERE username=’ dan i e l ’ or
’ 1 ’= ’ 1 ’ −− ’AND password=’Senha ’
Os termos “ or ‘1’=‘1’ ” adicionam uma nova condição para a seleção do usuário
no banco de dados e o termo “ -- ” faz com que todo o resta da consulta seja ignorada.
Uma vez que “ ‘1’=‘1’ ” sempre será verdade, todos os usuários serão selecionados.
2.5.2 Cross-Site Scripting
Assim como a vulnerabilidade de injeção de SQL, esta vulnerabilidade também é
consequência da falta de validação da entrada de usuário antes de algum processamento
por parte da aplicação web. Estetipo de vulnerabilidade, se explorado, pode ser utilizado
como forma de roubar dados pessoais da vítima ou executar alguma ação em websites. No
caso do tipo de vulnerabilidade de Cross-Site Scripting (Scripting entre sites), a aplicação
web permite que o usuário execute scripts na página exibida no navegador web, como se
esse script pertencesse à própria página.
2.5.2.1 Reflected Cross-Site Scripting
Neste tipo de cross-site scripting, o script malicioso é executado apenas uma vez.
Ele está, muitas vezes, presente em páginas de pesquisa onde o termo pesquisado é exibido
no resultado da pesquisa. A Figura 5 mostra um exemplo deste comportamento. Na página
web das imagens mostradas, a aplicação web pede por algum texto na qual será impresso
na página e quantas vezes isso deve ser feito.
2.5. Vulnerabilidades 33
Figura 5 – Exemplo de exploração da vulnerabilidade Reflected Cross-Site Scripting.
(a) (b)
(c)
A informação que é digitada para ser impressa na página, como mostra a Figura 5a,
é “XSS : <script>alert (“XSS”);</script>”. A primeira parte “XSS : ” é um texto
comum. No entanto, a segunda parte “<script>alert(“XSS”);</script>” é um texto
que, ao ser lido pelo navegador web, será interpretado como um script, e por isso, irá
executar a ação que esta indicado entre os termos “<script>” e “</script>”. Neste caso,
o script emitirá apenas um alerta na tela do usuário, com o texto “XSS”, como é mostrado
na Figura 5b. Na Figura 5c é mostrado o texto “XSS : ” impresso na tela. O código da
página após a impressão do texto na tela é mostrado na Figura 6.
Figura 6 – Código da página web após a exploração da vulnerabilidade de Reflected
Cross-Site Scripting.
2.5.2.2 Stored Cross-Site Scripting
No caso do Stored Cross-Site Scripting, o código malicioso é armazenado na
aplicação web. Este tipo de vulnerabilidade está muitas vezes presente em páginas de
discussões ou de comentários sobre algum produto. Isso acontece pois, no momento em que
34 Capítulo 2. Referêncial Teórico
um comentário é submetido a esse tipo de página, ele será armazenado no banco de dados
e toda vez que aquela página for visitada, o mesmo comentário será exibido novamente.
Caso este comentário esteja com um código malicioso, o navegador web da vítima, ou das
vítimas que abrirem este site, irão executar o código malicioso.
Um exemplo de exploração desta vulnerabilidade é mostrado na Figura 7. Na
Figura 7a, é mostrado a página onde é adicionada o comentário com o código malicioso,
no mesmo formato do texto usado na Figura 5a discutida na subseção anterior, sobre
Reflected Cross-Site Scripting. Na Figura 7b é mostrada a página onde são visualizados os
comentários colocados por todos os usuários da aplicação web. Como pode ser percebido,
o alerta também foi executado. A Figura 8 mostra o código fonte da página web após a
adição do comentário.
Figura 7 – Exemplo de exploração da vulnerabilidade Stored Cross-Site Scripting.
(a)
(b)
2.5. Vulnerabilidades 35
Figura 8 – Código da página web após a exploração da vulnerabilidade de Stored Cross-Site
Scripting.
2.5.3 Injeção de Comandos no Sistema Operacional
Esta vulnerabilidade é bastante semelhante à vulnerabilidade de injeção de SQL,
pois também é causada por falta de validação da entrada de dados do usuário e tem sua
atividade maliciosa manifestada no servidor de aplicação web, no entanto, sem precisar
interagir com o banco de dados. Ela acontece em casos em que esta entrada do usuário é
utilizada diretamente na execução de comandos do sistema operacional no lado do servidor.
Na Figura 9 é mostrada uma página da aplicação Mutillidae que faz o uso de
comandos do sistema operacional no processamento do lado do servidor. Nesta página,
é pedido apenas que seja digitado algum site para que seja dito qual o endereço IP do
mesmo. Neste caso, como é mostrado na Figura 9a, é digitado o site “google.com”, e a
resposta da aplicação web a esta entrada é mostrado na Figura 9b.
36 Capítulo 2. Referêncial Teórico
Figura 9 – Exemplo de aplicação web que utiliza commandos do sistema operacional.
(a)
(b)
Sem a sanitização desta entrada do usuário, é possível que seja digitado um texto
como é mostrado na Figura 10a. A entrada digitada neste caso foi a seguinte: “google.com
& ls”. Neste texto, o caractere “&” fará com que o servidor interprete o próximo pedaço
de texto como outro comando. O termo “ls” é um comando de sistemas operacionais
baseados em Unix que lista os arquivos presentes em um diretório. Sendo assim, o resultado
que será retornado do servidor de aplicação web será a lista de arquivos do diretório em
que está o código fonte da aplicação web, como é mostrado na Figura 10b.
Figura 10 – Exemplo de exploração da vulnerabilidade de Injeção de Comandos no Sistema
Operacional.
(a)
(b)
2.5.4 File Inclusion
Esta vulnerabilidade permite que o usuário execute scripts ou que carregue o
conteúdo de arquivos que estejam fora do conjunto de arquivos usados pela aplicação
web. Assim como as vulnerabilidades citadas acima, esta também é causada pela falta de
sanitização da entrada de dados do usuário. Desta vez, a entrada de usuário que pode ser
2.5. Vulnerabilidades 37
utilizada de forma maliciosa é a que indica qual a página será carregada pelo navegador
web.
2.5.4.1 Remote File Inclusion
Remote File Inclusion (Inclusão Remota de Arquivo) é o tipo de vulnerabilidade
de File inclusion que permite a execução remota de arquivos.
Uma prova de conceito desta vulnerabilidade pode ser vista na Figura 11 onde
a página de pesquisa do Google pôde ser carregada como se fosse mais uma página da
aplicação. Para isso, foi necessário apenas a alteração do parâmetro “page” na URL da
página, como o seguinte exemplo:
http://10.0.2.9/mutillidae/index.php?page=https://www.google.com/
No exemplo acima, a variável “page” deveria receber o nome das páginas da
aplicação web como, por exemplo, “home.php” e “login.php”. No entanto, uma vez que
o valor desta variável não é sanitizado, foi possível especificar a URL de uma página na
Internet, o que fez com que o servidor da aplicação buscasse esta página na Internet.
Figura 11 – Exemplo de exploração da vulnerabilidade Remote File Inclusion.
2.5.4.2 Local File Inclusion
Local File Inclusion (Inclusão de Arquivo Local) é o tipo de File inclusion que
permite apenas a execução de arquivos que estejam dentro do servidor de aplicação web.
A prova de conceito desta vulnerabilidade pode ser vista na Figura 12. Neste caso, assim
como no exemplo da Figura 11 sobre Remote File Inclusion, o parâmetro usado para fazer
esta inclusão foi o “page”, presente na URL da página. No caso da Figura 12, a URL
utilizada foi a seguinte:
http://10.0.2.9/mutillidae/index.php?page=/../../../../../../../../../../
../../etc/passwd
Nesta URL os caracteres “../” são uma indicação para o diretório pai, na árvore de
diretórios, do diretório atual. Sendo assim, o texto especificado na variável “page” mostra
38 Capítulo 2. Referêncial Teórico
o caminho para o arquivo local “passwd” no servidor de aplicação web. Este arquivo lista
todos os usuários do sistema, além de algumas de suas informações. A Figura 12 mostra
esta listagem.
Figura 12 – Exemplo de exploração da vulnerabilidade Local File Inclusion.
2.5.5 Cross Site Request Forgery
Esta vulnerabilidade possibilita que um usuário forge uma requisição, que será
acessada através de um link malicioso. No entanto, a ação gerada por este link é uma ação
permitida pela aplicação web, ou que faz parte do seu fluxo normal de funcionamento.
Cross-Site Request Forgery é, muitas vezes, confundida com a vulnerabilidade de Reflected
Cross-Site Scripting, pelo fato de que, para se explorar estas vulnerabilidades é necessário
a criação de uma URL adequada [Pauli 2015].
Esse tipo de vulnerabilidade foi demostrado por Georgia Weidman [Weidman 2014],
onde um usuário está navegando na Internet em duas abas diferentes do navegador, e uma
delas, ele está autenticado em sua conta do banco. Na outra aba, o mesmo usuário visita
uma páginaque possui a seguinte tag html:
Quadro 2.3 – Exemplo de requisição forjada
<img src="http :// bancoX . com/ Tran s f e r i r ? va l o r=100&conta=000">
No momento em que o navegador processar esta tag, a solicitação da URL será
executada. Naturalmente, o site do banco irá verificar se o usuário esta autenticado. Porém,
uma vez que o usuário já esteja autenticado no mesmo banco na outra aba do navegador,
o navegador possui os dados de autenticação do mesmo. Dessa forma, a ação maliciosa
será realizada sem que o usuário perceba.
Existem algumas técnicas para se proteger desta vulnerabilidade, e uma das mais
conhecidas é a utilização de Tokens. Estes Tokens são valores únicos para cada seção
de usuário e aleatoriamente criados, colocados escondidos dentro da página web. Estes
mesmos valores são utilizados para a validação das requisições feitas ao servidor. Uma vez
que somente o servidor de aplicação web sabe qual foi o valor de Token gerado, não há
2.5. Vulnerabilidades 39
como forjar uma requisição com o mesmo valor. Um exemplo de código HTML com este
Token, feito pela OWASP [OWASP 2018], é mostrado a seguir:
Quadro 2.4 – Exemplo de código HTML com Token
<form action="/ t r a n s f e r . do" method="post ">
<input type="hidden" name="CSRFToken"
value="OWY4NmQwODE4ODRjN2Q2NTlhMmZlYWEwYzU1YW( . . . )MGYwMGEwOA==">
. . .
</form>
2.5.6 Directory Browsing
Directory Browsing ou Directory Listing como também pode ser chamado, ocorre
quando o usuário acessa algum diretório da aplicação web e o servidor de aplicação web
retorna a listagem de todos os arquivos presentes no diretório acessado. Um exemplo desta
vulnerabilidade pode ser vista na Figura 13. Esta vulnerabilidade pode ser evitada apenas
com a configuração correta do software que oferece o serviço web, como o Apache. Um
exemplo desta configuração é mostrado a seguir [Apache 2012]:
Quadro 2.5 – Exemplo de configuração do Apache
<Direc tory / usr / l o c a l /apache2/ htdocs / dont l i s tme>
Options −Indexes
</Direc tory>
Figura 13 – Exemplo de exploração da vulnerabilidade Directory Browsing.
2.5.7 Click-Jacking
Esta vulnerabilidade está ligada ao fato de que a página com esta falha pode ser
utilizada em outra página, através de uma tag “iframe” por exemplo. Normalmente,
quando se deseja explorar esta vulnerabilidade, este “iframe” é escondido nesta nova
página, com a ajuda do CSS (Cascading Style Sheets), e alguma parte crucial da página que
está no “iframe” é colocada sob outro elemento também crucial desta nova página, como
40 Capítulo 2. Referêncial Teórico
por exemplo, um botão. Assim no momento em que o usuário clica no botão, desejando
realizar uma ação, ele realiza a ação da página que esta por baixo do botão visível.
A Figura 14 ilustra a exploração dessa vulnerabilidade através de uma prova de
conceito realizada pela OWASP [OWASP 2016], e que o código é mostrado a seguir:
Quadro 2.6 – Exemplo de prova de conceito sobre a vulnerabilidade de Click-Jacking
<html>
<head>
<t i t l e>Cl i ck j a ck t e s t page</ t i t l e>
</head>
<body>
<p>Website i s vu lne rab l e to c l i c k j a c k i n g !</p>
<iframe src="http ://www. t a r g e t . s i t e " width="500" height="500"></ iframe>
</body>
</html>
Figura 14 – Exemplo de exploração da vulnerabilidade Click-Jacking.
(a)
(b)
Fonte: https://www.owasp.org/index.php/Testing_for_Clickjacking_(OTG-CLIENT-009)
Na exploração desta vulnerabilidade, como é mostrado na Figura 14a, o usuário
irá visualizar a página destacada com “MALICIOUS WEB PAGE ” que possui um botão.
Entretanto, junto a isso, há outra página web escondida, destacada com “TARGET WEB
PAGE ”, que também possui um botão no mesmo local que a página anterior. Desta forma,
se o usuário clicar no botão da página web visível, ele irá executar a ação da página web
escondida. Uma outra forma de ver este mesmo cenário esta ilustrado na Figura 14b, onde
a página escondida esta sendo mostrada em uma cor mais clara.
Uma forma de evitar este tipo de vulnerabilidade é fazendo-se a configuração do
servidor de aplicação web para que, na resposta HTTP da solicitação de uma página da
aplicação, seja utilizado o cabeçalho Content-Security-Policy ou X-Frame-Options, sendo o
2.5. Vulnerabilidades 41
primeiro uma versão mais atualizada do segundo. Em ambos os casos, o cabeçalho servirá
para indicar ao navegador web se ele poderá ou não utilizar tal página dentro de uma tag
“<frame>” ou “<iframe>”. Os valores que tais cabeçalhos podem assumir são mostrados
na Tabela 1 [OWASP 2017].
Tabela 1 – Configurações de cabeçãlho de Content-Security-Policy (CSP) e X-Frame-
Options (XFO).
Ação desejada CSP XFO
Permite que qualquer site utilize esta página; frame-ancestors ’none’ DENY
Permite que apenas a própria página utiliza-a em
uma tag “frame”;
frame-ancestors ’self ’ SAMEORIGIN
Permite que apenas a própria página e as páginas
especificadas em “uri” utilizem-a em uma tag “frame”.
frame-ancestors ’self ’ ’uri’ ALLOW-FROM uri
43
3 Análise das Ferramentas e Resultados En-
contrados
Neste capítulo são apresentados os cenários utilizados para a análise das ferrametas
apresentadas no capítulo anterior, bem como os resultados encontrados.
3.1 Cenários Avaliados
Foram utilizadas duas máquinas virtuais, sendo uma rodando o OWASP BWA
(Broken Web Applications) e a outra rodando o Kali Linux, como mostrado no esquema
da Figura 15. A VM (Virtual Machine ou Máquina Virtual) com o OWASP BWA e com o
IP (Internet Protocol) 10.0.2.9 simula as aplicações web vulneráveis. Já a VM com o Kali
e com o IP 10.0.2.8 simula o usuário que faria uso destas aplicações web.
Na máquina 10.0.2.9 foram utilizadas as aplicações web Mutillidae e WackoPicko,
intensionalmente vulneráveis e que já estavam pré-instaladas no sistema OWASP BWA.
Assim, foram executadas as ferramentas OWASP ZAP, Vega, Paros e SkipFish, pré-
instaladas no sistema Kali Linux, sobre essas aplicações web para realizar a varredura em
busca de suas vulnerabilidades.
Figura 15 – Cenário utilizado.
3.2 Utilização das Ferramentas
3.2.1 Skipfish
Como foi dito no capítulo anterior, o Skipfish é uma ferramenta baseada em linha
de comando. Sendo assim, ao iniciar o terminal na máquina Kali Linux, foram usados os
seguintes comandos:
44 Capítulo 3. Análise das Ferramentas e Resultados Encontrados
Quadro 3.1 – Comandos para execução da ferramenta SkipFish
$ s k i p f i s h −o ~/Desktop/SkipFish_report_WackoPicko −I
http : / / 1 0 . 0 . 2 . 9 /WackoPicko/ http : / / 1 0 . 0 . 2 . 9 /WackoPicko/
$ s k i p f i s h −o ~/Desktop/ SkipFish_report_Muti l l idae −I
http : / / 1 0 . 0 . 2 . 9 / Mut i l l i d a e / http : / / 1 0 . 0 . 2 . 9 / Mut i l l i d a e /
Os comandos acima executam a varredura nas aplicações especificadas no final do co-
mando (no caso “http://10.0.2.9/WackoPicko/” e “http://10.0.2.9/Mutillidae/”),
e usam os seguintes parâmetros:
• -o : Indica a saída do comando, onde neste caso, será o resultado ou relatório da
varredura;
• -I : Especifica a URL na qual o scanner deve seguir. Este parâmetro é necessário
para evitar que o scanner vasculhe URLs que não pertençam à aplicação desejada;
3.2.2 Paros
Para a execução do Paros foi necessário primeiramente configurar o proxy no
navegador utilizado, que no caso foi o Mozilla Firefox, como é mostrado na Figura 16. Em
seguida, com o Paros já em execução, visitar a página das aplicações do Mutillidae e do
WackoPicko para que o proxy registrasse a página para ser utilizada posteriormente, como
esta ilustrado na Figura 17a.
Após acessar a aplicação desejada, é executado o Spider (ou web crawler) para que
seja feito o mapa de todos os caminhos de URL disponíveis na aplicação. Para executar
o Spider foi necessário clicar com o botão direito do mouse na aplicação registrada pelo
proxy, e clicar em “Spider ”, como é mostrado na Figura 17b.
Ao final da execução do Spider é que então poderia ser executada varredura, clicando
no menu “Analyse”, e em seguida clicando em “Scan”, como mostrado na Figura 17c.
3.2. Utilização dasFerramentas 45
Figura 16 – Configuração do proxy no navegador FireFox.
Figura 17 – Configuração da ferramenta Paros.
(a)
(b)
(c)
46 Capítulo 3. Análise das Ferramentas e Resultados Encontrados
3.2.3 OWASP ZAP
Ao iniciar a ferramenta pela primeira vez, é pedido que seja feita a atualização de
pacotes, onde, neste caso, foi clicado no botão “Update All ” para atualizá-los. Em seguida,
foi colocada a URL da aplicação na qual desejava-se testar no campo “URL to attack ”.
Como no caso desta ferramenta é possível escolher o modo do scanner, foi utilizado o
modo padrão, ou “Standard mode”. A Figura 18 ilustra esta configuração.
Figura 18 – Configuração da ferramenta ZAP.
3.2.4 Vega
Para configurar a varredura na ferramenta Vega somente é necessário abrir a
ferramenta e clicar no menu “Scan” e em seguida em “Start New Scan” como é mostrado na
Figura 19a. Na janela em que se abre, marque a opção “Use a base URI for scan” e digite
a URI no campo abaixo e em seguida em “Finish” como esta ilustrado na Figura 19b.
3.3. Resultados 47
Figura 19 – Configuração da ferramenta Vega.
(a)
(b)
3.3 Resultados
3.3.1 Métricas Avaliadas
Na exibição dos resultados, são utilizadas as medidadas de pontos vulneráveis
e tipos de vulnerabilidades. No caso deste trabalho, o primeiro significa a quantidade
de páginas web que possuem algum tipo de vulnerabilidade. Já o segundo significa a
classificação da vulnerabilidade, como por exemplo SQLi e XSS. Sendo assim, um mesmo
tipo de vulnerabilidade por ter vários pontos vulneráveis dentro de cada aplicação.
3.3.2 Análises Principais
Ao executar as ferramentas de varredura em cada aplicação, foram obtidos os
resultados mostrados nas Tabelas 2, 3, 4 e 5. Estes dados foram obtidos diretamente dos
relatórios dos scans, exatamente da mesma forma como estão apresentados.
Tabela 2 – Número de pontos vulneráveis na aplicação Mutillidae.
Severidade das Vulnerabilidades Número de Pontos Vulneráveis
OWASP ZAP Paros SkipFish Vega
Alta 36 226 3 18
Média 34 100 18 44
Baixa 44 27 6 45
Informação 0 0 94 244
Total 114 353 121 351
48 Capítulo 3. Análise das Ferramentas e Resultados Encontrados
Tabela 3 – Número de Tipos de Vulnerabilidades detectadas na aplicação Mutillidae.
Severidade das Vulnerabilidades Número de Tipos de Vulnerabilidades
OWASP ZAP Paros SkipFish Vega
Alta 5 2 2 9
Média 4 5 7 4
Baixa 11 1 2 3
Informação 0 0 12 6
Total 20 8 23 22
Tabela 4 – Número de pontos vulneráveis na aplicação WackoPicko.
Severidade das Vulnerabilidades Número de Pontos Vulneráveis
OWASP ZAP Paros SkipFish Vega
Alta 15 0 2 20
Média 34 41 15 3
Baixa 41 0 22 35
Informação 0 0 186 64
Total 90 41 225 122
Tabela 5 – Número de Tipos de Vulnerabilidades detectadas na aplicação WackoPicko.
Severidade das Vulnerabilidades Número de Tipos de Vulnerabilidades
OWASP ZAP Paros SkipFish Vega
Alta 6 0 2 10
Média 3 4 5 2
Baixa 5 0 1 3
Informação 0 0 17 3
Total 14 4 25 18
Ao analisar os resultados das tabelas, é possível perceber diferenças entre cada
WVS. Na Tabela 2, a ferramenta Paros se destacou com o melhor desempenho por ter sido
a ferramenta que detectou mais pontos vulneráveis de severidade alta. Em contrapartida,
a ferramenta SkipFish se destacou como a pior, uma vez que detectou apenas 3 pontos
vulneráveis de alta severidade.
Já na Tabela 3, é possível perceber que o Paros foi a ferrameta que detectou o menor
número que tipos diferentes de vulnerabilidade no total. Ela também foi a que detectou
menos tipos de vulnerabilidade de alta severidade, junto com a ferramenta SkipFish. Por
outro lado, a ferramenta que teve o melhor desempenho foi o Vega, uma vez que detectou
o maior número de tipos de vulnerabilidades de alta severidade.
Fazendo-se uma análise entre as tabelas 2 e 3, pode-se perceber que a ferramenta
ZAP foi a que teve a melhor proporção entre o número de tipos de vulnerabilidades
detectadas e o número de pontos vulneráveis, o que pode indicar uma maior eficiência. Por
3.3. Resultados 49
outro lado, a ferramenta Paros foi a que teve a pior proporção entre esses dois números, o
que pode indicar um grande número de falso-positivos.
Em relação a Tabela 4 que trata sobre a aplicação WackoPicko, as ferramentas que
mostraram um melhor desempenho foram as ferramentas Vega e ZAP, tendo sido a Vega
a que detectou maior número de pontos vulneráveis de alta severidade. No entanto, o ZAP
detectou mais pontos vulneráveis se somados os pontos de alta e média severidade. Por
outro lado, nesta tabela, a ferramenta que teve o pior desempenho, foi o Paros.
Analisando a Tabela 5, que também trata sobre a aplicação WackoPicko, a ferra-
menta que detectou o menor número de tipos de vulnerabilidades foi o Paros, com uma
grande diferença em relação as outras ferramentas. No entanto, a ferramenta que detectou
o maior número de tipos de vulnerabilidades com maior severidade foi o Vega.
Fazendo-se também uma análise entre as Tabelas 4 e 5, pode-se notar que a
ferramenta que teve uma melhor proporção entre o número de pontos vulneráveis e de tipos
de vulnerabilidades detectados foi o Vega. Em contrapartida, a que teve a pior proporção,
novamente foi o Paros.
Analisando-se também as tabelas 3 e 5 pode-se notar que as ferramentas SkipFish
e Vega são as únicas que mostraram vulnerabilidades com severidade de informação.
Após a obtenção dos relatórios de varredura, foi feita uma comparação com as listas
de vulnerabilidades conhecidas nas aplicações. No Mutillidae, esta lista é disponibilizada
dentro da própria aplicação, na seguinte URL: “http://<IP da máquina>/mutillidae/
index.php?page=./documentation/vulnerabilities.php”. Já no WackoPicko, esta
lista é disponibilizada na página do GitHub [Adamdoupe 2018].
Com o objetivo de realizar uma análise mais precisa das ferramentas, foi considerado
apenas um grupo das 9 vulnerabilidades mais relevantes e que estão presentes em ambas
aplicações. Esta seleção se deve também ao fato de que os resultados das varreduras
mostraram a presença de vulnerabilidades que são, frequentemente, não intencionais e
que não apresentam tanta influência sobre a avaliação das ferramentas, como por exemplo
“Password Autocomplete in browser” e “X-Content-Type-Options Header Missing”. Esta
abordagem é semelhante ao trabalho [Makino e Klyuev 2015]. A Tabela 6 mostra a
ocorrência destas vulnerabilidades em cada aplicação.
50 Capítulo 3. Análise das Ferramentas e Resultados Encontrados
Tabela 6 – Tipos de vulnerabilidades nas aplicações Mutillidae e WackoPicko.
Vulnerabilidade Mutillidae WackoPicko
SQL Injection (SQLi) 8 2
Reflected Cross Site Script (RXSS) 18 3Stored Cross Site Script (SXSS) 2
Operacional System Command Injection (OSCi) 2 1
Remote File Inclusion (RFI) ? ?Local File Inclusion (LFI) ?
Cross Site Request Forgery (CSRF) 2 -
Directory Browsing (DirB) ? -
Click Jacking (CJ) 3 -
Nestas tabelas um sinal de interrogação (?) foi colocado em algumas das vulnerabili-
dades, pois, nestes casos, a quantidade de páginas vulneráveis não estava bem determinada.
Assim, a verificação destas vulnerabilidades em específico foi feita de forma manual e
a quantidade de ocorrências destas vulnerabilidades em cada aplicação foi deixada em
aberto, avaliando-se apenas a quantidade de ocorrências detectadas por cada WVS.
Na aplicação Mutillidae, a documentação das ocorrências das vulnerabilidades não
é muito clara, o que também dificultou na montagem da Tabela 6. As vulnerabilidades que
possuíam os dados menos compreensíveis eram de SXSS e RXSS. Por isso, nesta tabela, a
contagem foi feita por uma somatória das duas vulnerabilidades.
Já a aplicação WackoPicko não possui ocorrências da vulnerabilidade de LFI. Em
sua lista de vulnerabilidades, é especificado apenas as ocorrências de FI (File Inclusion).
Por isso, na Tabela 6 também foi usado uma somatória para especificar as ocorrências das
vulnerabilidades de LFI e RFI.
Com isso, foi feita então a checagem dos relatórios em relação às vulnerabilidades
específicas, o que nos deu os dados mostrados nas Tabelas 7 e 8.Para a obtenção destas
tabelas foram utilizados os dados dos pontos vulneráveis em cada aplicação, como são mos-
trados nas Tabelas 2 e 4. Estes dados foram comparados com as listas de vulnerabilidades
disponibilizadas por cada aplicação, com o objetivo de verificar se cada ponto vulnerável
mostrado nos relatórios das WVSs, estavam presentes nestas listas de vulnerabilidades.
Caso estivessem, eram considerados verdadeiros positivos. Caso não estivessem, eram
considerados falso positivos. Os falsos negativos foram calculados subtraindo-se os números
mostrados na Tabela 6 dos valores de verdadeiros positivos, para cada vulnerabilidade.
Junto a verificação, comentada no parágrafo anterior, foi feita também uma veri-
ficação manual das vulnerabilidades consideradas como verdadeiros positivos. Para isso,
foram copiadas as URLs utilizadas para os testes das varreduras (como eram descritos nos
relatórios) e copiados no navegador para se analisar o comportamento da aplicação web.
Em alguns casos em que era necessário também a mudança de parâmetros no corpo das
requisições HTTP, foi usada a ferramenta Burp Suite [Portswigger 2018].
3.3. Resultados 51
Tabela 7 – Número de Verdadeiros Positivos (VP), Falso Positivos (FP) e Falso Negativos
(FN) de cada Vulnerabilidade na aplicação Mutillidae.
Vulnerabilidade ZAP SkipFish Paros Vega
VP FP FN VP FP FN VP FP FN VP FP FN
SQLi 1 2 6 2 0 6 3 110 5 1 1 7
XSS 1 16 15 0 4 17 12 54 5 1 6 17
OSCi - - 2 - - 2 - - 2 - - 2
RFI 8 0 0 0 0 0 - - 0 1 0 0
LFI 0 0 0 1 0 0 - - 0 2 0 0
CSRF - - 2 - - 2 - - 2 - - 2
DirB 14 0 0 20 0 0 3 0 0 29 0 0
CJ 0 20 2 - - 3 - - 3 - - 3
Tabela 8 – Número de Verdadeiros Positivos (VP), Falso Positivos (FP) e Falso Negativos
(FN) de cada vulnerabilidade na aplicação WackoPicko.
Vulnerabilidade ZAP SkipFish Paros Vega
VP FP FN VP FP FN VP FP FN VP FP FN
SQLi 1 1 1 1 0 1 - - 2 1 0 1
RXSS 1 4 2 1 0 2 1 0 2 1 1 2
SXSS 1 2 1 - - 2 1 1 1 1 1 1
OSCi 1 1 0 1 0 0 - - 1 1 0 0
FI 2 0 0 1 0 0 - - 0 - - 0
Como pode ser visto nas Tabelas 7 e 8, o WVS Paros possui o maior número
de falso-positivos, se considermos as duas aplicações, seguida do ZAP com a segunda
maior quantidade de falso-positivos. Ainda sobre o Paros, podemos ver que sua varredura
teve mais facilidade de detectar vulnerabilidades do tipo de Injeção de SQL e Cross-
site Scripting, uma vez que não detectou mais nenhuma ocorrência dos outros tipos de
vulnerabilidade, com exceção do Directory Browsing no Mutillidae. Outra conclusão que
pode ser tirada destes dados é que houve uma dificuldade unânime para detecção das
vulnerabilidades de OSCi, CSRF e CJ, como pode ser visto na Tabela 7.
Apesar destas análises feitas sobre a ferramenta Paros, foi encontrado em seu
relatório uma grande quantidade de pontos vulneráveis da vulnerabilidade de XSS na qual
não são descritas nas listas de vulnerabilidades das aplicações. No entanto, estes casos de
pontos vulneráveis ainda foram considerados como falso positivos pelo fato de não estarem
nas listas de vulnerabilidades.
Para entender melhor os casos mostrados nesta tabela, podemos ver o caso da
Figura 20 que mostram as vulnerabilidades de SQLi indicadas pela ferramenta ZAP. Nesta
caso, o segundo e o terceiro ponto vulnerável (com a URL igual a "http://10.0.2.9
/mutillidae/index.php?page=login.php") representam verdadeiros positivos, uma vez
que os valores testados ("ZAP’ OR ’1’=’1’ – ") nos parâmetros especificados, realizam
uma ação irregular. Assim como mostrado no Capítulo 2, a expressão "OR ’1’=’1’" fará
52 Capítulo 3. Análise das Ferramentas e Resultados Encontrados
com que a pesquisa no banco de dados selecione qualquer valor, e uma vez que a página
que esta sendo testada é a de autenticação ("login.php"), o usuário será autenticado
digitando-se o valor de teste em qualquer um dos parâmetros.
Já o caso do primeiro e terceiro pontos vulneráveis da mesma imagem, são exemplos
de falsos positivos, pois a resposta do servidor de aplicação web para tais testes não
apresentam nenhum comportamento irregular.
Outro caso que pode ser visto é o da ferramenta Paros, na Figura 21 sobre a
vulnerabilidade de XSS. Nesta figura, assim como na Figura 20, são mostradas as URLs e
os parâmetros usados para os testes. Destes testes, apenas 1 deles (com a URL igual a
"http://10.0.2.9/mutillidae/index.php?page=repeater.php" e parâmetro de teste
igual a "repeater-php-submit-button=<SCRIPT>alert("Paros");</SCRIPT>") foi con-
siderado falso positivo pois não realiza a execução do script usado como teste. Já nos
outros casos, o script é executado, da mesma forma como foi mostrado no Capítulo 2.
Figura 20 – Exemplo que vulnerabilidade reportada pela ferramenta ZAP
Figura 21 – Exemplo que vulnerabilidade reportada pela ferramenta Paros
3.3. Resultados 53
Figura 22 – Diagrama de Venn dos verdadeiros positivos de cada ferramenta.
(a) Mutillidae (b) WackoPicko
Outra forma de representar parte dos dados das Tabelas 7 e 8 é através de um
Diagrama de Venn, como é mostrado na Figura 22 acima, onde a Figura 22b representa
a aplicação WackoPicko e a Figura 22a aplicação Mutillidae. Nestes diagramas estão
sendo mostrados os verdadeiros positivos detectados por cada ferramenta em relação ao
número total. Para a criação destas imagens, foram levadas em conta as vulnerabilidades
da mesma forma como estão representadas na Tabela 6, ou seja, as vulnerabilidades que
estão representadas com um sinal de interrogação (?) não foram contabilizadas.
Assim como foi feito no trabalho [Mohammed 2016], o Recall e a Precisão de cada
WVS podem ser deduzidas com os dados das Tabelas 7 e 8 por meio das Equações 3.1 e 3.2.
Segundo o mesmo trabalho, Recall é a taxa de vulnerabilidades corretamente identificadas
em relação ao total existente. Já a Precisão é a taxa de vulnerabilidades relevantes em
relação ao total indicado pela ferramenta. Para que seja feita de forma mais direcionada
para cada ferramenta de análise de vulnerabilidade, foi feito um somatório entre os dados
obtidos nas duas aplicações. Os resultados estão sendo mostrados na Tabela 9.
Recall =
V P
V P + FN
(3.1)
Precisao =
V P
V P + FP
(3.2)
Tabela 9 – O valor de Recall e de Precisão de cada WVS para cada Vulnerabilidade
Vulnerabilidade ZAP SkipFish Paros Vega
R P R P R P R P
SQLi 14,2 33,3 30 100 30 2,6 20 66,6
XSS 6,2 5,8 5 20 60,9 20,3 13 27,3
OSCi 33,3 50 33,3 100 0 0 33,3 100
CSRF 0 0 0 0 0 0 0 0
CJ 0 0 0 0 0 0 0 0
54 Capítulo 3. Análise das Ferramentas e Resultados Encontrados
Como foi comentado anteriormente, as vulnerabilidades de Directory Brownsing,
Remote File Inclusion e Local File Inclusion não foram levadas em consideração nesta
tabela, pois a quantidade de ocorrências destas falhas em cada aplicação não estava bem
determinada, o que gera uma indeterminação no número de falso-negativos.
Pela quantidade reduzida de pontos de presença de algumas vulnerabilidades nas
aplicações avaliadas, as porcentagens de Precisão e de Recall apresentaram valores bem
acentuados e repetidos como foi o caso da vulnerabilidade OSCi. Como as vulnerabilidades
CSRF e CJ praticamente não foram detectadas, a Precisão e o Recall na maioria dos casos
resultou em zero. Seriam necessárias mais ocorrências para que as WVS pudessem ser
melhor analisadas em relação a essas vulnerabilidades. Uma vez que as vulnerabilidades
SQLi e XSS tinham mais presença nas aplicações, seus dados na Tabela 9 mostraram-se
mais variados. No entanto, independente do número de ocorrências das vulnerabilidades,
os resultados dos relatórios das WVS foram bastante insatisfatórios, uma vez que todos
detectaram uma porcentagem baixa destas ocorrências, como é mostrado nesta mesma
tabela.
Ainda sobre a Tabela 9, podemos perceber que o ferramenta SkipFish foi a que
apresentou maior Precisão na detecção de falhas do tipo SQLi, enquanto que seu valor de
Recall se igualou com o da ferramenta Paros, considerando o mesmo tipo de falha. Ainda
falando de SQLi, é possível ver que o WVS que apresentou a menor precisão foi o Paros,
com uma diferença notável entreos outros.
Já em relação a vulnerabilidade de XSS, a ferramentas que apresentou o melhor
recall foi o Paros, e a que apresentou o segundo pior valor da mesma taxa foi o ZAP. Em
relação a precisão sobre a mesma vulnerabilidade, o ZAP mais uma vez apresentou a
segunda pior taxa, e a ferramenta Vega foi a que apresentou a melhor taxa. A ferramenta
que apresentou a pior taxa de recall e precisão foi o SkipFish tendo apresentado o valor de
zero em ambos os casos.
3.3.3 Discuções Adicionais
Em paralelo a estas características mostradas, foram percebidos outros detalhes
na execução e nos relatórios de cada WVS. A ferramenta Vega, por exemplo, não possui
a opção de geração de relatório de varredura, nem a opção de salvar a sessão na qual
foi realizada a busca. Este fato dificultou a análise dos dados obtidos por parte desta
ferramenta, pois a única maneira de fazê-lo foi no momento da execução da varredura,
enquanto o programa estivesse aberto.
Outra dificuldade enfrentada foi na análise dos relatórios das demais ferramentas.
O relatório de varredura do SkipFish, especificamente, é bastante confuso, apesar de trazer
muitas informações sobre a execução da varredura. Um exemplo, é o caso em que uma
3.3. Resultados 55
falha de Local File Inclusion é especificada como "Interesting file". No caso do relatório
das ferramentas Paros e ZAP, eles apresentam pequenos detalhes que poderiam gerar
algum desentendimento, como na coloração das tabelas e na duplicação de um mesmo tipo
de alerta.
Apesar desta característica citada sobre o ZAP, ela é a ferramenta que, pelo que
foi visto, possui a maior quantidade de ferramentas e opções de varredura, assim como a
que foi citada no Capítulo 2.
57
4 Conclusão
Neste trabalho foram mostradas as necessidades e as dificuldades do desenvolvimento
de aplicações web seguras e que para esta tarefa, as ferramentas de busca de vulnerabilidades
web têm um papel importante. Neste contexto, este trabalho avaliou 4 ferramentas utilizadas
para a realização das análises.
Conforme proposto no início do trabalho, foi possível fazer a discussão das vantagens
e desvantagens de cada ferramenta acerca de diferentes características. Os WVSs Paros
e Vega foram os que mais se destacaram nos quesitos de Precisão e Recall sobre as
vulnerabilidades de Injeção de SQL e Cross Site Scripting. No entanto a ferramenta ZAP
pareceu ser a mais completa em relação ao número de opções de ferramentas de execução,
apesar de tais opções não terem sido exploradas nos testes. Também foi percebido que as
ferramentas Vega e SkipFish foram as que apresentaram melhores taxas de falso-positivo,
falso-negativo e verdadeiro-positivo em relação a todas as vulnerabilidades. Além disso,
as vulnerabilidades de Cross Site Request Forgery e Click Jacking pareceram ser as
vulnerabilidades mais difíceis de serem detectadas por todos os WVSs.
Com a execução das práticas mostradas aqui e com a análise final dos dados,
percebeu-se que, para obter melhores resultados é necessário o uso de um cenário que traga
uma quantidade maior de vulnerabilidades e de pontos vulneráveis dentro das aplicações de
teste. Esta mudança faria com que fosse possível a avaliação das ferramentas em relação a
detecção de uma quantidade maior de vulnerabilidades e com mais exatidão nos resultados
de detecção de cada uma delas.
Em relação a melhorias nas práticas de teste, poderiam ser feitas também análises
explorando mais recursos de cada scanner de vulnerabilidade. Assim, cada as ferramentas
poderiam ser avaliadas de uma forma mais completa.
Outra melhoria seria a utilização de mais aplicações web para teste, que utilizas-
sem diferentes linguagens de programação, tendo em vista a ampla gama de diferentes
tecnologias para o desenvolvimento de softwares web.
59
Referências
ABNT. Norma ABNT NBR ISO/IEC 27002. 2005. Último acesso em 13 de Novembro de
2018. Disponível em: <http://www.fieb.org.br/download/senai/NBR_ISO_27002.pdf>.
Citado 3 vezes nas páginas 22, 23 e 30.
ADAMDOUPE. WackoPicko Github. 2018. Último acesso em 30 de outubro de 2018.
Disponível em: <https://github.com/adamdoupe/WackoPicko>. Citado na página 49.
APACHE. Directory Listing Configuration. 2012. Último acesso em 25 de Novembro de
2018. Disponível em: <https://wiki.apache.org/httpd/DirectoryListings>. Citado na
página 39.
BHAMARE, K. OWASP ZAP Modes. 2016. Último acesso em 12 de Novembro de 2018.
Disponível em: <https://blog.e-zest.com/owasp-zap-modes>. Citado na página 29.
CERT. Cartilha de Segurança para Internet. 2017. Último acesso em 26 de Novembro de
2018. Disponível em: <https://cartilha.cert.br/glossario/#v>. Citado na página 30.
CERT.BR. FAQ: Perguntas Freqüentes ao CERT.br. 2018. Último acesso em 23 de
Novembro de 2018. Disponível em: <https://www.cert.br/docs/certbr-faq.html#6>.
Citado na página 21.
CERT.BR. Incidentes Reportados ao CERT.br – Janeiro a Dezembro de 2017.
2018. Último acesso em 13 de Novembro de 2018. Disponível em: <https:
//www.cert.br/stats/incidentes/2017-jan-dec/tipos-ataque.html>. Citado na página 22.
CERT.BR. Sobre o CERT.br. 2018. Último acesso em 13 de Novembro de 2018. Disponível
em: <https://www.cert.br/sobre/>. Citado na página 21.
DAVIS, A. A History of Hacking. 2015. Último acesso em 13 de Novembro de
2018. Disponível em: <http://theinstitute.ieee.org/technology-topics/cybersecurity/
a-history-of-hacking>. Citado na página 21.
FONSECA, J.; VIEIRA, M.; MADEIRA, H. Testing and comparing web vulnerability
scanning tools for sql injection and xss attacks. In: IEEE. 13th Pacific Rim International
Symposium on Dependable Computing (PRDC 2007). [S.l.], 2007. p. 365–372. Citado 2
vezes nas páginas 23 e 28.
FONSECA, J.; VIEIRA, M.; MADEIRA, H. Evaluation of web security mechanisms
using vulnerability and attack injection. IEEE Transactions on Dependable and Secure
Computing, IEEE, n. 1, p. 1, 2014. Citado na página 23.
FOROUZAN, B. A. Comunicação de dados e redes de computadores. 4. ed. [S.l.]:
McGraw-Hill, 2008. Citado na página 21.
GITHUB. skipfish. 2018. Último acesso em 27 de outubro de 2018. Disponível em:
<https://github.com/spinkham/skipfish>. Citado na página 29.
http://www.fieb.org.br/download/senai/NBR_ISO_27002.pdf
https://github.com/adamdoupe/WackoPicko
https://wiki.apache.org/httpd/DirectoryListings
https://blog.e-zest.com/owasp-zap-modes
https://cartilha.cert.br/glossario/#v
https://www.cert.br/docs/certbr-faq.html#6
https://www.cert.br/stats/incidentes/2017-jan-dec/tipos-ataque.html
https://www.cert.br/stats/incidentes/2017-jan-dec/tipos-ataque.html
https://www.cert.br/sobre/
http://theinstitute.ieee.org/technology-topics/cybersecurity/a-history-of-hacking
http://theinstitute.ieee.org/technology-topics/cybersecurity/a-history-of-hacking
https://github.com/spinkham/skipfish
60 Referências
KAGORORA, F. et al. Effectiveness of web application security scanners at detecting
vulnerabilities behind ajax/json. International Journal of Innovative Research in Science,
Engineering and Technology, v. 4, n. 6, p. 4179–4188, 2015. Citado na página 23.
MAKINO, Y.; KLYUEV, V. Evaluation of web vulnerability scanners. In: IEEE. Intelligent
Data Acquisition and Advanced Computing Systems: Technology and Applications
(IDAACS), 2015 IEEE 8th International Conference on. [S.l.], 2015. v. 1, p. 399–402.
Citado 2 vezes nas páginas 23 e 49.
MOHAMMED, R. Assessment of web scanner tools. International Journal of Computer
Applications (0975-8887), Citeseer, v. 133, n. 5, 2016. Citado 2 vezes nas páginas 24 e 53.
MORENO, D. Introdução ao Pentest. 1. ed. [S.l.]: novatec, 2015. Citado na página 23.
OWASP. OWASP Broken Web Applications Project. 2015. Disponível em:
<https://www.owasp.org/index.php/OWASP_Broken_Web_Applications_Project>.
Citado na página 30.
OWASP. Testing for Clickjacking (OTG-CLIENT-009). 2016. Último acesso em 4 de
Dezembro de 2018. Disponível em: <https://www.owasp.org/index.php/Testing_for_
Clickjacking_(OTG-CLIENT-009)>. Citado na página 40.
OWASP. Clickjacking Defense Cheat Sheet. 2017. Último acesso em4 de Dezembro de
2018. Disponível em: <https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_
Sheet>. Citado na página 41.
OWASP. Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet. 2018. Último
acesso em 25 de Novembro de 2018. Disponível em: <https://www.owasp.org/index.php/
Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet>. Citado na página
39.
OWASP. OWASP Zed Attack Proxy Project. 2018. Último acesso em 27 de outubro
de 2018. Disponível em: <https://www.owasp.org/index.php/OWASP_Zed_Attack_
Proxy_Project>. Citado na página 29.
PAULI, J. Introdução ao Web Hacking. 1. ed. [S.l.]: novatec, 2015. Citado 2 vezes nas
páginas 27 e 38.
PORTSWIGGER. Burp. 2018. Último acesso em 12 de Dezembro de 2018. Disponível em:
<https://portswigger.net/burp>. Citado na página 50.
ROSS, J. F. K. e K. W. Redes de computadores e a Internet: uma abordagem top-down. 5.
ed. [S.l.]: Addison Wesley, 2010. Citado na página 21.
SECURITY, O. Paros. 2014. Último acesso em 27 de outubro de 2018. Disponível em:
<https://tools.kali.org/web-applications/paros>. Citado na página 29.
SILBERSCHARTZ HENRY F. KORTH, S. S. A. Sistema de Bancos de Dados. 6. ed.
[S.l.]: Elsevier, 2012. Citado na página 28.
STALLING, W. Criptografia e segurança de redes: princípios e práticas. 6. ed. [S.l.]:
Pearson Education do Brasil, 2015. Citado na página 23.
https://www.owasp.org/index.php/OWASP_Broken_Web_Applications_Project
https://www.owasp.org/index.php/Testing_for_Clickjacking_(OTG-CLIENT-009)
https://www.owasp.org/index.php/Testing_for_Clickjacking_(OTG-CLIENT-009)
https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet
https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet
https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
https://portswigger.net/burp
https://tools.kali.org/web-applications/paros
Referências 61
SUBGRAPH. Vega. 2013. Último acesso em 27 de outubro de 2018. Disponível em:
<https://github.com/subgraph/Vega/wiki/About>. Citado na página 30.
SUBGRAPH. Vega. 2014. Último acesso em 27 de outubro de 2018. Disponível em:
<https://subgraph.com/vega/index.en.html>. Citado na página 30.
WEIDMAN, G. Penetration Testing: a hands-on introduction to hacking. 1. ed. [S.l.]: no
starch press, 2014. Citado na página 38.
https://github.com/subgraph/Vega/wiki/About
https://subgraph.com/vega/index.en.html
	Folha de aprovação
	Agradecimentos
	Resumo
	Abstract
	Lista de ilustrações
	Lista de tabelas
	Lista de quadros
	Lista de abreviaturas e siglas
	Sumário
	Introdução
	Problemática e Objetivos
	Metodologia
	Estrutura do Trabalho
	Referêncial Teórico
	Aplicação Web
	Ferramentas de Varredura de Vulnerabilidades Web
	OWASP ZAP
	SkipFish
	Paros
	Vega
	Aplicaçoes Web Vulneráveis
	OWASP Broken Web Application Project
	Outras Ferramentas
	Burp Suite
	Vulnerabilidades
	Injeção de SQL
	Cross-Site Scripting
	Reflected Cross-Site Scripting
	Stored Cross-Site Scripting
	Injeção de Comandos no Sistema Operacional
	File Inclusion
	Remote File Inclusion
	Local File Inclusion
	Cross Site Request Forgery
	Directory Browsing
	Click-Jacking
	Análise das Ferramentas e Resultados Encontrados
	Cenários Avaliados
	Utilização das Ferramentas
	Skipfish
	Paros
	OWASP ZAP
	Vega
	Resultados
	Métricas Avaliadas
	Análises Principais
	Discuções Adicionais
	Conclusão
	Referências