Daniel Galvão de Azevedo - Biblioteca Digital de Monografias · Um estudo sobre ferramentas de...

UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTEGRADUAÇÃO EM ENGENHARIA DE COMPUTAÇÃO

Daniel Galvão de Azevedo

UM ESTUDO SOBRE FERRAMENTAS DE BUSCA DEVULNERABILIDADES EM APLICAÇÕES WEB

Natal/RNDezembro 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 deComputação da Universidade Federaldo Rio Grande do Norte, como partedos requisitos para obtenção do graude Bacharel em Engenharia de Com-putação.

Orientador: Prof. Dr. Carlos Ma-nuel Dias ViegasCo-Orientador: Prof. Dr. Marco Vieira

Natal/RNDezembro 2018

Azevedo, Daniel Galvão de. Um estudo sobre ferramentas de busca de vulnerabilidades emaplicações web / Daniel Galvão de Azevedo. - 2018. 61 f.: il.

Monografia (Graduação) - Universidade Federal do Rio Grandedo Norte, Centro de Tecnologia, Curso de Engenharia deComputaçã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 devarredura 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 - UFRNSistema 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çãoda Universidade Federal do Rio Grande do Norte, como parte dos requisitos para obtençãodo grau de Bacharel em Engenharia de Computação.

Prof. Dr. Carlos Manuel Dias ViegasDCA/UFRN

Prof. Dr. Marco VieiraDEI/FCT/UC

Prof. Me. Francisco Sales de Lima FilhoDIATINF/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 passadosaté hoje. Sou muito grato por tudo.

Agradeço ao Prof. Carlos Manuel Dias Viegas, por toda a paciência, ajuda econhecimentos passados durante todo o curso e durante o processo de desenvolvimentodeste documento.

Agradeço Prof. Marco Vieira também pela ajuda e paciência durante o processo dedesenvolvimento deste trabalho.

Agradeço aos professores do DCA que me proporcionaram uma excelente formaçãono curso de engenharia de computação.

E, finalmente, a todos que direta ou indiretamente me ajudaram nessa etapa daminha 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, emconsequê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étodoscomo boas práticas de desenvolvimento e testes de invasão (pentest). Nestes dois casos, asferramentas de busca de vulnerabilidade web são bastante empregadas, principalmentepara a realização de testes do tipo black-box. No entanto, até mesmo estas ferramentasprecisam ser bem selecionadas, para se atingir o objetivo esperado. Este trabalho temcomo objetivo avaliar algumas das principais ferramentas de busca de vulnerabilidade webde código aberto, tais como OWASP ZAP, Paros, SkipFish e Vega. Estas ferramentasforam executadas sobre duas aplicações web intencionalmente vulneráveis e os relatóriosproduzidos foram comparados com a lista de vulnerabilidades de cada aplicação. Alémdisso, é 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 osdados 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 webapplications. In view of this, it is necessary to safely develop these applications, since theimpact 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 thissecurity, methods such as good development practices and penetration testing (pestest)are used. In these two cases, web vulnerability scanner tools are widely used, mainlyfor black-box type tests. However, even these tools need to be well-selected in order toachieve the expected goal. This work aims to evaluate some of the main open-source WebVulnerability Scanners, such as ZAP, Paros, SkipFish and Vega. These scanners were runon two intentionally vulnerable web applications and the produced Reports were comparedwith the list of vulnerabilities of each application. Besides, a brief explanation of the toolsand main vulnerabilities addressed in the practices are given, and the scenarios used andthe data obtained are shown below. Finally, positive and negative points of each tool areshown, 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 . . . . . . . . . . . . . . 22Figura 2 – Porcentagem dos tipos de incidentes ocorridos no ano de 2017 . . . . . 23Figura 3 – Arquitetura de uma aplicação web. . . . . . . . . . . . . . . . . . . . . 28Figura 4 – Exemplo de exploração da vulnerabilidade de Injeção de SQL. . . . . . 31Figura 5 – Exemplo de exploração da vulnerabilidade Reflected Cross-Site Scripting. 33Figura 6 – Código da página web após a exploração da vulnerabilidade de Reflected

Cross-Site Scripting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Figura 7 – Exemplo de exploração da vulnerabilidade Stored Cross-Site Scripting. 34Figura 8 – Código da página web após a exploração da vulnerabilidade de Stored

Cross-Site Scripting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Figura 9 – Exemplo de aplicação web que utiliza commandos do sistema operacional. 36Figura 10 – Exemplo de exploração da vulnerabilidade de Injeção de Comandos no

