View
218
Download
0
Category
Preview:
Citation preview
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
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
DEDICATÓRIA
Dedico este trabalho aos amigos e familiares.
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!
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
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
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
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
ix
Figura 47. Etapas da gestão do risco .............................................................................................. 73
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
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.
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.
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
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).
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.
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.
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.
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:
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.
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.
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
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
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
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á
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.
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.
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
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).
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:
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.
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)
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
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.
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
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
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)
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.
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).
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.
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
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).
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).
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á
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
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.
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:
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.
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.
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.
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.
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.
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.
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.
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;
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.
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.
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.
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
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.
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.
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.
50
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
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.
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
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).
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.
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.
57
Figura 34. Serviço autorizado pelo firewall do Open Suse
Figura 35. Porta liberada pelo firewall do Open Suse
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.
59
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.
61
Figura 38. Criptografia de senhas com o algoritmo MD5
62
Figura 39. Resultado do teste da criptografia de senha
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
64
Figura 43. Certificado utilizado no protocolo SSL do estudo de caso
Figura 44. Classe que calcula o tempo de processamento
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.
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
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
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
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
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
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
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
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
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.
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.
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.
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.
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.
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.
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
APÊNDICES
82
A) DIAGRAMA DE CLASSE
B) ATORES DO SISTEMA
83
C) DIAGRAMA ER
D) DIAGRAMAS DE SEQÜÊNCIA (Administrador)
84
85
86
87
88
89
90
91
E) DIAGRAMAS DE SEQÜÊNCIA (Administrador e operador)
92
Recommended