Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson...

104
UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO CONTROLES DE SEGURANÇA DE DADOS ACESSADOS VIA APLICAÇÕES WEB Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo Roberto Riccioni Gonçalves, M.Sc. Orientador São José (SC), Julho de 2008

Transcript of Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson...

Page 1: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR

CURSO DE CIÊNCIA DA COMPUTAÇÃO

CONTROLES DE SEGURANÇA DE DADOS ACESSADOS VIA APLICAÇÕES WEB

Segurança de Sistemas

por

Sanderson Scheuer Mocelin

Paulo Roberto Riccioni Gonçalves, M.Sc. Orientador

São José (SC), Julho de 2008

Page 2: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR

CURSO DE CIÊNCIA DA COMPUTAÇÃO

CONTROLES DE SEGURANÇA DE DADOS ACESSADOS VIA APLICAÇÕES WEB

Segurança de Sistemas

por

Sanderson Scheuer Mocelin Relatório apresentado à Banca Examinadora do Trabalho de Conclusão do Curso de Ciência da Computação para análise e aprovação. Orientador: Paulo Roberto Riccioni Gonçalves, M.Sc.

São José (SC), Julho de 2008

Page 3: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

DEDICATÓRIA

Dedico este trabalho aos amigos e familiares.

Page 4: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

AGRADECIMENTOS

Agradeço a Deus, todos os dias de minha vida, por ter me dado, a chance de voltar a estudar e a

direção correta para alcançar meu objetivo. Agradeço, também, a todos os meus amigos e

familiares, que deram muito apoio nesta jornada e, principalmente, à prima Patrícia Matos Scheuer

por ter ajudado com a organização deste trabalho. Agradeço, também, ao meu amigo Maiko

Eskelsen pela ajuda com o sistema operacional Open Suse. E, em especial, agradeço ao meu

orientador, professor e mestre, Paulo Roberto Riccioni Gonçalves.

Muito obrigado a todos vocês!

Page 5: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

SUMÁRIO

LISTA DE ABREVIATURAS .............................................................. vii

LISTA DE FIGURAS ........................................................................... viii

LISTA DE TABELAS ..............................................................................x

RESUMO ................................................................................................ xi

ABSTRACT ........................................................................................... xii

1 INTRODUÇÃO .....................................................................................1

1.1 PROBLEMATIZAÇÃO ................................................................................... 3

1.1.1 Formulação do Problema............................................................................... 3

1.1.2 Solução Proposta ............................................................................................ 3

1.2 OBJETIVOS ..................................................................................................... 3

1.2.1 Objetivo Geral ................................................................................................ 3

1.2.2 Objetivos Específicos...................................................................................... 4

1.3 METODOLOGIA ............................................................................................. 4

1.4 ESTRUTURA DO TRABALHO ..................................................................... 5

2 FUNDAMENTAÇÃO TEÓRICA .......................................................6

2.1 CONCEITOS BÁSICOS DE SEGURANÇA .................................................. 6

2.2 AMEAÇAS DE SEGURANÇA ........................................................................ 8

2.2.1 Ataques de Injeção de SQL............................................................................ 9

2.2.2 Ataques de Negação de Serviço ................................................................... 12

2.2.3 Cavalo de Tróia ............................................................................................ 13

2.2.4 Forjamento de IP ......................................................................................... 14

2.2.5 Análise de Riscos .......................................................................................... 15

2.3 REQUISITOS DE SEGURANÇA ................................................................. 16

2.4 CONTROLES E MECANISMOS DE SEGURANÇA PARA APLICAÇÕES WEB ............................................................................................. 17

2.4.1 Segurança na Web........................................................................................ 20

2.4.2 Proteção de Servidores Web ........................................................................ 21

2.4.3 Violação em Navegadores ............................................................................ 21

2.4.4 Política de segurança .................................................................................... 22

2.4.5 Mecanismo de Criptografia ......................................................................... 25

2.4.5.1 Criptografia de Chaves Simétricas ........................................................... 26

2.4.5.2 Criptografia de Chaves Assimétricas (Públicas) ...................................... 27

2.4.5.3 Ataques Referentes às Chaves de Criptografia ........................................ 32

2.4.6 Mecanismos de Controles de Acesso ........................................................... 33

2.4.7 Diretrizes de Injeção de SQL ....................................................................... 34

2.4.8 Firewall ......................................................................................................... 36

3 Desenvolvimento .................................................................................37

3.1 MODELAGEM DO ESTUDO DE CASO ..................................................... 40

Page 6: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

vi

3.2 IMPLEMENTAÇÃO DOS CONTROLES DE SEGURANÇA ................... 48

3.2.1 Diretrizes de controle contra ataque de injeção de SQL ............................ 49

3.2.2 Análise de controles criptográficos.............................................................. 51

3.2.3 Segurança do Servidor Web ........................................................................ 56

3.2.4 Testes dos Controles de Segurança e Desempenho..................................... 58

3.2.5 Análise de Riscos .......................................................................................... 70

4 CONCLUSÕES ..................................................................................75

REFERÊNCIAS BIBLIOGRÁFICAS ..................................................77

GLOSSÁRIO ..........................................................................................80

Page 7: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

vii

LISTA DE ABREVIATURAS

AC Autoridade Certificadora AES Advanced Encryption Standard ANSI American National Standards Institute ASP Active Server Pages CERT Computer Emergency Response Team CIA Central Intelligence Agency CPF Cadastro de Pessoas Físicas DES Data Encryption Standard DMZ DeMilitarized Zone DoS Denial of Service EUA Estados Unidos da America E/S Entra e Saída FBI Federal Bureau of Investigation HTTP Hyper Text Transfer Protocol IDEA Internationnal Data Encryption Algorithm IP Internet Protocol ISO International Standards Organization MD5 Message Digest 5 PGP Pretty Good Privacy PHP Hypertext Preprocessor RF Requisitos Funcionais RNF Requisitos não Funcionais RSA Ron Rivest, Adi Shamir e Len Adleman SGBD Sistema de Gerenciamento de Banco de Dados SO Sistema Operacional SQL Structured Query Language SSL Secure Sockets Layer TCC Trabalho de Conclusão de Curso UML Unified Modeling Language UNIVALI Universidade do Vale do Itajaí WWW World Wide Web

Page 8: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

viii

LISTA DE FIGURAS

Figura 1. Visão geral das aplicações Web dinâmicas. ...................................................................... 1 Figura 2. Ataque Mascaramento ...................................................................................................... 8 Figura 3. Ataque referente às aplicações Web que acessam informações ......................................... 9 Figura 4. Formulário HTML .......................................................................................................... 11 Figura 5. Injeção de SQL em formulários HTML .......................................................................... 11 Figura 6. Funcionamento da negação de serviço ............................................................................ 12 Figura 7. Cavalo de Tróia .............................................................................................................. 13 Figura 8. Ataque de Spoofing (Forjamento de IP) .......................................................................... 14 Figura 9. Componentes do risco e medidas de proteção usadas para reduzi-lo ............................... 19 Figura 10. Política de segurança e seus relacionamentos ................................................................ 23 Figura 11. Cifragem e decifragem ................................................................................................. 25 Figura 12. Funcionamento da criptografia assimétrica ................................................................... 28 Figura 13. Assinatura digital .......................................................................................................... 28 Figura 14. Hash ............................................................................................................................. 29 Figura 15. MD5 ............................................................................................................................. 30 Figura 16. Handshake.................................................................................................................... 31 Figura 17. Ataque Replay .............................................................................................................. 33 Figura 18. Ataque de criptografia referente à força bruta. .............................................................. 33 Figura 19. Sistema de Controle de Acesso ..................................................................................... 34 Figura 20. Situação atual do estudo de caso ................................................................................... 37 Figura 21. Funcionamento desejado do estudo de caso .................................................................. 38 Figura 22. Etapa do processo abordada neste projeto ..................................................................... 38 Figura 23. Caso de uso do estudo de caso, cadastro de usuários ..................................................... 40 Figura 24. Caso de uso do estudo de caso, cadastro de compatibilidades ....................................... 42 Figura 25. Caso de uso do estudo de caso cadastro de grupos ........................................................ 43 Figura 26. Caso de uso do estudo de caso cadastro de produtos ..................................................... 45 Figura 27. Caso de uso do estudo de caso de enviar e-mail, imprimir, login e análise de riscos ...... 46 Figura 28. Diretrizes de injeção de SQL em formulário de autenticação ........................................ 51 Figura 29. Limitação da quantidade de caracteres no formulário de autenticação ........................... 51 Figura 30. Classe de criptografia simétrica .................................................................................... 53 Figura 31. Como gerar certificado para o Apache Tomcat ............................................................. 54 Figura 32. Server.xml servidor Web Apache Tomcat ..................................................................... 54 Figura 33. Classe que criptografa as senhas do estudo de caso ....................................................... 56 Figura 34. Serviço autorizado pelo firewall do Open Suse ............................................................. 57 Figura 35. Porta liberada pelo firewall do Open Suse..................................................................... 57 Figura 36. Teste das diretrizes de injeção de SQL no JUnit............................................................ 60 Figura 37. Resultado do teste de injeção de SQL no JUnit ............................................................. 60 Figura 38. Criptografia de senhas com o algoritmo MD5 ............................................................... 61 Figura 39. Resultado do teste da criptografia de senha ................................................................... 62 Figura 40. Teste do algoritmo criptográfico simétrico .................................................................... 63 Figura 41. Resultado do teste da criptografia simétrica .................................................................. 63 Figura 42. Escolha do uso do protocolo SSL ................................................................................. 63 Figura 43. Certificado utilizado no protocolo SSL do estudo de caso ............................................. 64 Figura 44. Classe que calcula o tempo de processamento ............................................................... 64 Figura 45. Utilização da classe que calcula o tempo ...................................................................... 65 Figura 46. Tempo de processamento do salvar usuário .................................................................. 65

Page 9: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

ix

Figura 47. Etapas da gestão do risco .............................................................................................. 73

Page 10: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

x

LISTA DE TABELAS

Tabela 1. Exemplo de medidas preventivas e reativas e de métodos detectivos para a proteção da informação ............................................................................................................................ 18

Tabela 2. Requisitos do sistema ..................................................................................................... 38 Tabela 3: Salvar usuário ................................................................................................................ 40 Tabela 4: Buscar usuário ............................................................................................................... 41 Tabela 5: Excluir usuário ............................................................................................................... 41 Tabela 6: Salvar compatibilidade ................................................................................................... 42 Tabela 7: Buscar compatibilidade .................................................................................................. 42 Tabela 8: Excluir compatibilidade ................................................................................................. 43 Tabela 9: Salvar grupo .................................................................................................................. 43 Tabela 10: Buscar grupo ................................................................................................................ 44 Tabela 11: Excluir grupo ............................................................................................................... 44 Tabela 12: Salvar produto.............................................................................................................. 45 Tabela 13: Buscar produto ............................................................................................................. 46 Tabela 14: Excluir produto ............................................................................................................ 46 Tabela 15: Enviar e-mail ............................................................................................................... 47 Tabela 16: Imprimir ...................................................................................................................... 47 Tabela 17. Login do sistema ......................................................................................................... 47 Tabela 18. Análise de Riscos ......................................................................................................... 48 Tabela 19. Cálculo do tempo de processamento com e sem o controle de segurança ...................... 66 Tabela 20. Tipos de impactos ........................................................................................................ 70 Tabela 21. Os riscos do estudo de casos......................................................................................... 71

Page 11: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

xi

RESUMO

MOCELIN, Sanderson Scheuer. Controles de Segurança de dados acessados via Aplicações Web São José, 2008. 104 f. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação) – Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, São José, 2008.

Com o uso da Internet por instituições coorporativas, governamentais e educacionais, a preocupação com a segurança das informações tem aumentado. Qualquer organização engajada em atividades que usem a rede mundial de computadores deve avaliar a segurança computacional associada a estas atividades. As aplicações Web vem sofrendo vários ataques direcionados aos dados processados por estas. Os serviços com maior quantidade de ataques são os de: publicidade, comércio eletrônico, informações confidenciais e acesso à rede. Este trabalho tem o objetivo de implementar mecanismos de segurança que visem minimizar e/ou contornar as ameaças aos dados acessados por uma aplicação Web. Esta implementação dar-se-á por meio de um estudo de caso utilizando a tecnologia Java Web, que é descrita como um configurador de software para micro computador que tenha acesso à Internet ou Intranet. Este configurador oferece a opção de cadastrar, consultar, alterar e/ou excluir: grupos; produtos; usuários; e a compatibilidade entre os grupos e produtos. Com o uso deste configurador os funcionários e os administradores do sistema podem enviar informações dos produtos para os clientes via e-mail, e/ou imprimir as informações dos produtos. Este software utiliza o banco de dados PostgreSQL para armazenar as informações, pois é robusto e de código livre. Além de implementar os mecanismos de segurança, foi elaborado um roteiro para a realização de análise de riscos que visa avaliar os riscos do ambiente computacional. Palavras-chave: Segurança. Ameaças. Aplicação Web.

Page 12: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

xii

ABSTRACT

With the use of the Internet at corporation, governmental institutions and educational institutions, the bother with the security of the information has increased to each day; therefore, any organization engaged in activities that use the world-wide net of computers must evaluate the associated computational security to these activities. A great part of the Web applications comes suffering some attacks directed to the data processed for these. The services with bigger amount of attacks are of: advertising, electronic commerce, confidential information and access the net. This paper has the target to develop a security mechanisms that to direct to minimize and/or to avert the threats to the access data way of Web applications. This implementation will be made through a case study, which is implemented in an application that uses technology Java Web, that is described as a setting of software for computer that has access the Internet or Intranet, giving the option to register in cadastre, to consult and/or to exclude: groups, products, users and compatibility between the groups and products. With the use of this setting, the users and/or system administrators can to sent information of the products for the customers by email, or the same ones still can print the information of the products. This work use the PostgreSQL database to store the information because it is open source and robust. Further implementing the security mechanisms, I did a script for the accomplishment of analysis of risks that to focus to evaluate the computational environment.

Keywords: Security. Threats. Web application.

Page 13: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

1 INTRODUÇÃO

Com a evolução da Internet, principalmente, em relação ao aumento da velocidade de

transmissão e do desenvolvimento de tecnologias que permitem a criação de sistemas robustos, em

especial, no ambiente Web, muitas empresas estão fazendo da Internet seu escritório.

Este trabalho está direcionado para aplicações Web com conteúdo dinâmico. As aplicações

Web dinâmicas atendem às necessidades de interação com os usuários em tempo real. Estas

aplicações utilizam algumas linguagens de programação específicas, por exemplo: ASP (Active

Server Pages), PHP (Hypertext Preprocessor), Java, entre outras, conforme ilustrado na Figura 1.

Estas aplicações geralmente necessitam ter acesso aos dados armazenados nos bancos de dados da

própria empresa para cumprir suas funcionalidades.

Figura 1. Visão geral das aplicações Web dinâmicas.

Como o uso da Internet está cada vez mais freqüente em instituições coorporativas,

governamentais e educacionais, a preocupação com a segurança das informações tem aumentado a

cada dia, pois qualquer organização, engajada em atividades que usem a rede mundial de

computadores, deve avaliar a segurança computacional associada a estas atividades (BURNETT &

PAINE, 2002).

Um estudo realizado pela empresa de segurança Acunetix relatou, que sete em cada dez

sistemas Web possuem vulnerabilidades de segurança, que permitiriam ataques de intrusos aos seus

dados (PAES, 2007).

A segurança das informações é um dos pontos de maior relevância no contexto da Internet e

das aplicações Web. Segundo a ISO 17799 (2000), as informações são ativos que, como qualquer

outro ativo importante para a empresa, possui um imenso valor e, conseqüentemente, precisam ser

protegidos adequadamente. A proteção de informações deve tratar uma ampla gama de ameaças

Page 14: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

2

com o objetivo de assegurar a continuidade dos negócios, minimizar os prejuízos e maximizar o

retorno de investimentos e oportunidades comerciais.

Date (2004) afirma que nenhum sistema de segurança é perfeito, pois quando um invasor é

determinado, este encontrará diversas vulnerabilidades no sistema, podendo até quebrar os controles

impostos. Neste caso, torna-se importante impor uma auditoria interna e periódica dos controles de

segurança.

As propriedades de segurança que os sistemas computacionais deverão garantir são

(LANDWEHR, 2001; ISO 17799, 2000):

• confidencialidade: garante que as informações serão lidas somente por usuários

autorizados;

• integridade: garante que os dados não serão modificados ou removidos por usuários

não autorizados;

• disponibilidade: garante que usuários legítimos não terão o acesso indevidamente

negado a informações e recursos;

• autenticidade: garante que um sujeito usando uma identificação é seu verdadeiro

detentor; e

• não-repudiação: garante que um participante da comunicação não possa negá-la

posteriormente.

Conforme definido na ISO 17799 (2000), a confidencialidade, a integridade e a

disponibilidade das informações podem ser essenciais para manter a competitividade nos negócios

das empresas. Sendo assim, deve haver uma preocupação e uma ação que antecipe os problemas e,

não simplesmente procure solucioná-los depois. Por isso, as empresas, no que se refere à segurança,

também devem se preocupar com a preparação dos seus funcionários, visando oferecer

treinamentos contra qualquer possível atentado às informações. Todos os funcionários da

organização devem ser treinados seguindo um manual específico baseado em uma política de

segurança (DIAS, 2000).

Segundo Santos (2007), o estudo da ScanAlert realizado em São Francisco com 27 mil sites

de comércio eletrônico detectou que, 50% das lojas virtuais estão vulneráveis a ataques de

criminosos, estatística publicada em 07 de fevereiro de 2007.

A segurança das informações é obtida por meio da implementação de um conjunto adequado

