2013 - 2sem - Wellington Zanelli Ribeiro

Wellington Zanelli Ribeiro
APLICAÇÃO DE BOAS PRÁTICAS DE SEGURANÇA

NO DESENVOLVIMENTO DE SISTEMAS WEB
Trabalho de conclusão de curso apresentado ao Instituto

Federal de São Paulo – Campus de São João da Boa
Vista, como parte dos requisitos para a obtenção do grau
de Tecnólogo em Sistemas para Internet.
Área de Concentração: Segurança no Desenvolvimento

de Sistemas Web
Orientador: Prof. Breno Lisi Romano

Co-Orientador: Prof. Roan Simões da Silva
São João da Boa Vista

2013
Autorizo a reprodução e divulgação total ou parcial deste trabalho,
por qualquer meio convencional ou eletrônico, para fins de estudo e
pesquisa, desde que citada a fonte.
Ficha catalográfica preparada pela Seção de Tratamento

da Informação do Serviço de Biblioteca – IFSP
Ribeiro, Wellington Z.
Aplicação de Boas Práticas de Segurança no
desenvolvimento de Sistemas Web. / Wellington Zanelli
Ribeiro ; orientador Breno Lisi Romano ; co-orientador:
Roan Simões da Silva. São João da Boa Vista, 2013.
Trabalho de Conclusão de Curso, IFSP, 2013.
1. Segurança. 2. Sistemas Web. 3. Desenvolvimento.

4. Vulnerabilidades.
I. Aplicação de Boas Práticas de Segurança em

Sistemas Web
AGRADECIMENTOS
Agradeço primeiramente ao meu orientador Breno, pelo incentivo, entusiasmo
e por acreditar no meu trabalho. À minha esposa Bruna, sempre disposta a me
ajudar com as dúvidas de gramática e por último, mas não menos importante,
ao meu “Guia”, sempre ao meu lado nos momentos mais difíceis, me guiando
pelos desafios da vida, do universo e tudo mais e que mesmo quando toda
resistência parecia inútil seu precioso conselho era o que me fazia seguir em
frente: “Don’t Panic”.

RESUMO
RIBEIRO, Wellington Zanelli. Aplicação de boas práticas de segurança no

desenvolvimento de sistemas web. 2013. 56 f. Trabalho de Conclusão de
Curso (Tecnologia), Instituto Federal de São Paulo, São João da Boa Vista,
2013.
Com a popularização da internet, os sistemas web estão cada vez mais

presentes em nosso cotidiano. Juntamente com a expansão destes sistemas,
surgem os problemas de segurança relacionados a eles com maior frequência.
Este trabalho tem como objetivo fornecer um guia de boas práticas de
segurança no desenvolvimento de sistemas web, auxiliando desenvolvedores
durante e após o desenvolvimento. Foram exploradas, neste trabalho, as cinco
primeiras vulnerabilidades listadas no Top Ten de 2010 da OWASP. Foram
desenvolvidos dois sistemas web com as mesmas funcionalidades, porém
apenas um deles foi implementado de acordo com as boas práticas de
segurança sugeridas neste trabalho. Estes sistemas foram analisados e testados
utilizando algumas ferramentas específicas para cada uma das vulnerabilidades
abordadas e seguindo uma adaptação da metodologia de testes OSSTMM para
os sistemas web. As ferramentas adotadas para os testes atingiram devidamente
o seu objetivo e todas as vulnerabilidades foram demonstradas e tratadas.
Palavras-chave: Segurança. Desenvolvimento de Sistemas Web. Correções.

Vulnerabilidades.
ABSTRACT
RIBEIRO, Wellington Zanelli. Applying of security best practices in web

systems developments. In 2013. 56 f. Course Completion Study (Technology),
Instituto Federal de São Paulo, São João da Boa Vista, in 2013.
Due to the increasing of internet users, web systems have been more
present in daily routine of people. With the expansion of these systems,
security problems related to them appeared frequently. This work aims to
provide a guideline of security best practices to be applyied in web systems
development, supporting developers during and after the development process.
It was explored, in this work, the first five vulnerabilities listed in the Top Ten
of 2010 OWASP. Two web systems with the same features were developed,
but only one has been implemented according to the best security practices
suggested in proposed guideline. These systems were analyzed and tested using
some specific tools for each of the vulnerabilities discussed and following an
adaptation of the tests methodology OSSTMM for web systems. The tools used
in the tests properly reached their goal and all vulnerabilities were
demonstrated and treated.
Keywords: Security. Web systems development. Corrections. Vulnerabilities.

LISTA DE FIGURAS
Figura 1 - Estatísticas de ataques nos últimos 14 anos

disponibilizada pelo CERT ........................................................................ 22
Figura 2 - Média anual de vulnerabilidades críticas ................................................ 26
Figura 3 - SqlMap em execução .............................................................................. 44
Figura 4 - Tela inicial do WebScarab ...................................................................... 45
Figura 5 - Tela de requisições HTTP do CAL900 em execução ............................. 47
Figura 6 - Tela inicial do ZAP ................................................................................. 48
Figura 7 – Tela inicial do w3af. (Fonte: Elaboração do autor) ................................ 49
Figura 8 - Tipos de teste........................................................................................... 51
Figura 9 - Estratégia para verificar e corrigir vulnerabilidades de
segurança no desenvolvimento de sistemas web em uma
aplicação prática ......................................................................................... 53
Figura 10 - Estrutura de páginas dos sistemas elaborados ....................................... 56
Figura 11 - Diagrama estrutural do banco de dados ................................................ 57
Figura 12 - Página inicial das aplicações desenvolvidas ......................................... 58
Figura 13 - Parâmetro inicial do ZAP: Url to attack ............................................... 61
Figura 14 - Opção Fuzz no ZAP .............................................................................. 62
Figura 15 - Seleção de Fuzzers do ZAP ................................................................... 62
Figura 16 - Listagem de URLs que podem ser vulneráveis a XSS
pelo WebScarab .......................................................................................... 63
Figura 17 - Código de acesso ao banco de dados utilizando
consulta parametrizada ............................................................................... 67
Figura 18 - Código de acesso ao banco de dados concatenando
valores na consulta ..................................................................................... 68
Figura 19 - SqlMap realizando o dump do banco de dados da
aplicação vulnerável ................................................................................... 69
Figura 20 - SqlMap realizando testes na aplicação segura ...................................... 69
Figura 21 – Vulnerabilidades de injeção de SQL encontradas pela
ferramenta W3AF ....................................................................................... 70
Figura 22 - Resultado do escaneamento da vulnerabilidade de
Injeção realizado pela ferramenta W3AF ................................................... 70
Figura 23 – Validação automática do .NET ............................................................. 71
Figura 24 – Código adicional no arquivo web.config para evitar
as validações de requisições automáticas no .NET 4.5 .............................. 71
Figura 25 - Lista de caracteres reservados permitidos............................................. 72
Figura 26 - Lista de caracteres não reservados permitidos ...................................... 72
Figura 27 - Resultado do teste de XSS realizado na aplicação
vulnerável pelo ZAP .................................................................................. 72
Figura 28 - XSS em ação na aplicação vulnerável .................................................. 73
Figura 29 - Resultado do teste de XSS realizado na aplicação
segura pelo ZAP ......................................................................................... 73
Figura 30 - XSS encontrado pelo W3AF na aplicação vulnerável .......................... 74
Figura 31 - Resultado do escaneamento da aplicação segura
executado pelo W3AF................................................................................ 74
Figura 32 - URL com parâmetro malicioso criada pelo
WebScarab ................................................................................................. 75
Figura 33 - URL maliciosa gerada pelo WebScarab em execução ......................... 75
Figura 34 - Ataque XSS barrado na aplicação segura ............................................. 76
Figura 35 - Biblioteca de ataques XSS do CAL9000 .............................................. 77
Figura 36 - Cookie de autenticação da aplicação vulnerável .................................. 78
Figura 37 - Cookie de autenticação da aplicação segura ......................................... 78
Figura 38 - Acesso à página restrita sem realizar autenticação no
sistema vulnerável ...................................................................................... 79
Figura 39 - Validação de session no ASP.NET ....................................................... 79
Figura 40 - Validação de usuário autenticado na sessão ......................................... 80
Figura 41 - Validação do Anti-Forgery Token no ASP.NET .................................. 82
Figura 42 - Erro na validação do Anti-Forgery Token no
ASP.NET ................................................................................................... 82
Figura 43 - CSRF encontrado pelo W3AF .............................................................. 83
LISTA DE TABELAS
Tabela 1 - Lista das dez vulnerabilidades web mais críticas,

divulgada em 2010 pelo OWASP .............................................................. 22
Tabela 2 - Classificação básica da vulnerabilidade Injeção
(Injection) ................................................................................................... 32
Tabela 3 - Classificação básica da vulnerabilidade Scripting de
Site Cruzado (Cross-Site Scripting - XSS) ................................................ 33
Tabela 4 - Classificação básica da vulnerabilidade Autenticação e
Gerenciamento de Sessão Quebradas (Broken
Authentication and Session Management) ................................................. 36
Tabela 5 - Classificação básica da vulnerabilidade Referência
Insegura e Direta a Objetos (Insecure Direct Object
References) ................................................................................................. 37
Tabela 6 - Classificação básica da vulnerabilidade Falsificação de
Solicitação de Site Cruzado (Cross-Site Request Forgery
- CSRF) ...................................................................................................... 38
Tabela 7 - Classificação básica da vulnerabilidade de Má
Configuração de Segurança (Security Misconfiguration) .......................... 39
Tabela 8 - Classificação básica da vulnerabilidade de
Armazenamento Inseguro de Criptografia (Insecure
Cryptographic Storage).............................................................................. 40
Tabela 9 - Classificação básica da vulnerabilidade de Falha de
Restrição de Acesso à URL (Failure to Restrict URL
Access) ........................................................................................................ 41
Tabela 10 - Classificação básica da vulnerabilidade de Proteção
Insuficiente da Camada de Transporte (Insufficient
Transport Layer Protection) ...................................................................... 42
Tabela 11 - Classificação básica da vulnerabilidade de
Redirecionamentos e Encaminhamentos Não Validados
(Unvalidated Redirects and Forwards)...................................................... 43
Tabela 12 - Relação das vulnerabilidades e as ferramentas que
serão utilizadas para sua detecção e exploração ......................................... 55
LISTA DE QUADROS
Quadro 1 – Comandos do SqlMap para o dump do banco de
dados........................................................................................................... 60
Quadro 2 - Comando avançado no SqlMap ............................................................. 60
Quadro 3 - Criação de um Anti-Forgery Token no ASP.NET ................................. 81
LISTA DE SIGLAS
CSS Cascading Style Sheets (Folha de Estilos em Cascata)
DOM Document Object Model (Modelo Objeto de Documento)
HTTP Hypertext Transfer Protocol (Protocolo de Transferência
de Hipertexto)
HTTPS Hypertext Transfer Protocol Secure (Protocolo Seguro de
Transferência de Hipertexto)
IP Internet Protocol (Protocolo de Internet)
MD4 Message-Digest Algorithm 4th Generation (Algoritmo de
Mensagem de Sumário de 4ª Geração)
RFC Request for Comments (Pedido de Comentários)
SGBD Sistema de Gerenciamento de Banco de Dados
SHA1 Secure Hash Algorithm 1st Serie (Algoritmo de hash
seguro 1ª Série)
SQL Structured Query Language (Linguagem de Consulta
Estruturada)
SVN Apache Subversion
URL Universal Resource Locator (Localizador de Recursos
Universal)
SUMÁRIO
1 INTRODUÇÃO .......................................................................................................... 21
1.1 Motivação .............................................................................................................................. 23
1.2 Objetivos ............................................................................................................................... 23
1.3 Objetivos Específicos ............................................................................................................ 23
1.4 Organização deste trabalho.................................................................................................... 24
2 PESQUISA BIBLIOGRÁFICA ................................................................................... 25
2.1 Cenário Atual Sobre os Problemas de Segurança no Desenvolvimento
de Sistemas Web .......................................................................................................................... 26
2.2 Conceitos Básicos Sobre Segurança ...................................................................................... 27
2.3 Entidades e Normas Sobre Segurança Web .......................................................................... 29
2.3.1 ISO ..................................................................................................................................... 29
2.3.2 IEC ..................................................................................................................................... 29
2.3.3 ISO/IEC 27002 .................................................................................................................. 29
2.3.4 CERT.br ............................................................................................................................ 30
2.3.5 OWASP............................................................................................................................... 30
2.3.6 WhiteHat Security ............................................................................................................ 31
2.4 Vulnerabilidades de Segurança no Desenvolvimento de Sistemas Web ............................... 31
2.4.1 Injeção (Injection) ............................................................................................................. 32
2.4.2 Scripting de Site Cruzado (Cross-Site Scripting - XSS) .................................................. 33
2.4.2.1 XSS Refletido ................................................................................................................ 34
2.4.2.2 XSS Armazenado .......................................................................................................... 34
2.4.2.3 XSS Baseado em DOM ................................................................................................. 35
2.4.3 Autenticação e Gerenciamento de Sessão Quebradas (Broken
Authentication and Session Management) ................................................................................ 35
2.4.4 Referência Insegura e Direta a Objetos (Insecure Direct Object
References) .................................................................................................................................. 36
2.4.5 Falsificação de Solicitação de Site Cruzado (Cross-Site Request
Forgery - CSRF) .........................................................................................................................37
2.4.6 Má Configuração de Segurança (Security Misconfiguration)........................................38
2.4.7 Armazenamento Inseguro de Criptografia (Insecure
Cryptographic Storage) ...............................................................................................................39
2.4.8 Falha de Restrição de Acesso à URL (Failure to Restrict URL
Access) .........................................................................................................................................40
2.4.9 Proteção Insuficiente da Camada de Transporte (Insufficient
Transport Layer Protection) .......................................................................................................41
2.4.10 Redirecionamentos e Encaminhamentos Não Validados
(Unvalidated Redirects and Forwards).......................................................................................42
2.5 Ferramentas de Detecção de Vulnerabilidades ......................................................................43
2.5.1 SqlMap ...............................................................................................................................43
2.5.2 OWASP WebScarab .........................................................................................................44
2.5.3 OWASP CAL9000 ............................................................................................................46
2.5.4 OWASP Zed Attack Proxy Project (ZAP) .....................................................................47
2.5.5 W3AF - Web Application Attack and Audit Framework .............................................48
2.6 Teste das vulnerabilidades .....................................................................................................49
2.6.1 Metodologia dos testes ......................................................................................................50
2.6.2 Tipos de Teste ....................................................................................................................50
3 METODOLOGIA ....................................................................................................... 53
3.1 Objetivo .................................................................................................................................53
3.1.1 Escolher as Vulnerabilidades de Segurança no Desenvolvimento
de Sistemas Web .........................................................................................................................54
3.1.2 Definir as Ferramentas para Identificar cada Vulnerabilidade
Escolhida .....................................................................................................................................54
3.1.3 Apresentar Soluções para as Vulnerabilidades Identificadas.......................................55