Sistema Operacional. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36Figura 11 – Exemplo de exploração da vulnerabilidade Remote File Inclusion. . . . 37Figura 12 – Exemplo de exploração da vulnerabilidade Local File Inclusion. . . . . 38Figura 13 – Exemplo de exploração da vulnerabilidade Directory Browsing. . . . . . 39Figura 14 – Exemplo de exploração da vulnerabilidade Click-Jacking. . . . . . . . . 40Figura 15 – Cenário utilizado. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43Figura 16 – Configuração do proxy no navegador FireFox. . . . . . . . . . . . . . . 45Figura 17 – Configuração da ferramenta Paros. . . . . . . . . . . . . . . . . . . . . 45Figura 18 – Configuração da ferramenta ZAP. . . . . . . . . . . . . . . . . . . . . . 46Figura 19 – Configuração da ferramenta Vega. . . . . . . . . . . . . . . . . . . . . . 47Figura 20 – Exemplo que vulnerabilidade reportada pela ferramenta ZAP . . . . . 52Figura 21 – Exemplo que vulnerabilidade reportada pela ferramenta Paros . . . . . 52Figura 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. . . . . . . . . . 47Tabela 3 – Número de Tipos de Vulnerabilidades detectadas na aplicação Mutillidae. 48Tabela 4 – Número de pontos vulneráveis na aplicação WackoPicko. . . . . . . . . 48Tabela 5 – Número de Tipos de Vulnerabilidades detectadas na aplicação WackoPicko. 48Tabela 6 – Tipos de vulnerabilidades nas aplicações Mutillidae e WackoPicko. . . 50Tabela 7 – Número de Verdadeiros Positivos (VP), Falso Positivos (FP) e Falso

Negativos (FN) de cada Vulnerabilidade na aplicação Mutillidae. . . . 51Tabela 8 – Número de Verdadeiros Positivos (VP), Falso Positivos (FP) e Falso

Negativos (FN) de cada vulnerabilidade na aplicação WackoPicko. . . . 51Tabela 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 312.2 Exemplo de consulta SQL modificada . . . . . . . . . . . . . . . . . . . . . 322.3 Exemplo de requisição forjada . . . . . . . . . . . . . . . . . . . . . . . . . 382.4 Exemplo de código HTML com Token . . . . . . . . . . . . . . . . . . . . 392.5 Exemplo de configuração do Apache . . . . . . . . . . . . . . . . . . . . . . 392.6 Exemplo de prova de conceito sobre a vulnerabilidade de Click-Jacking . . 403.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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211.1 Problemática e Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . 231.2 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241.3 Estrutura do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2 REFERÊNCIAL TEÓRICO . . . . . . . . . . . . . . . . . . . . . . . . 272.1 Aplicação Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.2 Ferramentas de Varredura de Vulnerabilidades Web . . . . . . . . . . . 282.2.1 OWASP ZAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.2.2 SkipFish . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.2.3 Paros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.2.4 Vega . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.3 Aplicaçoes Web Vulneráveis . . . . . . . . . . . . . . . . . . . . . . . . . 302.3.1 OWASP Broken Web Application Project . . . . . . . . . . . . . . . . . 302.4 Outras Ferramentas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.4.1 Burp Suite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.5 Vulnerabilidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.5.1 Injeção de SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312.5.2 Cross-Site Scripting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322.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 . . . . . . . . . . . . . . . 352.5.4 File Inclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362.5.4.1 Remote File Inclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

2.5.4.2 Local File Inclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

2.5.5 Cross Site Request Forgery . . . . . . . . . . . . . . . . . . . . . . . . . 382.5.6 Directory Browsing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392.5.7 Click-Jacking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3 ANÁLISE DAS FERRAMENTAS E RESULTADOS ENCONTRADOS 433.1 Cenários Avaliados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433.2 Utilização das Ferramentas . . . . . . . . . . . . . . . . . . . . . . . . . 433.2.1 Skipfish . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433.2.2 Paros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.2.3 OWASP ZAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463.2.4 Vega . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

3.3 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.3.1 Métricas Avaliadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.3.2 Análises Principais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.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 coma criação da ARPAnet, um trabalho criado pela ARPA (Advanced Research Projects) eliderado por J. C. R. Licklider e Lawrence Roberts. A ARPAnet iniciou como uma pequenarede de computadores conectados, cujo objetivo era conectar pesquisadores para que elespudessem compartilhar descobertas de uma forma menos custosa. Sendo assim, esta redeconsistia, inicialmente, de 4 computadores localizados em diferentes universidades nosEstados Unidos da América. Em 1972, outras redes como a ARPAnet haviam sido criadase a própria ARPAnet já estava com 15 computadores conectados(ou nós, como tambémpodem ser chamados). No ano de 1974, outro trabalho foi criado com o objetivo de criaruma rede de redes. Desta vez liderado por Vinton Cerf e Robert Kahn e patrocinado pelaDARPA (Defense Advanced Research Projects Agency). Para descrever este trabalho, foientã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 estavamconectadas à ARPAnet. Ao final da década de 1980, o número de máquinasligadas à Internet pública, uma confederação de redes muito parecidacom 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á eramconhecidos por atuarem nas redes de telefone e por adulterarem telégrafos, antes de irempara a Internet. Em 1988, Robert T. Morris criou um vírus que infectou cerca de 6.000computadores, 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 ResponseTeam), 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 deresposta a incidentes computacionais foram criados ao redor do mundo, e o termo CSIRT(Computer Security Incident Response Team) também passou a ser usado para denominaressas equipes. Entre estes times criados está o CERT.br que é o grupo de resposta aincidentes de segurança para a Internet no Brasil e que tem, entre outros papéis, o deservir como ponto central para notificações de incidentes de segurança no Brasil [CERT.br2018].