de controles e regras, que podem ser políticas, práticas, procedimentos, estruturas organizacionais e

funções de software. Esses controles precisam ser estabelecidos para assegurar que os objetivos de

segurança específicos da organização sejam alcançados (ISO 17799, 2000).

Page 15: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

3

Neste trabalho, foram analisadas as ameaças de segurança às quais os dados estão

sucessíveis e os diferentes controles de segurança existentes, visando destacar os mais adequados

para prover segurança para os dados acessados por uma aplicação Web.

Observando esta preocupação com a segurança, a Netscape desenvolveu em 1994 um

protocolo de segurança chamado SSL (Secure Sockets Layer) que usa um esquema criptográfico

híbrido para prover um canal seguro entre duas partes. Este protocolo está implementado em quase

todos os navegadores Web e é o mecanismo criptográfico mais utilizado no desenvolvimento de

aplicações Web seguras. Como as duas partes envolvidas na comunicação terão um segredo

compartilhado, então o SSL garante a confidencialidade, a integridade e autenticidade das

mensagens trocadas (BURNETT & PAINE, 2002).

A criptografia pode ser classificada como simétrica ou assimétrica. Segundo Burnett e Paine

(2002), criptografia simétrica é quando se usa apenas uma chave, tanto para cifrar como para

decifrar, já a criptografia assimétrica usa duas chaves, uma chave para cifrar e outra chave para

decifrar a mensagem.

1.1 PROBLEMATIZAÇÃO

1.1.1 Formulação do Problema

Foi feito um levantamento e análise das possíveis ameaças de segurança aos dados

acessados via aplicações Web, focado em um estudo de caso.

1.1.2 Solução Proposta

Definir e implantar um conjunto de mecanismos de segurança a partir de um estudo de caso,

que visam minimizar e/ou contornar as ameaças.

1.2 OBJETIVOS

1.2.1 Objetivo Geral

Implementar mecanismos de segurança em um estudo de caso que visam minimizar e/ou

contornar ameaças aos dados acessados pelas aplicações Web.

Page 16: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

4

1.2.2 Objetivos Específicos

De forma a alcançar o objetivo geral definido, os seguintes objetivos específicos serão

perseguidos:

• analisar as principais ameaças e vulnerabilidades nas quais os dados manipulados via

aplicações Web, estão suscetíveis;

• modelar e implementar o estudo de caso; e

• integrar os mecanismos de segurança que visam minimizar e contornar ameaças aos

dados acessados pelas aplicações Web.

1.3 Metodologia

A metodologia do desenvolvimento deste trabalho foi dividida em seis etapas: (i) Estudo,

pesquisa e levantamento bibliográfico; (ii) Identificação das necessidades de segurança em

aplicações Web; (iii) Modelagem; (iv) Desenvolvimento; (v) Validação e (vi) Documentação. Cada

etapa foi executada de acordo com as informações a seguir.

Estudo, pesquisa e levantamento bibliográfico: Esta etapa consistiu em efetuar pesquisas,

estudos e levantamentos bibliográficos sobre: conceitos básicos de segurança, ameaças de

segurança, requisitos de segurança em aplicações Web, controles e mecanismos para segurança de

aplicações Web. Sendo assim, foram estudados definições, conceitos, características e importâncias

de cada mecanismo de segurança, em um estudo de caso, tendo como ponto de partida uma análise

de riscos.

Identificação das necessidades de segurança em aplicações Web: Nesta etapa foram

identificadas as necessidades e vulnerabilidades de aplicações Web, buscando citar soluções para

cada ataque citado.

Modelagem: A modelagem do estudo de caso foi uma das principais atividades desse

trabalho e foi o foco desta etapa. Para o sucesso desta modelagem foi necessário aplicar os

conceitos estudados na primeira etapa e elaborar uma análise de riscos do estudo de caso, citando as

soluções mais indicadas para os riscos apontados. Esta etapa foi fundamental para sucesso deste

projeto.

Page 17: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

5

Desenvolvimento: Esta etapa consistiu no desenvolvimento de mecanismos de segurança

para o estudo de caso. Todas as etapas anteriores foram necessárias para sucesso deste

desenvolvimento. A implementação dos mecanismos de segurança, que resolvam os riscos

apontados pela análise de riscos, foi a principal tarefa desta etapa, considerando que a análise de

riscos é um ponto crítico no desenvolvimento dos controles de segurança do estudo de caso.

Validação: Na validação foram avaliadas as necessidades de segurança apontadas pela

análise de riscos e, se as mesmas foram atendidas.

Documentação: Esta etapa consistiu na revisão e na correção de toda a documentação deste

trabalho e o incremento necessário.

1.4 Estrutura do trabalho

Este documento está estruturado em quatro capítulos. No Capítulo 1, a Introdução, apresenta

uma visão geral do trabalho.

No Capítulo 2, a Fundamentação Teórica apresenta uma revisão bibliográfica sobre: a

segurança de dados acessados via aplicações Web, enfocando uma descrição dos possíveis ataques

aos dados acessados via aplicações Web, os requisitos de segurança que estas aplicações devem

satisfazer, e os controles e mecanismos de segurança existentes.

O Capítulo 3 apresenta o desenvolvimento detalhado dos controles de segurança via

aplicações Web, incluindo a sua especificação e a modelagem em Unified Modeling Language

(UML). Este capítulo também discute a implementação do sistema proposto.

No Capítulo 4, apresentam-se as conclusões e são abordados os resultados alcançados. O

texto ainda inclui as referências bibliográficas e apêndices que complementam as informações

apresentadas no trabalho.

Page 18: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

2 FUNDAMENTAÇÃO TEÓRICA

Este capítulo está dividido em seções, sendo que: na Seção 2.1 define-se os conceitos

básicos de segurança; na Seção 2.2 as possíveis ameaças de segurança, tais como: injeção de SQL

(Structured Query Language), negação de serviço, buffer overflow, entre outros. Na Seção 2.3 são

descritos os requisitos de segurança para que a aplicação Web se torne segura e, na Seção 2.4 estão

descritos alguns controles para garantir a segurança dos dados acessados via aplicações Web, tais

como: política de segurança, mecanismos de controles de acesso, entre outros.

2.1 CONCEITOS BÁSICOS DE SEGURANÇA

Conforme descrito na ISO 17799 (2000), a segurança de informações visa proteger as

informações contra uma ampla gama de ameaças para garantir a continuidade dos negócios,

minimizar os prejuízos e maximizar o retorno de investimentos e oportunidades comerciais.

Para tratar as ameaças de segurança via aplicações Web é preciso definir alguns conceitos

básicos de segurança (BEAL, 2005; DIAS, 2000; GIL, 1998):

• recursos: são componentes de sistemas, podendo ser recurso físico, software,

hardware ou informação;

• intruso: fonte que produz eventos, que podem ter efeitos adversos sobre as

informações;

• ameaças: são eventos ou atitudes indesejáveis que podem remover, desabilitar,

danificar ou destruir alguns recursos;

• vulnerabilidade: é a fraqueza ou deficiência que pode ser explorada por uma

ameaça para concretizar um ataque e ainda pode ser associada à probabilidade da

ameaça ocorrer;

• ataques (ameaça contextualizada): são eventos decorrentes das explorações de

vulnerabilidades por uma ameaça;

• impactos: são conseqüências das violações de segurança do sistema; e

• riscos: medida da exposição a qual o sistema computacional está sujeito, ou seja, é a

probabilidade de uma vulnerabilidade ser explorada ou de uma ameaça ser

concretizada.

Segundo Beal (2005) e Dias (2000), as ameaças são classificadas como acidentais ou

intencionais:

Page 19: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

7

• acidentais: ocorre quando não existe intenção, por exemplo: falha de hardware, erros

de programação, desastres naturais, erros do usuário, bugs de software, entre outros;

e

• intencionais ou deliberadas: ocorre quando existe alguma intenção, por exemplo:

roubo, espionagem, fraude, sabotagem, invasão de intrusos, entre outros.

Neste trabalho, serão tratadas somente as ameaças de segurança intencionais causadas por

intrusos que exploram vulnerabilidades nos sistemas.

Os ataques podem ser passivos ou ativos (DIAS, 2000; KUROSE & ROSS, 2005). Os

ataques passivos podem invadir/monitorar, mas sem que haja alterações de informações,

ameaçando apenas a confidencialidade das informações. Já os ataques ativos estão ligados à

alteração dos dados, realizando assim a quebra da integridade e da disponibilidade. Segundo Dias

(2000, p.56), “a magnitude das ameaças deliberadas está diretamente relacionada com a

oportunidade, motivação e a forma com que são punidas e detectadas as quebras de segurança”.

Segundo Dias (2000), as violações fundamentais causadas por intrusos são:

• a revelação não autorizada das informações;

• a modificação não autorizada das informações; e

• a negação indevida de serviços (impedimento de acesso aos recursos).

De acordo com Dias (2000, p.56), “existem quatro formas de caracterizar as ameaças que ao

se efetivarem em um ataque, permitem a realização de uma ou mais ameaças fundamentais citadas

acima”:

• o mascaramento: quando um intruso se faz passar por um usuário autorizado, como

ilustra a Figura 2;

• o desvio de controles (bypass): quando o intruso explora as falhas do sistema e

vulnerabilidades burlando os controles para ter acesso não autorizado;

• a violação autorizada: quando algum usuário ou sistema autorizado usa os sistemas

com objetivos não autorizados; e

• as ameaças programadas: quando o código do software é armazenado com intuito

de comprometer a segurança, alterando o comportamento, violando os controles de

segurança, alterando ou destruindo dados, por exemplo: cavalo de tróia.

Page 20: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

8

Figura 2. Ataque Mascaramento

2.2 AMEAÇAS DE SEGURANÇA

As vulnerabilidades lógicas observadas em sistemas conectados na Internet incluem: as

atualizações que fornecem segurança aos servidores Web, que não são aplicadas adequadamente

pelos administradores; e a permanência de ferramentas de administração que, em muitos casos,

tornam o servidor Web inseguro (BEAL, 2005).

De acordo com Gomes (2000), existem vulnerabilidades que permitem que os intrusos

ganhem acesso não autorizado à aplicação Web. As explorações de vulnerabilidades podem

danificar parcialmente ou completamente a aplicação. Um exemplo típico é a falha na configuração

do servidor Web. Portanto, as vulnerabilidades encontradas nestes sistemas permitem que os

intrusos tenham acesso total ao servidor Web (GOMES, 2000).

Conforme Silberschatz (1999), os dados precisam ser protegidos contra acessos não

autorizados, destruição ou alteração. Segundo o autor, as perdas intencionais são as seguintes: roubo

de informação; alteração não autorizada dos dados; e destruição não autorizada de dados.

A segurança de dados acessados via aplicações Web visa garantir que os usuários terão

permissão de fazer o que for permitido (DATE, 2000). A Figura 3 ilustra os principais ataques de

segurança relacionados às aplicações Web. Estes ataques serão descritos nas próximas seções.

Page 21: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

9

Figura 3. Ataque referente às aplicações Web que acessam informações

Conforme ilustrado na Figura 3, o intruso, por meio de um navegador, pode invadir a

aplicação Web e ter acesso aos dados, podendo realizar alguns ataques, tais como: o mascaramento,

o monitoramento e a injeção de SQL. Mas o mesmo ainda pode invadir o servidor Web e realizar

alguns ataques com objetivo de capturar informações por meio: do mascaramento, da revelação não

autorizada de informações, do bypass, da negação de serviço e/ou inserir um cavalo de tróia na

aplicação. Nas próximas seções, serão apresentados os seguintes ataques: injeção de SQL

(Structured Query Language), negação de serviço, cavalo de tróia e Forjamento de IP (Internet

Protocol).

2.2.1 Ataques de Injeção de SQL

Os bancos de dados acessados por aplicações Web estão comumente vulneráveis aos ataques

conhecidos como injeção de SQL (MACORATTI, 2007; MICROSOFT CORPORATION, 2004). A

injeção de SQL não é nada mais que uma forma especializada de enviar strings de caráter nocivo

para a aplicação, que busca burlar a validação de entrada dos dados que manipulam os bancos de

dados das aplicações (MACORATTI, 2007; MICROSOFT CORPORATION, 2004).

As aplicações Web dinâmicas utilizam muito o acesso ao banco de dados para armazenar

diversas informações tais como: endereços e documentos pessoais, contas e valores financeiros,

números de cartões de crédito, dados empresariais, entre outros.

O SQL é uma linguagem estruturada que foi o padrão aceito pela ANSI (American National

Standards Institute) e pela ISO (International Standards Organization – CHAPELA, 2005). O SQL

Page 22: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

10

foi criado para manipular o banco de dados permitindo a execução de strings que podem executar

consultas, obtenção de dados, inserção de novos registros, alteração e deleção dos mesmos, além de

comandos específicos que permitem a administração do Sistema Gerenciador de Banco de Dados

(SGBD – GRÉGIO et al, 2005; CHAPELA, 2005). A maioria dos SGBDs possui os seus próprios

comandos particulares, além do padrão do SQL (CHAPELA, 2005).

A injeção de SQL ocorre quando um intruso tenta acessar ou modificar informações em um

banco de dados de forma indevida por meio da determinada aplicação, conseguindo ter acesso às

informações armazenadas no banco de dados de forma indevida (CARDOSO & SILVA, 2005;

MACORATTI, 2007; MICROSOFT CORPORATION, 2004). Quase todos os SGBDs e linguagens

de programação são potencialmente vulneráveis a este tipo de ataque (CHAPELA, 2005). As

aplicações Web que executam comandos SQL em determinada base de dados e não possuem

tratamento adequado de entrada de dados, estão vulneráveis a este tipo de ataque (CHAPELA,

2005; MACORATTI, 2007).

Os desenvolvedores de aplicações Web podem nem perceber a vulnerabilidade deixada

pelas aplicações Web, pois os mesmos, na maioria das vezes, não conhecem a fundo este problema,

já que o grande problema pode estar em uma simples tela de login sem os tratamentos adequados

(CHAPELA, 2005). Esta tela de login pode ser então uma porta aberta para a entrada de ataques

maliciosos, por meio da injeção de SQL (CARDOSO & SILVA, 2005).

A seguir, serão apresentados alguns passos para realizar a injeção de SQL com sucesso

(CHAPELA, 2005; MICROSOFT CORPORATION, 2004):

Passo 1: testar a utilização dos caracteres como apóstrofe, comandos SQL, entre outros;

Passo 2: analisar os erros gerados pela aplicação Web, com base no preenchimento das

informações digitadas pelo intruso;

Passo 3: manipular os campos de entrada de dados para saber a estrutura de bases,

tabelas e colunas; e

Passo 4: obter as informações propriamente ditas e verificar a possibilidade de obter

informações ou executar comandos no servidor.

Para ilustrar o funcionamento de uma injeção de SQL, será mostrado um exemplo de

mecanismo de autenticação baseado em formulários, com base no exemplo de Cardoso e Silva

(2005). Supondo que um intruso decida invadir uma aplicação Web a partir de um formulário de

login HTML (Hyper Text Markup Language), como mostra a Figura 4. O intruso começaria

testando e observando se o uso de apóstrofe está sendo tratado pela aplicação (Passo 1). A presença

de um caractere de apóstrofe (‘) no conteúdo de uma variável concatenada no SQL serve para

Page 23: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

11

delimitar comandos de texto. Para executar o Passo 1, o intruso entra com alguns dados na tela de

identificação do usuário, conforme a Figura 5 (linhas 1 e 2).

A falta de tratamento da apóstrofe causará o seguinte erro de SQL: Incorrect Syntax,

representado pela Figura 5 (linha 3). Observando este erro, o intruso pode deduzir que a página em

que o mesmo pretende invadir não trata a injeção de SQL (Passo 2). Em seguida, o intruso verifica

se o nome do usuário é admin ou administrador já que a senha, se não tiver tratamento de injeção de

SQL, sempre será verdadeira, pois o intruso poderá inserir no campo senha a expressão booleana

‘OR 1 = 1 -- (que é sempre uma sentença verdadeira), como mostra a Figura 5 (linhas 4 e 5). Ou

seja, se existir o usuário admin ou administrador, o intruso entrará no sistema. A Figura 5 (linha 6)

ilustra o comando SQL que a aplicação executará em sua base de dados de acordo com os dados

que foram preenchidos pelo intruso no formulário de login da aplicação Figura 5 (linhas 4 e 5) e

após preenchê-los o mesmo aciona o botão “Entrar”.

No Passo 3, o intruso executará alguns comandos no formulário de login da aplicação, como

foi descrito na Figura 5 (linhas 7 e 8), com objetivo de listar os nomes das tabelas do banco de

dados da aplicação Web. Já no Passo 4, o intruso tentará descobrir os tipos de dados de cada

variável da tabela do banco de dados, como ilustra a Figura 5 (linhas 9 e 10). A solução mais

indicada para evitar este ataque está descrita na Seção 2.4.7.

Figura 4. Formulário HTML

Figura 5. Injeção de SQL em formulários HTML

Page 24: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

12

2.2.2 Ataques de Negação de Serviço

O ataque referente à negação de serviço (DoS - Denial of Service) acontece quando os

intrusos exploram as vulnerabilidades dos sistemas e dos protocolos de comunicação e usam esta

técnica para esgotar temporariamente ou completamente os recursos do servidor onde se encontram

as aplicações Web, até que os usuários autorizados não consigam mais acessar ou sequer utilizar o

recurso, causando assim a indisponibilidade do serviço (GRÉGIO et al, 2005; GOMES, 2000). A

Figura 6 ilustra este tipo de ataque.

Figura 6. Funcionamento da negação de serviço

Neste ataque, ilustrado pela Figura 6, no Passo 1, o intruso acessa os serviços do servidor