3.1.4 Aplicar as Soluções Adotadas para Tratar as Vulnerabilidades em
um Experimento Prático ........................................................................................................... 55
3.1.5 Analisar os Resultados Obtidos da Aplicação no Experimento
Prático ......................................................................................................................................... 55
3.2 Estudo de caso - Sistemas...................................................................................................... 56
3.2.1 Estrutura dos sistemas...................................................................................................... 56
3.3 Testes ..................................................................................................................................... 58
3.3.1 Injeção (Injection) ............................................................................................................. 59
3.3.1.1 Teste com o SqlMap ...................................................................................................... 59
3.3.1.2 Teste com o W3AF ........................................................................................................ 60
3.3.2 Scripting de Site Cruzado (Cross-Site Scripting - XSS) .................................................. 60
3.3.2.1 Teste com o ZAP ........................................................................................................... 61
3.3.2.2 Teste com o W3AF ........................................................................................................ 63
3.3.2.3 Teste com o WebScarab ................................................................................................ 63
Authentication and Session Management) ................................................................................ 64
3.3.3.1 Teste com o W3AF ........................................................................................................ 64
References) .................................................................................................................................. 64
3.3.5 Falsificação de Solicitação de Site Cruzado (Cross-Site Request
Forgery - CSRF) ......................................................................................................................... 65
3.3.5.1 Teste com o W3AF ........................................................................................................ 65
4 RESULTADOS........................................................................................................... 67
4.1 Injeção (Injection) ................................................................................................................. 67
4.1.1 Resultados do SqlMap ...................................................................................................... 68
4.1.2 Resultados do W3AF ........................................................................................................ 70
4.2 Scripting de Site Cruzado (Cross-Site Scripting - XSS) ........................................................ 71
4.2.1 Resultados do ZAP............................................................................................................ 72

4.2.2 Resultados do W3AF ........................................................................................................73
4.2.3 Resultados do WebScarab ................................................................................................75
4.2.4 Aprofundamento com o CAL 9000 .................................................................................76
4.3 Autenticação e Gerenciamento de Sessão Quebradas (Broken
Authentication and Session Management) ...................................................................................77
4.4 Referência Insegura e Direta a Objetos (Insecure Direct Object
References) ...................................................................................................................................80
4.5 Falsificação de Solicitação de Site Cruzado (Cross-Site Request
Forgery - CSRF) ..........................................................................................................................81
5 CONCLUSÃO ............................................................................................................ 85
REFERÊNCIAS ............................................................................................................... 87
Capítulo
21
1 Introdução
Após o surgimento da internet foram desenvolvidos os primeiros sistemas baseados

nesta nova arquitetura. As páginas web, que antes eram somente estáticas, foram substituídas
por sistemas mais complexos, nos quais os usuários poderiam interagir na produção dos
conteúdos, seja através da publicação de vídeos ou interagindo em uma rede social.
Diante deste novo cenário, os denominados sites da “Web 2.0” possuem características
e funções similares a uma aplicação cliente-servidor tradicional, porém com um fator crítico
adicional: a aplicação agora não é mais executada em um ambiente controlado, mas sim em
um ambiente hostil, colocando em risco a segurança e confidencialidade das informações
(CAMPOS, SIGNORINI NETO E CANTO, 2010)
Após essa mudança de perspectiva no desenvolvimento de sistemas web, os usuários
mal intencionados têm explorado cada vez mais as vulnerabilidades destes sistemas. A Norma
ISO/IEC 27002 afirma que “danos causados por código malicioso, hackers e ataques de
denial of service estão se tornando cada vez mais comuns, mais ambiciosos e incrivelmente
mais sofisticados” (ISO/IEC 27002).
Em virtude desse crescente número de ataques, a principal dificuldade no
desenvolvimento de sistemas para web tem sido prover esta segurança, como proteger o
sistema em desenvolvimento da melhor maneira possível para que estes ataques não sejam
efetivos.
De acordo com estatísticas oficiais realizadas pelo CERTBR (Centro de Estudos,
Resposta e Tratamento de Incidentes de Segurança no Brasil), órgão responsável por tratar
incidentes de segurança em computadores que envolvam redes conectadas à Internet
brasileira, a exploração de vulnerabilidades nos sistemas web, de modo geral, aumentou cerca
de 7% de 2011 para 2012, como pode-se observar na Figura 1.
22
Figura 1 - Estatísticas de ataques nos últimos 14 anos disponibilizada pelo CERT