Incidente de segurança, segundo o próprio CERT.br, é classificado como [CERT.br2018] “[...] 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/IEC27.002 [ABNT 2005, p. 2], que diz que:

“um incidente de segurança da informação é indicado por um simplesou por uma série de eventos de segurança da informação indesejadosou inesperados, que tenham uma grande probabilidade de comprometeras operações do negócio e ameaçar a segurança da informação [ABNT2005, p. 2]”

Sabendo-se disso, pode-se analisar a Figura 1 que mostra que, de acordo com oCERT.br, o número de incidentes de segurança vem crescendo cada vez mais, tendo seupico 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 porcentagementre 7 a 8 porcento foram classificados como incidentes de web, os quais são descritospelo próprio CERT.br como [CERT.br 2018] "um caso particular de ataque visandoespecificamente o comprometimento de servidores Web ou desfigurações de páginas naInternet.". Um exemplo deste percentual é mostrado na Figura 2, que exibe a porcentagemdos 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 preocupantetendo 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 sobreaplicaçõ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 deaumentarem a gravidade dos danos causados por uma falha de segurança, uma vez quedados sensíveis estão sendo utilizados.

Dessa forma, para garantir a segurança de aplicações web, é necessário o uso deboas práticas em seu desenvolvimento. Entre estas boas práticas estão a validação deentrada e saída do sistema, controle do processamento interno e a aplicação de testes paraa visualização de vulnerabilidades [ABNT 2005].

Na aplicação de tais testes, principalmente testes do tipo black-box (quando nãose tem conhecimento do código fonte da aplicação), são utilizadas as ferramentas debusca de vulnerabilidades web (Web Vulnerability Scanners - WVSs), que são ferramentasautomatizadas que expõem as vulnerabilidades de uma determinada aplicação web paraque 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 deinvasão (pentest), que é uma bateria de testes metodológicos, executados em um sistemaou 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 deaplicações web podem ser citados, bem como os desafios para torná-las seguras. Como foidiscutido 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émpela vasta variedade de tecnologias utilizadas;

• O servidor web muitas vezes é a porta de entrada para dados sensíveis de umaempresa, 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 quefaz com que seja necessário uma análise da eficiência deste tipo de ferramenta [Mohammed2016].

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 nostestes. 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 webvulneráveis para a coleta dos relatórios de execução. Com estes relatórios, as análisesforam 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-positivosde cada ferramenta e para cada tipo de vulnerabilidade. Além disso, também foramobtidas e analisadas as taxas de Recall e Precisão de cada ferramenta como foi feito notrabalho [Mohammed 2016], uma vez que mostram mais claramente o desempenho dasferramentas.

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 2apresenta as ferramentas utilizadas e as vulnerabilidades abordadas no trabalho, assimcomo outros conceitos importantes para uma melhor compreensão do texto. No Capítulo 3os 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 paraa realização dos experimentos. Serão apresentadas também as ferramentas utilizadas pararealização das buscas de vulnerabilidades, assim como as utilizadas para simular umaaplicação web.

2.1 Aplicação Web

Para definir uma aplicação web será utilizada a definição de Josh Pauli em seulivro "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 comsistemas de backend. Quando um usuário interage com um web site pararealizar alguma ação, por exemplo, fazer login, fazer compras ou acessaro 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 MarkupLanguage revision 5), JavaScript e PHP (Hypertext Preprocessor);

• Para o processamento dos dados no Servidor de Aplicação Web é utilizado tambémo PHP;

• Para a comunicação com o banco de dados, será utilizado o SQL (Structured QueryLanguage), 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 HenryF. Korth 2012]

2.2 Ferramentas de Varredura de Vulnerabilidades Web

Como é dito em [Fonseca, Vieira e Madeira 2007], existem dois principais métodosde teste de aplicações web para varredura de vulnerabilidades. O primeiro é chamado dewhite-box onde o software de varredura tem conhecimento do código fonte da aplicaçãoweb, 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. Nestemétodo, o software de varredura não tem conhecimento do código fonte da aplicação, eassim 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 deum usuário.

Como é mostrado também em [Fonseca, Vieira e Madeira 2007], o funcionamentodeste 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 mapada estrutura interna da aplicação web, a partir da URL e dos parâmetros disponibilizadosna fase de configuração. Para fazer este mapa, a ferramenta examina o código da páginada URL disponibilizada, para encontrar novas URLs. Ao encontrar, a ferramenta examinao 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 deaplicação web, assim como suas respostas, são também analisadas levando-se em conta osparâ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 ApplicationSecurity Project, ou Projeto Aberto de Segurança em Aplicações Web), uma organizaçãosem fins lucrativos e imparcial, focada na melhoria da segurança de aplicações web [OWASP2018].

Para a configuração do scanner desta ferramenta, é possível selecionar o modo deaçã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 sejapotencialmente perigosa.

• Modo Protected : Neste modo, o scanner é capaz de realizar ações potencialmenteperigosas apenas em URLs especificadas no escopo da varredura.