Web com objetivo de impedir que usuários autorizados possam acessar estes serviços, ou seja, o

intruso esgota os serviços do servidor Web, para que nenhum usuário autorizado consiga acessar

(Passo 2). Estes ataques acabam causando diversos problemas para os serviços de redes em geral,

porém, o objetivo do intruso neste tipo de ataque é tentar sobrecarregar os recursos alvos, incluindo

a largura de banda, o acesso a um servidor Web, o uso interno de memória, a capacidade de

processamento ou espaço em disco (GRÉGIO et al, 2005).

O buffer overflow ou estouro de buffer é um tipo de ataque de negação de serviço, que é a

vulnerabilidade mais comum em servidores Web (LOZANO, 2004). Este ataque, geralmente,

ocorre quando um número de dados é maior que o suportado e escrito pelo buffer, esta

vulnerabilidade ocorre quando os dados são lidos e/ou armazenados fora dos limites alocados para o

buffer (GRÉGIO et al, 2005).

Em um ataque chamado Arc Injection o intruso pode explorar um buffer overflow, inserindo

dados não executáveis em um buffer de tal forma que alguma função já existente no sistema irá

Page 25: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

13

utilizar estes dados como parâmetro de entrada (GRÉGIO et al, 2005). Este tipo de ataque é

referenciado como, um buffer overflow, podendo ser utilizado para modificar o endereço de retorno

para um lugar dentro do espaço de endereçamento do sistema (GRÉGIO et al, 2005). A solução

mais indicada para este ataque é o uso de firewall, com objetivo de controlar a quantidade de dados

que transitam pelo servidor Web.

2.2.3 Cavalo de Tróia

Este tipo de ataque acontece por meio de programas maliciosos não autorizados, que são

encapsulados em um programa legítimo que podem acessar os dados da aplicação, como ilustra a

Figura 7 (GOMES, 2000). Estes programas contêm funções desconhecidas que são inúteis para o

hospedeiro (GARFINKEL & SPAFFORD, 1999).

Segundo Dias (2000, p.64), Os cavalos de tróia são parecidos com programas que os clientes gostariam de executar, mas enquanto parece estar executando o que o cliente quer, na verdade o cavalo de tróia está fazendo algo que o intruso deseja. Nesse caso, tudo que o cliente consegue observar são telas adulteradas.

Figura 7. Cavalo de Tróia

De acordo com a Figura 7, o intruso invade o servidor Web explorando as suas

vulnerabilidades e insere um cavalo de tróia na aplicação Web, que realizará tarefas escondidas do

cliente e irá executá-las em background, para que o cliente não perceba (GOMES, 2000; DIAS,

2000). O objetivo do cavalo de tróia é danificar e/ou capturar informações confidenciais do cliente,

tais como: dados pessoais, senhas, números de cartões de crédito, entre outras informações

(GOMES, 2000; DIAS, 2000). Os controles mais indicados para evitar este tipo de ataque são: o

uso de firewall, que serve para proteger o servidor Web de acessos indevidos de intrusos; e o

mecanismo criptográfico, para manter a confidencialidade das informações.

Page 26: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

14

2.2.4 Forjamento de IP

Conforme Gomes (2000, p.188) “este ataque consiste na troca do IP original por outro,

podendo se passar por outro host. Ou seja, este tipo de ataque consiste na simulação de pacotes IP

em que o objetivo é dar autenticidade nas relações que envolvem trocas de informações”. Segundo

o autor, este ataque ocupa o quarto método de invasão mais utilizado em uso de computadores.

Como a Internet utiliza o endereço IP para identificar recursos e máquinas, sendo que a

relação de confiança é baseada na identificação IP, então se o intruso conseguir trocar o seu IP por

um IP autorizado, o mesmo passa a ser um usuário autorizado (GOMES, 2000).

Figura 8. Ataque de Spoofing (Forjamento de IP) Fonte: Gomes (2000).

Na Figura 8, o intruso sobrecarrega o servidor Web, fazendo com que o mesmo se torne

inutilizável, assim o intruso pode trocar o seu IP pelo do servidor Web e criar uma conexão

confiável com o cliente como se fosse o servidor Web. Desta forma, o intruso poderá ter acesso

total às informações do cliente enviadas ao “falso” servidor Web (intruso) (GOMES, 2000).

Existem algumas soluções para este ataque, tais como: o uso de firewall, que tem objetivo de evitar

que o intruso consiga realizar uma negação de serviço, para poder realizar a troca do IP original por

outro; e a criptografia dos dados que visa manter a confidencialidade das informações se forem

capturadas pelos intrusos.

Page 27: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

15

2.2.5 Análise de Riscos

Para Dias (2000), antes de definir como o sistema será protegido, é feita uma análise das

possíveis ameaças e vulnerabilidades do ambiente computacional, considerando todos os eventos

adversos que podem explorar as fragilidades de segurança e acarretar danos ao ambiente.

Segundo Dias (2000), o risco é utilizado como sinônimo de ameaça ou probabilidade de

ocorrer uma ameaça, ou seja, o risco é a combinação da ameaça, vulnerabilidade e impacto. Dias

(2000, p. 57) afirma que, A análise das ameaças e vulnerabilidades tenta definir a probabilidade de ocorrência de cada evento adverso e as conseqüências da quebra de segurança, já a análise de impactos identifica os recursos críticos do sistema, isto é, os recursos que mais sofrerão impactos na ocorrência de uma quebra de segurança.

Para tomar as diretrizes de segurança adequadas, deve-se primeiro: identificar e classificar

os ativos, as ameaças e os impactos; estudar a probabilidade da ameaça acontecer; fazer análise dos

danos; e entender os riscos (DIAS, 2000; AZEVEDO, 2002).

Os intrusos exploram os alvos para depois atacá-los (BEAL, 2005). A vulnerabilidade é que

determina a exposição de uma informação, ambiente ou sistema (BEAL, 2005). Não existe

metodologia perfeita para realizar uma análise de custo/benefício para armazenar a informação

(CARUSO & STEFFEN, 1999; BEAL, 2005). Segundo Beal (2005, p. 67), Análise de custo/beneficio é a soma das receitas e dos gastos decorrentes da indisponibilidade do sistema. A maneira mais eficiente de se efetuar a análise de custo/beneficio é fazer que os usuários finais de cada sistema de informação avaliem o valor das informações para a organização; quem trabalha com as informações no dia-a-dia é o mais indicado para fazer a análise de riscos.

De acordo com Dias (2000, p. 54), “se combater uma ameaça for mais caro do que o seu

dano potencial, talvez não seja aconselhável tomar qualquer medida preventiva neste sentido, tudo

depende da importância do recurso ameaçado para se ter a continuidade dos negócios”.

Caruso e Steffen (1999) afirmam que dentro de uma organização, cada setor sofre

conseqüências desiguais e às vezes causam danos ao seu funcionamento. As conseqüências podem

afetar os ativos ou processos (CARUSO & STEFFEN, 1999).

A classificação dos impactos é dividida em (CARUSO & STEFFEN, 1999):

• alto risco: quando uma organização como um todo tem suas atividades fortemente

reduzidas em um curto prazo, não permitindo a continuidade das atividades;

• médio risco: quando uma organização sofre dificuldades sérias que trazem prejuízos

sensíveis, mas não chegam a afetar a sobrevivência da organização como um todo; e

Page 28: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

16

• baixo risco: quando uma organização não é afetada de forma significativa pela

ocorrência da atividade.

Os intrusos dispõem de técnicas para poder descobrir as vulnerabilidades e para poder

planejar um ataque (TERADA, 2000). Segundo a ISO 17799 (2000), a avaliação de riscos pode ser

aplicada em toda organização, ou em frações dela, bem como em sistemas de informação

individual, componentes de sistemas específicos ou onde o serviço for praticável, realístico e útil.

De acordo com Beal (2005), a gestão de riscos coordena as atividades com o objetivo de

direcionar e de controlar uma organização com relação ao risco e, esta normalmente inclui: a

avaliação, o tratamento, a aceitação e a comunicação do risco. O autor também alega que, a gestão

de riscos é um conjunto de processos que permitem que as organizações possam identificar e

implementar as medidas de proteções necessárias para diminuir os riscos.

A ISO 17799 (2000) afirma que, para avaliar adequadamente os riscos deve-se estudar: as

ameaças, as facilidades de processamento das informações, os impactos, as vulnerabilidades e as

probabilidades de ocorrência do risco. Conforme Caruso e Steffen (1999), a etapa final da análise

de riscos é a geração do plano de segurança1. O plano de segurança deve ser montado em função da

organização, com o objetivo de suprir as necessidades (CARUSO & STEFFEN, 1999). Conhecer os

riscos que podem existir na aplicação é um modo de ganhar mobilidade (AZEVEDO, 2002)

2.3 REQUISITOS DE SEGURANÇA

Os requisitos de segurança em aplicações Web se resumem na necessidade de estabelecer

uma segurança exclusiva dos dados processados (CARUSO & STEFFEN, 1999). Mas uma

aplicação só será considerada segura se os objetivos de segurança forem alcançados e se houver

alguma garantia de que esta funcionará como esperado (CARUSO & STEFFEN, 1999; DIAS,

2000). Existem alguns objetivos de segurança que devem ser atendidos, para que uma aplicação

Web se torne segura, são estes: a confidencialidade, a integridade, a disponibilidade, a autenticidade

e a não-repudiação (GIL, 1999; ISO, 2000).

Conforme a ISO 17799 (2000, p. vii), É essencial que uma organização defina seus requisitos de segurança. Existem três fontes principais. A primeira fonte é derivada da avaliação dos riscos contra a organização. Através da avaliação de riscos as ameaças aos ativos são identificadas, a vulnerabilidade e a probabilidade de ocorrência são avaliadas e o impacto

1 Perspectiva geral dos riscos de segurança que uma organização enfrenta (CARUSO & STEFFEN, 1999).

Page 29: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

17

potencial é estimado. A segunda fonte são as exigências legais, estatutárias, regulamentadoras e contratuais que uma organização, seus parceiros comerciais, empreiteiros e fornecedores de serviços precisam atender. A terceira fonte é o conjunto específico de princípios, objetivos e requisitos para processamento de informações que uma organização desenvolveu para dar suporte a suas operações.

De acordo com a ISO 17799 (2000), se houver algum problema que afete a

confidencialidade, a integridade e/ou a disponibilidade, a organização poderá sofrer sérios danos,

pois a segurança ficará comprometida, podendo acarretar sérias falhas nos negócios. Ou seja, as

organizações devem sempre ter uma preocupação e uma ação que antecipe os problemas e, não

simplesmente, procure solucioná-los depois. A expectativa de todo usuário quando se trata de

segurança da informação é de que a mesma fique ilesa por tempo indeterminado, sem que nenhum

intruso consiga violar os objetivos de segurança impostos (DIAS, 2000; BEAL, 2005; ISO 17799,

2000).

De acordo com Beal (2005, p. 10), “os processos de segurança da informação devem levar

em conta as questões relativas à segurança da informação, para garantir uma proteção adequada aos

dados e informações importantes para o negócio”.

A segurança imposta pela aplicação deve verificar todas as requisições de acesso,

comparando-as com as requisições de segurança (ou autoridades) armazenadas no catálogo do

sistema (DATE, 2000).

2.4 CONTROLES E MECANISMOS DE SEGURANÇA PARA

APLICAÇÕES WEB

As organizações preocupadas com a segurança dos seus dados devem trabalhar com uma

visão de antecipar os problemas. Isto ocorre através da elaboração de uma política de segurança e

de um plano de contingência. O plano de contingência determina como a organização deverá

proceder caso haja algum incidente (DIAS, 2000). Mas para elaborá-lo deve-se fazer: análise das

alternativas de recuperação, análise de impactos, entre outros e depois de elaborar o plano é que a

organização irá conseguir: treinar, realizar os testes, entre outros (DIAS, 2000).

A administração da segurança em aplicações Web torna-se muito complexa na medida em

que se aumenta o número de aplicações, serviços e usuários que acessam as mesmas (CARUSO &

STEFFEN, 1999). Conforme Beal (2005) as medidas de proteção utilizadas para diminuir os riscos

de segurança, podem ser classificadas em:

Page 30: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

18

• as medidas preventivas: são os controles que reduzem a probabilidade de uma

ameaça se concretizar ou, diminui o grau de vulnerabilidade do

ambiente/ativo/sistema, reduzindo a probabilidade de um ataque ou capacidade de

causar efeitos adversos à organização;

• as medidas corretivas ou reativas: reduzem o impacto de um ataque/incidente. São

medidas tomadas durante ou após a ocorrência do evento; e

• os métodos detectivos: esses controles tentam evitar a concretização do dano,

reduzindo ou impedindo que este se repita.

De acordo com Beal (2005, p.27),

Um exemplo de medida de proteção que reduz a probabilidade de uma ameaça se concretizar, seria a mudança de um data center (alvo) de uma localidade com registro de ocorrência freqüente de enchentes (ameaça) para outra com probabilidade menor de excesso de chuva.

A Tabela 1 apresenta alguns exemplos das medidas preventivas, reativas e os métodos

detectivos para a proteção da informação.

Tabela 1. Exemplo de medidas preventivas e reativas e de métodos detectivos para a proteção da informação

AMEAÇA MEDIDAS PREVENTIVAS

MEDIDAS REATIVAS MÉTODOS DETECTIVOS

FRAUDE Supervisão gerencial, segregação de funções, controle de senhas e permissões de acesso

Interrupção de pagamentos suspeitos, investigação interna, denuncia à polícia

Auditoria de logs, análise de trilhas de auditoria, conciliação de valores

FURTO DE EQUIPAMENTOS

Controles de entrada/saída (E/S)

Investigação interna, denuncia à polícia

Inventário periódico, controle de Entrada e Saída

Fonte: Beal (2005).

Conforme Dias (2000), os serviços ou medidas preventivas devem ser definidos de forma a

atender os requisitos definidos na política de segurança, considerando o equilíbrio entre as

necessidades de segurança e os custos. Além disso, o autor afirma que também é necessário

implantar uma gerência de segurança para a organização, nos quais os componentes de risco e as

medidas de proteção são usados para reduzir o risco, como mostra a Figura 9.

Page 31: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

19

Figura 9. Componentes do risco e medidas de proteção usadas para reduzi-lo Fonte: Beal (2005).

Segundo Wangham (2004, p. 4), Os mecanismos de segurança que implementam as políticas de autorização e de autenticação de sistemas fazem uso de controles criptográficos e de controles de acesso. A autenticação consiste em um conjunto de procedimentos que permite que uma entidade, comprove sua identidade perante um sistema e a autorização é a função que decide se as requisições de acesso a objetos2 feitas por usuários ou intrusos, podendo ser ou não permitidas.

As pessoas autenticam-se diariamente de muitas formas, como por: CPF (Cadastro de

Pessoas Físicas), senhas, cartão magnético, entre outros. Conforme Kurose e Ross (2005), no meio

computacional, a autenticação deve ser feita pela troca de mensagens e de dados como parte de um

protocolo de autenticação (PA). O protocolo de autenticação estabelece uma comunicação de

confiança entre as entidades envolvidas, mas após a autenticação, as partes envolvidas executarão

aquilo que as mesmas iriam executar (KUROSE & ROSS, 2005).

De acordo com Peterson e Davie (2004), há mais uma forma provável de segurança de

comunicação entre duas entidades, na qual nenhuma das entidades relacionadas irá saber

informações umas das outras, pois as mesmas confiam em um terceiro membro, que pode ser

chamado de servidor de autenticação, que utiliza um PA para ajudar as duas entidades a se

autenticarem mutuamente. A utilização deste mecanismo previne alguns sistemas contra certos tipos

de ataques (PETERSON & DAVIE, 2004).

2 São entidades que podem ou não armazenar dados dos sistemas (Wangham, 2004)

Page 32: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

20

Ainda Peterson e Davie (2004, p.435) afirmam que, “na autenticação de chave pública o

protocolo de autenticação final utiliza a criptografia assimétrica (por exemplo, RSA – Ron Rivest,

Adi Shamir e Len Adleman)”. A criptografia assimétrica é útil, porque os envolvidos não precisam

realizar a troca das chaves privadas, porém as entidades envolvidas precisam conhecer as chaves

públicas umas das outras (PETERSON & DAVIE, 2004).

De acordo com a informação de Terada (2000), a confidencialidade e a autenticidade das

informações podem ser resolvidas com a criptografia. Quando se quer garantir a segurança dos

dados em uma organização, é necessário considerar uma série de fatores, tais como: a segurança na

Web, a proteção de servidores Web, as violações que ocorrem em navegadores, a política de

segurança, os mecanismos de segurança como a criptografia e a política de controle de acesso.

2.4.1 Segurança na Web

De acordo com Garfinkel e Spafford (1999), a definição de segurança na Web resume-se a

um conjunto de procedimentos, práticas e tecnologias usadas para proteger os servidores Web e um

conjunto de comportamentos inesperados dos intrusos. A segurança na Web ainda requer muita

atenção, pois a Web e suas aplicações mudam constantemente em pontos considerados importantes

para a segurança de computadores (GARFINKEL & SPAFFORD, 1999).

Segundo Garfinkel e Spafford (1999), o problema de segurança Web envolve: a proteção

dos servidores e dos dados contidos nestes; a proteção das informações que trafegam entre o usuário

e o servidor; e a proteção do computador do próprio usuário. Segundo os autores, existem as

seguintes exigências para garantir a segurança Web: verificar a identidade do usuário no servidor

Web; verificar a identidade do servidor Web para o usuário; garantir a transferência de mensagens

cliente/servidor de maneira conveniente, confiável e sem repetição; registrar as informações das