(Disponível em http://www.cert.br/stats/incidentes/, acesso em 10/03/2013)
O OWASP (The Open Web Application Security Project) mantém uma lista
chamada Top Ten, apresentada na Tabela 1, que representa um amplo consenso sobre as
falhas de segurança mais críticas das aplicações web.
Tabela 1 - Lista das dez vulnerabilidades web mais críticas, divulgada em 2010 pelo OWASP
Top Ten 2010 - OWASP
1 - Injeção (Injection)
2 - Scripting de Site Cruzado (Cross-Site Scripting - XSS)
3 - Autenticação e Gerenciamento de Sessão Quebrados (Broken Authentication and Session
Management)
4 - Referência de Objeto Direto Insegura (Insecure Direct Object References)
5 - Falsificação de Solicitação de Site Cruzado (Cross-Site Request Forgery - CSRF)
6 - Má Configuração de Segurança (Security Misconfiguration)
7- Armazenamento Inseguro de Criptografia (Insecure Cryptographic Storage)
8 - Falha de Restrição de Acesso à URL (Failure to Restrict URL Access)
9 - Proteção Insuficiente da Camada de Transporte (Insufficient Transport Layer Protection)
10 - Redirecionamentos e Encaminhamentos Não Validados (Unvalidated Redirects and Forwards)
(Adaptado de https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project, acesso em 10/03/2013)
Neste trabalho, serão abordadas as cinco primeiras falhas de segurança

apontadas pelo Top Ten de 2010 (mais recente na época da publicação deste trabalho) e
suas respectivas soluções. Esta lista pode ser observada na Tabela 1.
23
1.1 Motivação
A motivação para este trabalho vem justamente do crescente número de ataques

aos sistemas web, da ausência de uma segurança adequada e da falta de um guia de boas
práticas a ser aplicado no desenvolvimento destes sistemas.
Com o surgimento de novas tecnologias, muitos desenvolvedores passaram a se
preocupar menos com a questão de segurança, atribuindo demasiada confiança nas
tecnologias adotadas.
1.2 Objetivos
O objetivo deste trabalho de pesquisa é apresentar a aplicação de boas práticas

de segurança no desenvolvimento de sistemas web, visando auxiliar na melhora da
segurança destes sistemas propondo um guia de boas práticas a ser utilizado em seus
respectivos desenvolvimentos.
1.3 Objetivos Específicos
Seguem abaixo os passos mínimos e necessários para atingir o objetivo proposto

para esta pesquisa:
 Levantamento bibliográfico sobre: os principais conceitos relacionados à
segurança, os diferentes tipos de vulnerabilidades existentes e as
principais normas nacionais e internacionais inseridas no escopo deste
trabalho;
 Levantamento de ferramentas para automação de testes de segurança em
sistemas web, específicas para as vulnerabilidades a serem corrigidas
neste trabalho;
 Apresentação da aplicação prática de correção para as cinco principais
vulnerabilidades apontadas pela lista Top Ten da OWASP; e
 Análise dos resultados obtidos na aplicação prática e sugestão para
trabalhos futuros.
24
1.4 Organização deste trabalho
No Capítulo 2 serão apresentados diversos conceitos utilizados no decorrer

deste trabalho, dentre eles as normas brasileiras e internacionais sobre a segurança de
sistemas web, assim como a definição de cada uma das vulnerabilidades listadas no
Top Ten da OWASP.
No Capítulo 3 serão elaborados os testes a serem realizados nas aplicações,
assim como as ferramentas a serem utilizadas.
No Capítulo 4 será demonstrada a aplicação prática de correção para as cinco
primeiras vulnerabilidades listadas no Top Ten, de acordo com o resultado dos testes
definidos no Capítulo 3, sugerindo assim as boas práticas que devem ser adotadas no
desenvolvimento de sistemas para web.
O Capítulo 5 mostrará as conclusões sobre os resultados atingidos ao longo do
trabalho.
Capítulo
25
2 Pesquisa Bibliográfica
“A informação é um ativo que, como qualquer outro ativo importante, é

essencial para os negócios de uma organização e, consequentemente, necessita
ser adequadamente protegida. [...] Como um resultado deste incrivel aumento
da interconectvidade, a informação está agora exposta a um crescente número e
a uma grande variedade de ameaças e vulnerabilidades” (ISO/IEC 27002).
Ao desenvolver um sistema web, o programador deve conhecer as

vulnerabilidades que podem ameaçar seu sistema e em que fase do ciclo de vida do
desenvolvimento do software elas podem ser evitadas ou removidas, pois numa fase
posterior do desenvolvimento a remoção destas vulnerabilidades aumentará,
significamente, o custo deste sistema. Desenvolvedores devem incorporar a segurança em
seu software desde o início do seu desenvolvimento (WAGNER; MACHADO, 2010).
Diante deste contexto, este capítulo irá abordar os seguintes tópicos:
 O cenário atual sobre os problemas de segurança no desenvolvimento de sistemas

web;
 Alguns conceitos básicos sobre segurança e termos que serão frequentemente
utilizados no decorrer deste trabalho;
 Uma listagem das principais entidades e normas sobre segurança web;
 As principais vulnerabilidades de segurança no desenvolvimento de sistemas web;
 Algumas ferramentas de detecção de vulnerabilidades que serão utilizadas neste
trabalho; e
 Uma abordagem sobre alguns trabalhos relacionados com esta pesquisa.
26
2.1 Cenário Atual Sobre os Problemas de Segurança no Desenvolvimento

de Sistemas Web
As aplicações web estão em todos os lugares e em todos os setores. Praticamente

tudo está na internet, desde triviais blogs pessoais até aplicativos financeiros críticos para
uma empresa são construídos em algum tipo de aplicação web. Se queremos mover
nossas aplicações com segurança para a web, devemos ser capazes de testar estas
aplicações de maneira eficaz, pois hoje as aplicações web enfrentam a onipresente e
crescente ameaça à segurança causada pelos hackers, especialistas web mal intencionados
e criminosos de vários tipos (HOPE; WALTHER, 2009).
Como pode-se observar na Figura 2, extraída do Relatório de Estatísticas de
Segurança Web fornecido pela WhiteHat Security, em maio de 2013, a quantidade de
vulnerabilidades por sistema web tem caído bastante nos último anos. Em 2010, foram
encontradas em média 230 vulnerabilidades por site testado, contra 79 em 2011 e 56 em
2012. Vale ressaltar que neste relatório, fornecido pela WhiteHat Security, são
consideradas apenas vulnerabilidades críticas, que são definidas pela própria empresa
como sendo aquelas vulnerabilidades “em que o invasor poderá assumir o controle sobre
a totalidade ou uma parte de um site, comprometer contas de usuário, acessar dados
sensíveis ou violar os requisitos de conformidade” do site afetado (WHITEHAT
SECURITY, 2013).
Figura 2 - Média anual de vulnerabilidades críticas

(WhiteHat Security, 2013)
27
Mas enquanto a quantidade de vulnerabilidades por site tem caído nos últimos
anos, em contrapartida a quantidade de ataques reportados ao CERT tem aumentado
consideravelmente (vide Figura 1). Partindo deste princípio, torna-se evidente que as
medidas tomadas ainda não são suficientes, pois em muitos casos os programadores
tratam apenas algumas vulnerabilidades, deixando outras de lado. O OWASP, inclusive,
recomenda que os desenvolvedores web não parem no Top Ten, pois ainda há “centenas
de outros problemas que afetam a segurança de um sistema web” (OWASP, 2013).
2.2 Conceitos Básicos Sobre Segurança
Para entender um pouco melhor sobre como os ataques funcionam, faz-se

necessária uma breve introdução aos termos que serão frequentemente utilizados neste
trabalho:
 Algoritmo de disperção: Algoritmo utilizado para gerar uma tabela hash.
Normalmente utiliza conceitos matemáticos avançados para garantir que cada
registro inserido na tabela seja único (VANDIERENDONCK; DE BOSSCHERE,
2005);
 Ameaça: causa potencial de um incidente indesejado, que pode resultar em
dano para um sistema ou organização (NORMA ISO/IEC 27002, 2005, p.3);
 Atacante: o CERT define atacante como a pessoa responsável pela
realização de um ataque. O OWASP refina a definição para a web com o termo
“Internet Attacker” (Atacante de Internet) afirmando que é alguém com acesso
exclusivo pela internet a um aplicativo, que pode ter ou não relação com o alvo e
possuir diversas motivações para realizar o ataque, desde apenas provar que tem alto
nível de habilidade em atacar e invadir sistemas, até interesses financeiros;
 Ativo: qualquer item material ou imaterial que tenha valor para a
organização (NORMA ISO/IEC 27002, 2005, p.1);
 Blacklist: Lista de palavras ou caracteres não permitidos;
 Bug: segundo Sawaya (2002), o bug pode ser descrito como um erro,
defeito ou falha de funcionamento de um software ou hardware. No âmbito do
desenvolvimento de software, um bug pode ser explorado por um atacante, tornando-
se uma vulnerabilidade;
28
 Cookie: são pequenos arquivos que são gravados em seu computador

quando você acessa um determinado site na internet. Este mesmo arquivo é enviado ao
site que o gerou a cada acesso. São usados para manter informações sobre você, como
carrinho de compras, lista de produtos e preferências de navegação (CERT, 2013);
 Defacement: ou pichação, consiste em alterar o conteúdo de uma página,
desfigurando-a (CERT, 2013);
 Dump: é um programa utilizado para fazer backups de arquivos;
 Fuzzer: é um programa que injeta, automaticamente, dados semi-aleatórios
em uma aplicação com o objetivo de detectar bugs (OWASP, 2013);
 Hash: é uma sequência de bits geradas por um algoritmo de dispersão,
com o objetivo de identificar um arquivo, um dado ou até mesmo um endereço de
memória de maneira única. É uma técnica utilizada também nos processadores para
melhorar a performance das tabelas de previsão e do cache (VANDIERENDONCK;
DE BOSSCHERE, 2005);
 Incidente de Segurança: é definido pelo CERT como qualquer evento
adverso, confirmado ou sob suspeita, relacionado à segurança de sistemas de
computação ou de redes de computadores (CERT, 2013);
 Malware: são programas especificamente desenvolvidos para executar
ações danosas e atividades maliciosas em um computador. No contexto deste trabalho,
este termo estará se referindo aos malwares que infectam um computador pelo acesso
a páginas Web maliciosas, utilizando navegadores vulneráveis (CERT, 2013);
 Phishing: também conhecido como phishing-scam ou simplesmente scam,
é o tipo de fraude em que o atacante tenta obter dados pessoais e financeiros de um
usuário, pela utilização combinada de meios técnicos e engenharia social;
 Risco: combinação da probabilidade de um evento e de suas consequências
(NORMA ISO/IEC 27002, 2005, p.2);
 Spider: é uma ferramenta utilizada para descobrir automaticamente novas
URLs (Universal Resource Locator) em um site qualquer (OWASP, 2013);
 Teste de Penetração: teste de eficiência das defesas de segurança, consiste
em realizar ações no sistema a ser testado como os atacantes reais fariam; e
 Vulnerabilidade: a norma ISO/IEC 27002 diz que vulnerabilidade é a
fragilidade de um ativo ou grupo de ativos que pode ser explorada por uma ou mais
29
ameaças. Já a OWASP leva a definição mais para o lado do desenvolvimento de

software e afirma que vulnerabilidade “é uma abertura ou uma falha no aplicativo, que
pode ser uma falha de projeto ou um bug de implementação, permitindo a um atacante
causar danos aos stakeholders de um aplicativo”;
 Whitelist: Lista de palavras ou caracteres permitidos.
2.3 Entidades e Normas Sobre Segurança Web
No contexto de desenvolvimento de software, existem várias entidades

preocupadas em estabelecer padrões e normalizações sobre a aplicação da segurança. Este
trabalho abordará algumas normas e recomendações internacionais aplicadas por estas
entidades e, neste capítulo, apresenta-se um pouco mais delas, suas normatizações e
recomendações.
2.3.1 ISO
A ISO (International Organization for Standardization ou Organização
Internacional para Normatização em tradução livre) é uma organização independente e
não governamental constituída por membros de 163 países. Foi fundada em 1947, em
Genebra, na Suíça e já publicou mais de 19.500 normas de padronização internacionais,
cobrindo praticamente todos os aspectos da tecnologia e negócios. É a maior
desenvolvedora do mundo de Padrões Internacionais. No Brasil é representada pela
ABNT, Associação Brasileira de Normas Técnicas (ISO, 2013).
2.3.2 IEC
A IEC (International Electrotechnical Commission ou Comissão Internacional
Eletrotécnica em tradução livre) é uma organização sem fins lucrativos e não
governamental, fundada em 1906, em Londres.
Atua, juntamente com a ISO, auxiliando e implementando as normatizações
relacionadas à área específica de padrões elétricos e eletrônicos (IEC, 2013).
2.3.3 ISO/IEC 27002

A ISO em parceria com a IEC elaborou, em 2005, a norma internacional 17799
chamada “Tecnologia da informação - Técnicas de segurança - Código de prática para a
30
gestão da segurança da informação” que, em 2007, teve sua numeração atualizada para a
27002.
A norma 27002 provê conselhos e recomendações para gestão da segurança da
informação e tem como público alvo aqueles que são responsáveis pela introdução,
implementação ou manutenção da segurança em suas organizações (ISO/IEC 27002,
2005).
Este trabalho se utilizará, principalmente, das recomendações fornecidas pelo
Capítulo 12 da norma 27002, pois é o capítulo em que ela se aprofunda no
desenvolvimento e manutenção de sistemas de informação, tendo como foco a
segurança destes sistemas.
2.3.4 CERT.br
O CERT.br (Centro de Estudos, Resposta e Tratamento de Incidentes de
Segurança no Brasil) é um grupo que atua como um ponto central para notificações de
incidentes de segurança no Brasil, provendo a coordenação e o apoio no processo de
resposta a incidentes, além de também atuar no trabalho de conscientização sobre os
problemas de segurança, da análise de tendências e correlação entre eventos na Internet
brasileira. É mantido pelo NIC.br (Núcleo de Informação e Coordenação do Ponto BR)
do Comitê Gestor da Internet no Brasil (CERT BR, 2013).
Este grupo, além de fornecer cartilhas de orientação sobre a utilização segura da
internet, mantém estatísticas sobre incidentes de segurança e spams sempre atualizadas.
É válido citar que as notificações enviadas à este grupo são voluntárias, portanto não
correspondem à 100% de todos os incidentes que ocorrem no Brasil.
2.3.5 OWASP
O OWASP (The Open Web Application Security Project) é uma entidade, sem
fins lucrativos e de reconhecimento internacional, que contribui para a melhoria da
segurança de software e aplicativos, reunindo informações importantes que permitem
avaliar riscos de segurança e combater formas de ataques através da internet.
Foi estabelecida em 2001 e sua missão é tornar a segurança de software visível
para que indivíduos e organizações possam tomar decisões conscientes sobre os
verdadeiros riscos do software.
31
Este trabalho contribui com a comunidade de desenvolvedores fornecendo

manuais, artigos e vídeos, além de oferecer projetos de testes de segurança, treinamento e
aprendizado (OWASP, 2013).
2.3.6 WhiteHat Security

Com sede em Santa Clara - Califórnia, a WhiteHat Security foi fundada em 2001
e oferece as soluções de segurança para sistemas web, com foco em evitar a perda de
dados.
A WhiteHat Security fornece uma plataforma paga, baseada em nuvem, para
monitorar e prevenir ataques aos sistemas web de seus clientes, além de fornecer
estatísticas de reconhecimento internacional sobre o monitoramento destes sistemas,
exibindo a média de vulnerabilidades encontradas por sistema e informando quais
vulnerabilidades são mais encontradas, entre outros dados (WHITEHAT, 2013).
2.4 Vulnerabilidades de Segurança no Desenvolvimento de Sistemas Web
Segundo a OWASP, atacantes podem potencialmente usar muitos caminhos

diferentes para atacar ou invadir uma aplicação. Cada um destes caminhos representam
um risco, que pode ou não, ser grave o suficiente para justificar sua atenção. Estes
caminhos podem ser, em alguns casos, triviais para se encontrar e explorar, mas em
outros casos, podem ser extremamente difíceis (OWASP, 2013).
O Top Ten do OWASP tem o foco em identificar os riscos mais graves para uma
ampla gama de organizações. Para cada um desses riscos, foram fornecidas informações
genéricas sobre facilidade de exploração, predomínio, detecção e impacto técnico usando
um esquema de classificação simples (OWASP, 2013).
Neste trabalho, esta classificação foi convertida para o formato tabular facilitando
assim sua visualização e identificação.
A seguir, detalham-se as definições de cada uma das dez vulnerabilidades
abordadas pelo Top Ten de 2010 da OWASP apresentadas na Tabela 1.
32
2.4.1 Injeção (Injection)

As falhas de Injection ocorrem quando dados não confiáveis são enviados para o
servidor como parte de um comando ou consulta. Estes dados contém scripts SQL
(Structured Query Language) que enganam o servidor com a intenção que ele execute
comandos não desejáveis ou permita o acesso a dados não autorizados (OWASP, 2013).
Esta vulnerabilidade consiste, basicamente, em inserir comandos SQL em campos
de formulários ou até mesmo na URL de uma aplicação. Uto e Melo (2009, p. 254)
afirmam que uma vez que este ataque seja realizado com sucesso, o atacante consegue
realizar qualquer operação no banco de dados, tendo como único limite os privilégios da
conta que realiza o acesso ao banco e que, como frequentemente os programadores
utilizam-se de contas com privilégios administrativos, com um pouco mais de elaboração
pode-se aproveitar dos mecanismos de interação com o sistema operacional existentes nos
SGBDs (Sistema de Gerenciamento de Banco de Dados) para leitura e escrita de
arquivos, além da execução de comandos arbitrários.
Segundo Lin, Chen e Liu (2008) esta vulnerabilidade acontece por falta de senso
de segurança do programador, e ainda alertam para a possibilidade do atacante inserir
código hostil na aplicação, que pode ser utilizado, inclusive, para a futura execução de
ataques mais elaborados, tais como o XSS (Cross-Site Scripting).
Esta vulnerabilidade é considerada pelo OWASP como sendo de fácil exploração
e de impacto severo, pois o sistema atacado pode sofrer várias consequências que vão
desde a corrupção ou perca dos dados, inserção de conteúdo não autorizado em sua base
de dados até o controle total da aplicação pelo atacante.
A Tabela 2 apresenta um resumo sobre a classificação de risco desta
vulnerabilidade.
Tabela 2 - Classificação básica da vulnerabilidade Injeção (Injection)
Injeção (Injection)
Facilidade de Exploração Fácil
Predomínio Comum
Detecção Média
Impacto Severo
Fonte: OWASP (2010)

33
2.4.2 Scripting de Site Cruzado (Cross-Site Scripting - XSS)

As falhas XSS ocorrem sempre que uma aplicação recebe dados não confiáveis e
os envia para um navegador Web sem que os tenha validado ou filtrado
convenientemente. O XSS permite que os atacantes executem scripts no navegador da
vítima, que podem ser utilizados para sequestrar informações da sessão do utilizador ou
redirecionar o utilizador para endereços maliciosos (OWASP, 2013).
Ainda de acordo com o OWASP, o XSS é um dos riscos mais recorrentes no
contexto das falhas de segurança em aplicações web e ocorre quando a aplicação exibe os
dados fornecidos pelo usuário na página web da mesma maneira que o usuário digitou,
sem que haja alguma validação ou filtragem prévia nestes dados.
Ao conseguir realizar um ataque XSS com sucesso, o atacante tem a possibilidade
de executar scripts e inserir conteúdo diretamente no navegador web da vítima,
redirecionando-a para outra página ou até mesmo “sequestrar o navegador” da vítima,
roubando sua sessão.
O OWASP considera esta vulnerabilidade como sendo de média dificuldade de
exploração e impacto moderado. Descobrir falhas XSS é razoavelmente fácil e pode ser
feita através de testes ou análise do código fonte.
Na edição de 2013 do relatório de vulnerabilidades da WhiteHat Security, 53%
dos sites monitorados apresentaram esta vulnerabilidade.
vulnerabilidade.
Tabela 3 - Classificação básica da vulnerabilidade Scripting de Site Cruzado (Cross-Site Scripting - XSS)
Scripting de Site Cruzado (Cross-Site

Scripting - XSS)
Facilidade de Exploração Média
Predomínio Generalizada
Detecção Fácil
Impacto Moderado
Fonte: OWASP (2010)
O OWASP ainda divide as falhas de XSS em três categorias distintas:

Armazenada, Refletida e baseadas em DOM (Document Object Model), enquanto alguns
autores, como Kieyzun et al. (2009), consideram apenas as duas primeiras categorias.
34
Apresenta-se a seguir um detalhamentos destas categorias.
2.4.2.1 XSS Refletido
Também conhecido por XSS de primeira ordem ou XSS de tipo 1 (KIEYZUN et

al., 2009), são aqueles em que o código injetado é refletido para fora do servidor afetado,
como por exemplo um link de confirmação em uma mensagem de erro, um link falso em
um resultado de pesquisa ou em qualquer outra resposta enviada do servidor que inclua
alguma parte ou todo o código malicioso que foi enviado para o servidor como parte da
requisição (OWASP, 2013).
Neste tipo de ataque, o atacante precisa utilizar engenharia social para convencer a
vítima a clicar em um link falso que contenha código HTML ou JavaScript malicioso.
Este link pode chegar até a vítima por e-mail ou até mesmo por outros sites que podem
ser falsos ou também já terem sido invadidos pelo atacante (KIEYZUN et al., 2009).
2.4.2.2 XSS Armazenado
Também conhecido por XSS de segunda ordem ou XSS de tipo 2 (KIEYZUN et

al., 2009) são aqueles em que o código injetado é permanentemente armazenado no
servidor de banco de dados da aplicação alvo. Normalmente, é encontrado em fóruns
onde usuários podem postar ou deixar comentários e em sistemas com registro de
visitantes e campo de comentários (OWASP, 2013).
É considerado mais prejudicial para a aplicação atacada do que o XSS refletido
por dois motivos:
1. O atacante pode se aproveitar da vulnerabilidade de SQL Injection,
inserindo o código malicioso diretamente na página, sem a necessidade de
utilizar engenharia social para enganar o usuário, forçando-o a clicar em
um link falso (KIEYZUN et al., 2009); e
2. Um único script malicioso, inserido apenas uma vez no banco de dados de
uma aplicação, pode ser executado inúmeras vezes, em vários
navegadores, dependendo da quantidade de visualizações da página
afetada (KIEYZUN et al., 2009).
35
2.4.2.3 XSS Baseado em DOM
Também conhecido por XSS de tipo 0, é um ataque que consiste em alterar o

ambiente DOM da página carregada no navegador da vítima em tempo de execução,
fazendo com que ela acesse uma versão alterada desta página. Por este motivo, este tipo
de XSS difere-se dos tipos 1 e 2, que já trazem a página de resposta alterada diretamente
do servidor, alterando-a em tempo de execução (OWASP, 2013).
Neste tipo de ataque é possível manipular qualquer elemento HTML da página
carregada mesmo sem ter acesso direto àquela área, como por exemplo, a URL dos links
da página ou então as propriedades CSS (Cascading Style Sheets), caracterizando o
defacement da página.

Authentication and Session Management)
Esta vulnerabilidade permite que os atacantes se utilizem de falhas ou brechas nas
funções de autenticação e gerenciamento de sessões, como por exemplo utilizar senhas e
identificadores de sessão para se passarem por outros usuários (OWASP, 2013).
Muitas aplicações web utilizam o gerenciamento de sessões para acompanhar as
atividades dos visitantes sobre protocolos stateless como o HTTP (Hypertext Transfer
Protocol). As sessões são associadas a um usuário específico em uma determinada
aplicação web. As sessões podem conter várias informações sobre as ações do usuário em
uma aplicação como, por exemplo, seu status de login, a URL da última página visitada
ou um histórico de compras (TAKAMATSU; KOSUGA; KONO, 2012).
A implementação das funções relacionadas a autenticação e gerenciamento de
sessões são relativamente difíceis de serem implementadas de forma correta, partindo do
ponto de vista da segurança. Desta forma, os atacantes podem até explorar outras falhas
na implementação do sistema que ele não teria acesso sem antes assumir a identidade de
outro utilizador (OWASP, 2013).
O OWASP ressalta que as principais áreas que comumente apresentam este tipo
de vulnerabilidade são as funções de encerramento de sessão, gerenciamento de senhas,
timeout das sessões, funções de “lembrar-me” ou “continuar conectado”, perguntas
secretas, entre outros. Encontrar e identificar estas falhas pode ser, na maioria dos casos
difícil, uma vez que cada implementação tem as suas próprias características.
36
Estas falhas podem permitir que algumas ou até mesmo todas as contas sejam
atacadas, mas geralmente as contas com maiores privilégios são os alvos preferidos.
Quando este ataque é bem sucedido, é possível ter acesso às mesmas áreas e
funcionalidades que a vítima teria no sistema.
vulnerabilidade.
Tabela 4 - Classificação básica da vulnerabilidade Autenticação e Gerenciamento de Sessão Quebradas (Broken

Autenticação e Gerenciamento de Sessão Quebrados

(Broken Authentication and Session Management)
Predomínio Comum
Detecção Média
Impacto Severo
Fonte: OWASP (2010)

References)
Uma referência direta a um objeto ocorre quando o programador expõe uma
referência para um objeto de implementação interno, como: um arquivo, um diretório ou
senha de uma base de dados. Sem uma verificação de controle de acesso ou outra
proteção semelhante, os atacantes podem manipular estas referências para acessar
informações não autorizadas. Para explorar esta vulnerabilidade, o atacante, que por sua
vez é um usuário autorizado do sistema, simplesmente altera o valor de um parâmetro que
se refere diretamente a um objeto do sistema para um outro que ele não deveria ter acesso
(OWASP, 2013).
O OWASP afirma que as aplicações usam, frequentemente, o nome real ou a
identificação de um objeto quando geram as páginas mas nem sempre verificam se o
usuário está autorizado para acessar o objeto alvo. Neste caso, teremos a falha de
Referência Insegura e Direta a Objetos.
Efetuando simples testes manipulando os valores dos parâmetros, pode-se detectar
estas falhas e, com uma breve análise de código, é possível verificar se a autorização de
acesso está aplicada de forma efetiva neste objeto.
37
De acordo com Fung, Cheung e Wong (2012), os programadores ao