• Modo Standard : Nesta modo, o usuário permite ao scanner que seja feita qualqueração que seja relevante.

• Modo ATTACK : Neste modo, todas as URLs descobertas na fase de crawling sãotestadas de forma ativa.

2.2.2 SkipFish

O SkipFish é um scanner de vulnerabilidades web operado apenas por meio delinhas de comando. É um programa escrito em linguagem C, de código aberto, criado emantido 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 [Security2014].

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


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 [Subgraph2013, Subgraph 2014]. Para a instalação deste programa no Kali Linux, foi utilizado oseguinte 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áquinavirtual 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 deanálise de código fonte, observar ataques em plataforma web e testar firewalls de aplicaçãoweb. O líder de projeto é Chuck Willis e é patrocinado em parte pela Mandiant. A versão1.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ósutilizamos 2 delas: Mutillidae 2 e WackoPicko. Estas aplicações foram escolhidas pelo fatode suas vulnerabilidades estarem mais facilmente explicitadas, tanto na Internet quantona 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çõesweb, de código proprietário, desenvolvido pela PostWigger. Também é uma ferramentapré-instalada no Kali Linux, porém, em sua versão comunity o que nos da direito a usarapenas as ferramentas básidas do software.

2.5 Vulnerabilidades

Vulnerabilidade se define como uma condição, ou fragilidade, que pode ser exploradapor um atacante, ou ameaça, que quando explorado, pode resultar em uma violação desegurança [ABNT 2005,CERT 2017]. Como são mostrados nos tópicos seguintes, existemvários motivos para o surgimento de vulnerabilidades, como a falha de configuração de umprograma, 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 umaconsulta 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 lojasvirtuais. Como exemplo, pode ser usado o caso mostrado na Figura 4a. Nesta figura, comopode ser visto, em vez de o usuário digitar apenas o nome do usuário em que desejaprocurar informações, digita “daniel’ or ‘1’=‘1’ -- ” o que faz com que a aplicaçãoretorne 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 AccountDetails”, o código da página web, presente nos “Navegadores Web” como mostrado naFigura 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. Seestes dois dados não forem tratados antes de serem inseridos na consulta SQL, a consultaserá enviada ao banco de dados com o nome e a senha exatamente da mesma forma queforam digitados, mesmo que o usuário tenha digitado caracteres inválidos. Isso possibilita


que algum usuário malicioso digite informações que alterem a consulta SQL que irá aobanco de dados. Estas modificações podem ir desde pequenas alterações, como mostradona Figura 4, até a criação de novas consultas SQL que podem ler, modificar ou até apagardados 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áriono 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 processamentopor parte da aplicação web. Este tipo de vulnerabilidade, se explorado, pode ser utilizadocomo forma de roubar dados pessoais da vítima ou executar alguma ação em websites. Nocaso do tipo de vulnerabilidade de Cross-Site Scripting (Scripting entre sites), a aplicaçãoweb permite que o usuário execute scripts na página exibida no navegador web, como seesse 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 é exibidono resultado da pesquisa. A Figura 5 mostra um exemplo deste comportamento. Na páginaweb das imagens mostradas, a aplicação web pede por algum texto na qual será impressona página e quantas vezes isso deve ser feito.


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 textocomum. No entanto, a segunda parte “<script>alert(“XSS”);</script>” é um textoque, 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 é mostradona Figura 5b. Na Figura 5c é mostrado o texto “XSS : ” impresso na tela. O código dapá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 ReflectedCross-Site Scripting.

2.5.2.2 Stored Cross-Site Scripting

No caso do Stored Cross-Site Scripting, o código malicioso é armazenado naaplicação web. Este tipo de vulnerabilidade está muitas vezes presente em páginas dediscussões ou de comentários sobre algum produto. Isso acontece pois, no momento em que


um comentário é submetido a esse tipo de página, ele será armazenado no banco de dadose 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 dasvítimas que abrirem este site, irão executar o código malicioso.

Um exemplo de exploração desta vulnerabilidade é mostrado na Figura 7. NaFigura 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, sobreReflected Cross-Site Scripting. Na Figura 7b é mostrada a página onde são visualizados oscomentá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 aadição do comentário.

Figura 7 – Exemplo de exploração da vulnerabilidade Stored Cross-Site Scripting.

(a)

(b)


Figura 8 – Código da página web após a exploração da vulnerabilidade de Stored Cross-SiteScripting.

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 suaatividade maliciosa manifestada no servidor de aplicação web, no entanto, sem precisarinteragir 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 decomandos 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 domesmo. Neste caso, como é mostrado na Figura 9a, é digitado o site “google.com”, e aresposta da aplicação web a esta entrada é mostrado na Figura 9b.


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 textocomo é 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çode texto como outro comando. O termo “ls” é um comando de sistemas operacionaisbaseados em Unix que lista os arquivos presentes em um diretório. Sendo assim, o resultadoque será retornado do servidor de aplicação web será a lista de arquivos do diretório emque 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 SistemaOperacional.

(a)

(b)

2.5.4 File Inclusion