transações; e equilibrar a carga dos servidores.

Conforme Chandler e Kirkner (1996, p.40), Para se alcançar a segurança Web, há três métodos básicos de reforçar a segurança: o primeiro método é impedir o acesso a partir de domínios não autorizados da Internet; o segundo método é a possibilidade de realizar a proteção através de senhas, para impedir o acesso aos serviços e/ou dados da aplicação; e o terceiro método é usado a codificação dos dados para proteger as informações que trafegam entre o cliente e o servidor.

Em 1996, pelo menos seis aplicações Web governamentais de suma importância foram

invadidas por intrusos sendo que duas dessas aplicações foram: Federal Bureau of Investigation

(FBI) e Central Intelligence Agency (CIA), que são organizações federais que cuidam da segurança

Page 33: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

21

dos Estados Unidos da America (EUA) e, de 1997 a 1998, aplicações Web de empresas como a

Coca-Cola foram invadidas por vários intrusos (GOMES, 2000).

2.4.2 Proteção de Servidores Web

A Web foi desenvolvida com objetivo de tornar as informações disponíveis a todos os seus

usuários, sendo que tudo que está disponível em um servidor Web é de domínio público e por isso

que é necessário proteger estas informações, mas não existe nenhuma maneira tecnicamente viável

de impedir o acesso a estas informações (CHANDLER & KIRKNER, 1996).

Para Garfinkel e Spafford (1999), a frase “servidor Web seguro” tem sido entendida de

várias formas diferentes dependendo de quem as houve, por exemplo: diversos fabricantes de

softwares dizem que um servidor seguro é aquele que implementa protocolos criptográficos para

que as informações que transitam entre o cliente e o servidor não sejam reveladas por intrusos;

resguarda a privacidade e não altera o navegador para que vírus ou trojan sejam baixados nos

computadores dos clientes para adquirir as informações; e resiste determinados ataques feitos por

intrusos através da Internet ou até mesmo pela rede interna.

De acordo com Garfinkel e Spafford (1999), um servidor Web seguro é confiável, pois

possui cópias de segurança de todas as suas informações, mas se caso houver alguma falha de

hardware ou software, as mesmas serão supridas o mais rápido possível. Os autores afirmam que, se

os intrusos conseguirem invadir e obtiverem controle sobre o sistema operacional do servidor Web,

é impossível utilizar este servidor para oferecer serviços seguros. Conforme Oppenheimer (1999) existem servidores Web que podem permitir acesso não

autenticado, mas os que não se encaixarem nessa alternativa, devem exigir autenticação e

autorização. De acordo com Oppenheimer (1999), os servidores Web devem ser disponibilizados

em uma rede mundial, sendo que os mesmos devem ser protegidos por um firewall.

2.4.3 Violação em Navegadores

De acordo com Krishnamurthy e Rexford (2001, p. 10), “o navegador é uma aplicação para

solicitar e exibir recursos existentes na Web”. Segundo Garfinkel e Spafford (1999, p. 27), Os navegadores são softwares extremamente complexos e se tornam cada vez mais complexos com o passar do tempo. Sempre que novos recursos são acrescentados, aumentam as chances de algo sair errado, isto é uma boa notícia para os intrusos interessados na segurança, pois a maioria dos erros de segurança são basicamente erros de programação.

Page 34: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

22

Os navegadores tornaram- se um front-end para o computador de vários clientes, sendo que

os mesmos utilizam os navegadores para enviar e receber mensagens através de páginas HTML

(KRISHNAMURTHY & REXFORD, 2001).

A maioria dos navegadores pode entender um conjunto de pequenos dados pré-definidos,

sendo que há uma forma de executar outros tipos de dados, que é através de aplicativos auxiliares,

por exemplo, os plugins (GARFINKEL & SPAFFORD, 1999). Estes aplicativos auxiliares causam

sérios problemas para a segurança, porque são executados nos computadores dos clientes,

processando informações fornecidas pelo que o servidor Web (GARFINKEL & SPAFFORD,

1999).

O uso de aplicativos auxiliares pode conter recursos poderosos e mal-intencionados que

utilizam os aplicativos Web para capturar as informações dos usuários, e/ou danificarem os

computadores dos mesmos para ter acesso às informações sigilosas, tais como: senhas, números de

cartões de crédito, dados pessoais, entre outros (OPPENHEIMER, 1999; GARFINKEL &

SPAFFORD, 1999).

De acordo com Garfinkel e Spafford (1999), com base nas preocupações que devem ser

tomadas em relação à segurança, os aplicativos auxiliares não são seguros, mas podem ser muito

úteis aos clientes, pois podem executar serviços interessantes como: áudio; vídeo; entre outros,

sendo assim a Netscape desenvolveu um sistema de “extensões3”.

2.4.4 Política de segurança

Segundo Dias (2000, p.48), A política de segurança é um mecanismo preventivo de proteção de informações e processos importantes de uma organização, que define um padrão de segurança a ser seguido pelo corpo técnico. A política deve estabelecer os princípios institucionais de como a organização irá proteger, controlar e monitorar seus recursos computacionais e conseqüentemente, as informações manipuladas.

Para Garfinkel e Spafford (1999), os cuidados com a elaboração da política de segurança

podem evitar muitos desastres. Os autores ainda afirmam que, o papel da política de segurança é

orientar os usuários para que saibam o que é permitido, ajudar na administração, gerenciar as

escolhas e o uso dos sistemas. De acordo com Dias (2000), a política de segurança pode conter: os

3 Modulo que é carregado diretamente no espaço do endereço do programa navegador e é executado quando alguns documentos são baixados pelo navegador

Page 35: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

23

princípios de continuidade de negócios, assim como os procedimentos de como agir caso haja

violação das regras de segurança e o plano de treinamento dos funcionários, caso o sistema sofra

alguma violação.

Segundo Garfinkel e Spafford (1999), a política de segurança é um tópico muito complexo,

com aspectos particulares. Para Campello e Weber (2001), a política de segurança é o conjunto de

leis e práticas que regulam as informações e os seus recursos para saber como gerenciar, proteger e

distribuir.

De acordo com Dias (2000, p. 48), “é importante que a política de segurança estabeleça as

responsabilidades das funções relacionadas com a segurança e descreva as principais ameaças,

riscos e impactos envolvidos”.

Uma política de segurança gera impactos em todos os projetos de computadores, que são: os

planos de desenvolvimento de sistemas, o planejamento de capacidade, o plano de contingência,

entre outros, porém é importante frisar que a política de segurança não envolve apenas a área de

informática, mas sim todos os dados de uma organização (DIAS, 2000).

A Figura 10 mostra o relacionamento da política de segurança com a estratégia da

organização, plano estratégico e os projetos relacionados.

Figura 10. Política de segurança e seus relacionamentos Fonte: Dias (2000).

Os roteiros para a elaboração de uma política de segurança conforme definido por Dias

(2000) e Garfinkel e Spafford (1999), tratam de sistemas em gerais. As perguntas apresentadas a

seguir, têm a intenção de mostrar aspectos específicos da política de segurança relacionados com as

Page 36: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

24

aplicações Web. Ou seja, antes de implantar um programa de segurança de informações, é

aconselhável responder as seguintes perguntas (DIAS, 2000; GARFINKEL & SPAFFORD, 1999):

• o que se deseja proteger?

• contra quem se deseja proteger a informação?

• quais são as ameaças mais prováveis à aplicação Web?

• qual é a importância de cada recurso protegido na aplicação Web?

• foram definidos procedimentos de backup e restauração dos sistemas?

• esses procedimentos de backup e restauração dos sistemas foram testados?

• existem controles de acesso lógico aos sistemas?

• quem é o responsável pela segurança, pelas atualizações, pelos backups e pela

manutenção da aplicação Web?

• como é identificado o corpo técnico da organização?

• quais são os tipos de softwares que se comunicam com a aplicação e como estes

poderão acessar a mesma?

• qual o grau de proteção desejado para a aplicação Web?

• quais as expectativas dos usuários em relação à segurança de informações?

• quais as conseqüências se os dados forem corrompidos ou roubados por intrusos?

• quais serão os usuários ou softwares que terão acesso aos serviços da aplicação e

quais serão as permissões?

• como a organização deverá proceder caso haja algum incidente?

• são investigados os incidentes de segurança? E, após uma violação da política, são

tomadas medidas necessárias para identificação de suas causas e agentes? São

corrigidas as vulnerabilidades e os infratores são punidos? e

• os aspectos de segurança são regularmente auditados a fim de verificar se as políticas

estão sendo cumpridas ou se são necessárias modificações?

Após responder as perguntas, o profissional de segurança começará a elaboração dos

documentos que descrevem a política de segurança da organização, de acordo com a análise de

riscos, os requerimentos legais e os padrões técnicos4 (BEAL, 2005; DIAS, 2000; GARFINKEL &

SPAFFORD, 1999). Depois de ter os documentos prontos, o responsável pela segurança irá deixá-

4 Padrões técnicos representam uma referência importante para a qualidade de processo, por exemplo:a norma da ISO 17799 parte 1 e parte 2 (BEAL, 2005)

Page 37: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

25

los à disposição dos membros da organização (BEAL, 2005; DIAS, 2000; GARFINKEL &

SPAFFORD, 1999).

Segundo Beal (2005, p.44), Embora o conteúdo da política de segurança vá variar com o tamanho da organização, missão, estágio de maturidade, nível de informatização, entre outros e a mesma organização deverá abranger, sempre que cabível os seguintes aspectos: a organização da segurança; a classificação e os controles de ativos de informação; os aspectos humanos da segurança; a segurança lógica/física; a segurança das comunicações; a prevenção e tratamentos de incidentes; o desenvolvimento/aquisição, implantação e manutenção de sistemas; a gestão da continuidade de negócio; e a conformidade.

2.4.5 Mecanismo de Criptografia

Segundo Garfinkel e Spafford (1999), a criptografia é um mecanismo de segurança capaz

de transformar palavras legíveis em formatos ilegíveis, na qual só o receptor autorizado pode

transformar essas palavras em formato legível novamente. A criptografia é um conjunto de funções

matemáticas usadas para codificar os dados, garantindo o segredo e a autenticação (OLIVEIRA,

2000). Muitas vezes a criptografia é a única que pode garantir a segurança dos dados, mas a mesma

sozinha não resolve todos os problemas de segurança, pois este mecanismo de segurança não é a

prova de falhas (BURNETT & PAINE, 2002).

Figura 11. Cifragem e decifragem

A criptografia funciona em dois processos, como ilustra a Figura 11: a cifragem acontece

quando o sistema recebe o texto ou palavras legíveis e as transforma em informações ilegíveis ou

cifradas, utilizando um algoritmo criptográfico e uma chave criptográfica; e a decifragem é o

processo inverso da cifragem, ou seja, o sistema recebe o texto cifrado e converte em texto legível,

usando o algoritmo criptográfico e a chave de decifragem fornecida (BURNETT & PAINE, 2002;

GARFINKEL & SPAFFORD, 1999).

Para Garfinkel e Spafford (1999), a criptografia é um mecanismo de segurança usado em

sistemas computacionais e a mesma fornece: a confidencialidade, a autenticidade e a integridade

dos dados armazenados ou transmitidos.

Page 38: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

26

Silberschatz (1999, p. 643) afirma: “técnicas simples de criptografia podem não fornecer o

grau de segurança adequado, já que talvez seja fácil para um intruso quebrar o código”. Os

algoritmos de criptografia não devem ser mantidos em segredo, ao invés disso, os algoritmos devem

ser sempre publicados, para que haja troca de informações com o meio acadêmico, sempre com

objetivo de tentar melhorá-lo, pois o segredo não deve estar no algoritmo e sim na chave

criptográfica (BURNETT & PAINE, 2002; GARFINKEL & SPAFFORD, 1999; OLIVEIRA,

2000).

Segundo Burnett e Paine (2002), o uso da chave é necessário, pois os intrusos podem até

entender dos algoritmos criptográficos, mas não terão acesso à informação se não souberem a chave

criptográfica. O termo chave serve para manter as informações em segredo, o funcionamento da

chave é semelhante à de uma “fechadura de porta”, ou seja, só tem acesso ao outro lado se obtiver a

chave, então o segredo da criptografia está todo na chave de criptográfica e em um bom algoritmo

criptográfico (BURNETT & PAINE, 2002; GARFINKEL & SPAFFORD, 1999).

Para ter a criptografia como um ato de proteção das informações, é preciso saber que as

pessoas autorizadas podem não ter acesso às informações criptografadas, mas os intrusos podem

tentar decifrá-las (GARFINKEL & SPAFFORD, 1999). Se um intruso conseguir uma cópia do

dado cifrado, o mesmo deve possuir o algoritmo e principalmente a chave de criptografia para obter

a informação original (BURNETT & PAINE, 2002).

A criptografia surgiu para auxiliar na segurança dos dados criptografando-os, mas também

este mecanismo pode ser usado para criptografar uma comunicação, que é feita por meio do

protocolo SSL (BURNETT & PAINE, 2002; GARFINKEL & SPAFFORD, 1999).

A criptografia se divide em algoritmos de chaves simétricas e assimétricas (BURNETT &

PAINE, 2002; GARFINKEL & SPAFFORD, 1999). A seguir, serão descritos o funcionamento da

criptografia simétrica, da criptografia assimétrica, dos certificados digitais, das assinaturas digitais,

do algoritmo MD5 (Message Digest 5) e do protocolo SSL e, por fim, alguns ataques referentes às

chaves criptográficas são apresentados.

2.4.5.1 Criptografia de Chaves Simétricas

Os algoritmos de chaves simétricas, também chamados de algoritmos de chaves secretas

ou privadas, foram projetados para serem rápidos (BURNETT & PAINE, 2002; GARFINKEL &

SPAFFORD, 1999). Os algoritmos de chaves simétricas são aqueles que utilizam apenas uma chave

de criptografia (BURNETT & PAINE, 2002).

Page 39: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

27

De acordo com Garfinkel e Spafford (1999, p. 193), os algoritmos de chaves simétricas

garantem a confidencialidade dos dados, pois “quando um dado é criptografado com uma

determinada chave, não há como decifrá-lo sem possuir o algoritmo criptográfico e, principalmente,

a chave de criptografia”.

Entre os algoritmos simétricos, pode-se destacar (BURNETT & PAINE, 2002;

GARFINKEL & SPAFFORD, 1999): Data Encryption Standard (DES) que são algoritmos de

blocos que usam chaves de 56 bits; triple DES que é um algoritmo que usa três chaves diferentes;

Advanced Encryption Standard (AES) que deve executar a criptografia com uma cifra do bloco

com tamanhos de bloco com no mínimo de 128 bits e ainda podendo ser com chaves de 192 e 256

bits; Blowfish algoritmo de bloco, rápido compacto e as chaves podem chegar até 448 bits;

Internationnal Data Encryption Algorithm (IDEA) algoritmo que usa chaves de 128 bits também

conhecido como Pretty Good Privacy (PGP); RC2 que permite a utilização de até chaves de 2048

bits; RC4 que permite que as chaves sejam até 2048 bits, mas em softwares de exportação (EUA) é

limitado em 40 bits; e o RC5 que permite que o tamanho da chave dos blocos e o número de vezes

que a criptografia será realizada seja definido pelo o usuário.

2.4.5.2 Criptografia de Chaves Assimétricas (Públicas)

Segundo Garfinkel e Spafford (1999), a chave assimétrica foi utilizada pela primeira vez

em 1975, onde os pesquisadores utilizaram uma técnica que utilizava uma chave para cifrar e outra

chave para decifrar a informação. De acordo com Burnett e Paine (2002), este método evita a troca

de chaves, na qual algum intruso poderá realizar alguns ataques para capturá-las e através desses

ataques os intrusos poderão acessar a mensagem original.

A infra-estrutura das chaves assimétricas consiste em (BURNETT & PAINE, 2002;

GARFINKEL & SPAFFORD, 1999):

• uma chave pública que pode ser usada para enviar mensagens criptografadas para um

usuário e/ou para verificar a assinatura digital de um usuário; e

• uma chave privada é usada pelo usuário para decifrar a mensagem recebida e para

assinar dados digitalmente.

Page 40: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

28

Figura 12. Funcionamento da criptografia assimétrica Fonte: Wangham (2004).

A Figura 12 ilustra o funcionamento da criptografia assimétrica, ou seja, é quando se

utiliza a chave pública para cifrar e a chave privada para decifrar o dado (WANGHAM, 2004).

Segundo Wangham (2004, p.6), A forma de distribuição de chaves criptográficas mais empregada atualmente são as que se baseiam em certificados digitais, que vinculam chaves públicas a principais. Para ter certeza de que a chave pública contida no certificado realmente pertence ao sujeito do certificado, é preciso que este certificado seja assinado por uma entidade confiável, chamada de autoridade certificadora (AC).

De acordo com Garfinkel e Spafford (1999), os certificados digitais foram projetados para

comprovar a identidade de um usuário, vinculando o nome a uma chave pública, os mesmos são

emitidos por órgãos de certificadores. Ainda para Garfinkel e Spafford (1999, p. 151), Os certificados digitais são úteis e fornecem vários benefícios, como: poder eliminar as necessidades de lembrar os nomes de usuários e senhas; em vez de ter um banco de dados distribuído, basta que as empresas utilizem um certificado digital emitido por uma AC, como prova de associação; entre outros.

Figura 13. Assinatura digital Fonte: Moreira (2007).

Conforme Kurose e Ross (2005); Peterson e Davie (2004), a assinatura digital se baseia

em criptografia assimétrica. Segundo Peterson e Davie (2004), para assinar um documento

digitalmente o usuário utiliza uma função hash one-way livre de colisões, gerando um hash do