desenvolverem suas aplicações tem uma concepção errônea de que os parâmetros
expostos ao cliente-side (lado do cliente) são imutáveis, e com isso não se preocupam em
efetivamente em checar os parâmetros recebidos no servidor e, nestes casos, as validações
quando existem, são feitas apenas com JavaScript deixando a aplicação vulnerável.
vulnerabilidade.
Tabela 5 - Classificação básica da vulnerabilidade Referência Insegura e Direta a Objetos (Insecure Direct Object
References)
Referência Insegura e Direta a Objetos

(Insecure Direct Object References)
Predomínio Comum
Detecção Fácil
Impacto Moderado
Fonte: OWASP (2010)
2.4.5 Falsificação de Solicitação de Site Cruzado (Cross-Site Request Forgery

- CSRF)
O ataque CSRF, também conhecido como ataque de um clique ou session riding
(CHEN et al., 2011), força o navegador da vítima que esteja com uma sessão ativa, a
enviar uma requisição HTTP falsa, incluindo o cookie e outras informações da sessão,
como por exemplo a informação de autenticação para uma aplicação web vulnerável. Esta
falha permite ao atacante forçar o navegador da vítima a criar pedidos que a aplicação
vulnerável aceita como pedidos legítimos oriundos da vítima (OWASP, 2013).
O ataque consiste em criar requisições HTTP falsas e induzir a vítima a submeter
esses pedidos através de tags HTML, XSS entre outras técnicas (OWASP, 2013).
O CSRF aproveita-se de aplicações web que permitem que os atacantes prevejam
todos os detalhes de uma determinada ação. Uma vez que os navegadores web enviam
automaticamente credenciais como cookies de sessão, os atacantes podem gerar páginas
web maliciosas que geram pedidos falsos, idênticos aos pedidos legítimos. O OWASP
38
ainda afirma que a detecção de falhas de CSRF é razoavelmente fácil de se realizar, por
meio de testes de penetração ou através de análises do código fonte.
As consequências de um ataque CSRF podem variar de acordo com os privilégios
de acesso do sistema que a vítima possui, e tratando-se de uma vulnerabilidade comum os
desenvolvedores devem ter uma atenção e nunca acreditar que qualquer requisição
enviada ao servidor reflete a intenção de um usuário legítimo (CHEN et al., 2011).
vulnerabilidade.
Tabela 6 - Classificação básica da vulnerabilidade Falsificação de Solicitação de Site Cruzado (Cross-Site Request
Forgery - CSRF)
Falsificação de Solicitação de Site Cruzado

(Cross-Site Request Forgery - CSRF)
Predomínio Comum
Detecção Fácil
Impacto Moderado
Fonte: OWASP (2010)
2.4.6 Má Configuração de Segurança (Security Misconfiguration)

A segurança da aplicação depende, além da existência de configurações seguras
definidas e usadas na aplicação, de frameworks, servidor web, servidor do banco de dados
e plataforma de desenvolvimento. Estas configurações devem ser definidas,
implementadas e mantidas, como também possuir todo o software atualizado, o que inclui
todas as bibliotecas de código fonte usadas pela aplicação (OWASP, 2013).
Quando esta vulnerabilidade ocorre, O OWASP afirma que o atacante pode
efetuar o acesso a contas padrão, páginas não utilizadas que ainda estejam no servidor, se
aproveitar de falhas de segurança não corrigidas e visualizar arquivos e diretórios não
protegidos. Com isso, ele consegue obter acesso não autorizado a áreas restritas do
sistema e obter conhecimento sobre outras áreas do sistema.
Uma má configuração de segurança pode ocorrer em qualquer nível da pilha da
aplicação e, os programadores e administradores de rede, devem trabalhar em conjunto
para assegurar que a aplicação esteja configurada corretamente. A utilização de
39
ferramentas automáticas de escaneamento são muito úteis e recomendadas para auxiliar

na detecção de correções e atualizações de segurança.
Corrigir este problema, no entanto, pode ser um pouco complexo, pois as
configurações variam de acordo com os sistemas instalados no servidor, contendo
configurações específicas variando desde o sistema operacional, até o servidor web e de
banco de dados.
A
Tabela 7 apresenta um resumo sobre a classificação de risco desta vulnerabilidade.
Tabela 7 - Classificação básica da vulnerabilidade de Má Configuração de Segurança (Security Misconfiguration)
Má Configuração de Segurança
(Security Misconfiguration)
Predomínio Comum
Detecção Fácil
Impacto Moderado
Fonte: OWASP (2010)
2.4.7 Armazenamento Inseguro de Criptografia (Insecure Cryptographic

Storage)
Muitas aplicações web não protegem devidamente dados confidenciais que são
armazenados em suas bases de dados. Assim, os atacantes conseguem roubar ou
modificar estes dados com a finalidade de realizar diversos crimes (OWASP, 2013).
Neste tipo de vulnerabilidade, os atacantes não procuram quebrar a
criptografia, mas sim quebrar outros elementos, tais como as chaves criptográficas. O
OWASP afirma também, que eles podem obter cópias legíveis dos dados, caso não haja
criptografia, ou tentar acessá-los através de canais que quebram a criptografia
automaticamente.
A falha mais comum desta área é o simples fato de não criptografar os dados
que necessitam de criptografia e, mesmo assim, quando se utiliza de criptografia é
comum descobrir que a chave criptográfica não está segura e que a rotatividade destas
chaves não acontece, além da frequente utilização de algoritmos fracos.
Os atacantes externos enfrentam muitas dificuldades para detectar estas falhas
justamente por seu acesso limitado ao sistema. Nestas situações, eles procuram explorar
40
outras vulnerabilidades do sistema e obter o nível de acesso desejado, para em seguida,

ter acesso a esses dados (OWASP, 2013).
O OWASP afirma que quando este ataque é bem sucedido, todos os dados que
deveriam ser criptografados ficam comprometidos. Estes dados, na maioria dos casos,
contém informações sensíveis, como dados pessoais, cartões de crédito, entre outros, o
que permite que o atacante cometa vários tipos de fraude.
vulnerabilidade.
Tabela 8 - Classificação básica da vulnerabilidade de Armazenamento Inseguro de Criptografia (Insecure

Cryptographic Storage)
Armazenamento Inseguro de Criptografia

(Insecure Cryptographic Storage)
Facilidade de Exploração Difícil
Predomínio Incomum
Detecção Difícil
Impacto Severo
Fonte: OWASP (2010)
2.4.8 Falha de Restrição de Acesso à URL (Failure to Restrict URL Access)

A maioria das aplicações web verificam os privilégios de acesso de uma URL
antes de exibir links e botões com funções que exigem um nível elevado de privilégios.
Mesmo assim, as aplicações devem realizar validações de controle de acesso similares
cada vez que as páginas são carregadas. Caso estas validações não sejam realizadas, os
atacantes podem forjar URLs e acessar estas páginas, sem qualquer restrição, constituindo
assim a falha de restrição de acesso à URL (OWASP, 2013).
O OWASP diz que partindo do caso em que o atacante é um utilizador autorizado
do sistema, ele pode facilmente alterar a URL atual para uma outra, com privilégios
administrativos, por exemplo. O mesmo pode acontecer com usuários anônimos quando
estes conseguem acessar páginas restritas sem ao menos estar autenticado no sistema.
Algumas aplicações não protegem corretamente as requisições às páginas do
sistema e, muitas vezes, esta proteção é gerenciada por painéis de configuração que
podem facilmente estar mal configurados ou até mesmo não permitir o detalhamento do
nível de controle para as páginas. Podem existir casos em que os programadores podem
se esquecer de inserir as validações adequadas no código (OWASP, 2013).
41
A detecção desta vulnerabilidade é relativamente fácil, pois acaba sendo difícil

identificar quais páginas estão vulneráveis a este tipo de ataque.
Quando esta vulnerabilidade é explorada com sucesso, os atacantes acessam
funcionalidades não autorizadas, como por exemplo as páginas administrativas da
aplicação (OWASP, 2013).
vulnerabilidade.
Tabela 9 - Classificação básica da vulnerabilidade de Falha de Restrição de Acesso à URL (Failure to Restrict
URL Access)
Falha de Restrição de Acesso à URL

(Failure to Restrict URL Access)
Predomínio Incomum
Detecção Média
Impacto Moderado
Fonte: OWASP (2010)
2.4.9 Proteção Insuficiente da Camada de Transporte (Insufficient Transport

Layer Protection)
As aplicações, frequentemente, possuem falhas na configuração de autenticação,

encriptação, proteção da confidencialidade e integridade do dados sensíveis que trafegam
pela rede. Quando as aplicações possuem estas configurações, muitas vezes, utilizam
algoritmos fracos e usam certificados inválidos ou expirados. Monitorar o tráfego dos
utilizadores na rede pode ser difícil, e a principal dificuldade está no monitoramento do
tráfego de rede quando os usuários acessam o endereço vulnerável (OWASP, 2013).
Esta vulnerabilidade ocorre quando as aplicações utilizam SSL/TLS (Secure
Sockets Layer/Transport Layer Security) durante a autenticação, mas não no restante do
sistema, expondo dados e IDs de sessão a uma possível intercessão, além do uso de
certificados mal configurados ou expirados (OWASP, 2013).
Detectar falhas básicas é fácil, basta observar o tráfego de rede do endereço.
Falhas mais sutis requerem inspeção da arquitetura da aplicação e da configuração do
servidor.
42
Quando explorada com sucesso, esta falha expõe os dados dos usuários, que
podem originar roubos de contas. Se uma conta administrativa for comprometida, todo o
endereço pode ficar exposto. As más configurações do SSL podem também facilitar
ataques de MITM (Man In The Middle) e phishing (OWASP, 2013).
vulnerabilidade.
Tabela 10 - Classificação básica da vulnerabilidade de Proteção Insuficiente da Camada de Transporte

(Insufficient Transport Layer Protection)
Proteção Insuficiente da Camada de Transporte

(Insufficient Transport Layer Protection)
Facilidade de Exploração Difícil
Predomínio Comum
Detecção Fácil
Impacto Moderado
Fonte: OWASP (2010)
2.4.10 Redirecionamentos e Encaminhamentos Não Validados (Unvalidated

Redirects and Forwards)
As aplicações Web, frequentemente, redirecionam e encaminham os usuários para
outras páginas e sites web, usando dados não confiáveis para determinar as páginas de
destino. Sem uma validação adequada, os atacantes podem redirecionar as vítimas para
sites de phishing ou de malware ou ainda usar o redirecionamento para acessar páginas
não autorizadas (OWASP, 2013).
Esta vulnerabilidade ocorre quando os atacantes conseguem alterar um
redirecionamento ou link de algum sistema, enganando as vítimas que clicarem neste link.
As vítimas estão mais propensas a acessar um link quando ele aponta para um endereço
válido e verdadeiro (OWASP, 2013).
As aplicações redirecionam os usuários para outras páginas ou utilizam
encaminhamentos internos de uma maneira similar. Muitas vezes, a página destino é
especificada através de um parâmetro que não é validado, permitindo que um atacante
possa escolher a página de destino (OWASP, 2013).
43
A detecção de redirecionamentos que não são validados é simples, basta procurar

por redirecionamentos onde pode-se definir a URL completa. Os redirecionamentos não
validados são mais difíceis, uma vez que eles possuem, como alvo, páginas internas.
Quando este ataque é realizado com sucesso, é possível a instalação de malwares,
além de tentar enganar as vítimas com o objetivo de descobrir senhas ou outras
informações sensíveis (OWASP, 2013).
vulnerabilidade.
Tabela 11 - Classificação básica da vulnerabilidade de Redirecionamentos e Encaminhamentos Não Validados

(Unvalidated Redirects and Forwards)
Redirecionamentos e Encaminhamentos Não

Validados (Unvalidated Redirects and Forwards)
Predomínio Incomum
Detecção Fácil
Impacto Moderado
Fonte: OWASP (2010)
2.5 Ferramentas de Detecção de Vulnerabilidades
Neste tópico, serão abordadas as principais ferramentas para automação de testes

de segurança em sistemas web e que serão utilizadas em nossa metodologia para detectar
e avaliar a efetividade das correções e prevenções das vulnerabilidades aplicadas.
2.5.1 SqlMap
A SqlMap é uma ferramenta de teste de penetração gratuita e de código aberto que
automatiza o processo de detecção e exploração de falhas de injeção SQL. Conta com um
poderoso mecanismo de detecção, possui diversas configurações para realizar os testes de
penetração, além de possuir recursos de identificação do banco de dados a partir dos
dados recebidos (SQLMAP, 2013).
Dentre suas principais funcionalidades destacam-se:
 Suporte completo para todos os SGBDs modernos, incluindo MySQL,
Oracle, PostgreeSQL, SQL Server e SQLite;
44
 Suporte para dump completo das tabelas de um SGBD;

 Suporte para execução de comandos arbitrários e recuperação da saída
padrão no servidor do sistema operacional quando SGBD for MySQL, PostgreSQL ou
Microsoft SQL Server; e
 Reconhecimento automático de padrões de hash e suporte para quebrá-los
usando um ataque baseado em dicionário.
Na Figura 3, pode-se observar o SqlMap em execução, com um destaque para as
informações obtidas sobre o SGBD, o sistema operacional hospedeiro e a tecnologia
utilizada no desenvolvimento da aplicação.
Figura 3 - SqlMap em execução
2.5.2 OWASP WebScarab

É um framework open source desenvolvido em Java e disponibilizado
gratuitamente pelo OWASP para testar a segurança de aplicações web. Esta ferramenta
tem como objetivo analisar aplicativos que utilizam os protocolos HTTP e HTTPS
(Hypertext Transfer Protocol Secure). É uma ferramenta de proxy que intercepta as
requisições, permitindo analisar e modificar as requisições HTTP tanto quando criadas
pelo navegador, antes de serem enviadas, quantos as requisições recebidas do servidor,
antes do navegador recebê-las (OWASP, 2013).
45
A única configuração necessária para a utilização básica do WebScarab é o proxy

do navegador que será utilizado, que deve ser alterado para utilizar o IP (Internet
Protocol) 127.0.0.1 e a porta 8008.
Na Figura 4 pode-se observar a tela inicial do WebScarab sendo executado no
sistema operacional Kali Linux 1.0.3, onde pode-se observar que durante a navegação
web ele lista todas as requisições HTTP realizadas pelo navegador, informando sobre a
requisição, além de executar alguns testes identificando pontos passíveis de
vulnerabilidades.
Figura 4 - Tela inicial do WebScarab
2.5.3 OWASP CAL9000