Esta vulnerabilidade permite que o usuário execute scripts ou que carregue oconteúdo de arquivos que estejam fora do conjunto de arquivos usados pela aplicaçãoweb. Assim como as vulnerabilidades citadas acima, esta também é causada pela falta desanitização da entrada de dados do usuário. Desta vez, a entrada de usuário que pode ser


utilizada de forma maliciosa é a que indica qual a página será carregada pelo navegadorweb.

2.5.4.1 Remote File Inclusion

Remote File Inclusion (Inclusão Remota de Arquivo) é o tipo de vulnerabilidadede File inclusion que permite a execução remota de arquivos.

Uma prova de conceito desta vulnerabilidade pode ser vista na Figura 11 ondea página de pesquisa do Google pôde ser carregada como se fosse mais uma página daaplicação. Para isso, foi necessário apenas a alteração do parâmetro “page” na URL dapá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 daaplicação web como, por exemplo, “home.php” e “login.php”. No entanto, uma vez queo valor desta variável não é sanitizado, foi possível especificar a URL de uma página naInternet, 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 quepermite 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, assimcomo no exemplo da Figura 11 sobre Remote File Inclusion, o parâmetro usado para fazeresta inclusão foi o “page”, presente na URL da página. No caso da Figura 12, a URLutilizada 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 dediretórios, do diretório atual. Sendo assim, o texto especificado na variável “page” mostra


o caminho para o arquivo local “passwd” no servidor de aplicação web. Este arquivo listatodos os usuários do sistema, além de algumas de suas informações. A Figura 12 mostraesta 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çãopermitida 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 ReflectedCross-Site Scripting, pelo fato de que, para se explorar estas vulnerabilidades é necessárioa 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 umadelas, ele está autenticado em sua conta do banco. Na outra aba, o mesmo usuário visitauma página que 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 maliciosaserá realizada sem que o usuário perceba.

Existem algumas técnicas para se proteger desta vulnerabilidade, e uma das maisconhecidas é a utilização de Tokens. Estes Tokens são valores únicos para cada seçãode usuário e aleatoriamente criados, colocados escondidos dentro da página web. Estesmesmos valores são utilizados para a validação das requisições feitas ao servidor. Uma vezque somente o servidor de aplicação web sabe qual foi o valor de Token gerado, não há


como forjar uma requisição com o mesmo valor. Um exemplo de código HTML com esteToken, 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, ocorrequando o usuário acessa algum diretório da aplicação web e o servidor de aplicação webretorna a listagem de todos os arquivos presentes no diretório acessado. Um exemplo destavulnerabilidade pode ser vista na Figura 13. Esta vulnerabilidade pode ser evitada apenascom a configuração correta do software que oferece o serviço web, como o Apache. Umexemplo 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 serutilizada em outra página, através de uma tag “iframe” por exemplo. Normalmente,quando se deseja explorar esta vulnerabilidade, este “iframe” é escondido nesta novapágina, com a ajuda do CSS (Cascading Style Sheets), e alguma parte crucial da página queestá no “iframe” é colocada sob outro elemento também crucial desta nova página, como


por exemplo, um botão. Assim no momento em que o usuário clica no botão, desejandorealizar 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 deconceito 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árioirá 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 WEBPAGE ”, 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 webescondida. Uma outra forma de ver este mesmo cenário esta ilustrado na Figura 14b, ondea página escondida esta sendo mostrada em uma cor mais clara.

Uma forma de evitar este tipo de vulnerabilidade é fazendo-se a configuração doservidor de aplicação web para que, na resposta HTTP da solicitação de uma página daaplicação, seja utilizado o cabeçalho Content-Security-Policy ou X-Frame-Options, sendo o


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 mostradosna 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 emuma tag “frame”;

frame-ancestors ’self ’ SAMEORIGIN

Permite que apenas a própria página e as páginasespecificadas 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 ferrametasapresentadas 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 esquemada Figura 15. A VM (Virtual Machine ou Máquina Virtual) com o OWASP BWA e com oIP (Internet Protocol) 10.0.2.9 simula as aplicações web vulneráveis. Já a VM com o Kalie 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 embusca 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 linhade comando. Sendo assim, ao iniciar o terminal na máquina Kali Linux, foram usados osseguintes 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 −Ihttp : / / 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 −Ihttp : / / 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 davarredura;

• -I : Especifica a URL na qual o scanner deve seguir. Este parâmetro é necessáriopara 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 nonavegador utilizado, que no caso foi o Mozilla Firefox, como é mostrado na Figura 16. Emseguida, com o Paros já em execução, visitar a página das aplicações do Mutillidae e doWackoPicko para que o proxy registrasse a página para ser utilizada posteriormente, comoesta ilustrado na Figura 17a.

Após acessar a aplicação desejada, é executado o Spider (ou web crawler) para queseja feito o mapa de todos os caminhos de URL disponíveis na aplicação. Para executaro Spider foi necessário clicar com o botão direito do mouse na aplicação registrada peloproxy, e clicar em “Spider ”, como é mostrado na Figura 17b.

