Embed Size (px)
DESCRIPTION
Citation preview
CENTRO UNIVERSITÁRIO METODISTA BENNETT
CURSO DE CIÊNCIA DA COMPUTAÇÃO
TRABALHO DE CONCLUSÃO DE CURSO
PROTEÇÃO E RECOMENDAÇÕES PARA O PROBLEMA
DO ARMAZENAMENTO CRIPTOGRÁFICO INSEGURO PROJETO AECRIPT
LUIZ FERNANDO GONÇALVES
RIO DE JANEIRO
JULHO, 2009
II
CENTRO UNIVERSITÁRIO METODISTA BENNETT
CURSO DE CIÊNCIA DA COMPUTAÇÃO
PROTEÇÃO E RECOMENDAÇÕES PARA O PROBLEMA
DO ARMAZENAMENTO CRIPTOGRÁFICO INSEGURO PROJETO AECRIPT
Trabalho de Final de curso submetido ao Centro Universitário Metodista Bennett como parte dos requisitos para a obtenção do grau de Bacharel em Ciências da Computação
Orientador: Prof. M.Sc. Willian Augusto R. de Souza
RIO DE JANEIRO JULHO, 2009
III
ESTE TRABALHO FOI JULGADO ADEQUADO PARA A OBTENÇÃO DO GRAU DE BACHAREL EM CIÊNCIA DA COMPUTAÇÃO E APROVADO EM SUA FORMA FINAL PELA DISCIPLINA DE TRABALHO DE CONCLUSÃO DE CURSO BANCA EXAMINADORA: _________________________________________ M.Sc. Willian Augusto R. de Souza Orientador _________________________________________ M. Sc. Pier Giovanni Taranti _________________________________________ D. Sc. Júlio Luiz Nunes Carvalho
Rio de Janeiro Julho, 2009
IV
AGRADECIMENTOS
Agradeço, antes de tudo, a Deus, por ter me munido de forças para
superar as dificuldades apresentadas durante o meu percurso acadêmico.
A minha esposa Márcia e meus filhos Marcos Fernando, Luiz Felipe,
Luiz Guilherme pela força, amparo, amor e compreensão, e por ajudarem a não
me deixar ser derrotado pelas dificuldades enfrentadas.
Aos meus professores, pelo incentivo e ajuda constante na busca pelo
conhecimento. Em especial ao meu Professor Orientador M.Sc William Augusto
Rodrigues de Souza, pela valorosa orientação, atenção e apoio em todos os
momentos e que em momento algum negou auxilio, propondo valiosas
sugestões.
A todos os meus amigos acadêmicos que me incentivaram, apoiaram
possibilitando esta oportunidade, ampliando assim meus horizontes na
conclusão desta importante jornada da minha vida.
“O que me preocupa não e o grito dos maus; mas o silêncio dos bons” Martin Luther King
RESUMO............................................................................................................. I ABSTRACT......................................................................................................... I 1. INTRODUÇÃO............................................................................................ 8
2. FERRAMENTAS SEGURAS EM APLICAÇÕES WEB............................ 11
2.1. FRAMEWORKS .................................................................................... 11
2.2. DADOS INSEGUROS ........................................................................... 12
3. VULNERABILIDADE................................................................................ 15
3.1. INTRODUÇÃO ...................................................................................... 15
3.2. DADOS SENSÍVEIS.............................................................................. 15
3.3. ALGORITMOS FORTES....................................................................... 17
3.4. ALGORITMOS FRACOS ...................................................................... 19
3.5. CODIFICAÇÃO DE CHAVES ............................................................... 22
4. VERIFICAÇÃO DE SEGURANÇA ........................................................... 26
4.1. INTRODUÇÃO ...................................................................................... 26
4.2. VERIFICAÇÃO DE SEGURANÇA EM APLICAÇÕES WEB................ 29
4.3. DADOS SENSÍVEIS EM SISTEMAS DE ARMAZENAMENTO............ 33
4.4. PESQUISA DE VULNERABILIDADES................................................. 38
4.5. FERRAMENTAS DE PESQUISA DE CÓDIGOS INSEGUROS ........... 43
5. PROTEÇÃO.............................................................................................. 47
5.1. INTRODUÇÃO ...................................................................................... 47
5.2. MECANISMOS DE SEGURANÇA........................................................ 48
5.3. AMEAÇAS À SEGURANÇA................................................................. 50
5.4. NÍVEL DE SEGURANÇA DE PROTEÇÃO........................................... 51
5.5. POLÍTICAS DE SEGURANÇA DE PROTEÇÃO .................................. 52
6. CONCLUSÃO ........................................................................................... 54
7. REFERÊNCIA BIBLIOGRÁFICA ............................................................. 60
8. SITES PESQUISADOS: ........................................................................... 61
RESUMO
Proteger dados sensíveis com criptografia tem sido parte chave das aplicações
web, este trabalho trata de uma pesquisa sobre proteção e recomendações
para o problema do armazenamento criptográfico inseguro (Projeto AECript),
abordando assuntos como armazenamento de dados sensíveis, ambientes
afetados, vulnerabilidades em códigos de aplicações web, sistemas de
aplicações inseguros, mostrando onde esta o problema da proteção de
armazenamentos de informações vulneráveis ao ataque e roubos de dados,
trazendo prejuízo financeiro a maioria das grandes empresas, e assegurar
como a solução para esses problemas, deverão ser feitas através de
algoritmos criptográfico.
ABSTRACT
Protect sensitive data with encryption key has been part of web applications,
this work deals with a research on protection and recommendations for the
problem of insecure cryptographic storage (Project AECript), addressing issues
such as storage of sensitive data, affected environments, vulnerabilities in the
code web applications, systems, applications unsafe, showing where the
problem is the protection of information stores vulnerable to attack and theft of
data, causing financial loss to most large companies, and provide as a solution
to these problems, should be made through cryptographic algorithms.
8
1. INTRODUÇÃO
A utilização da criptografia está crescendo cada vez mais devido à
grande explosão da Internet no Brasil e no mundo. Com a possibilidade de
comunicação segura surgiram muitas aplicações que facilitaram a utilização da
internet para transações como, por exemplo, o comércio eletrônico, bancos
eletrônicos e outros métodos que exigem a transmissão de informações
confidenciais através da rede. Em compensação, a maioria destas aplicações
possui algoritmos de criptografia mal concebidos, por isso podemos considerar
que a transmissão desses dados não é segura.
As falhas de segurança mais comuns são: não criptografia de dados
sensíveis; uso continuado de algoritmos comprovadamente fracos (MD5, SHA-
1, RC3, RC4, etc…); codificação difícil de chaves e armazenamento de chaves
em repositórios desprotegidos.
Técnicas de criptografia são usadas como um meio efetivo de proteção
de informações suscetíveis a ataques, estejam elas armazenadas em um
computador ou sendo transmitidas pela rede. Seu principal objetivo é prover
uma comunicação segura, garantindo serviços básicos de autenticação,
privacidade e integridade de dados.
1.1. MOTIVAÇÃO
A proteção de dados sensíveis através de criptografia tem se tornado
uma parte essencial da maioria das aplicações web. As aplicações web
raramente utilizam de modo adequado, funções de criptografia para proteger os
dados e credenciais de usuários. Aplicações que utilizam criptografia
9
geralmente possuem criptografia mal projetada, com cifras inadequadas ou
produzem erros graves ao usar cifras fortes. Estas falhas podem levar a
revelação de dados sensíveis e a violações de conformidade. Os atacantes
utilizam dados fracamente protegidos para furtar identidades e realizar outros
crimes, tais como fraude de cartão de crédito. (SILVA, 2007).
1.2. OBJETIVOS
Esta monografia faz parte do Projeto OWASP TOP TEM 2007 – A8
ARMAZENAMENTO CRIPTOGRAFICO INSEGURO que tem a finalidade de
ensino, aprendizagem e conscientização de problemas, soluções e segurança
da informação, pretende também colaborar como uma referência sobre
pesquisas na defesa, proteção, recomendações e principais falhas
relacionadas ao armazenamento criptográfico inseguro, informando como os
problemas funcionam, o que se pode fazer para solucionar os problemas de
segurança e práticas necessárias para evitar todos os tipos de ataque.
1.3. ORGANIZAÇÃO DO TRABALHO
Foram executadas consultas em sites na internet para obtenção de material
onde foi possível selecionar o que se fazia necessário para o entendimento do
tema abordado. A partir da coleta do material, elaborou-se uma criteriosa
seleção para a elaboração do texto desejado com a melhor forma, mais
eficiente para o desenvolvimento da pesquisa necessária para o projeto.
Este trabalho está organizado em 8 capítulos. O capítulo 2 traz uma pesquisa
dos conceitos de ambientes afetados em sistemas. O capitulo 3 aborda os
principais tipos de vulnerabilidades , tratando com maiores detalhes em dados
10
sensíveis apresentado algumas fragilidades em algoritmos de sistemas . são
apresentados no capítulo 4 verificações de segurança em aplicações web,
informações sensíveis em sistemas de armazenamentos . No capítulo 5 são
apresentados as informações necessárias para tratar da proteção de dados,
mecanismos de segurança, níveis de segurança de proteção. Por fim, os
capítulos 6, 7, 8 conclui esta monografia apontando as contribuições e
possíveis melhoramentos neste trabalho.
Palavras-chave: Criptografia, Armazenamento criptográfico, Segurança da
informação.
11
2. Ferramentas seguras em Aplicações web
2.1. Frameworks
Em desenvolvimento de software, framework é uma estrutura de suporte
definida onde outro projeto de software pode ser organizado e desenvolvido.
Um framework pode incluir programas de suporte, bibliotecas de código,
linguagens de script e outros softwares para auxiliar no desenvolvimento e unir
diferentes componentes de um projeto de software. (WIKIPÉDIA, 2009)
Em outras palavras, frameworks são soluções reutilizáveis de software,
que possuem um conjunto de classes com várias funções, rotinas e variáveis
inclusas. Mas para que funcionem é necessário ser implementadas com
lógicas que dependem da necessidade. Foram projetadas com a intenção de
facilitar o desenvolvimento de software, habilitando designers e programadores
a utilizarem o seu tempo de forma mais proveitosa, não sendo necessário
reinventar códigos. São um pouco mais complexos que as bibliotecas, mas
quando são utilizadas, executam uma ou mais funções específicas.
Um framework captura a funcionalidade comum entre várias aplicações,
que devem ter um grande ponto em comum: pertencer ao mesmo domínio de
problema.
As Vantagens na Utilização de Frameworks (Zemel, 2009):
• Em primeiro lugar cita-se a utilidade, cujo objetivo inicial dos
frameworks é auxiliar no desenvolvimento de aplicações e softwares.
Têm funcionalidades nativas das mais variadas, que auxiliam na
12
resolução de questões sobre programação, com muito mais qualidade
e eficiência.
• Quanto à Segurança, os bons frameworks são projetados de modo a
garantir a segurança dos desenvolvedores e, principalmente, de quem
utiliza o que foi feito a partir dele. Não havendo necessidade de
preocupação com aquelas intermináveis linhas de código que evitam
um SQL Injection, por exemplo. Com frameworks, a parte de
segurança já “vem de fábrica”.
• Além disso, os frameworks possuem estensibilidade permitindo a
extensão de suas funcionalidades nativas. Se uma determinada
biblioteca de envio de e-mails por SMTP não contempla todas as
possibilidades desejadas, simplesmente deve-se estender suas
funcionalidades e utiliza-las como se fossem partes do framework (na
verdade, elas serão).
• Outro fator importante é a economia de tempo. O que demoraria
algumas horas ou alguns dias para se desenvolver, encontra-se pronto
em um framework.
• Suporte ao desenvolvimento. Os desenvolvedores de framworks
geralmente disponibilizam material de qualidade nos web sites ou
repositórios oficiais, com uma vasta documentação a respeito. Além
disso, os bons frameworks sempre têm uma comunidade de
desenvolvedores dispostos a se ajudarem entre si.
2.2. Dados Inseguros
Um dos maiores problemas de segurança é não validar os inputs
(formulário de entrada) do usuário. O próprio (XSS - Cross-site scripting) é
13
aquele que permite a injeção de scripts no site atacado, em geral por meio de
algum campo de input do usuário. É importante observar que um ataque XSS é
um ataque ao usuário do site e não ao sistema servidor em si. Pois, o script
injetado nunca será executado no servidor, mas nos navegadores dos clientes
que visitarem a página infectada. A regra principal de qualquer sistema com
input de usuários é que não se deve confiar no que foi digitado pelo usuário.
Além de XSS, se a segurança não for bem definida podemos ser alvos
de muitos outros ataques, como SQL Injection, injeção de parâmetros e outros.
Um exemplo do problema é a injeção de parâmetros perigosos, que
acontece frequentemente devido a Web e aos frameworks modernos.
Um exemplo de Injeção de atributos é usarmos qualquer framework Java
para Web (VRaptor, Struts, Mentawai, Waffle). Muitos programadores estão
acostumados com a facilidade de não se preocupar com o
(request.getParameter), escrevem um JavaBean e o framework compila
automaticamente os dados, seguindo os nomes do parâmetro.
Imaginemos um sistema onde as pessoas se cadastram em algum
serviço online.
Se escrevermos uma classe Usuario:
public class Usuario { private String email; private String senha; }
E, no formulário de cadastro enviar os parâmetros usuario.email e
usuario.senha.
14
/usuario/[email protected]&usuario.senha=1234
Imaginemos também, que gostaríamos de ter uma área administrativa, e
certos usuários com permissão para acessá-la:
public class Usuario { private String email; private String senha; private boolean admin; }
No formulário de cadastro geral, a pessoa só cadastraria email e senha,
e no cadastro dentro da área de admin, teríamos um checkbox a mais.
/admin/usuario/[email protected]&usuario.senha=1234&usuario.admin=true
Isso seria extremamente inseguro. E se no cadastro dos usuários
normais um usuário mal intencionado passasse &usuario.admin=true?
Não poderíamos achar, só porque o form do html não tem o campo. O
problema não existiria se ainda programássemos com
request.getParameter(), já que na lógica dos usuários normais
obviamente só pegaríamos os parâmetros usuario e email. Isso aparece
quando usamos as facilidades dos frameworks que usam qualquer parâmetro
no JavaBean.
Revendo todos os seus códigos atrás desse tipo de falha e perceber o
quão grave ele é. A solução mais adequada seria não ter nenhum atributo no
JavaBean que não possa ser inserido pelo usuário.
15
3. VULNERABILIDADE
3.1. Introdução
De acordo com estudos OWASP (Open Web Application Security
Project), as vulnerabilidades que existem em mais abundância na web são as
falhas XSS (Cross Site Scripting) e XRSF (Cross Site Request Forgery), este
tipo de falha consiste em injetar código (normalmente JavaScript ou VBscript)
no browser do utilizador, alterando o código da página, podendo assim levar ao
roubo de informações.
Erros em validações de parâmetros é a principal causa deste tipo de
falha. Injeção de SQL é uma das vulnerabilidades mais conhecidas, pela
Internet e pequenos erros de validação podem se revelar perigosos e
extremamente prejudiciais ao usuário de uma aplicação web.
Enquanto as empresas desvalorizam a proteção aos seus sites,
aplicações e dados os ataques dos hackers ficam cada vez mais elaborados e
sofisticados. Na maioria das vezes, geram perda de dados ou outras violações
de segurança. A maioria das operações que exigem segurança na WEB é
projetada e desenvolvida de forma insegura e negligente. Essa negligencia
parte tanto de usuários quanto de grandes companhias, sendo importante e
necessário levar ao conhecimento dos “stakeholders” os riscos desta prática.
3.2. Dados Sensíveis
Segundo especialistas de segurança da informação que tratam das mais
diversas formas de armazenamentos de dados, a maioria das empresas não
usa os sistemas de criptografia de forma correta, dados sensíveis ficam
16
esquecidos em servidores com pouco ou sem nenhum tipo eficiente de
proteção.
A falta de utilização de sistemas criptográficos seguros nas empresas
deve-se em parte ao desinteresse das empresas, a falta de investimento ou
desconhecimento, e hoje em dia com o aumento no volume de dados
sensíveis, torna-se obrigatório o uso de criptografia segura nas empresas de
grande porte, como forma de proteger-se de espionagem industrial por parte de
seus concorrentes ou de ataques de hackers.
Os dados sensíveis requerem mais atenção também por parte de
usuários, pois ao gravar informações confidenciais em seu computador ou
notebook, sem se preocupar com o risco de eles caírem em mãos erradas,
caso o equipamento seja roubado ou invadido por hackers, certamente irá
expor todos seus dados importantes, uma possível solução seria a criptografia
de disco. Ao ativar a criptografia em uma partição, os dados que serão
gravados nela, a partir de então serão criptografados automaticamente, e o
eventual ladrão ou invasor terá uma tarefa nada fácil se quiser recuperá-los,
sem dispor do código criptográfico.
Na corrida para impulsionar mais serviços on-line, as aplicações web
freqüentemente sofrem com a falta de segurança incorporada. As
vulnerabilidades resultantes representam um caminho fácil para que hackers
acessem ou roubem dados e informações corporativas ou pessoais. Segundo
Lahr, um estudo realizado recentemente pela IBM ISS mostra que a
porcentagem de vulnerabilidades de risco alto continua crescendo, e 40% das
vulnerabilidades descobertas hoje são consideradas de risco crítico ou alto.
17
Apesar da maioria dos exploits para aplicações web serem gerados a
partir de ferramentas hospedadas em sites maliciosos, há uma grande
preocupação com o aumento de vulnerabilidades e explorações em aplicações
web. A quantidade de ataques utilizando métodos automatizados de
exploração de falhas, SQL Injection vem se destacando durante o ano,
mostrando que as aplicações web estão extremamente vulneráveis. (LAHR,
2007)
O número de vulnerabilidades afetando aplicações web vem crescendo
a cada ano em uma velocidade incrível. Se pegarmos de 2006 até a metade de
2008, vulnerabilidades afetando aplicações web somaram 51% de todas as
vulnerabilidades descobertas.
Os tipos predominantes de vulnerabilidades são Cross-Site-Scripting
(XSS), SQL Injection e File Include. Nos anos anteriores, as vulnerabilidades
baseadas em Cross-Site-Scripting eram as mais encontradas em aplicações
web, porém a primeira metade desse ano foi marcada pelo grande
aumento em descobertas de SQL Injection, mais que dobrando o número de
vulnerabilidades vistas no mesmo período de 2007. (LAHR, 2007)
3.3. Algoritmos fortes
Algoritmos fortes e poderosos são desenvolvidos para serem
executados por computadores ou dispositivos especiais de hardware. Na maior
parte das aplicações a criptografia é feita por software, e vários pacotes
criptográficos estão disponíveis.
18
Ter uma criptografia forte para proteger a troca de chaves de segurança
é tão importante quanto adotar um algoritmo forte para criptografar a voz.
Um exemplo de algoritmo forte para criptografar voz é o algoritmo A5,
utilizado para a autenticação e criptografia da comunicação móvel, através da
rede GSM (Global System for Mobile Communications). O protocolo utilizado
na comunicação da rede GSM utiliza, além do algoritmo A5, os algoritmos A3 e
A8. O algoritmo A3 realiza a autenticação junto a CA (Autoridade Certificadora)
pelo método de pergunta-resposta, utilizando o valor RAND (128 bits) gerado
pela CA na mensagem SRES (sinal de resposta, com 32 bits) e devolvida pelo
cliente juntamente com o valor Ki (128 bits), chave armazenado no seu SIM
card. O conteúdo as SRES, retornado pelo cliente, é comparado pelos valores
armazenados na CA, que aceita ou rejeita a autenticação. Uma vez autenticado
com sucesso, o algoritmo A8 calcula a chave de criptografia simétrica Kc (64
bits), utilizando o RAND e Ki que será utilizada para a criptografia das
mensagens trocadas.
O algoritmo A5 fica responsável por realizar o embaralhamento de bits
de dados codificados enviados a cada terminal fazendo assim a segurança da
comunicação. Existem algumas versões do algoritmo A5, como (A5/1, A5/2)
que são correlatas, porém a versão 1 provem uma encriptação mais elaborada,
logo realiza uma segurança mais forte. Possíveis vantagens:
• Os rumores que o A5 tem uma chave “efetiva” de 40 bits.
• Duas streams de 114 bits são usadas de chaves para cada frame
TDMA, e é efetuado um XOR dos dados de uplink e downlink com as
chaves.
19
• A5 é um cifrador de stream que possui três LFSR controlados por clock
com 19, 22 e 23 níveis.
• O controlador de clock tem uma função de transbordo no meio dos bits
de cada um dos três shift-registers.
Apesar do A5 ser considerado um algoritmo forte para comunicação rede GSM,
já sofreu alguns ataques. Nesses ataques destacam-se Shamir, Biryukov,
Goldberg e Wagner que conseguiram de alguma forma comprometer a
segurança deste algoritmo.
Chamamos a atenção para o fato de que não adianta aplicarmos um algoritmo
forte no processo de criptografia de voz se previamente, no processo de troca
das chaves, utilizou-se um algoritmo sem a segurança adequada para proteger
essa troca.
Podemos fazer uma analogia dos processos de segurança utilizados com um
cofre e seu segredo. Não adianta possuirmos um cofre extremante seguro
(“encriptação da voz”) se o seu segredo (“troca de chaves”) não está bem
protegido e pode ser acessado por terceiros.
3.4. Algoritmos Fracos
O MD5 (Message-Digest algorithm 5) é um algoritmo de hash de 128
bits unidirecional desenvolvido pela RSA Data Security, Inc., descrito na RFC
1321, e muito utilizado por softwares com protocolo ponto-a-ponto (P2P, ou
Peer-to-Peer, em inglês), verificação de integridade e logins.
Foi desenvolvido em 1991 por Ronald Rivest para suceder ao MD4 que
possuía alguns problemas de segurança. Por ser um algoritmo unidirecional,
20
uma hash md5 não pode ser transformada novamente no texto que lhe deu
origem. O método de verificação é, então, feito pela comparação das duas
hash (uma da base de dados, e a outra da tentativa de login). O MD5 também
é usado para verificar a integridade de um arquivo através, por exemplo, do
programa md5sum, que cria a hash de um arquivo. Isto se pode tornar muito
útil para downloads de arquivos grandes, para programas P2P que constroem
o arquivo através de pedaços e estão sujeitos à corrupção dos mesmos. Como
autenticação de login é utilizada em vários sistemas operacionais unix e em
muitos sites que requerem autenticação.
O SHA (stands for Secure Hash Algorithm) é constituído por cinco
funções hash, concebido pelo National Security Agency (NSA) e publicado pelo
Instituto Nacional de Padrões e Tecnologia (NIST). Os cinco são algoritmos
SHA-1, SHA-224, SHA-256, SHA-384, e SHA-512. SHA-1 é o mais comumente
utilizado da SHA série.
Algoritmos Hash são chamados seguros quando ele for impossível
encontrar uma mensagem que corresponde a uma determinada mensagem
digerir, e quando for impossível encontrar duas mensagens diferentes que
produzem a mesma mensagem digerir, caso se uma mensagem for mudada
até mesmo por um único personagem, o resultado será uma mensagem
completamente diferente digerir.
SHA-1 tem estas propriedades e, portanto, é referido como segura. É
projetado para trabalhar com a Assinatura Digital Algorithm (DSA). SHA-1 é um
21
one-way hash função. One-way funções são caracterizados por duas
propriedades. A primeira é que eles são uma via de sentido. Isto significa que
você pode ter uma mensagem e calcular um valor hash, mas você não pode ter
um valor hash e recriar a mensagem original. É também livre de colisão e,
portanto, não duas mensagens podem hash para o mesmo valor.
Em criptografia, RC4 (ou ARC4) é o algoritmo de criptografia de fluxo
mais usado no software e utilizado nos protocolos mais conhecidos, como
Secure Socket Layers (SSL) (para proteger o tráfego Internet) e WEP (para a
segurança de redes sem fios). RC4 não é considerado um dos melhores
sistemas criptográficos pelos adeptos da criptografia e em algumas aplicações
pode converter-se em sistemas muito inseguros. No entanto, alguns sistemas
baseados em RC4 são seguros o bastante num contexto prático.
Em 1987 Ron Rivest desenvolveu o algoritmo RC4 para a empresa RSA
Data Security, Inc., líder mundial em algoritmos de criptografia. Foi, durante
tempos, um segredo comercial muito bem guardado, muito popular, e utilizado
largamente em software, como Lotus Notes, Apple Computer’s AOCE, Oracle
Secure SQL, Internet Explorer, Netscape e Adobe Acrobat.
Sete anos depois, surge num mailing list dedicado à criptografia –
Cypherpunks - código alegadamente equivalente ao RC4. Utilizadores com
cópias legais puderam confirmar a compatibilidade. É importante ressaltar, no
entanto, que esta não é a implementação comercial, e, como tal, é
habitualmente referida como ARC4 (Alleged RC4).
22
As transformações neste algoritmo são lineares, por isso não são
necessários cálculos complexos, já que o sistema funciona basicamente por
permutações e somas de valores inteiros, o que torna este algoritmo muito
simples e rápido. Um raro exemplo de Barato, Rápido e Bom.
De uma forma geral, o algoritmo consiste em utilizar um array que a
cada utilização tem os seus valores permutados, e misturados com a chave, o
que provoca que seja muito dependente desta. Esta chave, utilizada na
inicialização do array, pode ter até 256 bytes (2048 bits), embora o algoritmo
seja mais eficiente quando é menor, pois a perturbação aleatória induzida no
array é superior.
3.5. Codificação de chaves
De acordo com a história antiga, enviar uma mensagem de forma segura
foi sempre uma preocupação que persistiu aos primeiros estrategistas em
segurança da informação que se têm notícia.
Houve época em que soldados tinham mensagens escritas em seu
couro cabeludo como estratégia para passar uma informação pelas linhas
inimigas, bastando chegar ao seu destino e ter sua cabeça raspada. (livro dos
códigos).
Na Segunda Guerra Mundial, a Alemanha tinha um sistema de
informações criptografadas. A base de todo esse sistema era uma máquina
eletro-mecânica conhecida como enigma, semelhante à apresentada na figura,
capaz de gerar mensagens criptografadas com enorme facilidade.
23
A garantia de dados secretos é à base da criptografia essencial para o
tráfego de informações seguras, especialmente nos dias atuais.
Neste mundo capitalista e corrido de hoje em dia, onde profissionais são
pressionados a agir com velocidade, onde meios de pagamento eletrônico são
uma solução muito conveniente.
As pessoas pagam suas contas e compras eletronicamente pela
internet, usando cartões de débito ou crédito, transferências de valores ou
sistemas eletrônicos instantâneos como PayPal. Emitir um cheque é
considerado antiquado e arcaico por muitos, além de consumir muito tempo e
representar custo.
Pagamentos eletronicos ia internet, seguem regulamentações bancárias
e governamentais restritas visando a segurança do sistema. Fraudes são
prevenidos através do uso conjunto de tecnologia avançada e processos de
desições bem estabelecidas. Processamento de cheques eletrônicos usa
várias ferramentas tecnológicas, chaves criptograficas, codificação de dados,
assinaturas digitais, certificados, email seguro, e tecnologia de cartão
inteligente para assegurar que a segurança do sistema seja garantida.
A codificação de chave pública é somente bem segura quanto a chave é
privada de cada indivíduo. Se alguém que não seja o proprietário da chave
privada tiver uma cópia dela e souber a senha, a codificação é quebrada
ficando vulneravel os seus dados e informações. Fichas de codificação são
usadas em conjunto com a codificação da chave pública para solucionar esta
abertura na segurança. Estas fichas fornecem uma maneira segura de gerar e
24
armazenar pares de chaves públicas e privadas, e de efetuar a assinatura.
Desta forma, chaves privadas nunca estão expostas a ataques por hackers,
vírus, ou até mesmo usuários que não levam a sério situações de segurança.
Um dos algoritmos mais seguros de encriptação de informações atuais
originou-se dos estudos de Ronald Rivest, Adi Shamir e Leonard Adleman, um
trio de Matemáticos brilhantes que mudaram a história da Criptografia.
O princípio do algoritmo é construir chaves públicas e privadas utilizando
números primos. Uma chave é uma informação restrita que controla toda a
operação dos algoritmos de criptografia. No processo de codificação uma
chave é quem dita a transformação do texto puro (original) em um texto
criptografado.
Chave Privada: É uma informação pessoal que permanece em posse da
pessoa - não publicável.
Chave Pública: Informação associada a uma pessoa que é distribuída a todos.
Uma analogia amplamente conhecida no meio acadêmico é a
transmissão de mensagens entre Alice e Bob.
Alice e Bob são personagens fictícios que precisam trocar mensagens
seguras sem interceptação. O algoritmo RSA permite essa troca segura de
mensagens pela utilização de chaves públicas e privadas:
1. Alice cria seu par de chaves (uma pública e outra privada) e envia
sua chave pública para todos, inclusive Bob;
25
2. Bob escreve sua mensagem para Alice. Após escrita, Bob faz a
cifragem do texto final com a chave pública de Alice, gerando um
texto criptografado;
3. Alice recebe o texto criptografado de Bob e faz a decifragem
utilizando a sua chave privada.
O procedimento é realizado com sucesso porque somente a chave
privada de Alice é capaz de decifrar um texto criptografado com a sua chave
pública.
É importante destacar que se aplicarmos a chave pública de Alice sobre
o texto criptografado não teremos a mensagem original de Bob. Dessa forma,
mesmo que a mensagem seja interceptada é impossível decifrá-la sem a chave
privada de Alice.
26
4. VERIFICAÇÃO DE SEGURANÇA
4.1. Introdução
Grande parte do desenvolvimento de aplicações web gira em torno da
rede mundial de computadores, a World Wide Web (Internet), conectando-se
via hyperlinks para englobar ambientes de aplicativos complexos e locais de
armazenamento virtuais, com a grande utilização dessas aplicações surgiram
problemas de segurança associados a ela.
Os navegadores e servidores tornaram-se mais capazes e poderosos,
porém, fornecendo muitos "buracos" para invasão dos hackers. Com o uso da
internet para transações financeiras de grande porte, e a transação com dados
sensíveis como o uso de números de cartões de crédito, pagamentos de
contas, acompanhamento de informações privadas e outras informações de
identificação que trafegam através da Web atualmente, os crackers e script
kiddies têm um grande incentivo para descobrir esses "buracos".
Na maioria dos casos, é simplesmente impossível para os usuários
gerenciar a própria segurança; os problemas são muitos complexos, o
ambiente é muito flexível e a maioria dos navegadores não permite que os
usuários tenham acesso fácil a informações de segurança importantes. Grande
parte da responsabilidade pela segurança deve, conseqüentemente, recair
sobre o desenvolvedor de aplicativos Web, que precisam codificar de forma
defensiva e segura para tentar impedir problemas relacionados à segurança.
O aumento na utilização de vários recursos dos navegadores modernos
levou a um problema novo e diferente na segurança da Web. A expressão
"Cross Script Site" está se tornando conhecida. Ele engloba um número maior
27
de ataques além de scripts; trata-se de uma técnica usada para muitos tipos de
ataques que tentam explorar a confiança entre um usuário e um site.
O problema surge quando um site outrora confiável incorpora em si
próprio, dados dinâmicos fornecidos pelos seus usuários sem verificar
completamente essas entradas. Usuários mal-intencionados podem explorar
esse problema fornecendo dados ao site que acabam apresentando efeitos
colaterais inesperados quando esses mesmos dados forem exibidos. Esses
efeitos normalmente envolvem o envio de dados ao cracker por meio de outro
site menos seguro, embora eles possam, em casos raros, usar o site em si
para transmitir as informações.
Isto é, através de um código em HTML ou XML, o atacante pode usar
tags maliciosos que podem trazer um sério comprometimento do sistema. Um
atacante pode fazer uma vítima enviar os seus dados para o programa. Então o
programa tem que estar apto a proteger a vítima dele.
Além disso, o cracker pode inserir referências em Java (inclusive
referências para applets maliciosos), tags DHTML, término do arquivo por
</HTML>, pedidos de tamanho de fontes absurdos e assim por diante.
Estas brechas podem ter uma vasta gama de efeitos, como expor
conexões SSL-codificadas, tendo acesso locais da rede restringidos pelo
cliente, violando políticas de segurança de domínio, fazendo a rede ficar fora
do ar, inserir um worm, criando DOS (Denial Of Service), enviando
simplesmente um código JavaScript para um loop infinito de aberturas de
janelas do browser, e até mesmo ataques muito destrutivos, inserindo ataques
28
em vulnerabilidade de segurança em linguagens de script ou buffers overflows
em browsers.
Usando tags maliciosas no lugar certo, um cracker pode até mesmo
enganar os usuários em revelar informação sensível, modificando o
comportamento de uma forma existente.
Existem providencias que podem ser tomadas para ajudá-lo a prevenir
esses tipos de ataques:
a) Sempre faça as entradas provenientes de fontes externas passarem
por um processo de validação. Isso inclui documentos extraídos de outros
sites, como sumários de notícias RSS/RDF, qualquer entrada de formulários
(mesmo proveniente de campos de formulários ocultos - é trivial POSTAR
valores arbitrários em qualquer URL), cookies ou uploads de arquivos.
b) Defina estritamente tipos de dados permitidos. Rejeitando tudo,
exceto entradas válidas (em vez de rejeitar apenas entrada inválida conhecida),
você impedirá que os crackers venham com maneiras mais difíceis de evitar o
seu validador.
c) Sempre valide a entrada após decodificá-la, e não antes. Isso impede
que o cracker lhe passe variantes de código de exploração codificados na URL.
d) Sempre especifique o charset para todas as páginas dinâmicas e,
preferencialmente, para qualquer página. Os navegadores usam conjuntos de
caracteres (charsets) padrão diferentes dependendo de diversos fatores.
Foram criadas explorações que se aproveitaram da ambigüidade do charset
29
para enviar texto aparentemente inútil em seu site que, quando exibido em um
determinado charset, produzia um efeito de ativação entre sites.
4.2. Verificação de segurança em aplicações Web
Com base na necessidade pró-ativa de segurança, neste projeto serão
tratadas técnicas adotadas para verificar a segurança de sistemas tanto do
ponto de vista das aplicações quanto das redes de computadores.
Os problemas na segurança das aplicações web são tais como:
• Problemas no Desenvolvimento de Software
• Problemas na Arquitetura de Redes
• Problemas na Configuração de Sistemas
• Problemas na Fragilidade Humana
Principais causas:
• Formação inadequada
• Falta de treinamento
• Desconhecimento do que está fazendo
Uma das melhores formas de colocar a segurança de uma aplicação
web a prova, é colocá-la sob testes.
Teste de Caixa Preta
• Identificar formas de acesso à aplicação
• Driblar lógicas de negócio e controles de acesso
30
Teste de Caixa Branca
• Revisão do código
• Identificar os trechos de código vulneráveis e possíveis
configurações inseguras
• Rastrear todas as entradas possíveis e comunicações internas
A verificação de problemas na arquitetura de redes e configurações de
sistemas tem como propósito:
1. Teste de penetração externa de rede
• Identificar componentes ocultos na rede
• Identificar formas de acesso ao ambiente
• Explorar fragilidades na segmentação incorreta de rede e na
configuração de sistemas
• Explorar vulnerabilidades dos sistemas e aplicações de forma
remota
2. Teste de penetração interna de rede
• Identificar formas de driblar a segmentação de rede e controles
de acesso de sistemas internos
• Explorar redes sem fio e sistemas internos (BARBATO, 2008)
As aplicações Web seguras são possíveis apenas quando um SDLC
“Produtos para o Ciclo de Desenvolvimento de Software” seguro é utilizado. Os
programas seguros são seguros, por concepção durante seu desenvolvimento
31
e por padrão. Existem no mínimo 300 problemas que afetam a segurança das
aplicações Web como um todo. [OWASP]
Abaixo o top 10, das falhas de segurança em uma aplicação Web
segundo a OWASP “Open Web Application Security Project”:
1. Cross Site Scripting (XSS): Os furos XSS ocorrem sempre que uma
aplicação obtém informações fornecidas pelo usuário e as envia de
volta ao navegador sem realizar validação ou codificação daquele
conteúdo. O XSS permite aos atacantes executarem scripts no
navegador da vítima, o qual pode roubar sessões de usuário, pichar
sites Web, introduzir worms, etc.
2. Falhas de injeção: As falhas de injeção, em especial SQL Injection,
são comuns em aplicações Web. A injeção ocorre quando os dados
fornecidos pelo usuário são enviados a um interpretador com parte
do comando ou consulta. A informação maliciosa fornecida pelo
atacante engana o interpretador que irá executar comandos mal
intencionados ou manipular informações.
3. Execução maliciosa de arquivos: Os códigos vulneráveis à inclusão
remota de arquivos (RFI) permitem ao atacante incluir código e
dados maliciosos, resultando em ataques devastadores, como o
comprometimento total do servidor. Os ataques de execução de
arquivos maliciosos afetam PHP, XML e todos os frameworks que
aceitem nomes de arquivo ou arquivos dos usuários.
4. Referencia insegura Direta a Objetos: Uma referência direta à objeto
ocorre quando um desenvolvedor expõe a referência a um objeto
32
implementado internamente, como é o caso de arquivos, diretórios,
registros da base de dados ou chaves, na forma de uma URL ou
parâmetro de formulário. Os atacantes podem manipular estas
referências para acessar outros objetos sem autorização.
5. Cross Site Request Forgery (CSRF): Um ataque CSRF força o
navegador da vítima, que esteja autenticado em uma aplicação, a
enviar uma requisição pré-autenticada à um servidor Web vulnerável,
que por sua vez força o navegador da vítima a executar uma ação
maliciosa em prol do atacante. O CSRF pode ser tão poderoso
quanto a aplicação Web que ele ataca.
6. Vazamento de informações e Tratamento de Erros Inapropriado: As
aplicações podem divulgar informações sobre suas configurações,
processos internos ou violar a privacidade por meio de uma série de
problemas na aplicação, sem haver qualquer intenção. Os atacantes
podem usar esta fragilidade para roubar informações consideradas
sensíveis ou conduzir ataques mais estruturados.
7. Autenticação falha e Gerenciamento de Sessão: As credenciais de
acesso e token de sessão não são protegidas apropriadamente com
bastante freqüência. Atacantes comprometem senhas, chaves ou
tokens de autenticação de forma a assumir a identidade de outros
usuários.
8. Armazenamento Criptográfico inseguro: As aplicações Web
raramente utilizam funções criptográficas de forma adequada para
proteção de informações e credenciais. Os atacantes se aproveitam
33
de informações mal protegidas para realizar roubo de identidade e
outros crimes, como fraudes de cartões de crédito.
9. Comunicações inseguras: As aplicações freqüentemente falham em
criptografar tráfego de rede quando se faz necessário proteger
comunicações críticas/confidenciais.
10. Falha de restrição de Acesso à URL: Frequentemente, uma
aplicação protege suas funcionalidades críticas somente pela
supressão de informações como links ou URLs para usuários não
autorizados. Os atacantes podem fazer uso desta fragilidade para
acessar e realizar operações não autorizadas por meio do acesso
direto às URLs.
4.3. Dados sensíveis em sistemas de armazenamento
Aplicações que precisam proteger comunicações sensíveis geralmente
falham na hora de encriptar este tráfego pela rede.
A encriptação (geralmente SSL) especialmente para páginas web com
acesso a internet e conexões com back-end deve ser usada em todas as
conexões autenticadas, senão, o aplicativo irá expor uma autenticação ou o
token de sessão.
A autenticação deve ser utilizada sempre que dados sensíveis, assim
como cartões de crédito, são transmitidos. Aplicações cujo modo de
encriptação possa ser subvertido são alvos de ataques.
Os padrões PCI requerem que todas as informações de cartões de
credito que são transmitidas pela internet sejam encriptadas.
34
Falha na hora de encriptar informações sensíveis significa que se um
invasor puder “escutar” o tráfego da rede poderá ter acesso à conversa,
incluindo quaisquer credenciais ou informações sensíveis transmitidas.
Considerando que redes diferentes terão mais, ou menos, suscetibilidade a
escuta. Entretanto, é importante notar que eventualmente um servidor será
comprometido em praticamente qualquer rede, e que invasores instalarão
rapidamente uma escuta para capturar as credenciais de outros sistemas.
O uso de SSL para comunicações com usuários finais é critico, pois é
muito provável que eles utilizem formas inseguras de acessar os aplicativos.
Porque o protocolo HTTP inclui credenciais de autenticação ou um token de
sessão para cada pedido, toda autenticação do tráfego deve ir para o SSL, não
só os pedidos de login.
O uso de encriptação de informações com servidores de back-end
também é muito importante. Mesmo que estes servidores sejam naturalmente
mais seguros, as informações e as credenciais que eles carregam são mais
sensíveis e mais impactantes. A encriptação de informação sensível, assim
como de cartões de crédito se tornou um regulamento financeiro e de
privacidade para várias empresas. Negligenciar o uso de SSL para o manuseio
de conexões de informações cria um risco de não conformidade. [OWASP,
2007]
O objetivo é verificar se as aplicações encriptam corretamente toda a
comunicação autenticada e sensível.
35
Abordagens automatizadas: ferramentas de localização de
vulnerabilidade podem verificar se o SSL é utilizado na interface do sistema e
pode localizar muitas falhas relacionadas à SSL. Entretanto, elas não têm
acesso às conexões no back-end e não podem verificar se elas são seguras.
As ferramentas de análise estática podem ajudar com análises de algumas
ligações no back-end, mas provavelmente não entenderão a lógica
customizada requerida para todos os tipos de sistemas. [OWASP, 2007]
Abordagens manuais: testes podem verificar se o SSL é utilizado e
localizar muitas falhas relacionadas à SSL na interface, mas as abordagens
automatizadas são provavelmente mais eficientes. A revisão de código é muito
eficiente para verificar o uso de SSL em conexões no back-end. [OWASP,
2007]
A parte mais importante da proteção em uma aplicação web é usar o
SSL em todas as conexões autenticadas ou em qualquer informação sensível
em transmissão. Existem inúmeros detalhes envolvendo a configuração do
SSL, então é importante entender e analisar seu ambiente. Por exemplo, o IE7
(internet Explorer 7) provê uma barra verde para certificados SSL altamente
confiáveis, mas isto não é um controle apropriado que demonstre por si só o
uso seguro da criptografia. [OWASP, 2007]
Cuidados que devem ser observados para a proteção de dados
sensíveis em sistemas de armazenamento:
36
• Utilizar SSL para todas as conexões que são autenticadas ou que
transmitam informações sensíveis e/ou de valor, assim como
credenciais, cartões de crédito, e outros.
• Assegure que as comunicações entre os elementos da infra-
estrutura, como servidores de web e sistemas de banco de dados,
estão propriamente protegidas pelo uso de camadas de
transporte de segurança ou de encriptação de nível de protocolo
para credenciais e informações de valor intrínseco.
• Dentro dos requisitos de segurança PCI 4, deve-se proteger as
informações dos proprietários de cartões de crédito em
transmissão. A conformidade com as normas PCI DSS é
mandatória até 2008 para todos os comerciantes e qualquer um
que lide com cartões de crédito. Em geral, clientes, parceiros,
funcionários e acesso administrativo online aos sistemas devem
ser encriptados via SSL ou similar. [OWASP, 2007].
Geralmente, a única proteção para uma URL é não mostrar o link para
usuários não autorizados. No entanto, um usuário motivado, hábil ou apenas
um audacioso atacante pode ser capaz de achar e acessar estas páginas,
executar funções e visualizar dados. Segurança por obscuridade não é
suficiente para proteger os dados e funções sensíveis em uma aplicação.
Verificações de controles de acesso devem ser executadas antes de permitir
uma solicitação uma função sensível, na qual garante que somente o usuário
autorizado acesse a respectiva função. [OWASP, 2007].
37
O principal método de ataque para esta vulnerabilidade é chamado de
“navegação forçada” (“forced browsing”), na qual envolve técnicas de
adivinhação de links (“guessing”) e força bruta (“brute force”) para achar
páginas desprotegidas. É comum que aplicações utilizem códigos de controle
de acesso por toda a aplicação, resultando em um modelo complexo que
dificulta a compreensão para desenvolvedores e especialistas em segurança.
Esta complexidade torna provável a ocorrência de erros e algumas páginas não
serão validadas, deixando a aplicação vulnerável. [OWASP, 2007].
Mas não é somente nos domínios da organização que dados podem ser
violados. Deve-se ter um cuidado especial com a computação móvel e o
trabalho remoto. Convém que seja adotada uma política formal levando em
conta os riscos de trabalhar com estes recursos. Esta política deve conter os
requisitos para proteção física, controles de acesso, criptografia e etc. É
necessário que os usuários que se beneficiam deste recurso recebam
treinamento específico. (RODRIGUES, 2009)
É importante que os sistemas sejam monitorados para detectar
divergências entre a política de controle de acesso e os registros de eventos
monitorados, fornecendo evidências no caso de incidentes de segurança.
(RODRIGUES, 2009)
Registro de eventos de segurança relevantes é mantido por um período
de tempo para auxiliar em investigações futuras. (RODRIGUES, 2009)
38
4.4. Pesquisa de vulnerabilidades
Os ataques a sistemas computacionais têm se tornado mais freqüentes
e cada vez mais complexos, distribuídos e em larga escala tanto através da
internet quanto dentro da própria infra-estrutura. Códigos maliciosos
automatizados que trabalham de forma aleatória e pessoas com motivações
especificas exploram vulnerabilidades em aplicações e fragilidades em
arquiteturas de rede. Para endereçar estas ameaças efetivamente, não é
prudente esperar que a exploração seja efetuada, e sim antecipar os possíveis
ataques de forma a aumentar o nível de segurança e estar preparado
adequadamente. [Barbato]
Ataques como phishing, podem explorar várias vulnerabilidades,
particularmente, XSS e problemas de autenticação e autorização. Violação de
privacidade devido à validação fraca, regras de negócio e verificações de
autorizações fracas. Roubo de identidade por meio de controles de criptografia
fracos ou não existentes, inclusão de arquivo remoto e autenticação, regras de
negócio e verificação de autorização. Comprometimento de sistema, alteração
de informações e destruição de dados por ataques de injeção e inclusão de
arquivo remoto. Perda financeira por meio de transações não autorizadas e
ataques CSRF. Perda de reputação devido à exploração de qualquer uma das
vulnerabilidades anteriormente citadas. Uma vez que a organização se
distancie da preocupação de controles reativos e vai de encontro à pro-
atividade na redução de riscos de seu negócio, ela melhorará a conformidade
com regimes regulatórios, reduzirá custos operacionais, e certamente terá um
sistema mais robusto e seguro como resultado. (Barbato 2008)
39
O XSS, mencionado em parágrafos anteriores, Cross Site Scripting, é de
fato um subconjunto de inserções HTML. XSS é a questão de segurança em
aplicações Web mais prevalente e perniciosa. Os furos XSS ocorrem em
aplicações quaisquer que recebam dados originados do usuário e o envie ao
navegador sem primeiramente validar ou codificar aquele conteúdo.
O XSS permite aos atacantes executarem script no navegador da vítima,
podendo assim “seqüestrar” sessões de usuários, desfigurarem web sites,
inserir conteúdo hostil, conduzir ataques de roubo de informações pessoais
(phishing) e obter o controle do navegador do usuário usando um script mal
intencionado (malware). O script malicioso é freqüentemente em Java Script,
mas qualquer linguagem de script suportada pelo navegador da vítima é um
alvo potencial para este tipo de ataque.
A forma de descobrir as falhas de um software é similar ao método
utilizado em ataques reais, em especial, no que se refere à pseudo-atacantes
(“script kiddies”). Protegendo sua aplicação contra vulnerabilidades proverá
uma proteção módica contra as formas mais comuns de ataques e ajudará a
traçar um rumo para melhorar a segurança de seu software.
Todos os frameworks de aplicação web são vulneráveis a Cross Site
Scripting (XSS). Existem três tipos bem conhecidos de XSS: refletido,
armazenado e inserção DOM.
O XSS refletido é o de exploração mais fácil – uma página refletirá o
dado fornecido pelo usuário como retorno direto a ele: echo
$_REQUEST['userinput'].
40
O XSS armazenado recebe o dado hostil, o armazena em arquivo,
banco de dados ou outros sistemas de suporte à informação e então, em um
estágio mais avançado mostra o dado ao usuário, não filtrado. Isto é
extremamente perigoso em sistemas como CMS, blogs ou fóruns, onde uma
grande quantidade de usuários acessará entradas de outros usuários.
Com ataques XSS baseados em DOM, o código Java Script do site e as
variáveis são manipulados ao invés dos elementos HTML.
Alternativamente, os ataques podem ser, uma combinação dos três
tipos. O perigo com o XSS não está no tipo de ataque, mas na sua
possibilidade. Comportamentos não padrão do navegador pode introduzir
vetores de ataque sutis. O XSS é também potencialmente habilitado a partir de
quaisquer componentes que o browser utilize.
Os ataques são freqüentemente implementados em Java Script, que é
uma ferramenta poderosa de scripting. O uso do Java Script habilita atacante a
manipular qualquer aspecto da página a ser renderizada, incluindo a adição de
novos elementos, como um espaço para login que encaminha credenciais para
um site hostil, a manipulação de qualquer aspecto interno do DOM e a remoção
ou modificação de forma de apresentação da página. O Java Script permite o
uso do XmlHttpRequest, que é tipicamente usado por sites que usam a
tecnologia AJAX, mesmo se a vítima não use o AJAX no seu site.
O uso do XmlHttpRequest permite, em alguns casos, contornar a política
do navegador conhecida como "same source origination" – assim,
encaminhando dados da vítima para sites hostis e criar worms complexos e
41
zumbis maliciosos que duram até o fechamento do navegador. Os ataques
AJAX não necessitam ser visíveis ou requerem interação com o usuário para
realizar os perigosos ataques cross site request forgery (CSRF).
O objetivo é verificar que todos os parâmetros da aplicação são
validados e/ou recodificados antes de ser incluídos em páginas HTML.
Abordagens automatizadas: ferramentas de teste de penetração
automatizadas são capazes de detectar XSS de reflexão a partir de injeção de
parâmetro, mas freqüentemente falha na localização de XSS persistente,
particularmente se a saída do vetor de injeção XSS é prevenida via verificação
de autorização (como por exemplo, se um usuário fornece dados de entradas
maliciosos que são vistos posteriormente apenas pelos administradores).
Ferramentas de análise de código fonte podem encontrar pontos APIs com
falhas ou perigosas, mas é comum não poderem determinar se a validação ou
recodificação foram aplicadas, que pode resultar em falsos positivos. Nenhuma
ferramenta é capaz de encontrar XSS baseado em DOM, isso significa que
aplicações em Ajax estarão sempre em risco se somente forem aplicados
testes automatizados. [OWASP]
Abordagens manuais: caso um mecanismo centralizado de validação,
e recodificação for usado, da maneira mais eficiente de verificar a segurança é
verificar o código. Se uma implementação distribuída for usada, então a
verificação demandará esforço adicional considerável. O teste demanda muito
esforço, pois a superfície de ataque da maioria das aplicações é muito grande.
[OWASP]
42
A melhor proteção para XSS está na combinação de validação de “lista
branca” de todos os dados de entrada e recodificação apropriada de todos os
dados de entrada. A validação habilita a detecção de ataques e a recodificação
previne qualquer injeção de script bem sucedida de ser executada no
navegador. A prevenção de XSS ao longo da aplicação como um todo requer
uma abordagem arquitetural consistente. [OWASP]
Validação de entrada: utilize mecanismo padrão de validação de
entrada para validar todas as entradas quanto ao tamanho, tipo, sintaxe e
regras de negócio antes de aceitar que o dado seja mostrado ou armazenado.
Use uma estratégia de validação “aceite o conhecido como bom”. Rejeite
entrada inválida ao invés da tentativa de corrigir dados potencialmente hostis.
Não se esqueça que as mensagens de erro podem também incluir dados
inválidos. [OWASP]
Forte codificação de saída: garanta que qualquer dado de entrada do
usuário esteja apropriadamente codificado (tanto para HTML ou XML,
dependendo do mecanismo de saída) antes da renderização, usando a
abordagem de codificação de todos os caracteres, com exceção de um
subconjunto muito limitado. Esta é a abordagem da biblioteca Microsoft Anti-
XSS e a biblioteca prevista OWASP PHP Anti-XSS. [OWASP]
Adicionalmente, configure a codificação de caracteres para cada página
a ser produzida como saída, que diminuirá a exposição a algumas variações.
[OWASP]
Especifique a codificação de saída como ISO 8859-1 ou UTF-8: Não
43
permita que o atacante escolha isso para seus usuários. [OWASP]
Não use validação de “lista negra” para detectar XSS na entrada ou
codificação de saída. A procura ou troca de poucos caracteres ("<" ">" e outros
caracteres similares ou frases como “script”) é fraco e tem sido explorado com
sucesso. Mesmo uma tag “<b>” não verificada é insegura em alguns contextos.
O XSS possui um conjunto surpreendente de variantes que torna simples
ultrapassar validações de “lista negra” (Blacklist). [OWASP]
Cuidado com os erros de conversão. As entradas devem ser
decodificadas e convertidas para a representação interna corrente antes de ser
validada. Certifique-se que sua aplicação não decodifica a mesma entrada
duas vezes. Tais erros podem ser usados para ultrapassar esquemas de “lista
branca” pela introdução de entradas perigosas após serem checados.
[OWASP]
4.5. Ferramentas de pesquisa de códigos inseguros
A revisão de código, é a melhor forma de verificar se a aplicação
criptográfica tem mecanismos de chaves corretamente implementados, no
ponto de vista de segurança, é muito importante que se tenham profissionais
treinados em identificar problemas relacionados à segurança, do que um
número grande de ferramentas especifica para isso. Isto porque alguns erros
de segurança são difíceis de encontrar, e algumas vezes são considerados
“soluções normais” pela maioria dos desenvolvedores. Por exemplo, a
utilização de variáveis globais em linguagens de programação para aplicações
web é uma solução, que vários desenvolvedores consideraram, válida.
44
Levou algum tempo até que olhos treinados em segurança
identificassem o problema e, lentamente, isso fosse se tornando uma prática
esquecida. O ponto é procurar problemas de segurança em código requer
olhos que estejam especificamente procurando por erros e saibam como os
identificar.
Existem várias ferramentas que podem ajudar no processo de revisão,
logicamente nada é melhor que alguém ativamente analisando o código em
busca de problemas, mas, ferramentas podem ajudar a apontar os erros mais
gritantes e facilitar o trabalho de quem está fazendo a revisão. Nada substitui
olhos ativamente revisando o código, ferramentas ajudam, mas nunca devem
substituir o fator humano. O processo pode ser inclusive automatizado no
sistema de controle de versões ou no processo de se fazer um release.
Existem ferramentas que verificam o código por funções inseguras,
variáveis mal utilizadas, vulnerabilidades conhecidas de linguagens e ataques
comuns a aplicações web. A implantação de uma rotina de revisão de código
pode ser automatizada e se realizada desde o início do projeto é um trabalho
não muito pesado. Algumas ferramentas que podem ajudar na pesquisa de
testes de segurança em aplicações são citadas abaixo.
O Nessus é uma ferramenta de pesquisa remota de vulnerabilidades
para sistemas Linux, BSD, Solaris e outros Unixes. O seu funcionamento é
baseado em plugins, possui uma interface GTK e efectua mais de 1200
verificações remotas de segurança. Produz relatórios em HTML, XML, LaTeX e
texto simples que indicam as vulnerabilidades detectadas e os passos que
devem ser seguidos para elimina-los.
45
Snort: Um sistema de detecção de intrusões (IDS) público.
O Snort é uma ferramenta eficiente de detecção de intrusões, capaz de efetuar
análises em tempo real de tráfego capturado e registo de dados em redes IP.
Permite analisar protocolos, procurar conteúdos e pode ser usado para
detectar diversos ataques e sondas, nomeadamente transbordamentos de
memória (buffer overflows), levantamentos furtivos (stealth) de portos de
transporte, ataques usando CGI, sondas para SMB, tentativas de identificação
de sistemas operacionais, etc. O Snort usa uma linguagem flexível baseada em
regras para descrever o tráfego que deverá ser considerado ou não para
posterior análise.
Vários profissionais da área de segurança de dados sugeriram que a
Console de Análise de Bases de Dados de Intrusões (Analysis Console for
Intrusion Databases, ACID) fosse usada com o Snort.
GFI LANguard: Um pesquisador de problemas de segurança comercial
para Windows, o LANguard analisa redes e produz relatórios com informação
que inclui quais os nível de atualização (Service Packs level) do sistema de
cada máquina, as correções de falha de segurança , os recursos partilhados
disponíveis, serviços/aplicações disponíveis no computador, entradas-chave do
registo (registry), senhas fracas, utilizadores e grupos e mais ainda. Os
resultados da análise são apresentados num relatório em HTML, que pode ser
adaptado/pesquisado. Aparentemente uma versão gratuita limitada está
disponível para fins não comerciais ou para avaliação.
O Whisker é ferramenta de inspeção de servidores HTTP que permite
detectar muitos problemas de segurança, nomeadamente a presença de CGI
46
perigosos. Libwhisker é uma biblioteca de perl (usada pelo Whisker) que
permite a criação de inspetores de HTTP específicos. Pretende-se auditar mais
do que servidores HTTP.
Retina: pesquisador de vulnerabilidades comercial da eEye. Tal como o
Nessus e o ISS Internet Scanner previamente mencionados, a função do
Retina é a de procurar vulnerabilidades em todas as máquinas de uma rede e
de produzir um relatório de avaliação sobre as mesmas.
47
5. PROTEÇÃO
5.1. Introdução
A Informação é tudo que pode ser armazenado ou transferindo
destinado a um propósito e sendo de utilidade ao ser humano. A informação
digital pode ser visualizada de diversas maneiras, à medida que ela circula por
vários ambientes, percorrendo diversos fluxos de trabalho, podendo ser
armazenada para os variados fins, possibilidade ela ser lida, alterado e
excluída.
A Segurança da informação é um conjunto de medidas que têm por
objetivo proteger e preservar informações de sistemas de informações,
assegurando-lhes integridade, disponibilidade, não repúdio, autenticidade e
confidencialidade. Esses elementos constituem os cinco pilares da proteção da
segurança da informação e logo são essenciais para assegurar a integridade e
a confiabilidade em sistemas de informações. Os componentes criptográficos
da segurança da informação cuidam da confidencialidade, integridade e
autenticidade.
Vale ressaltar que o uso dos pilares é feito de acordo com as
necessidades específicas de cada organização, que pode ir de certo nível de
ameaças a quaisquer outras decisões de gestão de riscos. Esses pilares são
essenciais no mundo atual, onde se tem ambientes públicos e privados
conectados a nível mundial. Assim, é necessário dispor de uma tática, levando
em conta os pilares usados pela segurança de informação, com o objetivo de
compor uma arquitetura de segurança que venha unificar os propósitos de
todos eles.
48
Hoje em dia, onde conhecimento e informação e criptografia são fatores
de muita importância para qualquer organização ou nação, para que suas
informações e dados sensíveis sejam bem protegidos, a segurança da
informação é um pré-requisito para todo e qualquer sistema de informações.
Uma proteção bem elaborada oferece suporte à prevenção de revelação
não autorizada de informações, além de manter os dados e recursos ocultos a
usuários sem privilégio de acesso. A integridade trata que a modificação não
autorizada de informações.
As ameaças podem ser de diversos tipos, elas são, geralmente,
classificadas como ativa, passiva, maliciosa, não maliciosa. Para combater
essas ameaças, torna-se necessário a definição de políticas e mecanismos de
segurança, visando dar suporte a:
Prevenção – evitar que invasores violem os mecanismos de segurança;
Detecção – habilidade de detectar invasão aos mecanismos de
segurança;
Recuperação – mecanismo para interromper a ameaça, avaliar e reparar
danos, além de manter a operacionalidade do sistema caso ocorra invasão ao
sistema.
5.2. Mecanismos de segurança
O suporte para as recomendações de segurança pode ser encontrado
em:
49
Controles físicos: são barreiras que limitam o contato ou acesso direto a
informação ou a infra-estrutura, que garante a existência da informação que a
suporta. Existem mecanismos de segurança que apóiam os controles físicos:
Portas, trancas, paredes, blindagem, guardas, etc ..
Controles lógicos: são barreiras que impedem ou limitam o acesso a
informação, que está em ambiente controlado, geralmente eletrônico, e que, de
outro modo, ficaria exposta a alteração não autorizada por elemento mal
intencionado. Existem mecanismos de segurança que apóiam os controles
lógicos:
Mecanismos de criptografia, que permitem a transformação reversível da
informação de forma a torná-la ininteligível a terceiros. Utiliza-se para tal,
algoritmos determinados e uma chave secreta para, a partir de um conjunto de
dados não criptografados, produzir uma seqüência de dados criptografados. A
operação inversa é a decifração.
Assinatura digital: Um conjunto de dados criptografados, associados a
um documento do qual são função, garantindo a integridade do documento
associado, mas não a sua confidencialidade.
Mecanismos de garantia da integridade da informação: Usando funções
de "Hashing" ou de checagem, consistindo na adição.
Mecanismos de controle de acesso: Palavras-chave, sistemas
biométricos, firewalls, cartões inteligentes.
Mecanismos de certificação: Atesta a validade de um documento.
50
Integridade: Medida em que um serviço/informação é genuíno, isto é,
está protegido contra a personificação por intrusos.
Honeypot: É o nome dado a um software, cuja função é detectar ou de
impedir a ação de um cracker, de um spammer, ou de qualquer agente externo
estranho ao sistema, enganando-o, fazendo-o pensar que esteja de fato
explorando uma vulnerabilidade daquele sistema.
Protocolos seguros: uso de protocolos que garantem um grau de
segurança e usam alguns dos mecanismos citados aqui existe hoje em dia um
elevado número de ferramentas e sistemas que pretendem fornecer segurança.
Alguns exemplos são os detectores de intrusões, os antivírus, firewalls,
firewalls locais, filtros anti-spam, fuzzers, analisadores de código, etc.
5.3. Ameaças à segurança
As ameaças à segurança da informação são relacionadas diretamente à
perda de suas características principais, que são:
Perda de Confidencialidade: seria quando há uma quebra de sigilo de
uma determinada informação (ex: a senha de um usuário ou administrador de
sistema) permitindo com que sejam expostas informações restritas as quais
seriam acessíveis apenas por um determinado grupo de usuários.
Perda de Integridade: aconteceria quando uma determinada
informação fica exposta a manuseio por uma pessoa não autorizada, que
efetua alterações que não foram aprovadas e não estão sob o controle do
proprietário (corporativo ou privado) da informação.
51
Perda de Disponibilidade: acontece quando a informação deixa de
estar acessível por quem necessita dela. Seria o caso da perda de
comunicação com um sistema importante para a empresa, que aconteceu com
a queda de um servidor ou de uma aplicação crítica de negócio, que
apresentou uma falha devido a um erro causado por motivo interno ou externo
ao equipamento ou por ação não autorizada de pessoas com ou sem má
intenção.
No caso de ameaças à rede de computadores ou a um sistema, estas
podem vir de agentes maliciosos, muitas vezes conhecidos como crackers,
(hackers não são agentes maliciosos, pois tentam ajudar a encontrar possíveis
falhas). Estas pessoas são motivadas para fazer esta ilegalidade por vários
motivos. Os principais são: notoriedade, auto-estima, vingança e o dinheiro. De
acordo com pesquisa elaborada pelo CSI (Computer Security Institute), mais de
70% dos ataques partem de usuários legítimos de sistemas de informação
(Insiders), o que motiva corporações a investir largamente em controles de
segurança para seus ambientes corporativos (intranet).
5.4. Nível de segurança de proteção
As organizações empresariais e governamentais devem decidir o nível
de segurança que deverá ser estabelecido para que suas redes, sistemas,
recursos físicos e lógicos, tenham proteção realmente segura. No nível de
segurança devem ser quantificados os custos associados aos ataques e os
associados à implementação de mecanismos de proteção para minimizar a
probabilidade de ocorrência de um ataque.
52
Segurança física: Considera as ameaças físicas como incêndios,
desabamentos, relâmpagos, alagamento, acesso indevido de pessoas, forma
inadequada de tratamento e manuseamento do material.
Segurança lógica: Atenta contra ameaças ocasionadas por vírus,
acessos remotos à rede, backup desatualizados, violação de senhas, etc.
5.5. Políticas de segurança de proteção
De acordo com o RFC 2196 (The Site Security Handbook), uma política
de segurança consiste num conjunto formal de regras que devem ser seguidas
pelos utilizadores dos recursos de uma organização.
As políticas de segurança devem ter implementação realista, e definir
claramente as áreas de responsabilidade dos utilizadores, do pessoal de
gestão de sistemas e redes e da direção. Deve também adaptar-se a
alterações na organização. As políticas de segurança, definem procedimentos
de segurança adequados, processos de auditoria à segurança e estabelecem
uma base para procedimentos legais na sequência de ataques.
O documento que define a política de segurança deve deixar de fora
todos os aspectos técnicos de implementação dos mecanismos de segurança,
pois essa implementação pode variar ao longo do tempo. Deve ser também um
documento de fácil leitura e compreensão, além de resumido.
Algumas normas definem aspectos que devem ser levados em
consideração ao elaborar políticas de segurança. Entre essas normas estão a
BS 7799 (elaborada pela British Standards Institution) e a NBR ISO/IEC 17799
53
(a versão brasileira desta primeira). A ISO começou a publicar a série de
normas 27000, em substituição à ISO 17799 (e por conseguinte à BS 7799),
das quais a primeira, ISO 27001, foi publicada em 2005. ( Segadas, 2009 )
Existem duas filosofias por trás de qualquer política de segurança: a
proibitiva - tudo que não é expressamente permitido é proibido e a permissiva -
tudo que não é proibido é permitido.
Os elementos da política de segurança devem ser considerados:
A Disponibilidade: o sistema deve estar disponível de forma que quando
o usuário necessitar possa usar. Dados críticos devem estar disponíveis
ininterruptamente.
A Utilização: o sistema deve ser utilizado apenas para os determinados
objetivos.
A Integridade: o sistema deve estar sempre íntegro e em condições de
ser usado.
A Autenticidade: o sistema deve ter condições de verificar a identidade
dos usuários, e este ter condições de analisar a identidade do sistema.
A Confidencialidade: dados privados devem ser apresentados somente
aos donos dos dados ou ao grupo por ele liberado. ( Segadas, 2009 )
54
6. CONCLUSÃO
O mundo de hoje fornece mecanismos facilitadores para adquirir
produtos e esse fato nos faz acreditar que podemos comprar soluções de
segurança prontas para atender a nossa demanda. Nem sempre o que nós
estamos procurando pode ser encontrado em prateleiras de lojas de
informática e também não podemos simplesmente gerar uma receita de
bolo na forma de algoritmo.
Técnicas e procedimentos mais eficazes são desenvolvidos como
tentativa de utilização de ferramentas na área de criptografia e chaves
digitais, atualmente conhecidos para a construção de mecanismos
criptográficos de dados digitais e de meios para que sejam integrados em
sistemas de informação que queiram ser protegidos.
Algumas áreas de conhecimento são diretamente correlacionadas
com o nosso assunto de criptografia e chaves digitais. Podemos citar o
conhecimento de aritmética modular (aritmética dos processadores digitais),
do funcionamento básico de sistemas operacionais, conhecimento em redes
de computadores e também noção de complexidade de algoritmos.
Criptografia é uma especialização da matemática e engenharia que
oferecem técnicas de proteção a mecanismos de acesso e a integridade de
dados, e também de ferramentas para avaliação da eficácia dessas
técnicas. Estas técnicas e ferramentas são relacionadas no sentido sintático
e não podemos atribuir confiança no sentido semântico nas informações
dos dados veiculados.
55
Para uma boa política de segurança, esses três itens devem ser
respeitados:
• Planejamento - Avaliar e analisar os riscos e custos.
• Especificação para implementar serviços e salvaguardas.
• Atribuição documentada de autorização e responsabilidades.
Um exemplo de roteiro para planejamento para as políticas de
Segurança de Dados:
• Quais recursos e ativos em bits devem ser protegidos?
• De quem (securityu) e de que(safety) se quer protegê-los?
• Qual a chance/probabilidade de acidentes, ameaças e
trapaças?
• Como medir o valor dos ativos em bits e recursos?
• Quais ações podem protegê-los com custo/benefício aceitável?
• Que planos de contingência, reavaliação, terceirização, etc.
decorrem?
Além de disponibilidade de serviço de segurança é importante
também saber o que fazer quando se ocorre algum problema não
planejado. Podemos citar algumas salvaguardas não computacionais
abaixo:
• Segurança física - controle de acesso físico, blindagem, etc.
• Segurança funcional - recrutamento, treinamento, motivação.
56
• Segurança administrativa - auditoria, fiscalização,
contingência.
• Segurança na mídia - backup, destruição de material, etc.
• Radiação ou Engenharia Reversa - blindagem no
encapsulamento.
• Controles de ciclos - reavaliação da política de segurança.
É indiscutível a importância da segurança da informação no cenário
atual. O aumento no número de aplicações, a distribuição dessas aplicações
através do uso maciço de redes de computadores e o número crescente de
ataques a esses sistemas retrata essa preocupação e justifica o esforço em
pesquisas voltadas a essa área. Novos mecanismos, técnicas mais eficientes e
normas internacionais para a gestão da segurança da informação, são
constantemente desenvolvidos, incentivados por organismos governamentais e
empresas preocupadas com o atual estágio de fragilidade da maioria das
instalações computacionais.
A disponibilidade dessas novas ferramentas, no entanto, não tem
representado um aumento equivalente no nível de segurança das
organizações, retrato, principalmente, da falta de uma abordagem correta na
seleção e implementação dessas técnicas. A maioria dos profissionais
responsáveis pela gerência de segurança, oriundos principalmente da área de
computação, possui uma formação técnica que os leva a partir da seleção de
mecanismos sem considerar as reais necessidades da organização. Essa
prática causa distorções que vão desde o gasto desnecessário com
mecanismos desproporcionais ao problema enfrentado até a falta de proteção
57
às informações realmente importantes, problemas abordados como ponto
principal neste curso.
Segurança é um atributo muito complexo e difícil de implementar
consistentemente em um sistema, principalmente em ambientes
computacionais. Projetar e implementar um sistema visando segurança
significa analisar um conjunto complexo de situações adversas onde o
projetista e um oponente elaboram estratégias de modo completamente
independente. O resultado desta análise depende fortemente das escolhas e
técnicas feitas por cada um dos oponentes.
Outra característica marcante é que segurança é essencialmente um
atributo negativo. É fácil caracterizar um sistema inseguro, mas não existe uma
metodologia capaz de provar que um sistema é seguro. Assim, um sistema é
considerado seguro se não foi possível, até o momento atual, determinar uma
maneira de torná-lo inseguro.
Com muita freqüência isto decorre simplesmente do fato que não foram
testados todos os métodos de ataque (ou até mesmo menosprezados alguns)
ou que não foram identificados todos os possíveis atacantes.
Por esses e outros fatores, tão inviável e ineficaz quanto construir um
prédio sem planejar antecipadamente cada detalhe, é impossível pensar em
segurança como um apanhado de ferramentas dispostas sem uma avaliação
prévia, levando em consideração vulnerabilidades, riscos, importância dos bens
e relação custo/benefício. Isso representa a conjugação de três critérios
fundamentais: política, cultura e mecanismos de segurança. O desequilíbrio
58
causado pela falência de algum desses três aspectos pode representar a
queda significativa no nível de segurança esperado, cenário comum em muitas
instalações atuais.
A política de segurança dita os princípios e as regras que regem a
segurança da informação, importante para balizar a escolha de mecanismos e
a adoção de procedimentos relacionados ao assunto. A cultura de segurança é
um dos aspectos mais delicados e está ligada ao treinamento e
conscientização de todos os envolvidos no processo computacional, sejam eles
funcionários, técnicos ou mesmo acadêmicos. Sem essa preocupação,
qualquer estratégia de segurança será ineficaz pela simples razão de estar
suscetível a ataques que explorem tal fragilidade, como os conhecidos ataques
de engenharia social, por exemplo. Por fim, mas não menos importante, os
mecanismos de segurança garantem o cumprimento da política de segurança
traçada, e devem estar alinhados com as exigências da mesma.
O grande problema observado atualmente é o excessivo enfoque em
mecanismos de segurança, causando distorções já citadas e, em muitos casos,
uma falsa sensação de segurança. Sistemas operacionais são selecionados
segundo características meramente comerciais, firewalls são mal configurados
e instalados em pontos pouco eficazes e sistemas de detecção de intrusão são
comprados e instalados sem um conhecimento mínimo da realidade de tal
organização, entre outros problemas. Escolhas equivocadas como essas estão
ligadas ao despreparo que a maioria dos profissionais responsáveis pela
administração e gerência tem em relação a práticas corretas de avaliação,
seleção e implementação de técnicas de segurança. Não bastam bons
59
conhecimentos em mecanismos de segurança: é preciso levar em
consideração a política e a cultura de segurança.
Isso reforça a importância de profissionais que tenham uma boa noção
de todos os aspectos que permeiam a verdadeira segurança, encarando-a
como uma política global dentro de uma organização e não como atitudes
isoladas e mal planejadas. Além disso, vale ressaltar a importância da
experiência quando o assunto é segurança, o que pode ser adquirido com o
tempo ou através do contato com exemplos e situações práticas na criação de
políticas, no estabelecimento de uma cultura e na implementação de
mecanismos adequados.
60
7. REFERÊNCIA BIBLIOGRÁFICA
• BARBATO, L.G.C., Segurança de Sistemas: Antecipando os
Acontecimentos, 2008.
• OWASP Foundation, As 10 vulnerabilidades de segurança mais
criticas em aplicações Web. Traduzido por: Brandão, C., Braz, F. A.,
Militelli, L. C., Rodrigues, M. A., Hamada, M., Montoro, R., 2007.
• SILVA, L. S. Uma metodologia para detecção de ataques no tráfego
de redes baseada em redes neurais. São José dos Campos: INPE,
2007.
61
8. SITES PESQUISADOS:
• ARAÚJO, João Gualberto R. 2009. Disponível em:
http://www.ogeda.com.br/php/modules/eNoticias/column.php?columnID=
1
• WIKIPÉDIA, acessado em 03/06/2009, disponível em:
http://pt.wikipedia.org/wiki/Frameworks
• ZEMEL, Tárcio, 2009. Disponível em:
http://codeigniterbrasil.com/passos-iniciais/o-que-e-um-framework-
definicao-e-beneficios-de-se-usar-frameworks/
• LAHR, ThiagoCanozzo, 2009. Disponível em:
http://www.ogeda.com.br/php/modules/eNoticias/column.php?columnID=
1
• SLAVADOR, Henrique, 2009. Disponível em:
http://henriquesalvador.blogspot.com/2009/04/algoritmo-a5.html
• CIVIDANES, Segurança Lógica 2009 ITA, 2009. Disponível em:
http://fcividanes.blogspot.com/2009/04/algoritmo-a5.html
• Desenvolvimento Seguro e Software Livre – Dica 2: Revisão de Código,
2009. Disponível em:
http://core.eti.br/2008/12/27/desenvolvimento-seguro-e-software-livre-
dica-2-revisao-de-codigo/
![[Tcc] apresentação final](https://img.document.onl/doc/110x75/5492e99fac7959092e8b4735/tcc-apresentacao-final.jpg)