O CAL9000 (Figura 5) é uma coleção de ferramentas de testes de segurança de
aplicações web open source e é disponibilizado gratuitamente pelo OWASP. Ela foi
46
escrita em JavaScript, o que possibilita o acesso completo ao código fonte (OWASP,

2013).
O OWASP ainda diz que esta coleção foi “propositalmente concebida para fazer
algumas coisas terrivelmente inseguras” e encoraja seu uso somente em ambientes
controlados e nunca em um servidor (OWASP, 2013).
Entre os seus principais recursos destacam-se:
 Ataques XSS: uma lista pré-configurada de ataques XSS que pode ser
configurada para a utilização em um navegador específico, aplicar filtros por
expressão regular, além da possibilidade de inclusão de seus próprios scripts de
ataque;
 Codificador e Decodificador de Caracteres: trabalha com as mais diversas
codificações de caracteres, entre elas: URL, Hex, Unicode, Html, Javascript
Escaped, XML Escaped, entre outros. Pode apenas codificar para MD4 (Message-
Digest Algorithm 4th Generation) e SHA1 (Secure Hash Algorithm 1st Serie);
 Requisições HTTP: possibilita criar e enviar manualmente solicitações
HTTP para os servidores, além de poder lançar ataques automáticos com mais de
um pedido por vez; e
 Respostas HTTP: permite a visualização dos códigos de status da
requisição e todo o seu conteúdo. Separa a resposta em script, formulários e
cookies.
Na Figura 5 pode-se observar a tela da ferramenta de requisições HTTP do
CAL9000.
47
Figura 5 - Tela de requisições HTTP do CAL900 em execução

(OWASP, 2013)
2.5.4 OWASP Zed Attack Proxy Project (ZAP)

O ZAP é uma ferramenta integrada para testes de penetração open source, foi
desenvolvida em Java e é disponibilizada gratuitamente pelo OWASP. Seu principal
objetivo é encontrar vulnerabilidades em aplicações web. Foi projetada para ser usado
por pessoas de vários níveis técnicos, desde pessoas com uma ampla experiência em
segurança até desenvolvedores e testadores funcionais que são novos em testes de
penetração (OWASP, 2013).
Esta ferramenta fornece scanners automatizados, além de um conjunto de
ferramentas que permitem encontrar vulnerabilidades de segurança manualmente
(OWASP, 2013).
Entre suas principais funcionalidades estão a interceptação de proxy, scanners
automatizados e passivos e ferramentas de fuzzer e spider (OWASP, 2013).
48
Na Figura 6 pode-se observar a tela inicial do ZAP sendo executado no sistema

operacional Kali Linux.
Figura 6 - Tela inicial do ZAP

Fonte: Elaboração do autor
Uma outra ferramenta muito utilizada para a mesma finalidade do ZAP é o Paros
Proxy, que é uma ferramenta open source desenvolvida em Java para realizar auditorias
de segurança em aplicativos web (PAROS, 2013).
Assim como o ZAP, o Paros Proxy permite interceptar requisições HTTP e
HTTPS, além realizar scanners automatizados para XSS e SQL Injection, possui suporte
para realizar spidering e interceptação de cookies (PAROS, 2013), porém esta ferramenta
foi descontinuada e não recebe atualizações desde 2006, motivo este que levou à não
utilização desta ferramenta nos testes deste trabalho.
2.5.5 W3AF - Web Application Attack and Audit Framework

O w3af (Web Application Attack and Audit Framework) é um framework de ataque e
auditoria de sistemas web, é open source e foi desenvolvido em Python (W3AF 2013).
49
O projeto w3af tem como objetivo ser o melhor framework open source para
auxiliar na melhoria da segurança das aplicações web, encontrando e explorando todas as
vulnerabilidades de uma aplicação web (W3AF 2013).
O framework que já vem com alguns perfis de teste prontos e permite a criação de
novos perfis, onde serão armazenadas as configurações específicas para um determinado
teste.
Na Figura 7 pode-se observar a tela inicial do w3af, listando os perfis padrão do
aplicativo.
Figura 7 – Tela inicial do w3af
2.6 Teste das vulnerabilidades
O teste de cada uma das vulnerabilidades será realizado seguindo uma adaptação
dos sete passos descritos no guia OSSTMM (The Open Source Security Testing
Methodology Manual).
O OSSTMM é mantido pelo Institute for Security and Open Methodologies
(ISECOM) e está atualmente na versão 3, publicada em 14 de dezembro de 2010.
OSSTMM foi criado para a definição e realização de testes de segurança e abrange não
somente o ambiente de teste em desktops, servidores ou equipamentos de roteamento,
mas também aborda todos os canais que possam gerar ou contribuir para que ocorra uma
vulnerabilidade à uma aplicação, incluindo o ser humano (OSSTMM, 2010).
50
Contudo, o OSSTMM não abrange o teste em aplicações web, seu foco principal é
em infraestrutura e equipamentos de rede. Para este trabalho serão realizadas algumas
adaptações nesta metodologia, tornando-a aplicável para testar sistemas web.
2.6.1 Metodologia dos testes

O OSSTMM define 7 passos para a realização dos testes:
1. Definir o que proteger, os ativos que devem estar seguros.
2. Identificar a área em que a interação com os ativos deverá ocorrer, esta é a

engagement zone (zona de compromisso).
3. Definição de tudo de fora da engagement zone que é necessário para
manter os ativos operacionais. Este é o escopo do teste.
4. Definir como o escopo interage entre si e com o exterior. Este é o vetor do
teste. Cada vetor deve ser testado separadamente, para manter os testes
compartimentados e manter a duração dos testes a mínima possível, pois
durante os testes podem ocorrer muitas mudanças no ambiente de testes.
5. Identificar quais equipamentos serão necessários para a realização dos
testes.
6. Determinar quais informações eu quero extrair com os testes.
7. Assegurar que o teste realizado está em conformidade com as regras de
engajamento, ou seja, que não desrespeite as leis vigentes e que tenha a
devida autorização para realizar os testes.
2.6.2 Tipos de Teste

Segundo o OSSTMM, há seis tipos comuns de testes e eles se diferenciam de
acordo com a informação prévia que o analista testador tem do alvo e a informação que o
alvo tem sobre os testes a serem realizados:
1. Blind (Cego): O analista testa o alvo sem ter um conhecimento prévio
mínimo do alvo. O alvo é preparado para os testes, sabendo previamente de
todas as etapas que serão seguidas durante os testes. Este tipo de teste
também é conhecido como War Gaming (Jogos de Guerra) ou Role Playing
(Dramatização ou Encenação);
51
2. Double Blind (Duplo cego): O analista testa o alvo sem ter um

conhecimento prévio mínimo do alvo. O alvo não tem conhecimento prévio
do escopo do teste a ser realizado, do que será testado ou dos vetores de
teste. Este tipo de teste também é conhecido como Black Box Test (Teste da
Caixa Preta) ou Penetration Test (Teste de Penetração);
3. Gray Box (Caixa Cinza): O analista testa o alvo um conhecimento prévio
limitado das defesas e ativos do alvo. O alvo é preparado para os testes,
sabendo previamente de todas as etapas que serão seguidas durante os
testes. Este tipo de teste é conhecido como Vulnerability Test (Teste de
Vulnerabilidade);
4. Double Gray Box (Caixa Cinza Dupla): O analista testa o alvo um
conhecimento prévio limitado das defesas e ativos do alvo. O alvo tem
conhecimento prévio do escopo e da duração dos testes. Este tipo de teste
também é conhecido como White Box Test (Teste de Caixa Branca);
5. Tandem (Conjunto): O analista e o alvo são preparados para os testes,
ambos conhecendo antecipadamente todos os detalhes da auditoria. Este
tipo de teste é também conhecido como Crystal Box Test (Teste da Caixa de
Cristal);
6. Reversal (Reverso): O analista tem pleno conhecimento de todos os
processos e da segurança operacional do alvo. O alvo não sabe o que,
quando, como ou quando o teste será executado. Este teste é também
conhecido como Red Team Exercise (Exercício do Time Vermelho).
A Figura 8 ilustra os tipos de teste segundo o OSSTMM.
Figura 8 - Tipos de teste. Fonte: Adaptação do autor

52
Capítulo
53
3 Metodologia
Após a contextualização do cenário atual sobre os problemas no desenvolvimento de

sistemas web, a apresentação das principais entidades envolvidas com a segurança de sistemas
web, dos tipos de ataques a estes sistemas e de algumas ferramentas de detecção de
vulnerabilidades, apresenta-se neste capítulo a estratégia para a aplicação prática das
correções das cinco principais vulnerabilidades apontadas pelo Top Ten do OWASP.
3.1 Objetivo
Para atingir o objetivo deste trabalho, apresentando uma aplicação prática que
exemplifique as vulnerabilidades e suas respectivas correções, foi elaborada uma estratégia
constituída por cinco passos:
1. Escolha das vulnerabilidades;
2. Definição das ferramentas de detecção para cada vulnerabilidade;
3. Apresentação de soluções para cada vulnerabilidade;
4. Aplicação de correções em cada vulnerabilidade; e
5. Análise dos resultados obtidos.
A Figura 9 detalha as etapas definidas para atingir o objetivo deste trabalho:
Figura 9 - Estratégia para verificar e corrigir vulnerabilidades de segurança no desenvolvimento de sistemas web em
uma aplicação prática. Fonte: Elaboração do autor
54
Apresenta-se nas próximas seções, o desenvolvimento de cada uma das etapas da

estratégia para verificar e corrigir vulnerabilidades de segurança no desenvolvimento web.
3.1.1 Escolher as Vulnerabilidades de Segurança no Desenvolvimento de

Sistemas Web
Nesta etapa, foram definidas as vulnerabilidades dos sistemas web que serão
abordadas neste trabalho.
As vulnerabilidades escolhidas foram as cinco primeiras apontadas pelo Top Ten de
2010 da OWASP que estão listadas na Tabela 1. A opção por trabalhar com esta lista foi
motivada pelo renome internacional desta entidade, assim como o embasamento estatístico
desta lista, onde foram analisados dados de risco de oito empresas especializadas em
segurança de aplicações web.
3.1.2 Definir as Ferramentas para Identificar cada Vulnerabilidade Escolhida

Nesta etapa, foram definidas as ferramentas de detecção de vulnerabilidades e testes de
penetração automatizados que foram utilizadas no decorrer deste trabalho, tanto para procurar
e explorar as vulnerabilidades quanto para atestar a sua ausência.
As ferramentas escolhidas foram:
1. SqlMap;
2. OWASP WebScarab;
3. OWASP CAL9000;
4. OWASP ZAP;
5. W3AF.
Estas ferramentas foram escolhidas por serem, em sua maioria, fortemente indicadas
pelo guia de testes de software do OWASP, além da facilidade de utilização e vasta
documentação.
Para cada uma das vulnerabilidades, definiram-se algumas destas ferramentas para sua detecção e exploração. Esta
detecção e exploração. Esta estratégia pode ser observada na
Tabela 12.
55
Tabela 12 - Relação das vulnerabilidades e as ferramentas que serão utilizadas para sua detecção e exploração
Vulnerabilidade Ferramentas
Injeção (Injection) SqlMap e W3AF
WebScarab, CAL9000, W3AF
Scripting de Site Cruzado (Cross-Site Scripting - XSS)
e ZAP
Autenticação e Gerenciamento de Sessão Quebradas
W3AF
Referência Insegura e Direta a Objetos (Insecure Direct
Teste manual
Object References)
Falsificação de Solicitação de Site Cruzado (Cross-Site
W3AF
Request Forgery - CSRF)
3.1.3 Apresentar Soluções para as Vulnerabilidades Identificadas

Com base nas pesquisas realizadas no Capítulo 2 deste trabalho, esta seção foi
subdividida em outras duas etapas: na primeira etapa serão apresentadas as maneiras de se
explorar cada uma das vulnerabilidades, assim como exemplos de código-fonte vulnerável
para as mesmas.
Na segunda etapa, serão apresentadas propostas de soluções para as vulnerabilidades,
além de exemplos de códigos-fonte ilustrando o saneamento das mesmas.
3.1.4 Aplicar as Soluções Adotadas para Tratar as Vulnerabilidades em um

Experimento Prático
Nesta fase do trabalho, propõe-se criar dois aplicativos web: o primeiro utilizando uma
codificação vulnerável às falhas de segurança e outro aplicando as boas práticas demonstradas
no tópico anterior.
Ao final, serão utilizadas as ferramentas de detecção e exploração das vulnerabilidades
listadas na Seção 2.4 para atestar a eficiência das correções aplicadas e demonstrar como a
aplicação vulnerável poderia ser invadida.
56
3.1.5 Analisar os Resultados Obtidos da Aplicação no Experimento Prático

Nesta última etapa, será feita uma análise dos resultados obtidos no experimento
prático.
A partir desta análise, serão apresentadas as vantagens e possíveis desvantagens na
adoção de cada uma das técnicas de prevenção das vulnerabilidades. Ressalta-se que o
resultado desta análise será apresentado no Capítulo 4 deste trabalho.
3.2 Estudo de caso - Sistemas
Os sistemas definidos como estudo de caso foram desenvolvidos pelo próprio autor,
utilizando a linguagem de programação C# (Microsoft, 2013), framework .NET MVC4
(ASP.NET, 2013), o banco de dados SQL Server 2012 (Microsoft, 2013) e o servidor de
aplicação foi o IIS 8.5 (IIS, 2013) para Windows 8.1 (Microsoft, 2013).
A principal motivação para a escolha destas tecnologias foi pelo fato do autor já
trabalhar com as mesmas e ter uma maior afinidade, em comparação à outras tecnologias para
o desenvolvimento de sistemas web.
3.2.1 Estrutura dos sistemas

Os sistemas desenvolvidos para este trabalho possuem funcionalidades idênticas e a
mesma estrutura de banco de dados. O objetivo dos sistemas é simular uma agenda telefônica,
com um cadastro completo de contatos: inclusão, edição, exclusão e pesquisa pelo nome do
contato. Com estas funcionalidades é possível reproduzir, nestes sistemas, um ambiente em
que as cinco primeiras vulnerabilidades do Top Ten ocorram e possam ser corrigidas.
Os sistemas foram desenvolvidos utilizando o repositório SVN online do Google Code
e podem ser baixados no endereço https://code.google.com/p/tcc-app/. A Figura 10 mostra a
estrutura das páginas dos sistemas desenvolvidos.
57
Figura 10 - Estrutura de páginas dos sistemas elaborados
Os bancos de dados de ambos os sistemas são idênticos e são constituídos por duas
tabelas: Usuário e Contatos. O relacionamento das tabelas é de 1 usuário para N contatos e
esta estrutura pode ser observada, com maiores detalhes, na Figura 11.
Figura 11 - Diagrama estrutural do banco de dados

58
A estilização dos sistemas foi feita utilizando o framework CSS Bootstrap do Twitter
(Bootstrap, 2013). Para diferenciação e identificação visual dos sistemas, a cor da barra de
menus foi alterada: na aplicação segura ela é azul e na aplicação vulnerável é preta. Uma
comparação visual dos dois sistemas pode ser observada na Figura 12.
Figura 12 - Página inicial das aplicações desenvolvidas
3.3 Testes
Conforme apresentado na seção 2.6 deste trabalho, os testes serão realizados seguindo
uma adaptação dos 7 passos do OSSTMM.
59
A seguir, pode-se observar as adaptações realizadas na metodologia. Ressalta-se que o