documento, como ilustra a Figura 13. O hash é cifrado com a chave privada do usuário, só que a

intenção não é embaralhar ou disfarçar o conteúdo do documento, mas sim assiná-lo digitalmente,

de maneira que possa garantir a não-repudiação (KUROSE & ROSS, 2005). E, para verificar se a

Page 41: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

29

assinatura é autêntica, precisa-se decifrar o documento com a chave pública do usuário que assinou

e recalcular o hash do documento, comprovando assim a identidade de quem assinou o documento

(KUROSE & ROSS, 2005).

MD5

No mundo analógico, quando queremos garantir a veracidade de um documento, basta ir a

um cartório e constatar a autenticidade. No mundo digital, procedemos de maneira similar, ou seja,

através de AC (organizações pagas), que oferecem a constatação da veracidade de um documento,

por meio de um conjunto de técnicas, práticas e procedimentos elaborados para suportar um

determinado sistema criptográfico (BURNETT & PAINE, 2002; TERADA, 2000).

O algoritmo criptográfico MD5 (RFC 1321) foi desenvolvido por Ron Rivest e produz

uma saída (hash) de tamanho fixo, a partir do tamanho da entrada (MISAGHI, 2007; TERADA,

2000; BURNETT & PAINE, 2002).

Segundo Jamhour (2007), o MD5 é muito utilizado para calcular a assinatura digital,

autenticações, garantir a integridade e para gerenciar chaves. De acordo com Misaghi (2007) e

Terada (2000), este algoritmo toma por base a criptografia assimétrica, sendo que o mesmo gera um

hash do documento com tamanho de 128 bits, garantindo assim a integridade e confidencialidade de

informações.

Para garantir a integridade, o algoritmo MD5 gera um hash da informação criptografada e

se o usuário for preocupado com a alteração da informação, o mesmo verifica se o hash é igual, pois

o hash é único para cada dado cifrado com este algoritmo, como mostra a Figura 14 (BURNETT &

PAINE, 2002).

Figura 14. Hash

O funcionamento do MD5 está ilustrado na Figura 15, ou seja, é quando a mensagem a ser

cifrada é dividida em blocos de 512 bits (cada bloco de 512 bits sofre um total de 64 interações com

16 sub-blocos de 32 bits) e, no último bloco é acrescentado um “1” binário, seguidos de tantos “0”

até que o bloco tenha um comprimento de 448 bits (512-64) (JAMHOUR, 2007; TERADA, 2000).

Page 42: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

30

Figura 15. MD5 Fonte: Adaptado de Puttini (2007).

“O MD5 opera embaralhando os bits de um documento de forma complexa, sendo que os

bits de saída são afetados por todos os bits de entrada; assim, logo a função aumenta o tamanho da

mensagem e o tamanho é dividido em tamanhos de 64bits, gerando tamanho múltiplo de 512bits”

(CAMPOS, IBERÊ & MIGUEL, 2007).

Protocolo Criptográfico SSL

Segundo Garfinkel e Spafford (1999), o protocolo SSL utiliza diferentes algoritmos de

criptografia, para poder oferecer a autenticação e a integridade dos dados com o uso de chaves

diferentes, mas a vantagem da separação da segurança em funções tem o objetivo de poder utilizar

chaves maiores para garantir a autenticação, integridade e a confidencialidade.

Esse protocolo de criptografia e de autenticação é baseado em sessões, fornecendo um

canal seguro entre as duas partes (BURNETT & PAINE, 2002). O SSL evita a espionagem através

de autenticações cliente/servidor, mantendo um segredo compartilhado entre as duas partes e

fornecendo a confidencialidade em uma conexão (BURNETT & PAINE, 2002; GARFINKEL &

SPARFFORD, 1999).

O uso do protocolo SSL pode incluir muitas conexões seguras, que podem conter múltiplas

sessões simultâneas, mas o desempenho do SSL diminuiu perceptivelmente a velocidade de

transmissão dos dados pela Internet, com o uso da criptografia assimétrica (GARFINKEL &

SPAFFORD, 1999).

De acordo com Garfinkel e Spafford, (1999), os usuários de aplicações Web afirmam que o

uso do protocolo SSL, causa uma queda de 50% do desempenho em relação ao uso comum da

Internet, pois os mesmos ainda informam que, dos dez segundos utilizados, a criptografia e a

decifragem duram aproximadamente três segundos por usuário, usando chaves de 1024 bits.

Para minimizar o impacto do SSL em organizações, as mesmas transmitem os dados

pesados sem criptografá-los, para tornar mais rápida a comunicação, utilizando o protocolo SSL

apenas para criptografar os dados mais importantes (GARFINKEL & SPAFFORD, 1999).

Page 43: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

31

O SSL funciona na camada de transporte abaixo da camada de aplicação,

independentemente dos protocolos de aplicativos utilizados (BURNETT & PAINE, 2002). Este

protocolo SSL possui dois tipos de máquinas de estados: uma cliente e a outra servidor. A interação

entre essas duas máquinas de estado é chamada de handshake, como ilustra a Figura 16 (BURNETT

& PAINE, 2002).

Figura 16. Handshake Fonte: Burnett e Paine (2002).

Segundo Burnett e Paine (2002), o protocolo handshake de SSL negocia os parâmetros da

comunicação. Na Figura 16 ilustra que as duas partes concordam com a versão de protocolo,

selecionam os algoritmos criptográficos, opcionalmente se autenticam uns aos outros e utilizam

técnicas de criptografia assimétrica para gerar os segredos compartilhados através de uma série de

mensagens trocadas entre cliente e servidor (BURNETT & PAINE, 2002).

Segundo Kurose e Ross (2005, p. 556), “a fase de apresentação mútua do SSL, percorre as

seguintes etapas”, como mostra a Figura 16:

1. a comunicação inicia com a mensagem do cliente para o servidor (hello cliente),

contendo a versão do SSL e a preferência criptográfica;

2. o servidor responde a mensagem do cliente com a seguinte mensagem hello

servidor, que informa a versão do SSL e as preferências criptográficas que foram

adotadas de acordo com a mensagem enviada pelo cliente. O servidor ainda enviará

Page 44: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

32

outra mensagem contendo o seu certificado para o cliente, contendo a sua chave

pública;

3. o cliente possui uma lista de ACs de confiança com suas respectivas chaves públicas.

(Quando o cliente recebe o certificado do servidor o mesmo irá verificar se a AC do

servidor esta em sua lista de ACs de confiança. Caso não esteja na lista, o cliente

receberá um comunicado avisando que não estabelecerá a conexão criptografada e

autenticada, mas se a AC estiver na lista, o cliente validará o certificado);

4. o cliente gera uma chave de sessão simétrica, criptografa-a com a chave pública do

servidor e a transmite para o mesmo;

5. o cliente transmite uma mensagem para o servidor avisando que as mensagens serão

criptografadas com a chave de sessão, então o cliente envia outra mensagem ao

servidor, avisando que a sua parte da apresentação mútua está encerrada;

6. o servidor transmite uma mensagem para o cliente com conteúdo semelhante da

Etapa 5; e

7. finalizando a apresentação mútua começa a sessão SSL, ou seja o cliente e o servidor

utilizam as chaves de sessão para cifrar e decifrar os dados da comunicação e para

validar a sua integridade.

2.4.5.3 Ataques Referentes às Chaves de Criptografia

Muitos dados e informações são protegidos com as técnicas de criptografia (BURNETT &

PAINE, 2002). Como existem vários ataques referentes às chaves criptográficas, deve-se dar uma

atenção especial para a segurança destas chaves (TANENBAUM, 1994; TERADA, 2000). Segundo

Terada (2000); Tanenbaum (1994); e Burnett e Paine (2002), os principais ataques referente as

chaves criptográficas, são:

• os ataques de chaves conhecidas: é quando o intruso já conhece algumas chaves

usadas pelo alvo e usa isso para descobrir as chaves novas;

• o ataque chamado de feliz aniversário (birthday attack): acontece quando um

intruso utiliza as falhas do algoritmo de hashing, sendo que o hashing não deve

produzir valores similares para mensagens diferentes. Caso isso aconteça, dizemos

que ocorreu uma colisão. Se o intruso obtiver uma amostra desta colisão, o mesmo

terá grandes chances de quebrar o método criptográfico, mas se for usado o MD5

Page 45: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

33

este ataque se torna impraticável, pois o mesmo ataque levaria 500 anos com um

bilhão de compilações por segundo para decifrar a informação;

• o ataque por replay ou mensagens antigas: é quando um intruso grava a

comunicação e depois tenta utilizar posteriormente para seu proveito (Figura 17); e

• o ataque de força bruta: é a maneira mais simples de se quebrar um código, ou seja,

o intruso testa todas as chaves possíveis, para conseguir ter acesso à informação

desejada (Figura 18).

Figura 17. Ataque Replay

Figura 18. Ataque de criptografia referente à força bruta.

2.4.6 Mecanismos de Controles de Acesso

Segundo Dias (2000), os controles de acesso podem ser físicos, lógicos e ambientais, sendo

que cada controle de acesso possui o objetivo de proteger os recursos computacionais contra perdas,

danos, ou alterações não autorizadas. Como esta monografia limitar-se-á apenas aos controles de

acesso lógico, novamente estes serão descritos a seguir.

Page 46: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

34

Os controles de acesso em sistemas de informação devem assegurar que todos os acessos

diretos a aplicação ocorram exclusivamente de acordo com as regras de acesso pré-estabelecidas

(CARDOSO & SILVA, 2005; CARUSO & STEFFEN, 1999).

O sistema de controle do acesso representado pela Figura 19 inclui assuntos como usuários e

processos que alcançam informações e softwares com as operações leitura, escrita e executar

(CARDOSO & SILVA, 2005). A Figura 19 ilustra o funcionamento do sistema de controle de

acesso (política de segurança), que consiste nos seguintes componentes (CARDOSO & SILVA,

2005):

• as políticas e as regras de acesso: consiste na informação armazenada no sistema e

indica as modalidades e os tipos de acesso a serem seguidos;

• os procedimentos de controle (mecanismos de segurança): observa-se o pedido do

acesso que vai ao encontro das regras de acesso; e

• os pedidos de acesso: podem ser permitidos ou negados ou ainda podem ser pedidas

modificações no pedido de acesso.

Figura 19. Sistema de Controle de Acesso Fonte: Cardoso e Silva (2005).

2.4.7 Diretrizes de Injeção de SQL

Segundo a estatística realizada pela CERT (Computer Emergency Response Team), As tentativas de fraudes com uso da Internet cresceram 53% no ano de 2005. Com esses números, o Brasil ficou na segunda colocação entre os 10 países com maior número de incidentes reportados, concentrando 21,2% das denúncias, atrás apenas dos Estados Unidos, acrescentado por Azeredo. A escalada dos incidentes é surpreendente e acompanha a celeridade da evolução tecnológica: os incidentes foram 2.107 em 1999, passaram para 5.997, 12.301, 25.092, 54,607, 75.722, sucessivamente, até mais que dobrar e chegar aos 197 mil do ano passado.

De acordo com Cardoso e Silva (2005), os desenvolvedores de aplicação Web devem fazer

o máximo para evitar um ataque de injeção de SQL, seguindo no mínimo os seguintes passos:

Page 47: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

35

• estabelecer uma política de segurança rígida e criteriosa limitando o acesso dos seus

usuários;

• limitar a entrada de caracteres nos formulários de entrada de dados;

• elaborar um tratamento adequado de erros, não permitindo que mensagens de erros

do banco de dados exponha informações sobre a estrutura dos seus dados;

• propor um “log” para auditar os erros ocorridos e as operações mais importantes da

aplicação;

• fazer a validação da entrada de dados no formulário, não permitindo a entrada de

caracteres inválidos, tais como : (‘), (—), (;), entre outros;

• não aceitar comandos SQL ou palavras maliciosas ao banco de dados, tais como:

insert, drop, delete, xp_, entre outras;

• evitar que os intrusos consigam obter as informações propriamente ditas e verificar a

possibilidade de obter informações ou executar comandos no servidor.

• manter os nomes de usuários diferentes dos tradicionais como: admin, administrador

ou os próprios nomes dos administradores: (leandro, luis, entre outros comuns) e

apelidos: (zezinho, le, luizinho, entre outros);

• evitar mostrar o comando SQL; e

• evitar que o intruso consiga usar o sistema para obter as informações.

Bortoluzzi (2005) afirma que, as recomendações contra a injeção de SQL em aplicações

Web, devem criar uma metodologia de programação segura através de treinamentos adequados e à

utilização de bibliotecas preexistentes, delegando assim ao banco de dados a tarefa de autenticar as

entidades e instalar na aplicação, detectores de intrusão específicos para a tarefa de detecção de

comandos de injeção de SQL.

Segundo Microsoft (2004), para evitar ataques de injeção SQL, as seguintes diretrizes

devem ser seguidas:

• não se deve criar comandos SQL por concatenação de seqüências de caracteres,

especialmente seqüências de caracteres que incluam entradas de usuários;

• realizar consultas parametrizadas ou procedimentos armazenados; e

• para criar uma consulta parametrizada, deve-se utilizar objetos parametrizados para

estabelecer valores para estes parâmetros.

Page 48: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

36

Conforme OWASP (2006), “O uso de “stored procedures” ou “prepared statementes” irá

prover proteção significante, assegurando que a entrada fornecida é tratada como dados. Estas

medidas irão reduzir, mas não eliminar completamente o risco”.

2.4.8 Firewall

De acordo com Kurose e Ross (2005, p. 541), Firewall é uma combinação de hardware e software que isola uma rede interna de uma organização da Internet em geral, permitindo que alguns pacotes passem e bloqueando outros. Um firewall permite que um administrador de rede controle o acesso entre o mundo externo e os seus recursos da rede que administra gerenciando o fluxo de trafego de e para esses recursos.

Firewall são dispositivos utilizados na segurança de redes de computadores contra ataques,

dificultando o trânsito dos invasores entre as redes de computadores (DIAS, 2000). Conforme Dias

(2000), os sistemas tradicionais de rede, sem o uso de um firewall, normalmente permitem acesso

direto ao mundo externo de qualquer máquina conectada na rede interna ou vice-versa.

Os firewalls também podem filtrar os pacotes de um servidor com base no endereço de

origem, podendo ser útil para proteger os domínios contra, por exemplo: uma inundação indesejada

de pacotes de (negação de serviço), acesso não autorizado, entre outros (PETERSON & DAVIE,

2004).

De acordo com Peterson e Davie (2004), o uso de firewall é comum por dois motivos: o

primeiro motivo é pela complexidade dos algoritmos e protocolos de segurança, os firewalls foram

criados como uma medida substituta para auxiliar a segurança de servidores e/ou aplicativos; e o

segundo motivo é permitir que os administradores dos servidores Web e/ou servidores de banco de

dados, entre outros, implementem uma política de segurança em um local centralizado para facilitar

a sua administração.

Page 49: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

3 DESENVOLVIMENTO

O objetivo deste projeto é modelar e implementar um estudo de caso, para demonstrar como

se devem levantar os riscos que a aplicação Web pode possuir, por meio da técnica de análise de

riscos, para poder propor soluções. O estudo de caso é definido como um configurador de software

para micro computador que possua acesso à Internet ou à Intranet. Este oferece a opção de

cadastrar, alterar, excluir e deletar: grupos, produtos, usuários, compatibilidade entre os grupos e

produtos. Com este configurador pode-se enviar informações de produtos para os clientes pelos

funcionários e administradores do sistema via e-mail, ou os mesmos ainda podem imprimir as

informações dos produtos. O estudo de caso não possui nenhum mecanismo de segurança

implementado, assim como ilustra o cenário atual na Figura 20.

Figura 20. Situação atual do estudo de caso

Situação desejada: o software deve suportar a análise de riscos citada na Seção 3.2.5, ou

seja, após a aplicação das soluções indicadas pela análise de riscos, nenhum risco previsto poderá

ser encontrado. Para isto deve-se identificar as vulnerabilidades do estudo de caso através da técnica

conhecida como análise de risco e, propor os controles de segurança que atendam às necessidades

apontadas para que o sistema não seja vulnerável a ataques de intrusos e que afete o mínimo de

desempenho possível. A partir da análise de riscos, o projeto de segurança do estudo de caso utiliza

uma DeMilitarized Zone (DMZ) ou zona desmilitarizada, conhecida como Rede de Perímetro.

A DMZ é uma pequena rede situada entre uma rede confiável e uma não confiável, ou seja,

rede local e a Internet. Esta serve para restringir o acesso de intrusos e visualizar os servidores

disponíveis, tais como: de banco de dados e Web, como mostra o cenário proposto, ilustrado pela

Figura 21.

Page 50: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

38

Figura 21. Funcionamento desejado do estudo de caso

Este projeto utiliza um modelo de ciclo de vida incremental, composto por quatro etapas,

que são: análise, projeto, codificação e testes, como ilustra a Figura 22.

Figura 22. Etapa do processo abordada neste projeto

Na etapa de análise foram levantados os requisitos funcionais, não funcionais e foi

elaborada uma análise de riscos, que visa levantar as vulnerabilidades do estudo de caso. Os

requisitos funcionais e não funcionais estão descritos na Tabela 2. A análise de riscos que lista: as

ameaças, os tipos de impactos, os impactos, as probabilidades e as soluções indicadas para cada

risco do estudo de caso, se encontra na Seção 3.2.5, deste trabalho.

Tabela 2. Requisitos do sistema Referência Descrição

Requisitos Funcionais (RF) RF01 O sistema deve permitir somente que o administrador cadastre,

altere, delete e consulte usuários, compatibilidades, grupo e produtos no sistema. Esta regra é herdada.

RF02 O sistema deve permitir que os usuários autorizados tenham acesso às informações, através dos controles de segurança impostos.