Ao final da execução do Spider é que então poderia ser executada varredura, clicandono menu “Analyse”, e em seguida clicando em “Scan”, como mostrado na Figura 17c.

3.2. Utilização das Ferramentas 45

Figura 16 – Configuração do proxy no navegador FireFox.

Figura 17 – Configuração da ferramenta Paros.

(a)

(b)

(c)


3.2.3 OWASP ZAP

Ao iniciar a ferramenta pela primeira vez, é pedido que seja feita a atualização depacotes, 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 omodo 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 aferramenta e clicar no menu “Scan” e em seguida em “Start New Scan” como é mostrado naFigura 19a. Na janela em que se abre, marque a opção “Use a base URI for scan” e digitea 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áveise tipos de vulnerabilidades. No caso deste trabalho, o primeiro significa a quantidadede páginas web que possuem algum tipo de vulnerabilidade. Já o segundo significa aclassificação da vulnerabilidade, como por exemplo SQLi e XSS. Sendo assim, um mesmotipo 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 osresultados mostrados nas Tabelas 2, 3, 4 e 5. Estes dados foram obtidos diretamente dosrelató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áveisOWASP ZAP Paros SkipFish Vega

Alta 36 226 3 18Média 34 100 18 44Baixa 44 27 6 45

Informação 0 0 94 244

Total 114 353 121 351


Tabela 3 – Número de Tipos de Vulnerabilidades detectadas na aplicação Mutillidae.

Severidade das Vulnerabilidades Número de Tipos de VulnerabilidadesOWASP ZAP Paros SkipFish Vega

Alta 5 2 2 9Média 4 5 7 4Baixa 11 1 2 3


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áveisOWASP ZAP Paros SkipFish Vega

Alta 15 0 2 20Média 34 41 15 3Baixa 41 0 22 35


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 VulnerabilidadesOWASP ZAP Paros SkipFish Vega

Alta 6 0 2 10Média 3 4 5 2Baixa 5 0 1 3


Total 14 4 25 18

Ao analisar os resultados das tabelas, é possível perceber diferenças entre cadaWVS. Na Tabela 2, a ferramenta Paros se destacou com o melhor desempenho por ter sidoa 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 pontosvulneráveis de alta severidade.

Já na Tabela 3, é possível perceber que o Paros foi a ferrameta que detectou o menornúmero que tipos diferentes de vulnerabilidade no total. Ela também foi a que detectoumenos tipos de vulnerabilidade de alta severidade, junto com a ferramenta SkipFish. Poroutro lado, a ferramenta que teve o melhor desempenho foi o Vega, uma vez que detectouo 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 ferramentaZAP foi a que teve a melhor proporção entre o número de tipos de vulnerabilidadesdetectadas 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, oque pode indicar um grande número de falso-positivos.

Em relação a Tabela 4 que trata sobre a aplicação WackoPicko, as ferramentas quemostraram um melhor desempenho foram as ferramentas Vega e ZAP, tendo sido a Vegaa que detectou maior número de pontos vulneráveis de alta severidade. No entanto, o ZAPdetectou mais pontos vulneráveis se somados os pontos de alta e média severidade. Poroutro 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 umagrande diferença em relação as outras ferramentas. No entanto, a ferramenta que detectouo 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 aferramenta que teve uma melhor proporção entre o número de pontos vulneráveis e de tiposde 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 SkipFishe 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 listasde vulnerabilidades conhecidas nas aplicações. No Mutillidae, esta lista é disponibilizadadentro da própria aplicação, na seguinte URL: “http://<IP da máquina>/mutillidae/

index.php?page=./documentation/vulnerabilities.php”. Já no WackoPicko, estalista é disponibilizada na página do GitHub [Adamdoupe 2018].

Com o objetivo de realizar uma análise mais precisa das ferramentas, foi consideradoapenas um grupo das 9 vulnerabilidades mais relevantes e que estão presentes em ambasaplicações. Esta seleção se deve também ao fato de que os resultados das varredurasmostraram a presença de vulnerabilidades que são, frequentemente, não intencionais eque 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”. Estaabordagem é semelhante ao trabalho [Makino e Klyuev 2015]. A Tabela 6 mostra aocorrência destas vulnerabilidades em cada aplicação.


Tabela 6 – Tipos de vulnerabilidades nas aplicações Mutillidae e WackoPicko.

Vulnerabilidade Mutillidae WackoPicko

SQL Injection (SQLi) 8 2Reflected Cross Site Script (RXSS) 18 3Stored Cross Site Script (SXSS) 2Operacional System Command Injection (OSCi) 2 1Remote 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 ea quantidade de ocorrências destas vulnerabilidades em cada aplicação foi deixada emaberto, 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 quepossuíam os dados menos compreensíveis eram de SXSS e RXSS. Por isso, nesta tabela, acontagem foi feita por uma somatória das duas vulnerabilidades.

Já a aplicação WackoPicko não possui ocorrências da vulnerabilidade de LFI. Emsua 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 dasvulnerabilidades de LFI e RFI.