item 3 da metodologia de testes do OSSTMM não se aplica aos sistemas web, portanto a
numeração foi ajustada e a partir de agora o item 4 será referenciado como 3, o item 5 será
referenciado como como 4, e assim sucessivamente:
1. Definir qual vulnerabilidade deseja-se proteger;
2. Nos sistemas web, todas as interações e acessos às aplicações ocorrerão pelos
protocolos de internet HTTP ou HTTPS;
3. Dividir o teste em pequenas etapas sempre que possível. Para algumas
vulnerabilidades este item não se aplicará;
4. Identificar quais ferramentas de detecção de vulnerabilidades serão utilizadas
para estes testes;
5. Determinar quais informações deseja-se extrair com os testes;
6. Assegurar que o teste realizado está em conformidade com as regras de
engajamento, ou seja, que não desrespeite as leis vigentes e que tenha a devida
autorização para realizar os testes. Este item não se aplicará aos testes
realizados neste trabalho, pois todos os testes serão realizados localmente, em
um ambiente controlado.
Os itens de 1 a 5 serão levantados e apresentados nas próximas subseções para cada
vulnerabilidade.
3.3.1 Injeção (Injection)

Apresenta-se abaixo a definição do teste para a vulnerabilidade Injeção (Injection),
seguindo os passos adaptados do OSSTMM:
1. Vulnerabilidade: Injeção (Injection);
2. Protocolo: HTTP;
3. Etapas:
a. Localizar uma área vulnerável;
b. Realizar o dump do banco de dados, a partir da área vulnerável.
4. Ferramentas: SqlMap e W3AF;
5. Informações a serem extraídas: Obter acesso ao banco de dados da aplicação, e

realizar um dump dos dados.
60
3.3.1.1 Teste com o SqlMap
O SqlMap foi executado em ambas aplicações com os mesmos comandos, alterando-se

apenas a URL de destino, como pode-se observar no Quadro 1.
Aplicação segura:
sqlmap –u “http://192.168.0.201/seguro/Home/Login” --data=”login=” --dump
Aplicação vulnerável:
sqlmap –u “http://192.168.0.201/vulneravel/Home/Login” --data=”login=” –-dump
Quadro 1 – Comandos do SqlMap para o dump do banco de dados
Na aplicação segura, ainda foi utilizado um comando mais avançado que pode ser
observado no Quadro 2. Este comando eleva o risco de detecção da tentativa de injection,
porém é mais eficaz.
sqlmap –u http://192.168.0.201/seguro/Home/PesquisarContato?q=a –level=5 –risk=3
Quadro 2 - Comando avançado no SqlMap
3.3.1.2 Teste com o W3AF
Para o teste de injection com o W3AF, foi criado um novo perfil de testes com as
seguintes configurações:
 Audit: blindSqli e sqli
 Discovery: webSpider
O teste foi realizado nos dois sistemas com este mesmo perfil.
3.3.2 Scripting de Site Cruzado (Cross-Site Scripting - XSS)

Apresenta-se abaixo a definição do teste para a vulnerabilidade Scripting de Site
Cruzado (Cross-Site Scripting - XSS), seguindo os passos adaptados do OSSTMM:
1. Vulnerabilidade: Scripting de Site Cruzado (Cross-Site Scripting - XSS);
2. Protocolo: HTTP;
3. Etapas:
61
a. Localizar uma área vulnerável;
b. Inserir o código malicioso na área vulnerável.
4. Ferramentas: W3AF, ZAP, WebScarab e CAL9000;
5. Informações a serem extraídas: Fazer com que um código malicioso seja executado na
página vulnerável.
3.3.2.1 Teste com o ZAP
Na tela inicial do ZAP, após inserir a URL do Sistema alvo, o botão “Ataque” foi
acionado para realizar um escaneamento no sistema e descobrir áreas vulneráveis ao XSS
como pode ser observado na Figura 13.
Figura 13 - Parâmetro inicial do ZAP: Url to attack
Ao término do escaneamento, uma lista de links descobertos é listada na aba

Varredura Ativa. Para testar a URL, é necessário selecionar um link da listagem e clicar na
aba Requisição. Logo após, ao clicar com o botão direito sobre qualquer um dos parâmetros
listados, a opção “fuzz” foi selecionada, conforme mostra a Figura 14.
62
Após clicar na opção Fuzz, na janela de seleção de bibliotecas Fuzz, foi selecionada
a opção “jbrofuzz/XSS” e o “Fuzzer XSS 101”. Esta janela de configuração pode ser
observada com detalhes na Figura 15.
Ao clicar em Fuzz, os testes iniciam-se na URL previamente selecionada.
Figura 14 - Opção Fuzz no ZAP

63
Figura 15 - Seleção de Fuzzers do ZAP
Para o teste de injection com o W3AF foi criado um novo perfil de testes com as
 Audit: xss
3.3.2.3 Teste com o WebScarab
Para realizar o teste com o WebScarab, é necessário alterar o navegador para utilizar o
proxy 127.0.0.1 ou localhost. Com isto, o WebScarab monitora, automaticamente, todas as
requisições realizadas pelo navegador.
Ao clicar na aba XSS/CRLF, é possível visualizar uma lista de URLs que podem ser
vulneráveis à XSS. Ao selecionar a URL listada e clicar em Check, a caixa “Confirmed
64
Vulnerabilities” é preenchida com as URLs que tiveram a vulnerabilidade confirmada,

conforme mostra a Figura 16.
Figura 16 - Listagem de URLs que podem ser vulneráveis a XSS pelo WebScarab

Apresenta-se abaixo a definição do teste para a vulnerabilidade Autenticação e
Gerenciamento de Sessão Quebradas (Broken Authentication and Session Management),
seguindo os passos adaptados do OSSTMM:
1. Vulnerabilidade: Autenticação e Gerenciamento de Sessão Quebradas (Broken

Authentication and Session Management);
2. Protocolo: HTTP;
3. Etapas:
a. Descobrir todas as URLs do sistema e identificar as áreas restritas;
b. Acessar as URLs de acesso restrito sem efetuar login no sistema;
c. Visualizar os dados de autenticação do usuário;
65
4. Ferramentas: W3AF;
5. Informações a serem extraídas:
a. Acessar URLs restritas sem efetuar o login nos sistemas;
b. Visualizar dados sensíveis de um usuário autenticado.
Para descobrir as URLs da aplicação e realizar os testes manuais da vulnerabilidade de

Autenticação e Gerenciamento de Sessão Quebradas com o W3AF, foi criado um novo perfil
de testes com as seguintes configurações:
3.3.4 Referência Insegura e Direta a Objetos (Insecure Direct Object References)

Apresenta-se abaixo a definição do teste para a vulnerabilidade Referência Insegura e
Direta a Objetos (Insecure Direct Object References), seguindo os passos adaptados do
OSSTMM:
1. Vulnerabilidade: Referência Insegura e Direta a Objetos (Insecure Direct Object

References);
2. Protocolo: HTTP;
3. Etapas:
a. Alterar o valor do cookie;
b. Acessar a página de listagem de contatos do usuário;
4. Ferramentas: Teste manual;
a. Acessar a lista de contatos de outros usuários;
3.3.5 Falsificação de Solicitação de Site Cruzado (Cross-Site Request Forgery -

CSRF)
Apresenta-se abaixo a definição do teste para a vulnerabilidade Falsificação de
Solicitação de Site Cruzado (Cross-Site Request Forgery - CSRF), seguindo os passos
adaptados do OSSTMM:
66
1. Vulnerabilidade: Falsificação de Solicitação de Site Cruzado (Cross-Site Request

Forgery - CSRF);
2. Protocolo: HTTP;
3. Etapas:
a. Identificar uma URL vulnerável através de um escaneamento automatizado;
4. Ferramentas: W3AF;
a. Identificação da vulnerabilidade no sistema;
Para o teste de CSRF com o W3AF foi criado um novo perfil de testes com as
 Audit: xsrf
67
Capítulo
68
4 Resultados
Neste capítulo, serão apresentados os resultados dos testes obtidos no experimento
prático que foi elaborado no Capítulo 3, assim como a divulgação dos trechos de código das
duas aplicações demonstrando assim a diferença entre a aplicação segura e a vulnerável.
4.1 Injeção (Injection)

O tratamento para esta vulnerabilidade pode ser feito, basicamente, ao utilizar as
consultas SQL parametrizadas.
Um exemplo pode ser observado na
Figura 17, onde na linha 55 a consulta é realizada utilizando o parâmetro @Id e na
linha 63 o valor recebido pelo parâmetro id do método Carregar é atribuído ao parâmetro
@Id. Nesta atribuição, informa-se qual o tipo de dado desta variável. Com isso, tudo que for
diferente do especificado é bloqueado por padrão.
69
Figura 17 - Código de acesso ao banco de dados utilizando consulta parametrizada

O mesmo método, porém vulnerável, pode ser observado na
Figura 18, onde na linha 52, o valor recebido por parâmetro é simplesmente adicionado
à consulta SQL como uma string, sem tratamento algum.
70
Figura 18 - Código de acesso ao banco de dados concatenando valores na consulta
4.1.1 Resultados do SqlMap

Utilizando a ferramenta SqlMap, foi possível atestar a segurança contra a
vulnerabilidade de Injection das duas aplicações desenvolvidas.
Na aplicação vulnerável, após executar o SqlMap, além de atestar a vulnerabilidade foi
possível até realizar um dump de todo o banco de dados da aplicação, conforme mostra a
Figura 19.
71
Figura 19 - SqlMap realizando o dump do banco de dados da aplicação vulnerável
Na aplicação segura, o SqlMap não encontrou vulnerabilidades, mesmo com a

utilização de parâmetros avançados que aumentam a possibilidade de detectar a
vulnerabilidade de Injeção, como pode ser visto na Figura 20.
Figura 20 - SqlMap realizando testes na aplicação segura

72
4.1.2 Resultados do W3AF

No sistema vulnerável, o W3AF encontrou 11 vulnerabilidades, como pode ser
observado na Figura 21. Já na aplicação segura, nenhuma vulnerabilidade foi encontrada. A
Figura 22 exibe a lista de vulnerabilidades vazia após o escaneamento.
Figura 21 – Vulnerabilidades de injeção de SQL encontradas pela ferramenta W3AF
Figura 22 - Resultado do escaneamento da vulnerabilidade de Injeção realizado pela ferramenta W3AF