RF03 O sistema deve ter a opção de enviar e-mail para o cliente com os dados dos produtos. Esta regra é herdada.

RF04 O sistema deve ter a opção de imprimir os dados dos produtos. Esta regra é herdada.

Page 51: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

39

RF05 O sistema deve possuir um mecanismo de controle de segurança para evitar que pessoas não autorizadas tenham acesso ao sistema. (tela de login)

Requisitos não Funcionais (RNF) Segurança RNF.01.01 As senhas cadastradas que estiverem no banco de dados não deverão

ser visíveis diretamente, devendo estar em um modo criptografado. Segurança RNF.01.02 O sistema deve criptografar os dados sigilosos. Segurança RNF.01.03 O sistema deve possuir tratamento contra a Injeção de SQL, no

formulário de autenticação da aplicação. Segurança RNF.01.04 O sistema deve utilizar auxilio de um firewall para a segurança de

alguns ataques citados na análise de riscos. Usabilidade RNF.02.01 Os navegadores deverão ser Internet Explorer 5.0 ou versões

superiores. Esta regra é herdada. Usabilidade RNF.02.02 O sistema deve possuir uma interface amigável. Confiabilidade RNF.03.01 O sistema deve ser suficientemente robusto para permitir acessos 24

horas por dia, todos os dias da semana. Desempenho RNF.04.01 O sistema deve estar preparado para atender a mais de 20 usuários

simultâneos com a segurança imposta. Software e Hardware RNF.05.01

O sistema deve estar preparado para trabalhar com o banco de dados PostgreSQL.

Software e Hardware RNF.05.02

O sistema pode ser executado na Internet (rede mundial de computadores) ou intranet

Software e Hardware RNF.05.03

O sistema executa no Apache Tomcat 5 ou versões superiores.

Software e Hardware RNF.05.04

O sistema deve estar preparado para processar no sistema operacional Open Suse.

Na etapa projeto foi modelada a segurança do estudo de caso através dos diagramas: de

classes (Apêndice A), Atores (Apêndice B), ER (Apêndice C) e de seqüência (Apêndices D e E).

Na etapa de codificação foi utilizada a linguagem de programação Java Web, seguindo a

modelagem produzida pela etapa de projeto. Para finalizar as etapas anteriores foram realizados

testes, para verificar se os riscos apontados na análise de riscos foram suprimidos e após estes

testes, foram realizados testes de desempenho da aplicação com a segurança imposta.

Page 52: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

40

3.1 Modelagem do Estudo de Caso

Figura 23. Caso de uso do estudo de caso, cadastro de usuários

Será detalhado nas tabelas a seguir cada caso de uso do estudo de caso sobre o cadastro de

usuários, ilustrado pela Figura 23.

Tabela 3: Salvar usuário Nome do estudo de caso USC-001 Salvar usuário. Ator Principal Administrador. Resumo O ator deve acessar o cadastro de usuário, preencher o formulário e

acionar o botão salvar. Pré-condição O ator deve acessar o cadastro de usuário e preencher os dados do

formulário, como: nome do usuário, margem, e-mail, classificação se é ou não administrador do sistema e acionar o botão salvar.

Pós-condição Usuário salvo. Cenário do ator

Fluxo principal 1- o ator precisa estar no cadastro de usuário e preencher o formulário (cadastro) com o nome do usuário, margem, e-mail, classificação se é ou não administrador, senha e confirmação da senha; 2- em seguida o ator deve acionar o botão salvar; e 3- para que o sistema possa salvar o usuário no banco de dados, será proposto a utilização do mecanismo de criptografia na senha, com o algoritmo MD5.

Page 53: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

41

Fluxo alternativo - se o formulário do cadastro de usuário estiver vazio, o sistema não executará nada. - senha de confirmação invalida.

Tabela 4: Buscar usuário Nome do estudo de caso USC-002 Buscar usuário. Ator Principal Administrador e agente de pesquisa. Resumo O ator deve estar no cadastro de usuário para fazer a busca no

sistema. Pré-condição O ator deve estar no cadastro de usuário, preencher ou não o nome

do usuário e/ou email e acionar o botão buscar. Pós-condição Lista de usuários.

Cenário do ator Fluxo Principal 1- o ator precisa estar no cadastro de usuário;

2- preencher ou não o nome do usuário e/ou e-mail; e 3- acionar o botão buscar, que o estudo de caso irá listar os usuários.

Fluxo alternativo Nenhum.

Tabela 5: Excluir usuário Nome do estudo de caso USC-003 Excluir usuário. Ator Principal Administrador. Resumo O ator deve e estar no cadastro de usuário, executar uma busca,

selecionar qual usuário deseja excluir e acionar o botão excluir. Pré-condição Buscar e selecionar usuário. Pós-condição Usuário excluído.

Cenário do ator Fluxo Principal 1- o ator precisa estar no cadastro de usuário;

2- executar uma busca; 3- selecionar o usuário desejado; e 5- acionar o botão excluir.

Fluxo alternativo O sistema avisa que deve ser selecionado um usuário.

Page 54: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

42

Figura 24. Caso de uso do estudo de caso, cadastro de compatibilidades

Será detalhado nas tabelas a seguir cada caso de uso do estudo de caso sobre o cadastro de

compatibilidades, ilustrado pela Figura 24.

Tabela 6: Salvar compatibilidade Nome do estudo de caso USC-004 Salvar compatibilidade. Ator Principal Administrador. Resumo O ator deve estar no cadastro de compatibilidade preencher o

formulário e acionar o botão salvar. Pré-condição O ator deve estar no cadastro de compatibilidade preencher o

formulário com o nome da compatibilidade e acionar o botão salvar. Pós-condição Compatibilidade salva.

Cenário do ator Fluxo Principal 1- o ator precisa estar no cadastro de compatibilidade;

2- preencher o formulário com o nome da compatibilidade; e 3- em seguida o ator deve acionar o botão salvar.

Fluxo alternativo Se o formulário do cadastro da compatibilidade estiver vazio, o sistema não executará nada.

Tabela 7: Buscar compatibilidade Nome do estudo de caso USC-005 Buscar compatibilidade. Ator Principal Administrador e agente de pesquisa. Resumo O ator deve estar no cadastro de compatibilidade, para fazer a busca

no sistema. Pré-condição Estar no cadastro de compatibilidade e acionar o botão buscar. Pós-condição Lista de compatibilidades.

Cenário do ator Fluxo Principal 1- o ator precisa estar no cadastro de compatibilidade;

Page 55: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

43

2- preencher ou não o nome da compatibilidade que deseja procurar; 3- acionar o botão buscar; e 4- o estudo de caso irá listar as compatibilidades referente a busca no estudo de caso, mas se o campo for vazio será listada todas as compatibilidades do sistema.

Fluxo alternativo Nenhum.

Tabela 8: Excluir compatibilidade Nome do estudo de caso USC-006 Excluir compatibilidade. Ator Principal Administrador. Resumo O ator deve e estar no cadastro de compatibilidade selecionar qual

compatibilidade deseja excluir e acionar o botão excluir. Pré-condição Buscar e selecionar compatibilidade. Pós-condição Compatibilidade excluída.

Cenário do ator Fluxo Principal 1- o ator precisa estar no cadastro de compatibilidade;

2- fazer uma busca; 3- selecionar a compatibilidade desejada; e 4- executar o botão excluir.

Fluxo alternativo O sistema avisa que deve ser selecionada uma compatibilidade.

Figura 25. Caso de uso do estudo de caso cadastro de grupos

Será detalhado nas tabelas a seguir cada caso de uso do estudo de caso sobre o cadastro de

grupos, ilustrado pela Figura 25.

Tabela 9: Salvar grupo Nome do estudo de caso USC-007 Salvar grupo. Ator Principal Administrador.

Page 56: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

44

Resumo O ator deve estar no cadastro de grupo, preencher o formulário e acionar o botão salvar.

Pré-condição Estar no cadastro de grupo e preencher o formulário, com: o nome do grupo, ordem e informar se possuí compatibilidade e acionar o botão salvar.

Pós-condição Grupo salvo. Cenário do ator

Fluxo principal 1- o ator precisa estar no cadastro de grupo; 2- preencher o formulário com o nome do grupo, ordem e informar se possuí compatibilidade; e 3- acionar o botão salvar.

Fluxo alternativo Se o formulário do cadastro de grupo estiver vazio, o sistema não executará nada.

Tabela 10: Buscar grupo Nome do estudo de caso USC-008 Buscar grupo. Ator Principal Administrador e agente de pesquisa. Resumo O ator deve estar no cadastro de grupo, para fazer a busca no

sistema. Pré-condição Estar no cadastro de grupo, preencher ou não o nome do grupo e

acionar o botão buscar. Pós-condição Lista de grupos.

Cenário do ator Fluxo principal 1- o ator precisa estar no cadastro de grupo;

2- preencher o nome do grupo que se deseja procurar e acionar o botão buscar; e 3- o estudo de caso irá listar os grupos do estudo de caso.

Fluxo alternativo Nenhum.

Tabela 11: Excluir grupo Nome do estudo de caso USC-009 Excluir grupo. Ator Principal Administrador. Resumo O ator deve executar uma busca, selecionar o grupo e acionar o

botão excluir. Pré-condição Buscar e selecionar grupo. Pós-condição Grupo excluído.

Cenário do ator Fluxo principal 1- o ator precisa estar no cadastro de grupo;

2- fazer uma busca; 2- selecionar o grupo desejado; e 4- executar o botão excluir.

Fluxo alternativo O sistema avisa que deve ser selecionado um grupo.

Page 57: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

45

Figura 26. Caso de uso do estudo de caso cadastro de produtos

Será detalhado nas tabelas a seguir cada caso de uso do estudo de caso sobre o cadastro de

produtos, ilustrado pela Figura 26.

Tabela 12: Salvar produto Nome do estudo de caso USC-010 Salvar produto. Ator Principal Administrador. Resumo O ator deve estar no cadastro de produto, preencher o formulário e

acionar o botão salvar. Pré-condição Estar no cadastro de produto e preencher o formulário, com: o nome

do mesmo, selecionar uma compatibilidade cadastrada, selecionar um grupo cadastrado, preencher o preço e fornecer ao ator um campo para o ator descrever dados do produto e, acionar o botão salvar.

Pós-condição Produto cadastrado. Cenário do ator

Fluxo Principal 1- o ator precisa estar no cadastro produto; 2- preencher o formulário com o nome do produto; 3- selecionar um grupo cadastrado; 4- selecionar uma compatibilidade cadastrada; 5- preencher o preço do produto; 6- deixa o ator descrever as descrições do produto; e 7- acionar o botão salvar. Para que o sistema possa salvar um produto no banco de dados, será proposto a utilização do mecanismo de criptografia simétrica.

Fluxo alternativo Se o formulário do cadastro de produto estiver vazio, o sistema não executará nada.

Page 58: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

46

Tabela 13: Buscar produto Nome do estudo de caso USC-011 Buscar produto. Ator Principal Administrador e agente de pesquisa. Resumo O ator deve estar no cadastro de produto para fazer a busca no

sistema. Pré-condição Estar no cadastro de produto, selecionar ou não um grupo e/ou, uma

compatibilidade e acionar o botão buscar. Pós-condição Lista de produtos.

Cenário do ator Fluxo principal 1- o ator precisa estar no cadastro de produto;

2- selecionar ou não o grupo, e/ou a compatibilidade; e 3- acionar o botão buscar que o estudo de caso irá listá-los.

Fluxo alternativo Nenhum.

Tabela 14: Excluir produto Nome do estudo de caso USC-012 Excluir produto. Ator Principal Administrador. Resumo O ator deve executar uma busca, selecionar produto e acionar o

botão excluir. Pré-condição Buscar e selecionar um produto. Pós-condição Produto excluído.

Cenário do Ator Fluxo principal 1- o ator precisa estar no cadastro de produto;

2- fazer uma busca; 3- selecionar o produto desejado; e 4- acionar o botão excluir.

Fluxo alternativo O sistema avisa que deve ser selecionado um produto.

Figura 27. Caso de uso do estudo de caso de enviar e-mail, imprimir, login e análise de riscos

Page 59: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

47

Será detalhado nas tabelas a seguir cada o caso de uso do estudo de caso sobre enviar e-mail,

imprimir, login e análise de riscos, ilustrado pela Figura 27.

Tabela 15: Enviar e-mail Nome do estudo de caso USC-013 Enviar e-mail. Ator Principal Administrador, operador e agente de pesquisa. Resumo O ator envia e-mail para o cliente. Pré-condição O ator deve efetuar o login no sistema. Pós-condição E-mail enviado

Cenário do ator Fluxo principal 1- os atores precisam efetuar o login no sistema, na qual vão se

deparar com a tela de enviar email; 2- na tela de enviar email o ator digita o nome do cliente, telefone, localiza o produto e aciona o botão enviar; e 3- concluindo o passo 2, será feito a pergunta “Enviar para:” o ator preenche o email do destinatário neste campo e aciona o botão ‘ok’.

Fluxo alternativo Pedido de um email valido.

Tabela 16: Imprimir Nome do estudo de caso USC-014 Imprimir Ator Principal Administrador, operador e agente de pesquisa. Resumo O ator imprime as informações do produto Pré-condição Efetuar o login no sistema. Pós-condição Imprimir

Cenário do ator Fluxo principal 1- o ator deve efetuar um login no sistema;

2- na tela de imprimir o ator digita o nome do cliente, telefone, localiza o produto; e 3- acionar o botão imprimir, na qual, fará o pedido da impressora, então o mesmo a seleciona e conclui este processo.

Fluxo alternativo Pedido de uma impressora.

Tabela 17. Login do sistema Nome do estudo de caso USC-014 Login Ator Principal Administrador, operador e agente de pesquisa. Resumo O ator utiliza a tela mostrada pelo sistema e entra com os seguintes

dados: usuário e a senha. Para enviar estes dados para o sistema via formulário HTML, será proposto o uso de criptografia e tratamento de injeção de SQL.

Pré-condição - Efetuar o acesso ao sistema; e - Os Usuários do sistema não podem usar os seguintes caracteres (‘, --, xp_, insert, select, drop, or e and), no username e nem em no password, por motivo de ter sido implementado o controle de Injeção de SQL.

Pós-condição Ser um usuário autorizado.

Page 60: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

48

Cenário do ator Fluxo principal 1- o ator acessa o domínio do sistema;

2- será exibida uma tela de login pelo sistema; e 3- o ator entra com o usuário e a senha. Preenchendo estes dados o ator será submetido à autenticação e o sistema verificará se é usuário autorizado. E, para enviar os dados digitados nos formulários HTML do sistema, será proposto o uso do mecanismo de criptografia e de tratamento contra a injeção de SQL.

Fluxo alternativo Se o usuário não for autenticado, o sistema retornará para a tela de login a seguinte mensagem: “USUÁRIO INVALIDO”, mas caso contenha algum caractere que induza da injeção de SQL o mesmo exibirá a seguinte mensagem: “O SISTEMA IGNOROU A TENTATIVA DE ATAQUE DE INJECAO DE SQL”.

Tabela 18. Análise de Riscos Nome do estudo de caso USC-015 Análise de Riscos Ator Principal Administrador, operador e agente de pesquisa. Resumo O aluno lista as vulnerabilidades do sistema, e propõe algumas

medidas corretivas para solucionar as vulnerabilidades encontradas. Pré-condição Ter acesso a todo o sistema. Pós-condição Ser um usuário autorizado.

Cenário do ator Fluxo principal 1- o analista verifica as vulnerabilidades do sistema;

2- será elaborada uma tabela listando as vulnerabilidades do estudo de caso e suas possíveis soluções; 3- após elaborar esta análise de riscos, será executado as soluções indicadas para cada vulnerabilidade; e 4 - após executar as soluções indicadas para cada vulnerabilidade encontrada, o sistema não deverá ser vulnerável aos ataques listados.

Fluxo alternativo Se o sistema for encontrada alguma vulnerabilidade, o mesmo deverá se protegido.

3.2 Implementação dos controles de segurança

A implementação dos controles de segurança no estudo de caso, foi feita de acordo com as

necessidades apontadas pela análise de riscos, descrita na Seção 3.2.5. Desta forma foram

preparados:

• diretrizes de controle contra ataque de injeção de SQL, no formulário de

autenticação;

• controles criptográficos;

• segurança do servidor Web, com auxílio de um firewall; e

• testes de segurança e desempenho.

Page 61: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

49

3.2.1 Diretrizes de controle contra ataque de injeção de SQL

Conforme descrito na Seção 2.2.1 sobre o ataque de Injeção de SQL, constatou-se que o

estudo de caso possui comandos SQL para verificar se os dados dos usuários enviados pelo

formulário de autenticação existem no banco de dados. Portanto, foram inseridas diretrizes de

injeção de SQL para este formulário no método Login.injeçãoSQL(). Neste método, eliminou-se a

possibilidade de utilizar o caractere Apóstrofe (‘), --, ;, xp_ e comandos SQL, tais como: insert,

select, entre outros. Caso o intruso execute um Submit com estes caracteres e/ou comandos SQL, o

estudo de caso avisará imediatamente ao mesmo com a seguinte mensagem: “O SISTEMA

IGNOROU A TENTATIVA DE ATAQUE DE INJECAO DE SQL”.

Estas diretrizes estão detalhadas no método Login.injeçãoSQL(), que foi definido como

privado, porque somente a classe Login deve acessá-lo, por questões de segurança. O método

Login.injeçãoSQL (String texto) recebe uma String e retorna um valor booleano com o resultado da

verificação, que informa se a String será (valor true) ou não (valor false) ignorada. O código fonte

deste método esta sendo representado pela Figura 28.