Com isso, foi feita então a checagem dos relatórios em relação às vulnerabilidadesespecíficas, o que nos deu os dados mostrados nas Tabelas 7 e 8. Para a obtenção destastabelas 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 vulnerabilidadesdisponibilizadas por cada aplicação, com o objetivo de verificar se cada ponto vulnerávelmostrado nos relatórios das WVSs, estavam presentes nestas listas de vulnerabilidades.Caso estivessem, eram considerados verdadeiros positivos. Caso não estivessem, eramconsiderados falso positivos. Os falsos negativos foram calculados subtraindo-se os númerosmostrados 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 nosrelató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 dasrequisiçõ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 VegaVP FP FN VP FP FN VP FP FN VP FP FN

SQLi 1 2 6 2 0 6 3 110 5 1 1 7XSS 1 16 15 0 4 17 12 54 5 1 6 17OSCi - - 2 - - 2 - - 2 - - 2RFI 8 0 0 0 0 0 - - 0 1 0 0LFI 0 0 0 1 0 0 - - 0 2 0 0

CSRF - - 2 - - 2 - - 2 - - 2DirB 14 0 0 20 0 0 3 0 0 29 0 0CJ 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 VegaVP FP FN VP FP FN VP FP FN VP FP FN

SQLi 1 1 1 1 0 1 - - 2 1 0 1RXSS 1 4 2 1 0 2 1 0 2 1 1 2SXSS 1 2 1 - - 2 1 1 1 1 1 1OSCi 1 1 0 1 0 0 - - 1 1 0 0FI 2 0 0 1 0 0 - - 0 - - 0

Como pode ser visto nas Tabelas 7 e 8, o WVS Paros possui o maior númerode falso-positivos, se considermos as duas aplicações, seguida do ZAP com a segundamaior quantidade de falso-positivos. Ainda sobre o Paros, podemos ver que sua varredurateve 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 devulnerabilidade, com exceção do Directory Browsing no Mutillidae. Outra conclusão quepode ser tirada destes dados é que houve uma dificuldade unânime para detecção dasvulnerabilidades de OSCi, CSRF e CJ, como pode ser visto na Tabela 7.

Apesar destas análises feitas sobre a ferramenta Paros, foi encontrado em seurelatório uma grande quantidade de pontos vulneráveis da vulnerabilidade de XSS na qualnão são descritas nas listas de vulnerabilidades das aplicações. No entanto, estes casos depontos vulneráveis ainda foram considerados como falso positivos pelo fato de não estaremnas listas de vulnerabilidades.

Para entender melhor os casos mostrados nesta tabela, podemos ver o caso daFigura 20 que mostram as vulnerabilidades de SQLi indicadas pela ferramenta ZAP. Nestacaso, 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 vezque os valores testados ("ZAP’ OR ’1’=’1’ – ") nos parâmetros especificados, realizamuma ação irregular. Assim como mostrado no Capítulo 2, a expressão "OR ’1’=’1’" fará


com que a pesquisa no banco de dados selecione qualquer valor, e uma vez que a páginaque esta sendo testada é a de autenticação ("login.php"), o usuário será autenticadodigitando-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 exemplosde falsos positivos, pois a resposta do servidor de aplicação web para tais testes nãoapresentam nenhum comportamento irregular.

Outro caso que pode ser visto é o da ferramenta Paros, na Figura 21 sobre avulnerabilidade de XSS. Nesta figura, assim como na Figura 20, são mostradas as URLs eos 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 testeigual 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á nosoutros 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 umDiagrama de Venn, como é mostrado na Figura 22 acima, onde a Figura 22b representaa aplicação WackoPicko e a Figura 22a aplicação Mutillidae. Nestes diagramas estãosendo mostrados os verdadeiros positivos detectados por cada ferramenta em relação aonúmero total. Para a criação destas imagens, foram levadas em conta as vulnerabilidadesda mesma forma como estão representadas na Tabela 6, ou seja, as vulnerabilidades queestã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 cadaWVS 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 identificadasem relação ao total existente. Já a Precisão é a taxa de vulnerabilidades relevantes emrelação ao total indicado pela ferramenta. Para que seja feita de forma mais direcionadapara cada ferramenta de análise de vulnerabilidade, foi feito um somatório entre os dadosobtidos 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 VegaR P R P R P R P

SQLi 14,2 33,3 30 100 30 2,6 20 66,6XSS 6,2 5,8 5 20 60,9 20,3 13 27,3OSCi 33,3 50 33,3 100 0 0 33,3 100CSRF 0 0 0 0 0 0 0 0CJ 0 0 0 0 0 0 0 0


Como foi comentado anteriormente, as vulnerabilidades de Directory Brownsing,Remote File Inclusion e Local File Inclusion não foram levadas em consideração nestatabela, pois a quantidade de ocorrências destas falhas em cada aplicação não estava bemdeterminada, o que gera uma indeterminação no número de falso-negativos.