73
4.2 Scripting de Site Cruzado (Cross-Site Scripting - XSS)
O framework .NET 4.5 utilizado no desenvolvimento dos sistemas possui uma proteção automática contra a
proteção automática contra a vulnerabilidade XSS que verifica todas as requisições do sistema (Figura 23). Com isto,
(Figura 23). Com isto, foi necessário desabilitar esta configuração no sistema vulnerável para que fosse possível
explorar esta vulnerabilidade (
Figura 24).
Figura 23 – Validação automática do .NET
Figura 24 – Código adicional no arquivo web.config para evitar as validações de requisições automáticas no .NET 4.5
74
Para evitar a vulnerabilidade XSS, deve-se validar toda entrada de dados do sistema. O
recomendado para esta validação é a utilização de uma whitelist. Há uma RFC que trata sobre
o assunto (http://tools.ietf.org/html/rfc3986).
Os caracteres reservados permitidos são:
Figura 25 - Lista de caracteres reservados permitidos
Os caracteres não reservados permitidos são:
Figura 26 - Lista de caracteres não reservados permitidos
Quanto a exibição dos dados, deve-se sempre utilizar a codificação de caracteres

HTML, ou seja, ao invés de exibir o caractere “<” uma troca pela entidade HTML “<” deve
ser realizada.
4.2.1 Resultados do ZAP

Na aplicação vulnerável, ao realizar o Fuzzer, foi listada uma série de tentativas de
XSS, todas com sucesso, como pode ser observado nas colunas Status e Reason da Figura 27.
Figura 27 - Resultado do teste de XSS realizado na aplicação vulnerável pelo ZAP
A vulnerabilidade se confirmou ao inserir o comando listado na coluna “Fuzz” no

formulário da aplicação vulnerável e o resultado pode ser observado na Figura 28. O código
malicioso inserido na página é executado toda vez que a página é carregada.
75
Figura 28 - XSS executado na aplicação vulnerável
Já na aplicação segura, ao realizar os mesmos testes da aplicação vulnerável, pode-se

observar que todas as requisições não foram bem-sucedidas pelos erros listados nas colunas
“Status” e “Reason”. A Figura 29 exibe com detalhes as mensagens recebidas.
Figura 29 - Resultado do teste de XSS realizado na aplicação segura pelo ZAP

Na aplicação vulnerável, o W3AF encontrou uma URL vulnerável que pode ser
observada na Figura 30.
76
Figura 30 - XSS encontrado pelo W3AF na aplicação vulnerável
Na aplicação segura, nenhuma URL vulnerável foi encontrada e o resultado do

escaneamento pode ser observado na Figura 31.
Figura 31 – Log do escaneamento da aplicação segura executado pelo W3AF

77
4.2.3 Resultados do WebScarab

Na aplicação vulnerável, após o WebScarab apontar a URL possivelmente vulnerável,
ao clicar na aba Messages do WebScarab, pode-se observar a URL com o parâmetro utilizado
no teste automatizado pela ferramenta na Figura 32.
Figura 32 - URL com parâmetro malicioso criada pelo WebScarab
Ao copiar e colar a URL com o parâmetro malicioso no navegador, é possível

confirmar a vulnerabilidade, como pode-se observar na Figura 33.
Figura 33 - URL maliciosa gerada pelo WebScarab em execução

78
Na aplicação segura, nenhuma URL possivelmente vulnerável foi identificada pela

ferramenta. Ao acessar a página de pesquisa do sistema seguro com o mesmo parâmetro
utilizado na aplicação vulnerável, a página de bloqueio do .NET era exibida, como pode ser
observado na Figura 34.
Figura 34 - Ataque XSS barrado na aplicação segura
4.2.4 Aprofundamento com o CAL 9000

Após obter uma URL vulnerável com o WebScarab, é possível utilizar a biblioteca de
ataques de XSS do CAL9000, para realizar testes mais avançados, como pode ser visto com
mais detalhes na Figura 35.
A maioria dos ataques listados na biblioteca do CAL9000 foram executados com
sucesso na aplicação vulnerável, enquanto que na aplicação segura todos foram bloqueados.
79
Figura 35 - Biblioteca de ataques XSS do CAL9000
4.3 Autenticação e Gerenciamento de Sessão Quebradas (Broken

Segundo Troy Hunt (2011), o tratamento para esta vulnerabilidade nunca resultará em
práticas facilmente aplicadas, pois “a autenticação é um assunto muito amplo, com inúmeras
armadilhas e é muito fácil de errar, ou pelo menos não deixá-la tão segura como poderia”.
Ele resume as boas práticas para esta vulnerabilidade, com duas premissas básicas:
1. Não manter dados sensíveis no lado cliente;

2. Criptografar todo e qualquer dado que ficará armazenado do lado cliente;
Atendendo à primeira premissa, ele refere-se a dados sensíveis como sendo, por
exemplo, login e senha do usuário. Na Figura 36, pode-se observar, na aplicação vulnerável,
um exemplo de dados sensíveis armazenados no lado cliente.
80
Figura 36 - Cookie de autenticação da aplicação vulnerável
Já na Figura 37, pode-se observar uma outra postura com relação a estes dados na
aplicação segura: estes dados não são armazenados no lado do cliente. No lado cliente, apenas
é armazenado um identificador de sessão único e criptografado do usuário. Com esta
abordagem, mesmo que os cookies da aplicação fossem sequestrados, nenhum dado sensível
seria exposto apenas por este fato.
Figura 37 - Cookie de autenticação da aplicação segura
Para manter a segurança durante a transmissão dos dados, é necessário ter um

certificado digital instalado no servidor, de modo que a conexão por SSL (HTTPS) seja
possível, com esta abordagem dificulta-se o ataque conhecido como Man in the Middle.

Tendo as URLs identificadas pelo W3AF, este teste consiste em acessar estes
endereços pelo navegador, nas URLs de acesso restrito. O ideal seria que os sistemas
exibissem uma mensagem de erro ou então redirecionassem o usuário para a página de login.
Uma das URLs de acesso restrito identificadas foi a de pesquisa de contatos. Na
aplicação vulnerável, foi possível acessar a página e realizar pesquisas, como se fosse um
usuário autenticado. A Figura 38 mostra a página em execução sem ter um usuário
autenticado.
81
Figura 38 - Acesso à página restrita sem realizar autenticação no sistema vulnerável
Na aplicação segura, ao tentar acessar as URLs restritas, sem efetuar login, um

redirecionamento automático para a página de autenticação é realizado.
Na Figura 39 é possível observar a validação de seção sendo chamada no controller da
página “AlteraContato” e na Figura 40 pode-se observar o método “UsuarioLogado” da classe
“Usuario”, onde a partir da sessão, a criptografia é retirada dos atributos do usuário e o objeto
usuário é instanciado.
Figura 39 - Validação de session no ASP.NET

82
Figura 40 - Validação de usuário autenticado na sessão
Esta é uma forma simples e eficiente de verificar se há um usuário autenticado no

sistema. Uma alternativa para este método, seria a utilização das funções de autenticação
nativas do ASP.NET, este método não foi utilizado neste trabalho para que fosse possível
demonstrar a implementação e aplicação de uma validação de autenticação.
4.4 Referência Insegura e Direta a Objetos (Insecure Direct Object

References)
De acordo com Troy Hunt (2011), esta vulnerabilidade, assim como a vulnerabilidade
de Autenticação e Gerenciamento de Sessão quebrado, é um outro bom exemplo de como a
proteção dos sistemas web não é algo simples de ser feito.
Na aplicação vulnerável, esta vulnerabilidade foi explorada na página de listagem de
contatos. Esta página obtém o valor ID do cookie de autenticação e com isso traz todos os
contatos destes usuário.
Se o valor do cookie é alterado para outro número sequencial, pode-se visualizar os
contatos de outro usuário do sistema.
83
Existem várias maneiras de corrigir esta vulnerabilidade, uma delas refere-se à

vulnerabilidade anterior: Autenticação e Gerenciamento de Sessão Quebrados, ou seja, basta
não manter dados sensíveis do usuário no lado cliente.
Se a aplicação busca o valor do ID do usuário autenticado diretamente da sessão
criptografada no servidor, não é possível alterar o valor do ID do usuário apenas no lado
cliente, exigindo assim um ataque mais elaborado ao sistema alvo.
Um outro tratamento bastante simples para esta vulnerabilidade é não consultar a lista
de usuários apenas pelo ID, fazendo uma consulta com os parâmetros ID e e-mail, por
exemplo. Com isto, o atacante teria que descobrir o ID e o e-mail de um outro usuário para
que seja possível visualizar seus contatos, o que tornaria o ataque muito mais difícil, porém
não impossível. Neste caso, o ideal seria criptografar os dados do cookie de autenticação e
utilizar 2 ou mais parâmetros para a consulta ao banco de dados.
4.5 Falsificação de Solicitação de Site Cruzado (Cross-Site Request Forgery -

CSRF)
O tratamento para esta vulnerabilidade pode ser feito utilizando uma técnica chamada
Anti-Forgery Token (Símbolo Anti-Falsificação). Esta técnica consiste em armazenar um
cookie de valor único no lado cliente e armazenar este mesmo valor em um campo oculto do
formulário a ser enviado. Quando a página é enviada, caso o valor do cookie não corresponda
com valor do formulário, um erro é gerado e a requisição é interrompida.
O ASP.NET fornece um Anti-Forgery Token já pronto para a utilização, tendo em
vista a complexidade de implementação deste mecanismo. Sua utilização consiste em
adicionar um campo no formulário, utilizando a sintaxe exibida no Quadro 3.
@Html.AntiForgeryToken()
Quadro 3 - Criação de um Anti-Forgery Token no ASP.NET
No controller que irá receber este formulário deve-se inserir uma anotação antes do
método que receberá a requisição, como pode ser visto na linha 128 da
Figura 41.
84
Figura 41 - Validação do Anti-Forgery Token no ASP.NET
Nesta estrutura, um campo oculto é adicionado ao formulário, se o valor deste campo

ou do cookie de persistência do Anti-Forgery Token for alterado, uma mensagem de erro é
exibida, como pode ser visto na Figura 42.
Figura 42 - Erro na validação do Anti-Forgery Token no ASP.NET
Complementando esta validação, recomenda-se utilizar uma conexão SSL/HTTPS ao

transmitir o Anti-Forgery Token, para evitar que seu valor possa ser alterado caso o cookie de
validação tenha sido sequestrado.
85

Ao realizar o escaneamento automatizado do W3AF na aplicação vulnerável, foi
possível identificar a vulnerabilidade, como visto na Figura 43. Na aplicação segura o W3AF
não encontrou esta vulnerabilidade.
Figura 43 - CSRF encontrado pelo W3AF

86
Capítulo
87
5 Conclusão
Este trabalho teve como objetivo principal ser um guia de boas práticas de segurança
no desenvolvimento de sistemas web, auxiliando desenvolvedores durante e após o
desenvolvimento.
Para atingir este objetivo, foi realizado um levantamento bibliográfico sobre as
principais vulnerabilidades que os sistemas web atuais sofrem, assim como o tratamento para
cada uma destas vulnerabilidades.
Como fruto desta pesquisa, foi selecionada a lista Top Ten de 2010 da OWASP para
ser utilizada como um guia, ditando quais vulnerabilidades deveriam ser citadas no trabalho.
Pela limitação de tempo para este trabalho, decidiu-se aprofundar somente nas cinco
primeiras vulnerabilidades desta lista, sendo estas as que foram o foco deste guia de boas
práticas, assim como o passo a passo de como testar cada uma destas vulnerabilidades.
Durante a pesquisa, sentiu-se a necessidade de apresentar também algumas
ferramentas que facilitam os testes de vulnerabilidades nestas aplicações. Com isso, os
objetivos específicos foram atualizados e passaram a incluir um guia de utilização destas
ferramentas para analisar as aplicações web em busca de vulnerabilidades.
Também para cumprir o objetivo proposto, foi definida uma estratégia (Figura 9) em
cinco passos, que foram concluídos com sucesso.
A demonstração das cinco vulnerabilidades foi realizada com sucesso, assim como
suas respectivas correções.
As ferramentas adotadas para os testes atingiram devidamente o objetivo proposto
para cada uma das vulnerabilidades que foi proposta a sua utilização.
Porém, durante os testes, foi sentida uma necessidade de uma metodologia existente
para realizar devidamente os testes. A metodologia OSSTMM foi adotada pelo autor, porém
ela não era integralmente compatível com os testes voltados aos sistemas web, o que
demandou uma adaptação desta metodologia para seu uso nestes sistema.
Uma das principais dificuldades encontradas neste trabalho foi a configuração de
algumas ferramentas. Em alguns casos, a documentação da ferramenta abordava apenas os
88
testes e deixavam de lado a configuração inicial, como por exemplo, ativar a ferramenta para
interceptação das requisições, como um servidor proxy.
5.1 Trabalhos Futuros

Como recomendação para trabalhos futuros, sugere-se pesquisar sobre novas
metodologias de teste de segurança para sistemas web, trabalhar na melhoria da adaptação do
OSSTMM para estes sistemas e também realizar os testes em aplicações reais, após obter as
devidas permissões.
Também como recomendação, pesquisar sobre outras ferramentas de detecção de
vulnerabilidades em sistemas web e também ferramentas que complementem as já utilizadas
neste trabalho.
Estender a pesquisa para as outras cinco vulnerabilidades, contemplando todo o Top
Ten do OWASP e realizar testes mais aprofundados em todas as dez vulnerabilidades.
Desenvolver os sistemas utilizados para identificação e correção das vulnerabilidades
em outras linguagens, como o Java ou PHP, elaborando uma metodologia de testes para estes
sistemas e identificando as ações tomadas para prevenir as vulnerabilidades que se
diferenciaram das apontadas neste trabalho.
Uma outra sugestão para trabalhos futuros, por entender que não faz parte do escopo
desta pesquisa, recomenda-se analisar o desempenho dos dois sistemas desenvolvidos, de
modo que seja possível observar se há, de alguma forma, perda de desempenho no sistema
que teve as boas práticas aplicadas.
89
Referências
ASP.NET MVC 4 (2013). The Official Microsoft ASP.NET Site. Disponível em
<http://www.asp.net/mvc/mvc4>. Acesso em: 26 outubro, 2013.
ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBRISO/IEC27002 Engenharia

de software - Qualidade de produto - Parte 1: Modelo de qualidade. 2005.
AOKI, Eric Komiyama; CARVALHO, Alan Henrique Pardo de. Práticas de segurança para o
desenvolvimento de sistemas Web. FaSCi-Tech, v. 1, n. 5, 2012.
BOOTSTRAP (2013). Sleek, intuitive, and powerful mobile first front-end framework for
faster and easier web development. Disponível em <http://getbootstrap.com/>. Acesso em: 26
outubro, 2013.
CAMPOS, Fernando; NETO, Nery Signorini; CANTO, Wagner F. Web 2.0 Sob a Perspectiva
da Segurança. Online. Disponível: http://fernandocampos.pro.br/artigos/Web, v. 202.
2010.
CERT.br (2013). Centro de Estudos, Resposta e Tratamento de Incidentes de Segurança no

Brasil. Disponível em: <http://www.cert.br>. Acesso em: 01 mar, 2013.
CERT.br (2013). Estatísticas total de incidentes reportados ao CERT.br por ano. Disponível
em: <http://www.cert.br/stats/incidentes>. Acesso em: 10 mar, 2013.
CERT.br (2013). Cartilha de Segurança para Internet. Disponível em:

<http://cartilha.cert.br/>. Acesso em: 10 mar, 2013.
CERT.br (2013). Glossário da Cartilha de Segurança para Internet. Disponível em:

<http://cartilha.cert.br/glossario/>. Acesso em: 10 mar, 2013.
CHEN, Boyan et al. A study of the effectiveness of CSRF guard. In: Privacy, security, risk
and trust (passat), 2011 ieee third international conference on and 2011 ieee third
international conference on social computing (socialcom). IEEE, 2011. p. 1269-1272.
FUNG, Adonis PH; CHEUNG, K. W.; WONG, T. Y. FAITH: Scanning of Rich Web
Applications for Parameter Tampering Vulnerabilities. arXiv preprint arXiv:1204.1216,
2012.
HOPE, Paco; WALTHER, Ben. Web security testing cookbook. O'Reilly Media, 2009.
ISO (2013). International Organization for Standardization. Disponível em

<http://www.iso.org/iso/home/about.htm>. Acesso em: 01 maio, 2013.
KIEYZUN, Adam et al. Automatic creation of SQL injection and cross-site scripting attacks.
In: Software Engineering, 2009. ICSE 2009. IEEE 31st International Conference on.
IEEE, 2009. p. 199-209.
90
LIN, Jin-Cherng; CHEN, Jan-Min; LIU, Cheng-Hsiung. An Automatic Mechanism for

Sanitizing Malicious Injection. In: Young Computer Scientists, 2008. ICYCS 2008. The
9th International Conference for. IEEE, 2008. p. 1470-1475.
MICROSOFT DEVELOPER NETWORK (2013). Visual C#. Disponível em

<http://msdn.microsoft.com/pt-br/library/kx37x362.aspx>. Acesso em: 26 outubro, 2013.
MICROSOFT SQL SERVER (2013). Business Intelligence, Gestão de Banco de Dados e

Data Warehousing. Disponível em <http://www.microsoft.com/sqlserver/pt/br/default.aspx>.
Acesso em: 26 outubro, 2013.
MICROSOFT IIS (2013). The Official Microsoft IIS Site. Disponível em

<http://www.iis.net/>. Acesso em: 26 outubro, 2013.
MICROSOFT WINDOWS (2013). Windows 8.1. Disponível em

<http://windows.microsoft.com/pt-br/windows-8/meet>. Acesso em: 26 outubro, 2013.
OSSTMM - Open Source Security Testing Methodology Manual. Institute for Security and
Open Methodologies, ISECOM. http://www.isecom.org/osstmm Acesso em: 17 ago, 2013.
OWASP (2013). The Open Web Application Security Project. Disponível em:
<https://www.owasp.org/index.php/Main_Page>. Acesso em: 01 mar, 2013.
PAROS (2013). Paros Project. Disponível em <http://www.parosproxy.org/index.shtml>

Acesso em 01 setembro, 2013.
SAWAYA, Márcia Regina. Dicionário de informática & Internet. Livraria Nobel Sa, 2002.
– Utilizado para retirar as definições de alguns termos utilizados no trabalho.
TAKAMATSU, Yusuke; KOSUGA, Yuji; KONO, Kenji. Automated detection of session

management vulnerabilities in web applications. In: Privacy, Security and Trust (PST),
2012 Tenth Annual International Conference on. IEEE, 2012. p. 112-119.
UTO, Nelson. Teste de invasão de aplicações web Disponível em:

<http://pt.scribd.com/doc/73586437/Teste-de-Invasao-de-Aplicacoes-Web> Acesso em: 14
abr. 2013.
UTO, Nelson; MELO, S. P. Vulnerabilidades em Aplicações Web e Mecanismos de

Proteção. IX Simpósio Brasileiro de Segurança da informação e de sistemas
computacionais±SBSEG, cap, v. 6, 2009.
VANDIERENDONCK, Hans; DE BOSSCHERE, Koenraad. XOR-based hash

functions. Computers, IEEE Transactions on, v. 54, n. 7, p. 800-812, 2005.
WAGNER, Rosana; MACHADO, Alencar. Níveis de segurança para processos de

desenvolvimento de software seguro. 2010.
WHITEHAT (2013). WhiteHat Security Disponível em

<https://www.whitehatsec.com/index.html> Acesso em 19 maio, 2013.
91
WHITEHAT (2013). WhiteHat Security Press Releases: Whitehat Security Reveals New
Trends In Web Vulnerabilities With Annual Website Security Statistics Report. Disponível
em <https://www.whitehatsec.com/news/13pressarchives/PR_050213_statsreport.html>
Acesso em 19 maio, 2013.
WHITEHAT (2013). WhiteHat Security: Press Releases: Website Security Statistics Report
May 2013. Disponível em <https://www.whitehatsec.com/assets/WPstatsReport_052013.pdf>
Acesso em 19 maio, 2013.
W3AF (2013). Web Application Attack and Audit Framework. Disponível em

<http://w3af.org/>. Acesso em: 01 setembro, 2013.
92
93
APÊNDICE A – Guia de Configuração das

Ferramentas de Teste
1 Injeção (Injection)
1.1 Teste com o SqlMap
O SqlMap foi executado em ambas aplicações com os mesmos comandos, alterando-se
apenas a URL de destino, como pode-se observar no Quadro 1.
Aplicação segura:
sqlmap –u “http://192.168.0.201/seguro/Home/Login” --data=”login=” --dump
Aplicação vulnerável:
sqlmap –u “http://192.168.0.201/vulneravel/Home/Login” --data=”login=” –-dump
Quadro 4 – Comandos do SqlMap para o dump do banco de dados
Na aplicação segura, ainda foi utilizado um comando mais avançado que pode ser
observado no Quadro 2. Este comando eleva o risco de detecção da tentativa de injection,
porém é mais eficaz.
sqlmap –u http://192.168.0.201/seguro/Home/PesquisarContato?q=a –level=5 –risk=3
Quadro 5 - Comando avançado no SqlMap
1.2 Teste com o W3AF

Para o teste de injection com o W3AF, foi criado um novo perfil de testes com as
 Audit: blindSqli e sqli
94
2 Scripting de Site Cruzado (Cross-Site Scripting - XSS)

2.1 Teste com o ZAP
Na tela inicial do ZAP, após inserir a URL do Sistema alvo, o botão “Ataque” foi
acionado para realizar um escaneamento no sistema e descobrir áreas vulneráveis ao XSS
como pode ser observado na Figura 13.
Figura 44 - Parâmetro inicial do ZAP: Url to attack
Ao término do escaneamento, uma lista de links descobertos é listada na aba

Varredura Ativa. Para testar a URL, é necessário selecionar um link da listagem e clicar na
aba Requisição. Logo após, ao clicar com o botão direito sobre qualquer um dos parâmetros
listados, a opção “fuzz” foi selecionada, conforme mostra a Figura 14.
Após clicar na opção Fuzz, na janela de seleção de bibliotecas Fuzz, foi selecionada
a opção “jbrofuzz/XSS” e o “Fuzzer XSS 101”. Esta janela de configuração pode ser
observada com detalhes na Figura 15.
Ao clicar em Fuzz, os testes iniciam-se na URL previamente selecionada.
95
Figura 45 - Opção Fuzz no ZAP
Figura 46 - Seleção de Fuzzers do ZAP

96

Para o teste de injection com o W3AF foi criado um novo perfil de testes com as
 Audit: xss
2.3 Teste com o WebScarab

Para realizar o teste com o WebScarab, é necessário alterar o navegador para utilizar o
proxy 127.0.0.1 ou localhost. Com isto, o WebScarab monitora, automaticamente, todas as
requisições realizadas pelo navegador.
Ao clicar na aba XSS/CRLF, é possível visualizar uma lista de URLs que podem ser
vulneráveis à XSS. Ao selecionar a URL listada e clicar em Check, a caixa “Confirmed
Vulnerabilities” é preenchida com as URLs que tiveram a vulnerabilidade confirmada,
conforme mostra a Figura 16.
Figura 47 - Listagem de URLs que podem ser vulneráveis a XSS pelo WebScarab
97
3 Autenticação e Gerenciamento de Sessão Quebradas

Para descobrir as URLs da aplicação e realizar os testes manuais da vulnerabilidade de
Autenticação e Gerenciamento de Sessão Quebradas com o W3AF, foi criado um novo perfil
de testes com as seguintes configurações:
4 Referência Insegura e Direta a Objetos (Insecure Direct

Object References)
4.1 Teste Manual
Etapas:
1 Alterar o valor do cookie;
2 Acessar a página de listagem de contatos do usuário;
5 Falsificação de Solicitação de Site Cruzado (Cross-Site

Para o teste de CSRF com o W3AF foi criado um novo perfil de testes com as
 Audit: xsrf
98
99
APÊNDICE B – Guia de Correção para as

Vulnerabilidades
1 Injeção (Injection)
O tratamento para esta vulnerabilidade pode ser feito, basicamente, ao utilizar as
consultas SQL parametrizadas.
Um exemplo pode ser observado na
Figura 17, onde na linha 55 a consulta é realizada utilizando o parâmetro @Id e na
linha 63 o valor recebido pelo parâmetro id do método Carregar é atribuído ao parâmetro
@Id. Nesta atribuição, informa-se qual o tipo de dado desta variável. Com isso, tudo que for
diferente do especificado é bloqueado por padrão.
Figura 48 - Código de acesso ao banco de dados utilizando consulta parametrizada

O mesmo método, porém vulnerável, pode ser observado na
Figura 18, onde na linha 52, o valor recebido por parâmetro é simplesmente adicionado
à consulta SQL como uma string, sem tratamento algum.
100
Figura 49 - Código de acesso ao banco de dados concatenando valores na consulta
2 Scripting de Site Cruzado (Cross-Site Scripting - XSS)
O framework .NET 4.5 utilizado no desenvolvimento dos sistemas possui uma proteção automática contra a
vulnerabilidade XSS que verifica todas as requisições do sistema (Figura 23). Com isto, foi necessário desabilitar esta
configuração no sistema vulnerável para que fosse possível explorar esta vulnerabilidade (
Figura 24).
101
Figura 50 – Validação automática do .NET
Figura 51 – Código adicional no arquivo web.config para evitar as validações de requisições automáticas no .NET 4.5
Para evitar a vulnerabilidade XSS, deve-se validar toda entrada de dados do sistema. O
recomendado para esta validação é a utilização de uma whitelist. Há uma RFC que trata sobre
o assunto (http://tools.ietf.org/html/rfc3986).
102
Os caracteres reservados permitidos são:
Figura 52 - Lista de caracteres reservados permitidos
Os caracteres não reservados permitidos são:
Figura 53 - Lista de caracteres não reservados permitidos
Quanto a exibição dos dados, deve-se sempre utilizar a codificação de caracteres

HTML, ou seja, ao invés de exibir o caractere “<” uma troca pela entidade HTML “<” deve
ser realizada.
3 Autenticação e Gerenciamento de Sessão Quebradas

Segundo Troy Hunt (2011), o tratamento para esta vulnerabilidade nunca resultará em
práticas facilmente aplicadas, pois “a autenticação é um assunto muito amplo, com inúmeras
armadilhas e é muito fácil de errar, ou pelo menos não deixá-la tão segura como poderia”.
Ele resume as boas práticas para esta vulnerabilidade, com duas premissas básicas:
3. Não manter dados sensíveis no lado cliente;

4. Criptografar todo e qualquer dado que ficará armazenado do lado cliente;
Atendendo à primeira premissa, ele refere-se a dados sensíveis como sendo, por
exemplo, login e senha do usuário. Na Figura 36, pode-se observar, na aplicação vulnerável,
um exemplo de dados sensíveis armazenados no lado cliente.
103
Figura 54 - Cookie de autenticação da aplicação vulnerável
Já na Figura 37, pode-se observar uma outra postura com relação a estes dados na
aplicação segura: estes dados não são armazenados no lado do cliente. No lado cliente, apenas
é armazenado um identificador de sessão único e criptografado do usuário. Com esta
abordagem, mesmo que os cookies da aplicação fossem sequestrados, nenhum dado sensível
seria exposto apenas por este fato.
Figura 55 - Cookie de autenticação da aplicação segura
Para manter a segurança durante a transmissão dos dados, é necessário ter um

certificado digital instalado no servidor, de modo que a conexão por SSL (HTTPS) seja
possível, com esta abordagem dificulta-se o ataque conhecido como Man in the Middle.
4 Referência Insegura e Direta a Objetos (Insecure Direct

Object References)
De acordo com Troy Hunt (2011), esta vulnerabilidade, assim como a vulnerabilidade
de Autenticação e Gerenciamento de Sessão quebrado, é um outro bom exemplo de como a
proteção dos sistemas web não é algo simples de ser feito.
Na aplicação vulnerável, esta vulnerabilidade foi explorada na página de listagem de
contatos. Esta página obtém o valor ID do cookie de autenticação e com isso traz todos os
contatos destes usuário.
Se o valor do cookie é alterado para outro número sequencial, pode-se visualizar os
contatos de outro usuário do sistema.
104
Existem várias maneiras de corrigir esta vulnerabilidade, uma delas refere-se à

vulnerabilidade anterior: Autenticação e Gerenciamento de Sessão Quebrados, ou seja, basta
não manter dados sensíveis do usuário no lado cliente.
Se a aplicação busca o valor do ID do usuário autenticado diretamente da sessão
criptografada no servidor, não é possível alterar o valor do ID do usuário apenas no lado
cliente, exigindo assim um ataque mais elaborado ao sistema alvo.
Um outro tratamento bastante simples para esta vulnerabilidade é não consultar a lista
de usuários apenas pelo ID, fazendo uma consulta com os parâmetros ID e e-mail, por
exemplo. Com isto, o atacante teria que descobrir o ID e o e-mail de um outro usuário para
que seja possível visualizar seus contatos, o que tornaria o ataque muito mais difícil, porém
não impossível. Neste caso, o ideal seria criptografar os dados do cookie de autenticação e
utilizar 2 ou mais parâmetros para a consulta ao banco de dados.
5 Falsificação de Solicitação de Site Cruzado (Cross-Site

O tratamento para esta vulnerabilidade pode ser feito utilizando uma técnica chamada
Anti-Forgery Token (Símbolo Anti-Falsificação). Esta técnica consiste em armazenar um
cookie de valor único no lado cliente e armazenar este mesmo valor em um campo oculto do
formulário a ser enviado. Quando a página é enviada, caso o valor do cookie não corresponda
com valor do formulário, um erro é gerado e a requisição é interrompida.
O ASP.NET fornece um Anti-Forgery Token já pronto para a utilização, tendo em
vista a complexidade de implementação deste mecanismo. Sua utilização consiste em
adicionar um campo no formulário, utilizando a sintaxe exibida no Quadro 3.
@Html.AntiForgeryToken()
Quadro 6 - Criação de um Anti-Forgery Token no ASP.NET
No controller que irá receber este formulário deve-se inserir uma anotação antes do
método que receberá a requisição, como pode ser visto na linha 128 da
Figura 41.
105
Figura 56 - Validação do Anti-Forgery Token no ASP.NET
Nesta estrutura, um campo oculto é adicionado ao formulário, se o valor deste campo

ou do cookie de persistência do Anti-Forgery Token for alterado, uma mensagem de erro é
exibida, como pode ser visto na Figura 42.
Figura 57 - Erro na validação do Anti-Forgery Token no ASP.NET
Complementando esta validação, recomenda-se utilizar uma conexão SSL/HTTPS ao

transmitir o Anti-Forgery Token, para evitar que seu valor possa ser alterado caso o cookie de
validação tenha sido sequestrado.

2013 - 2sem - Wellington Zanelli Ribeiro

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

2013 - 2sem - Wellington Zanelli Ribeiro

Enviado por

Direitos autorais:

Formatos disponíveis

Wellington Zanelli Ribeiro

APLICAÇÃO DE BOAS PRÁTICAS DE SEGURANÇA

Trabalho de conclusão de curso apresentado ao Instituto

Área de Concentração: Segurança no Desenvolvimento

Orientador: Prof. Breno Lisi Romano

São João da Boa Vista

Ficha catalográfica preparada pela Seção de Tratamento

Trabalho de Conclusão de Curso, IFSP, 2013.

1. Segurança. 2. Sistemas Web. 3. Desenvolvimento.

I. Aplicação de Boas Práticas de Segurança em

Agradeço primeiramente ao meu orientador Breno, pelo incentivo, entusiasmo

e por acreditar no meu trabalho. À minha esposa Bruna, sempre disposta a me

frente: “Don’t Panic”.

RIBEIRO, Wellington Zanelli. Aplicação de boas práticas de segurança no

Com a popularização da internet, os sistemas web estão cada vez mais

Palavras-chave: Segurança. Desenvolvimento de Sistemas Web. Correções.

RIBEIRO, Wellington Zanelli. Applying of security best practices in web

Keywords: Security. Web systems development. Corrections. Vulnerabilities.

Figura 1 - Estatísticas de ataques nos últimos 14 anos

Tabela 1 - Lista das dez vulnerabilidades web mais críticas,

CSS Cascading Style Sheets (Folha de Estilos em Cascata)

DOM Document Object Model (Modelo Objeto de Documento)

HTTP Hypertext Transfer Protocol (Protocolo de Transferência

HTTPS Hypertext Transfer Protocol Secure (Protocolo Seguro de

IP Internet Protocol (Protocolo de Internet)

MD4 Message-Digest Algorithm 4th Generation (Algoritmo de

Mensagem de Sumário de 4ª Geração)

RFC Request for Comments (Pedido de Comentários)

SGBD Sistema de Gerenciamento de Banco de Dados

SHA1 Secure Hash Algorithm 1st Serie (Algoritmo de hash

SQL Structured Query Language (Linguagem de Consulta

SVN Apache Subversion

URL Universal Resource Locator (Localizador de Recursos

1.1 Motivação .............................................................................................................................. 23

1.2 Objetivos ............................................................................................................................... 23

1.3 Objetivos Específicos ............................................................................................................ 23

1.4 Organização deste trabalho.................................................................................................... 24

2 PESQUISA BIBLIOGRÁFICA ................................................................................... 25

2.1 Cenário Atual Sobre os Problemas de Segurança no Desenvolvimento

de Sistemas Web .......................................................................................................................... 26

2.2 Conceitos Básicos Sobre Segurança ...................................................................................... 27

2.3 Entidades e Normas Sobre Segurança Web .......................................................................... 29

2.3.1 ISO ..................................................................................................................................... 29

2.3.2 IEC ..................................................................................................................................... 29

2.3.3 ISO/IEC 27002 .................................................................................................................. 29

2.3.4 CERT.br ............................................................................................................................ 30

2.3.6 WhiteHat Security ............................................................................................................ 31

2.4 Vulnerabilidades de Segurança no Desenvolvimento de Sistemas Web ............................... 31

2.4.1 Injeção (Injection) ............................................................................................................. 32

2.4.2 Scripting de Site Cruzado (Cross-Site Scripting - XSS) .................................................. 33

2.4.2.1 XSS Refletido ................................................................................................................ 34

2.4.2.2 XSS Armazenado .......................................................................................................... 34

2.4.2.3 XSS Baseado em DOM ................................................................................................. 35

2.4.3 Autenticação e Gerenciamento de Sessão Quebradas (Broken

Authentication and Session Management) ................................................................................ 35

2.4.4 Referência Insegura e Direta a Objetos (Insecure Direct Object

Forgery - CSRF) .........................................................................................................................37

2.4.6 Má Configuração de Segurança (Security Misconfiguration)........................................38

2.4.7 Armazenamento Inseguro de Criptografia (Insecure

Cryptographic Storage) ...............................................................................................................39

2.4.8 Falha de Restrição de Acesso à URL (Failure to Restrict URL

2.4.9 Proteção Insuficiente da Camada de Transporte (Insufficient