Page 62: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

50

Page 63: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

51

Figura 28. Diretrizes de injeção de SQL em formulário de autenticação

A quantidade de caracteres, nos campos do formulário de autenticação de usuários no

estudo de caso, foi limitada a fim de evitar que intrusos insiram comandos SQL, o que poderia

causar danos ao sistema. E, as mensagens de erros do estudo de caso foram tratadas para não

demonstrar vulnerabilidade a este ataque. Ao mesmo tempo, foram utilizados nomes de usuários

diferentes dos tradicionais, como forma de dificultar o acesso de intrusos e por motivos de

segurança, não são mostrados comandos SQL.

A quantidade de caracteres foi limitada em dez, nos campos txtUsuario e txtSenha do

formulário de autenticação da aplicação. Esta limitação encontra-se na página index.jsp e, o trecho

de código que representa essa diretriz está ilustrado pela Figura 29 (linhas 53 e 57).

Figura 29. Limitação da quantidade de caracteres no formulário de autenticação

3.2.2 Análise de controles criptográficos

No estudo de caso, foram utilizadas a criptografia simétrica e a assimétrica. A criptografia

simétrica foi implementada na classe PWSec, com algoritmo DES e foi utilizada, no nome do

produto e na descrição do mesmo, com objetivo de dificultar que os intrusos consigam obter acesso

Page 64: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

52

à informação original através da, invasão do SGBD, da utilização de cavalo de tróia, ou de outros

tipos de ataques. Apesar de ter sido utilizada a criptografia simétrica para manter a

confidencialidade dos dados e devido ao desempenho da aplicação, há destaque para o uso da

criptografia assimétrica.

A criptografia simétrica no estudo de caso é feita através de dois métodos estáticos: o

PWSec.encrypt(String text), que recebe uma String para cifrar e o PWSec.descrypt(String text) que

recebe uma String para decifrar. Estes métodos estão representados pela Figura 30, na linha 25

mostra e a chave de criptografia simétrica com algoritmo DES que está armazenada no código fonte

do estudo de caso.

Page 65: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

53

Figura 30. Classe de criptografia simétrica

O servidor Web Apache Tomcat oferece a opção de utilizar o protocolo de comunicação

SSL. Este protocolo de comunicação necessita de uma chave de segurança pública, obtida através

de uma AC, detalhado na Seção 2.4.5.2.

Para habilitar o protocolo SSL no servidor Apache Tomcat sem envolver custos, deve-se

executar os seguintes passos (GUJ, 2006):

1. criar um certificado SSL através do seguinte comando do Java: keytool -genkey -

alias tomcat -keyalg RSA -keystore /home/san/certificado/key.jks;

2. responder as perguntas, conforme as sugestões da Figura 31;

3. entrar novamente com a senha changeit; e

4. modificar o server.xml do servidor Web Apache Tomcat, de acordo com a Figura 32,

na qual foi definido a porta como 8080 como padrão do Tomcat e a 8081 para o SSL

junto com o prefixo de domínio HTTPS.

Para verificar se o protocolo SSL esta habilitado no servidor Web Apache Tomcat, deve-

se:

1. inicializar o servidor Web Apache Tomcat;

2. executar um navegador; e

Page 66: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

54

3. acessar o seguinte endereço: https://localhost:8081/, de acordo com o server.xml do

servidor Web Apache Tomcat do estudo de caso, que exibirá o certificado SSL.

Figura 31. Como gerar certificado para o Apache Tomcat Fonte: (GUJ, 2006).

Figura 32. Server.xml servidor Web Apache Tomcat Fonte: (GUJ, 2006).

Page 67: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

55

As senhas dos usuários do estudo de caso foram criptografadas com o algoritmo

assimétrico MD5, mantendo-as em um tamanho fixo de caracteres. A classe responsável pela

criptografia de senhas com o algoritmo MD5 no estudo de caso é a CriptoUtil (Figura 33), com o

método estático CriptoUtil.criptografarSenha().

A classe CriptoUtil também possui um método estático utilizado para comparar as senhas

armazenadas no banco de dados, que é o CriptoUtil.senhaCompareTo(String senhaDoBanco, String

senha). Este método criptografa a String enviada pelo formulário e verifica se a senha é igual a que

está armazenada no banco de dados, se for igual retorna o valor booleano true, caso contrário, a

aplicação retorna o valor booleano false. O algoritmo MD5 produz uma saída unidirecional, através

de um hash de 128 bits.

Page 68: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

56

Figura 33. Classe que criptografa as senhas do estudo de caso

3.2.3 Segurança do Servidor Web

Para que o servidor do estudo de casos torne-se seguro, foi utilizado o auxílio do firewall do

Open Suse, liberando o acesso externo apenas para o servidor Web Apache Tomcat, pelas portas

8080 (porta padrão do servidor Apache Tomcat) e 8081 (definida como porta do protocolo SSL),

conforme ilustrado pelas Figuras 34 e 35.

O objetivo do Firewall neste trabalho é a construção de uma DMZ, que limite diversos

ataques citados na análise de riscos do estudo de caso. A função desta DMZ é manter todos os

serviços, que possuem acesso externo, separados dos serviços de uma rede local, limitando assim os

danos causados por intrusos.

Page 69: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

57

Figura 34. Serviço autorizado pelo firewall do Open Suse

Figura 35. Porta liberada pelo firewall do Open Suse

Page 70: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

58

3.2.4 Testes dos Controles de Segurança e Desempenho

Preparou-se testes com o JUnit do Java para verificar se as diretrizes de injeção de SQL,

descritas na Seção 2.4.7, foram impostas de forma adequada no formulário de autenticação do

estudo de caso. Este teste está sendo ilustrado pela Figura 36 e, o resultado do mesmo encontra-se

na Figura 37.

Page 71: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

59

Page 72: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

60

Figura 36. Teste das diretrizes de injeção de SQL no JUnit

Figura 37. Resultado do teste de injeção de SQL no JUnit

Se o intruso conseguir capturar as informações que estejam armazenadas no banco de

dados da aplicação Web, o mesmo não conseguirá obter as senhas “em claro”, pois as mesmas

encontram-se criptografadas com o algoritmo assimétrico MD5. O intruso não conseguirá nem

mesmo o nome e/ou a descrição dos produtos “em claro”, pois estes valores estão criptografados

com algoritmo simétrico DES.

O teste do algoritmo criptográfico MD5 está representado pela Figura 38 e o resultado

deste teste encontra-se na Figura 39. O teste da criptografia simétrica está sendo representado pela

Figura 40 e, o resultado deste teste encontra-se na Figura 41.

Page 73: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

61

Figura 38. Criptografia de senhas com o algoritmo MD5

Page 74: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

62

Figura 39. Resultado do teste da criptografia de senha

Page 75: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

63

Figura 40. Teste do algoritmo criptográfico simétrico

Figura 41. Resultado do teste da criptografia simétrica

O estudo de caso possui a opção de utilizar ou não o protocolo SSL, como ilustra a Figura

42. A Figura 43 mostra o certificado utilizado pelo protocolo SSL no estudo de caso. Este protocolo

de comunicação elimina as vulnerabilidades da aplicação em diversos ataques. Devido ao uso da

criptografia assimétrica o servidor Web necessita de muito processamento de informações. Por esse

motivo, preparou-se uma classe, representada pela Figura 44, que calcula o tempo de processamento

das rotinas do estudo de caso.

Figura 42. Escolha do uso do protocolo SSL

Page 76: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

64

Figura 43. Certificado utilizado no protocolo SSL do estudo de caso

Figura 44. Classe que calcula o tempo de processamento

Page 77: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

65

A classe Tempo possui uma função que calcula o tempo de processamento da aplicação,

como ilustra a Figura 45 (linhas 68, 69, 73, 76 e 80). Esta classe Tempo é utilizada em cada rotina

do estudo de caso, com objetivo de mostrar para o usuário final o desempenho da aplicação, como

mostra a Figura 46.

Figura 45. Utilização da classe que calcula o tempo

Figura 46. Tempo de processamento do salvar usuário

Na Tabela 19 pode-se observar o tempo que a aplicação leva para processar os dados com e

sem os controles de segurança, em um servidor com a seguinte configuração: AMD X2 3600 GHz,

512 MB RAM, HD 80 GB SATA e rede 10/100 Mbps e, como cliente foi utilizado um notebook de

marca DELL com a seguinte configuração: CORE 2 DUO 2.2 GHz, 2048 MB RAM, 160 GB

SATA, REDE 10/100 Mbps e WIFI 100Mbps. Este tempo foi calculado em uma rede de 100 Mbps.

Page 78: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

66

Tabela 19. Cálculo do tempo de processamento com e sem o controle de segurança

Controle Sistema com segurança Sistema sem segurança Tela

Diretrizes de injeção de SQL

- 0.018 msec Autenticação

Diretrizes de injeção de SQL – SSL

0.070 msec 0.018 msec Autenticação

Diretrizes de injeção de SQL e firewall

0.034 msec 0.018 msec Autenticação

Diretrizes de injeção de SQL – SSL e firewall

0.070 msec 0.018 msec Autenticação

Criptografia de senhas com o algoritmo MD5 (salvar usuário)

0.012 msec 0.011 msec Cadastro de usuários

Criptografia de senhas com o algoritmo MD5 – SSL (salvar usuário)

0.0020 msec 0.011 msec Cadastro de usuários

Criptografia de senha com MD5 – firewall (salvar usuário)

0.0090 msec 0.0011 msec Cadastro de usuários

Criptografia de senha com MD5 – SSL e firewall (salvar usuário)

0.0020 msec 0.011 msec Cadastro de usuários

Criptografia de senha com MD5 (buscar usuário)

0.0060 msec 0.01 msec Cadastro de usuários

Protocolo de comunicação SSL (buscar usuário)

0.0040 msec 0.01msec Cadastro de usuários

Firewall (buscar usuário)

0.0060 msec 0.01 msec Cadastro usuário

Protocolo de comunicação SSL e

0.040 msec 0.01msec Cadastro usuário

Page 79: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

67

firewall (buscar usuário)

Excluir usuário – criptografia de senha

0.01 msec 0.01 msec Cadastro de usuários

Excluir usuário – criptografia de senha – SSL

0.0020 msec 0.01 msec Cadastro de usuários

Excluir usuário – criptografia de senha – firewall

0.01 msec 0.01 msec Cadastro de usuários

Excluir usuário – criptografia de senha – SSL e firewall

0.0020 msec 0.01 msec Cadastro de usuários

Criptografia de nomes e descrição (salvar produtos)

0.016 msec 0.031 msec Cadastro de produtos

Criptografia de nomes e descrição (salvar produtos) – SSL

0.129 msec 0.031 msec Cadastro de produtos

Criptografia de nomes e descrição (salvar produtos) – firewall

0.058 msec 0.031 msec Cadastro de produtos

Criptografia de nomes e descrição (salvar produtos) – SSL e firewall

0.129 msec 0.31 msec Cadastro de produtos

Criptografia de nomes e descrição (buscar produtos)

2.437 msec 1.854 msec Cadastro de produtos

Criptografia de nomes e descrição – SSL (buscar produtos)

0.911 msec 1.854 msec Cadastro de produtos

Criptografia de nomes 2.788 msec 1.854 msec Cadastro de

Page 80: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

68

e descrição – firewall (buscar produtos)

produtos

Criptografia de nomes e descrição – firewall e SSL (buscar produtos)

0.911 msec 1.854 msec Cadastro de produtos

Excluir produto 0.0060 msec 0.0030 msec Cadastro de produtos

Excluir produto – SSL

0.020 msec 0.0030 msec Cadastro de produtos

Excluir produto – firewall

0.014 msec 0.0030 msec Cadastro de produtos

Excluir produto SSL e firewall

0.020 msec 0.0030 msec Cadastro de produtos

Salvar grupo 0.012 msec 0.0020 msec Cadastro de grupo

Salvar grupo – SSL 0.026 msec 0.0020 msec Cadastro de grupo

Salvar grupo – firewall

0.0060 msec 0.0020 msec Cadastro de grupo

Salvar grupo – SSL e firewall

0.026 msec 0.0020 msec Cadastro de grupo

Buscar grupo 0.31 msec 0.302 msec Cadastro de grupo

Buscar grupo – SSL 0.146 msec 0.302 msec Cadastro de grupo

Buscar grupo – firewall

0.36 msec 0.302 msec Cadastro de grupo

Buscar grupo – SSL e firewall

0.146 msec 0.302 msec Cadastro de grupo

Page 81: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

69

Excluir grupo 0.011 msec 0.0020 msec Cadastro de grupo

Excluir grupo – SSL 0.0020 msec 0.0020 msec Cadastro de grupo

Excluir grupo – firewall

0.0030 msec 0.0020 msec Cadastro de grupo

Excluir grupo – SSL e firewall

0.0020 msec 0.0020 msec Cadastro de grupo

Salvar compatibilidade

0.025 msec 0.012 msec Cadastro de compatibilidade

Salvar compatibilidade – SSL

0.035 msec 0.012 msec Cadastro de compatibilidade

Salvar compatibilidade – firewall

0.0030 msec 0.012 msec Cadastro de compatibilidade

Salvar compatibilidade – SSL e firewall

0.035 msec 0.012 msec Cadastro de compatibilidade

Buscar compatibilidade

0.304 msec 0.26 msec Cadastro de compatibilidade

Buscar compatibilidade – SSL

0.154 msec 0.26 msec Cadastro de compatibilidade

Buscar compatibilidade – firewall

0.255 msec 0.26 msec Cadastro de compatibilidade

Buscar compatibilidade – SSL e firewall

0.154 msec 0.26 msec Cadastro de compatibilidade

Page 82: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

70

Excluir compatibilidade

0.0020 msec 0.0020 msec Cadastro de compatibilidade

Excluir compatibilidade – SSL

0.0020 msec 0.0020 msec Cadastro de compatibilidade

Excluir compatibilidade – firewall

0.012 msec 0.0020 msec Cadastro de compatibilidade

Excluir compatibilidade – SSL e firewall

0.0020 msec 0.0020 msec Cadastro de compatibilidade

3.2.5 Análise de Riscos

O principal risco deste projeto é que o estudo de caso pode ser manipulado por intrusos

através de ataques, tais como: injeções de SQL, IP Spoofing, cavalos de tróia, entre outros, que

podem causar inconsistências nas informações. Estes riscos devem ser discutidos com os

stakeholders, para poder escolher controles mais eficientes e baratos e que possam evitá-los.

Segundo Dias (2000), os impactos podem ser classificados em:

0 – impacto irrelevante;

1 – efeito pouco significativo, ou seja, sem afetar a maioria dos negócios da

organização;

2 – sistema indisponível por um período de tempo;

3 – perdas financeiras;

4 – efeitos desastrosos sem comprometer a organização; e

5 – efeitos desastrosos comprometendo a organização.

Os tipos de impactos estão ilustrados na Tabela 20, que é feito em uma escala de 1 a 7.

Tabela 20. Tipos de impactos Tipo Descrição 01 Modificação de dados 02 Sistemas não disponíveis 03 Divulgação de informações confidenciais 04 Fraude 05 Perda de credibilidade

Page 83: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

71

06 Possibilidade de processo legal contra a instituição 07 Perda de clientes para a concorrência Fonte: Dias (2000).

Probabilidade de ocorrer uma ameaça é feita em uma escala de 0 a 5 (DIAS, 2000):

0 – probabilidade de não ocorrer uma ameaça;

1 – probabilidade de uma ameaça menos de uma vez por ano;

2 – probabilidade de ocorrer uma ameaça pelo menos uma vez por ano;

3 – probabilidade de ocorrer uma ameaça pelo menos uma vez por mês;

4 – probabilidade de ocorrer uma ameaça pelo menos uma vez por semana; e

5 – probabilidade de ocorrer uma ameaça diariamente.

A Tabela 21 ilustra algumas ameaças, tipos de impactos, impactos e probabilidade de

ocorrência de uma ameaça e solução indicada para cada risco, mas neste trabalho serão tratadas

apenas as vulnerabilidades lógicas.

Tabela 21. Os riscos do estudo de casos Ameaça Impacto Tipo de impacto Probabilidade Solução

indicada Erros humanos (destruição ou modificação acidental de informações, fornecimento acidental de informações confidenciais, configuração incorreta do sistema operacional)

0 07 5 Treinamento do funcionário

Instalação de hardware e software não autorizado

0 05 5 Treinamento do funcionário

Ameaça programada (vírus, bombas lógicas)

1 5 5 Treinamento do funcionário

Bugs do SO 4 02 5 Treinamento do funcionário

Ameaça programada que marcará sua identificação (cavalo de tróia)

5 03 5 Firewall e criptografia

Intrusos fazendo se passar por usuários autorizados (mascaramento)

5 03 5 Firewall e criptografia

Desastres naturais (incêndio, enchente, terremoto)

0 07 3 Treinamento do funcionário

Page 84: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

72

Desastres causados por pessoas (guerras, bombas)

0 02 1 Treinamento do funcionário

Falha de equipamento 1 05 3 Treinamento do funcionário

Sabotagem 5 04 5 Treinamento do funcionário

Roubo 1 04 5 Treinamento do funcionário

Grampo de linhas telefônicas 0 03 0 Treinamento do funcionário

Monitoramento de trafego de informações interna

0 03 5 Firewall e criptografia

Monitoramento de trafego de informações externa

4 03 5 Firewall e criptografia

Modificação deliberada de informações

5 05 5 Firewall e criptografia

Dano deliberado ao conteúdo de arquivos ou sistemas confidenciais

4 01 5 Firewall, autenticação e criptografia

Acesso a arquivos de senhas 5 04 5 Firewall, criptografia e autenticação