Pela quantidade reduzida de pontos de presença de algumas vulnerabilidades nasaplicações avaliadas, as porcentagens de Precisão e de Recall apresentaram valores bemacentuados e repetidos como foi o caso da vulnerabilidade OSCi. Como as vulnerabilidadesCSRF e CJ praticamente não foram detectadas, a Precisão e o Recall na maioria dos casosresultou em zero. Seriam necessárias mais ocorrências para que as WVS pudessem sermelhor analisadas em relação a essas vulnerabilidades. Uma vez que as vulnerabilidadesSQLi e XSS tinham mais presença nas aplicações, seus dados na Tabela 9 mostraram-semais 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 todosdetectaram uma porcentagem baixa destas ocorrências, como é mostrado nesta mesmatabela.

Ainda sobre a Tabela 9, podemos perceber que o ferramenta SkipFish foi a queapresentou maior Precisão na detecção de falhas do tipo SQLi, enquanto que seu valor deRecall se igualou com o da ferramenta Paros, considerando o mesmo tipo de falha. Aindafalando de SQLi, é possível ver que o WVS que apresentou a menor precisão foi o Paros,com uma diferença notável entre os outros.

Já em relação a vulnerabilidade de XSS, a ferramentas que apresentou o melhorrecall foi o Paros, e a que apresentou o segundo pior valor da mesma taxa foi o ZAP. Emrelação a precisão sobre a mesma vulnerabilidade, o ZAP mais uma vez apresentou asegunda pior taxa, e a ferramenta Vega foi a que apresentou a melhor taxa. A ferramentaque apresentou a pior taxa de recall e precisão foi o SkipFish tendo apresentado o valor dezero em ambos os casos.

3.3.3 Discuções Adicionais

Em paralelo a estas características mostradas, foram percebidos outros detalhesna execução e nos relatórios de cada WVS. A ferramenta Vega, por exemplo, não possuia opção de geração de relatório de varredura, nem a opção de salvar a sessão na qualfoi realizada a busca. Este fato dificultou a análise dos dados obtidos por parte destaferramenta, 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 trazermuitas 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óriodas ferramentas Paros e ZAP, eles apresentam pequenos detalhes que poderiam geraralgum desentendimento, como na coloração das tabelas e na duplicação de um mesmo tipode alerta.

Apesar desta característica citada sobre o ZAP, ela é a ferramenta que, pelo quefoi visto, possui a maior quantidade de ferramentas e opções de varredura, assim como aque foi citada no Capítulo 2.

57

4 Conclusão

Neste trabalho foram mostradas as necessidades e as dificuldades do desenvolvimentode aplicações web seguras e que para esta tarefa, as ferramentas de busca de vulnerabilidadesweb têm um papel importante. Neste contexto, este trabalho avaliou 4 ferramentas utilizadaspara a realização das análises.

Conforme proposto no início do trabalho, foi possível fazer a discussão das vantagense desvantagens de cada ferramenta acerca de diferentes características. Os WVSs Parose Vega foram os que mais se destacaram nos quesitos de Precisão e Recall sobre asvulnerabilidades de Injeção de SQL e Cross Site Scripting. No entanto a ferramenta ZAPpareceu 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 asferramentas 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 asvulnerabilidades 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 tragauma quantidade maior de vulnerabilidades e de pontos vulneráveis dentro das aplicações deteste. Esta mudança faria com que fosse possível a avaliação das ferramentas em relação adetecção de uma quantidade maior de vulnerabilidades e com mais exatidão nos resultadosde detecção de cada uma delas.

Em relação a melhorias nas práticas de teste, poderiam ser feitas também análisesexplorando mais recursos de cada scanner de vulnerabilidade. Assim, cada as ferramentaspoderiam 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 diferentestecnologias para o desenvolvimento de softwares web.

59

Referências

ABNT. Norma ABNT NBR ISO/IEC 27002. 2005. Último acesso em 13 de Novembro de2018. 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 de2018. Disponível em: <https://wiki.apache.org/httpd/DirectoryListings>. Citado napá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 de2018. 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 deNovembro 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ívelem: <https://www.cert.br/sobre/>. Citado na página 21.

DAVIS, A. A History of Hacking. 2015. Último acesso em 13 de Novembro de2018. 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 vulnerabilityscanning tools for sql injection and xss attacks. In: IEEE. 13th Pacific Rim InternationalSymposium on Dependable Computing (PRDC 2007). [S.l.], 2007. p. 365–372. Citado 2vezes nas páginas 23 e 28.

FONSECA, J.; VIEIRA, M.; MADEIRA, H. Evaluation of web security mechanismsusing vulnerability and attack injection. IEEE Transactions on Dependable and SecureComputing, 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 detectingvulnerabilities 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. IntelligentData 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 ComputerApplications (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 deDezembro 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 em 4 de Dezembro de2018. 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. Últimoacesso 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ágina39.

OWASP. OWASP Zed Attack Proxy Project. 2018. Último acesso em 27 de outubrode 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 naspá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.]: nostarch press, 2014. Citado na página 38.

https://github.com/subgraph/Vega/wiki/About

https://subgraph.com/vega/index.en.html

Daniel Galvão de Azevedo - Biblioteca Digital de Monografias · Um estudo sobre ferramentas de...

Documents

Transcript of Daniel Galvão de Azevedo - Biblioteca Digital de Monografias · Um estudo sobre ferramentas de...