Uso de senhas frágeis 5 05 5 Criptografia Acesso físico não autorizado ao sistema

0 04 0 Autenticação e firewall

Usuários internos praticando atos ilegais

4 04 1 Treinamento do funcionário

Não cumprimentos de normas legais

5 04 1 Treinamento do funcionário

Envio de dados criptografados do formulário de autenticação do usuário na aplicação Web

5 04 5 Criptografia e protocolo de autenticação

Ataque as propriedades de segurança

5 04 5 Firewall e criptografia

Injeção de SQL 5 04 5 Criptografia e diretrizes de injeção de SQL

IP Spoofing 5 04 5 Firewall Bypass 5 04 5 Firewall DOS 2 02 2 Firewall

Page 85: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

73

Vulnerabilidade em servidores Web

5 04 5 Firewall

Violação em navegadores 4 03 5 Não instalar aplicativos auxiliares

Vulnerabilidades na Web 5 03 5 Firewall e criptografia

Fonte: Adaptado de Dias (2000).

O estudo de caso pode sofrer ataques entre o cliente e o servidor, pois não possui proteção

criptográfica nas comunicações. Conforme Beal (2005), para elaborar uma análise de risco deve-se

seguir alguns passos como ilustra a Figura 47.

Figura 47. Etapas da gestão do risco Fonte: Beal (2005).

Conforme a Figura 47 deve-se iniciar com o estabelecimento do contexto para poder seguir

com a identificação dos riscos e, após isto, deve-se iniciar a análise dos riscos, verificando: as

possíveis ameaças e as probabilidades destas ocorrerem; as vulnerabilidades e análise do grau de

Page 86: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

74

exposição da informação; e o impacto para verificar a perda estimada da informação. Com os

resultados destas três análises obtém-se uma estimativa dos riscos. Em seguida deve-se avaliar os

riscos para poder saber tratá-los e saber aceitá-los.

Page 87: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

4 CONCLUSÕES

No decorrer do século XXI, as organizações têm se preocupado cada vez mais com a

segurança das informações processadas via aplicações Web e, este tema foi escolhido para

demonstrar as inúmeras vulnerabilidades encontradas, através de um estudo de caso. Por isso, foi

preparada uma Fundamentação Teórica que auxiliou no entendimento do assunto, detalhando como

funcionam os possíveis ataques que as aplicações Web podem sofrer e as possíveis soluções para

estes ataques.

Pelo fato da bibliografia, sobre segurança na Web, ser muito vasta, houve dificuldade de

seleção de materiais confiáveis. No entanto, o professor orientador sinalizou fontes precisas, como:

livros, artigos, teses, monografias e sites.

Na fase da Fundamentação Teórica, muitos conhecimentos foram descobertos e isso agregou

informações adicionais ao trabalho. A análise de riscos elaborada permitiu identificar os possíveis

riscos e propor soluções com tecnologias de segurança. No estudo de caso foram realizados testes

para verificar se os riscos apontados na análise de riscos foram suprimidos. Também foram

realizados testes de desempenho da aplicação com a segurança imposta. Portanto, o presente

trabalho pode servir como fonte de pesquisa aos profissionais da área que queiram impor segurança

em aplicações Web.

Na fase de Desenvolvimento, foram colocados em prática vários controles de segurança

descritos na Fundamentação Teórica, tais como: diretrizes de injeção de SQL no formulário de

autenticação, criptografia de senhas com o algoritmo MD5, o uso do protocolo de comunicação

criptográfico SSL, criptografia simétrica de informações e o uso de um firewall. Com a aplicação

destes controles de segurança, percebe-se que o tempo de processamento do servidor da aplicação

Web aumenta proporcionalmente ao número de controles de segurança que são impostos, conforme

detalhado na Tabela 19. Devido a isto, foi implementada uma classe que calcula o tempo de

processamento resultante da utilização de cada um dos controles de segurança aplicados no estudo

de caso. Além disso, foram estudados e elaborados testes com a biblioteca JUnit do Java para testar

a aplicação.

Para poder demonstrar os controles de segurança implementados no servidor do estudo de

caso, foi implantado o sniffer (wireshark), com objetivo de demonstrar o uso: do firewall e do

protocolo de segurança Secure Socket Layer. Neste tipo de ataque observou-se que o firewall limita

o acesso às portas do servidor, enquanto que o SSL utiliza diferentes algoritmos de criptografia, para

oferecer a autenticação e a integridade dos dados com o uso de chaves diferentes.

Page 88: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

76

Além destes controles de segurança, foi implementada: a criptografia simétrica, com o

algoritmo DES, que é utilizada no cadastro de produtos; a criptografia assimétrica com o algoritmo

MD5, que é utilizada nas senhas dos usuários; e também as diretrizes de injeção de SQL, que são

utilizadas no formulário de autenticação do estudo de caso, na qual, ignora o caractere Apóstrofe

(‘), --, ;, xp_ e comandos SQL, tais como: insert, select, entre outros.

Recomenda-se que as organizações que se preocupam com a segurança dos dados

processados pelas suas aplicações Web, atentem para a utilização de controles de segurança, tais

como: diretrizes de injeção de SQL, criptografia simétrica e/ou criptografia assimétrica, firewall e,

se possível, utilizar o protocolo de comunicação SSL. O protocolo criptográfico SSL é o mais

utilizado em aplicações Web seguras, mas os testes demonstraram que o mesmo consome muito

desempenho devido ao uso da criptografia assimétrica.

Conclui-se ainda que as organizações podem obter segurança de informações em suas

aplicações Web, sendo que, para isso, as mesmas devem elaborar uma análise de riscos para

poderem levantar os possíveis riscos. E, com base na Análise de Riscos elaborada, é possível

decidir quais controles de segurança devem ser escolhidos e também é possível observar se os

mecanismos escolhidos garantem as propriedades de segurança, corrigem os riscos, fornecem um

alto desempenho e apresentam um baixo custo.

Para trabalhos futuros são sugeridos os seguintes temas:

• integridade de dados com algoritmo SHA-01 e MD5;

• interação do sistema de segurança dos sistemas de gerenciamento de banco de dados e do

ambiente de rede; e

• adaptação do estudo de caso para a área didática para as disciplinas de redes e banco de

dados.

Page 89: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

REFERÊNCIAS BIBLIOGRÁFICAS

AZEVEDO, Felipe Vieralves. Análise de Risco. Acessado em: (25/09/2007), disponível em: http://www.cafesoftware.com.br/imprensa_artigo1.htm, 2002.

BEAL, Adriana. Segurança da informação: princípios e melhores práticas para a proteção dos ativos de informação nas organizações. São Paulo: Atlas, 2005.

BORTOLUZZI, Fabrício. Aplicação da Análise de Causa Raiz em Sistemas de Detecção de Intrusões. Florianópolis, 2005. Dissertação (Mestrado) – Universidade Federal de Santa Catarina, Centro de Tecnológico.

BURNETT, Steve; PAINE, Stephen. Criptografia e segurança: o guia oficial RSA. Rio de Janeiro: Campus: Elsevier, 2002.

CAMPELLO, Rafael; WEBER, Raul. Sistemas de Detecção de Intrusão. Acessado em: (08/05/2007), disponível em: http://www.inf.ufrgs.br/~gseg/producao/minicurso-ids-slides-sbrc-2001.pdf, 2001.

CAMPOS, Bruno; MONTEIRO, Iberê; MIGUEL, Marcos. Criptografia. Acessado em: (15/09/2007), disponível em: http://www.google.com.br/url?sa=t&ct=res&cd=17&url=http%3A%2F%2Fwww.dei.unicap.br%2F~almir%2Frc2%2Fapresentacao%2Frc%2Fassinatura%2FCriptografia%2520-%2520Redes.ppt&ei=X3_sRv25JYTeeurcsN8G&usg=AFQjCNGhkZmHcpCr4LjZzgFdGy8Ridt2tw&sig2=6t-C7KU0b5KzUQ8xswaWAw, 2007.

CARDOSO, Ana Paula da Costa; SILVA, Wender Antônio. Revista do Instituto Luterano de Ensino Superior de Itumbiara. Acessado em: (04/04/2007), disponível em: http://www.editoradaulbra.com.br/catalogo/periodicos/pdf/periodico17_7_2.pdf, 2005.

CARUSO, Carlos A. A. (Carlos Alberto Antonio); STEFFEN, Flavio Deny. Segurança em informática e de informações. 2.ed. São Paulo: SENAC, 1999.

CERT (Computer Emergency Response Team). Proposta de combate aos crimes de informática avança no senado. Acessado em: (04/05/2007), disponível em: http://www.cert.org, 2005.

CHANDLER, David M.; KIRKNER, Bill. Como montar o seu site na World Wide Web. Rio de Janeiro: Campus, 1996.

CHAPELA, Victor. Advanced SQL Injection. Acessado em: (20/05/2007), disponível em: http://www.owasp.org/images/7/74/Advanced_SQL_Injection.ppt, 2005.

DATE, C. J. Introdução a sistemas de bancos de dados. 7. ed. Rio de Janeiro: Campus, 2000.

DATE, C. J. Introdução a sistemas de bancos de dados. Rio de Janeiro: Elsevier Butterworth Heinemann, 2004.

DIAS, Claudia. Segurança e auditoria da tecnologia da informação. Rio de Janeiro: Axcel Books, 2000.

Page 90: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

78

GAMMA, Erich. Padrões de projeto: soluções reutilizáveis de software orientado a objetos. Porto Alegre: Bookman, 2000.

GARFINKEL, Simson; SPAFFORD, Gene. Comercio & segurança na Web: riscos, tecnologias e estratégias. São Paulo: Market Press, 1999.

GIL, Antonio de Loureiro. Segurança em informática: ambientes mainframe, WAN, LAN e conexões via EDI com plataformas de informática de outras organizações. 2. ed. São Paulo: Atlas 2, 1998.

GOMES, Olavo Jose Anchieschi. Segurança total. São Paulo: Makron Books, 2000.

GRÉGIO, André Ricardo Abed; BARBATO, Luiz Gustavo C; DUARTE, Luiz Otávio; MONTES, Antonio. Codificação segura: Abordagens práticas. Acessado em (28/08/2007), disponível em: http://www.linorg.cirp.usp.br/SSI/SSI2005/Microcursos/MC01.pdf, 2005.

GUJ. Noticias, Tutoriais e o maior Fórum brasileiro sobre Java. Acessado em: (19/05/2008), disponível em: http://www.guj.com.br/posts/list/54839.java, 2006.

ISO/IEC 17799:2000 (E) - Tecnologia da Informação – Código de Prática para Gestão da Segurança de Informações ISO/IEC 15408, 2000.

JAMHOUR, Edgard. Internet e Segurança. Acessado em: (15/09/2007), disponível em: http://www.google.com.br/url?sa=t&ct=res&cd=1&url=http%3A%2F%2Fwww.ppgia.pucpr.br%2F~jamhour%2FPessoal%2FEspecializacao%2FAno01%2FINTERSEGWEB%2FSSL2.ppt&ei=fCTsRpWFFJuOeaz86eAG&usg=AFQjCNHiS4EG-TQfeDb26bMhA0DHFFT5CQ&sig2=l_iwvswrcAaAhARrShNMyA, 2007.

KRISHNAMURTHY, Balachander; REXFORD, Jennifer. Redes para a Web: http/1.1, protocolos de rede, caching e medição de trafego. Rio de Janeiro: Campus, 2001.

KUROSE, James F.; ROSS, Keith W. Redes de computadores e a internet: uma abordagem top-down 3. ed. São Paulo: Pearson, 2005.

LANDWEHR, Carl. Computer security. International Journal of Information Security, 1(1):3–16, 2001.

LOZANO, Fernando. Programação Segura para a Web. Revista Java Magazine, 2004.

MACORATTI, José Carlos. Previna-se contra a Injeção SQL. Acessado em: (16/03/2007), disponível em: http://www.macoratti.net/sql_inj.htm.

MICROSOFT. Ameaças e contramedidas, Acessado em: (16/03/2007), disponível em: http://www.microsoft.com/brasil/security/guidance/topics/devsec/secmod87.mspx, 2004.

MICROSOFT. Protegendo seu Servidor de Banco de Dados. Acessado em: (14/04/2007), disponível em: http://www.microsoft.com/brasil/security/guidance/topics/devsec/secmod91.mspx, 2004.

MISAGHI, Mehran. O Papel de Criptografia em Segurança da Informação. Acessado em: (15/09/2007), disponível em: www.vision.ime.usp.br/~mehran/ensino/seg10.ppt, 2007.

MENDES, Hammurabi das Chagas; SANTOS, Carlos da Silva dos. Condicionamento de Ambiente. Acessado em: (28/08/2007), disponível em: http://gsd.ime.usp.br/~kon/PLoP/2005/2005/CondicionamentoDeAmbiente.pdf, 2005.

Page 91: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

79

MOREIRA, Rodrigo da Silva. Assinaturas digitais. Acessado em: (03/08/2007), disponível em: http://www.gta.ufrj.br/grad/00_1/rodrigo/fr8right.htm, 2007.

NAVARRO, Marcos Cunha e NERIVAN, Luciano Itaparica. CRIPTOGRAFIA. Acessado em: (15/09/2007), disponível em: http://www.google.com.br/url?sa=t&ct=res&cd=13&url=http%3A%2F%2Ftwiki.im.ufba.br%2Fpub%2FMAT060%2FWebHome%2FCriptografia20051.ppt&ei=X3_sRv25JYTeeurcsN8G&usg=AFQjCNGjKPeanwZMjLvhX2qzJWM9nqKh1A&sig2=hMPha0Xkfa5Cg0H4FyodNQ, 2007.

OLIVEIRA, Wilson Jose de. WAP: tecnologia e segurança. Florianópolis: Bookstore, 2000.

OPPENHEIMER, Priscilla. Projeto de redes top-down: um enfoque de análise de sistemas para o projeto de redes empresariais. 2.ed. Rio de Janeiro: Campus, 1999.

OWASP Chapter Brasil, a enciclopédia livre. Falhas de Injeção. Acessado em: (23/08/2007), disponível em: http://owasp.securenet.com.br/index.php/A6_Falhas_de_Inje%C3%A7%C3%A3o, 2006.

PAES, Evandro. Arquivos para 'Segurança' Categoria. Acessado em: (20/05/2007), disponível em: http://evandropaes.wordpress.com/tag/informatica/seguranca/, 2007.

PETERSON, Larry L.; DAVIE, Bruce S.Redes de computadores: uma abordagem de sistemas. Rio de Janeiro: Campus: Elsevier, 2004.

PUTTINI, Ricardo S. Criptografia. Acessado em: (15/09/2007), disponível em: https://www.redes.unb.br/security/criptografia.pdf, 2007.

SANTANA FILHO, Ozeas Vieira. Introdução a internet: tudo que você precisa saber para navegar bem na rede. São Paulo: Editora SENAC São Paulo, 1998.

SANTOS, Daniel. Metade das lojas de comércio eletrônico é vulnerável a ataques, revela estudo. Acessado em: (20/02/2007), disponível em: http://idgnow.uol.com.br/seguranca/2007/02/07/idgnoticia.2007-02-07.8704834843/IDGNoticia_view, 2007.

SILBERSCHATZ, Abraham. Sistema de banco de dados. 3. ed. São Paulo: Makron, MCGraw-Hill, 1999.

SILVA, Jamil de Almeida. UMA PROPOSTA DE METODOLOGIA PARA SEGURANÇA EM SISTEMAS DE TECNOLOGIA DA INFORMAÇÃO. Acessado em: (28/09/2007) Disponível em: http://teses.eps.ufsc.br/defesa/pdf/7368.pdf, 2001.

TANENBAUN, Andrew S. Redes de Computadores. 3 ed. Rio de Janeiro:Campus, 1994.

TERADA, Routo. Segurança de dados: criptografia em redes de computador. São Paulo: Edgard Blucher Ltda, 2000.

TERADA, Routo. Segurança de Dados: criptografia. Acessado em: (14/04/2007), disponível em: http://www.usp.br/cci/geinfo/cripto.pdf, 2003.

WANGHAM, Michelle Silva. Esquema de segurança para agentes móveis em sistemas abertos. Florianópolis, 2004. 187 f. Tese (Doutorado) - Universidade Federal de Santa Catarina, Centro de Tecnológico. Programa de Pós-Graduação em Engenharia Elétrica.

WEBER, Raul Fernando. Criptografia Contemporânea. Acessado em: (13/09/2007), disponível em: http://www.inf.ufsc.br/~mauro/curso/redes/cripto.doc, 2007.

Page 92: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

GLOSSÁRIO

Background Processa sem que o usuário saiba Buffer Memória do servidor Web Buffer overflow Estouro de memória do servidor Web Intruso Usuário malicioso Handshake Comunicação cliente/servidor Plugins Aplicativos auxiliares Sniffer Coletor de informações Stack smash Quebra da pilha Strings Comandos Trojan Sistema Modificado Web É um aplicativo da internet

Page 93: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

APÊNDICES

Page 94: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

82

A) DIAGRAMA DE CLASSE

B) ATORES DO SISTEMA

Page 95: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

83

C) DIAGRAMA ER

D) DIAGRAMAS DE SEQÜÊNCIA (Administrador)

Page 96: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

84

Page 97: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

85

Page 98: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

86

Page 99: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

87

Page 100: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

88

Page 101: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

89

Page 102: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

90

Page 103: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

91

E) DIAGRAMAS DE SEQÜÊNCIA (Administrador e operador)

Page 104: Segurança de Sistemas por Sanderson Scheuer Mocelin Paulo ...siaibib01.univali.br/pdf/Sanderson Scheuer Mocelin.pdf · Injeção de SQL em formulários HTML ..... 11 Figura 6. Funcionamento

92