Tcc luizfernando final
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Tcc luizfernando final

on

  • 2,044 views

 

Statistics

Views

Total Views
2,044
Views on SlideShare
2,044
Embed Views
0

Actions

Likes
0
Downloads
32
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Tcc luizfernando final Document Transcript

  • 1. CENTRO UNIVERSITÁRIO METODISTA BENNETT CURSO DE CIÊNCIA DA COMPUTAÇÃO TRABALHO DE CONCLUSÃO DE CURSOPROTEÇÃO E RECOMENDAÇÕES PARA O PROBLEMADO ARMAZENAMENTO CRIPTOGRÁFICO INSEGURO PROJETO AECRIPT LUIZ FERNANDO GONÇALVES RIO DE JANEIRO JULHO, 2009
  • 2. IICENTRO UNIVERSITÁRIO METODISTA BENNETT CURSO DE CIÊNCIA DA COMPUTAÇÃOPROTEÇÃO E RECOMENDAÇÕES PARA O PROBLEMADO 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
  • 3. IIIESTE TRABALHO FOI JULGADO ADEQUADO PARA A OBTENÇÃO DOGRAU DE BACHAREL EM CIÊNCIA DA COMPUTAÇÃO E APROVADO EMSUA FORMA FINAL PELA DISCIPLINA DE TRABALHO DE CONCLUSÃODE CURSOBANCA EXAMINADORA:_________________________________________M.Sc. Willian Augusto R. de SouzaOrientador_________________________________________M. Sc. Pier Giovanni Taranti_________________________________________D. Sc. Júlio Luiz Nunes Carvalho Rio de Janeiro Julho, 2009
  • 4. IVAGRADECIMENTOS Agradeço, antes de tudo, a Deus, por ter me munido de forças parasuperar 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ãome deixar ser derrotado pelas dificuldades enfrentadas. Aos meus professores, pelo incentivo e ajuda constante na busca peloconhecimento. Em especial ao meu Professor Orientador M.Sc William AugustoRodrigues de Souza, pela valorosa orientação, atenção e apoio em todos osmomentos e que em momento algum negou auxilio, propondo valiosassugestões. A todos os meus amigos acadêmicos que me incentivaram, apoiarampossibilitando esta oportunidade, ampliando assim meus horizontes naconclusã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
  • 5. RESUMO............................................................................................................. IABSTRACT......................................................................................................... I1. INTRODUÇÃO............................................................................................ 82. FERRAMENTAS SEGURAS EM APLICAÇÕES WEB ............................ 112.1. FRAMEWORKS .................................................................................... 112.2. DADOS INSEGUROS ........................................................................... 123. VULNERABILIDADE ................................................................................ 153.1. INTRODUÇÃO ...................................................................................... 153.2. DADOS SENSÍVEIS.............................................................................. 153.3. ALGORITMOS FORTES....................................................................... 173.4. ALGORITMOS FRACOS ...................................................................... 193.5. CODIFICAÇÃO DE CHAVES ............................................................... 224. VERIFICAÇÃO DE SEGURANÇA ........................................................... 264.1. INTRODUÇÃO ...................................................................................... 264.2. VERIFICAÇÃO DE SEGURANÇA EM APLICAÇÕES WEB................ 294.3. DADOS SENSÍVEIS EM SISTEMAS DE ARMAZENAMENTO ............ 334.4. PESQUISA DE VULNERABILIDADES................................................. 384.5. FERRAMENTAS DE PESQUISA DE CÓDIGOS INSEGUROS ........... 435. PROTEÇÃO.............................................................................................. 475.1. INTRODUÇÃO ...................................................................................... 475.2. MECANISMOS DE SEGURANÇA ........................................................ 485.3. AMEAÇAS À SEGURANÇA................................................................. 505.4. NÍVEL DE SEGURANÇA DE PROTEÇÃO........................................... 515.5. POLÍTICAS DE SEGURANÇA DE PROTEÇÃO .................................. 526. CONCLUSÃO ........................................................................................... 547. REFERÊNCIA BIBLIOGRÁFICA ............................................................. 608. SITES PESQUISADOS: ........................................................................... 61
  • 6. RESUMOProteger dados sensíveis com criptografia tem sido parte chave das aplicaçõesweb, este trabalho trata de uma pesquisa sobre proteção e recomendaçõespara o problema do armazenamento criptográfico inseguro (Projeto AECript),abordando assuntos como armazenamento de dados sensíveis, ambientesafetados, vulnerabilidades em códigos de aplicações web, sistemas deaplicações inseguros, mostrando onde esta o problema da proteção dearmazenamentos de informações vulneráveis ao ataque e roubos de dados,trazendo prejuízo financeiro a maioria das grandes empresas, e assegurarcomo a solução para esses problemas, deverão ser feitas através dealgoritmos criptográfico.
  • 7. ABSTRACTProtect sensitive data with encryption key has been part of web applications,this work deals with a research on protection and recommendations for theproblem of insecure cryptographic storage (Project AECript), addressing issuessuch as storage of sensitive data, affected environments, vulnerabilities in thecode web applications, systems, applications unsafe, showing where theproblem is the protection of information stores vulnerable to attack and theft ofdata, causing financial loss to most large companies, and provide as a solutionto these problems, should be made through cryptographic algorithms.
  • 8. 81. 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 decomunicação segura surgiram muitas aplicações que facilitaram a utilização dainternet para transações como, por exemplo, o comércio eletrônico, bancoseletrônicos e outros métodos que exigem a transmissão de informaçõesconfidenciais através da rede. Em compensação, a maioria destas aplicaçõespossui algoritmos de criptografia mal concebidos, por isso podemos considerarque a transmissão desses dados não é segura. As falhas de segurança mais comuns são: não criptografia de dadossensíveis; uso continuado de algoritmos comprovadamente fracos (MD5, SHA-1, RC3, RC4, etc…); codificação difícil de chaves e armazenamento de chavesem repositórios desprotegidos. Técnicas de criptografia são usadas como um meio efetivo de proteçãode informações suscetíveis a ataques, estejam elas armazenadas em umcomputador ou sendo transmitidas pela rede. Seu principal objetivo é proveruma 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 tornadouma parte essencial da maioria das aplicações web. As aplicações webraramente utilizam de modo adequado, funções de criptografia para proteger osdados e credenciais de usuários. Aplicações que utilizam criptografia
  • 9. 9geralmente possuem criptografia mal projetada, com cifras inadequadas ouproduzem erros graves ao usar cifras fortes. Estas falhas podem levar arevelação de dados sensíveis e a violações de conformidade. Os atacantesutilizam dados fracamente protegidos para furtar identidades e realizar outroscrimes, tais como fraude de cartão de crédito. (SILVA, 2007). 1.2. OBJETIVOS Esta monografia faz parte do Projeto OWASP TOP TEM 2007 – A8ARMAZENAMENTO CRIPTOGRAFICO INSEGURO que tem a finalidade deensino, aprendizagem e conscientização de problemas, soluções e segurançada informação, pretende também colaborar como uma referência sobrepesquisas na defesa, proteção, recomendações e principais falhasrelacionadas ao armazenamento criptográfico inseguro, informando como osproblemas funcionam, o que se pode fazer para solucionar os problemas desegurança e práticas necessárias para evitar todos os tipos de ataque. 1.3. ORGANIZAÇÃO DO TRABALHOForam executadas consultas em sites na internet para obtenção de materialonde foi possível selecionar o que se fazia necessário para o entendimento dotema abordado. A partir da coleta do material, elaborou-se uma criteriosaseleção para a elaboração do texto desejado com a melhor forma, maiseficiente para o desenvolvimento da pesquisa necessária para o projeto.Este trabalho está organizado em 8 capítulos. O capítulo 2 traz uma pesquisados conceitos de ambientes afetados em sistemas. O capitulo 3 aborda osprincipais tipos de vulnerabilidades , tratando com maiores detalhes em dados
  • 10. 10sensíveis apresentado algumas fragilidades em algoritmos de sistemas . sãoapresentados 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ãoapresentados 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, oscapítulos 6, 7, 8 conclui esta monografia apontando as contribuições epossíveis melhoramentos neste trabalho.Palavras-chave: Criptografia, Armazenamento criptográfico, Segurança dainformação.
  • 11. 112. Ferramentas seguras em Aplicações web 2.1. Frameworks Em desenvolvimento de software, framework é uma estrutura de suportedefinida 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 unirdiferentes 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áveisinclusas. Mas para que funcionem é necessário ser implementadas comlógicas que dependem da necessidade. Foram projetadas com a intenção defacilitar o desenvolvimento de software, habilitando designers e programadoresa utilizarem o seu tempo de forma mais proveitosa, não sendo necessárioreinventar códigos. São um pouco mais complexos que as bibliotecas, masquando 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 deproblema. 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. 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. 13aquele que permite a injeção de scripts no site atacado, em geral por meio dealgum 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 scriptinjetado nunca será executado no servidor, mas nos navegadores dos clientesque visitarem a página infectada. A regra principal de qualquer sistema cominput 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 alvosde muitos outros ataques, como SQL Injection, injeção de parâmetros e outros. Um exemplo do problema é a injeção de parâmetros perigosos, queacontece frequentemente devido a Web e aos frameworks modernos. Um exemplo de Injeção de atributos é usarmos qualquer framework Javapara Web (VRaptor, Struts, Mentawai, Waffle). Muitos programadores estãoacostumados com a facilidade de não se preocupar com o(request.getParameter), escrevem um JavaBean e o framework compilaautomaticamente os dados, seguindo os nomes do parâmetro. Imaginemos um sistema onde as pessoas se cadastram em algumserviç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 eusuario.senha.
  • 14. 14 /usuario/cadastra?usuario.email=example@example.com& usuario.senha=1234 Imaginemos também, que gostaríamos de ter uma área administrativa, ecertos 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/cadastra?usuario.email=example@exampl e.com&usuario.senha=1234&usuario.admin=true Isso seria extremamente inseguro. E se no cadastro dos usuáriosnormais 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. Oproblema não existiria se ainda programássemos comrequest.getParameter(), já que na lógica dos usuários normaisobviamente só pegaríamos os parâmetros usuario e email. Isso aparecequando usamos as facilidades dos frameworks que usam qualquer parâmetrono JavaBean. Revendo todos os seus códigos atrás desse tipo de falha e perceber oquão grave ele é. A solução mais adequada seria não ter nenhum atributo noJavaBean que não possa ser inserido pelo usuário.
  • 15. 153. VULNERABILIDADE 3.1. Introdução De acordo com estudos OWASP (Open Web Application SecurityProject), as vulnerabilidades que existem em mais abundância na web são asfalhas XSS (Cross Site Scripting) e XRSF (Cross Site Request Forgery), estetipo 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 aoroubo de informações. Erros em validações de parâmetros é a principal causa deste tipo defalha. Injeção de SQL é uma das vulnerabilidades mais conhecidas, pelaInternet e pequenos erros de validação podem se revelar perigosos eextremamente 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 esofisticados. Na maioria das vezes, geram perda de dados ou outras violaçõesde segurança. A maioria das operações que exigem segurança na WEB éprojetada e desenvolvida de forma insegura e negligente. Essa negligenciaparte tanto de usuários quanto de grandes companhias, sendo importante enecessá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 maisdiversas formas de armazenamentos de dados, a maioria das empresas nãousa os sistemas de criptografia de forma correta, dados sensíveis ficam
  • 16. 16esquecidos em servidores com pouco ou sem nenhum tipo eficiente deproteção. A falta de utilização de sistemas criptográficos seguros nas empresasdeve-se em parte ao desinteresse das empresas, a falta de investimento oudesconhecimento, e hoje em dia com o aumento no volume de dadossensíveis, torna-se obrigatório o uso de criptografia segura nas empresas degrande porte, como forma de proteger-se de espionagem industrial por parte deseus concorrentes ou de ataques de hackers. Os dados sensíveis requerem mais atenção também por parte deusuários, pois ao gravar informações confidenciais em seu computador ounotebook, 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 criptografiade disco. Ao ativar a criptografia em uma partição, os dados que serãogravados nela, a partir de então serão criptografados automaticamente, e oeventual 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 webfreqüentemente sofrem com a falta de segurança incorporada. Asvulnerabilidades resultantes representam um caminho fácil para que hackersacessem ou roubem dados e informações corporativas ou pessoais. SegundoLahr, um estudo realizado recentemente pela IBM ISS mostra que aporcentagem de vulnerabilidades de risco alto continua crescendo, e 40% dasvulnerabilidades descobertas hoje são consideradas de risco crítico ou alto.
  • 17. 17 Apesar da maioria dos exploits para aplicações web serem gerados apartir de ferramentas hospedadas em sites maliciosos, há uma grandepreocupação com o aumento de vulnerabilidades e explorações em aplicaçõesweb. A quantidade de ataques utilizando métodos automatizados deexploraçã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 crescendoa cada ano em uma velocidade incrível. Se pegarmos de 2006 até a metade de2008, vulnerabilidades afetando aplicações web somaram 51% de todas asvulnerabilidades descobertas. Os tipos predominantes de vulnerabilidades são Cross-Site-Scripting(XSS), SQL Injection e File Include. Nos anos anteriores, as vulnerabilidadesbaseadas em Cross-Site-Scripting eram as mais encontradas em aplicações web, porém a primeira metade desse ano foi marcada pelo grandeaumento em descobertas de SQL Injection, mais que dobrando o número devulnerabilidades vistas no mesmo período de 2007. (LAHR, 2007) 3.3. Algoritmos fortes Algoritmos fortes e poderosos são desenvolvidos para seremexecutados por computadores ou dispositivos especiais de hardware. Na maiorparte das aplicações a criptografia é feita por software, e vários pacotescriptográficos estão disponíveis.
  • 18. 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 darede GSM (Global System for Mobile Communications). O protocolo utilizadona comunicação da rede GSM utiliza, além do algoritmo A5, os algoritmos A3 eA8. O algoritmo A3 realiza a autenticação junto a CA (Autoridade Certificadora)pelo método de pergunta-resposta, utilizando o valor RAND (128 bits) geradopela CA na mensagem SRES (sinal de resposta, com 32 bits) e devolvida pelocliente juntamente com o valor Ki (128 bits), chave armazenado no seu SIMcard. O conteúdo as SRES, retornado pelo cliente, é comparado pelos valoresarmazenados na CA, que aceita ou rejeita a autenticação. Uma vez autenticadocom sucesso, o algoritmo A8 calcula a chave de criptografia simétrica Kc (64bits), utilizando o RAND e Ki que será utilizada para a criptografia dasmensagens trocadas. O algoritmo A5 fica responsável por realizar o embaralhamento de bitsde dados codificados enviados a cada terminal fazendo assim a segurança dacomunicaçã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. 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 asegurança deste algoritmo.Chamamos a atenção para o fato de que não adianta aplicarmos um algoritmoforte no processo de criptografia de voz se previamente, no processo de trocadas chaves, utilizou-se um algoritmo sem a segurança adequada para protegeressa troca.Podemos fazer uma analogia dos processos de segurança utilizados com umcofre 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á bemprotegido e pode ser acessado por terceiros. 3.4. Algoritmos Fracos O MD5 (Message-Digest algorithm 5) é um algoritmo de hash de 128bits unidirecional desenvolvido pela RSA Data Security, Inc., descrito na RFC1321, e muito utilizado por softwares com protocolo ponto-a-ponto (P2P, ouPeer-to-Peer, em inglês), verificação de integridade e logins. Foi desenvolvido em 1991 por Ronald Rivest para suceder ao MD4 quepossuía alguns problemas de segurança. Por ser um algoritmo unidirecional,
  • 20. 20uma hash md5 não pode ser transformada novamente no texto que lhe deuorigem. O método de verificação é, então, feito pela comparação das duashash (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, doprograma md5sum, que cria a hash de um arquivo. Isto se pode tornar muitoútil para downloads de arquivos grandes, para programas P2P que constroemo arquivo através de pedaços e estão sujeitos à corrupção dos mesmos. Comoautenticação de login é utilizada em vários sistemas operacionais unix e emmuitos sites que requerem autenticação. O SHA (stands for Secure Hash Algorithm) é constituído por cincofunções hash, concebido pelo National Security Agency (NSA) e publicado peloInstituto Nacional de Padrões e Tecnologia (NIST). Os cinco são algoritmosSHA-1, SHA-224, SHA-256, SHA-384, e SHA-512. SHA-1 é o mais comumenteutilizado da SHA série. Algoritmos Hash são chamados seguros quando ele for impossívelencontrar uma mensagem que corresponde a uma determinada mensagemdigerir, e quando for impossível encontrar duas mensagens diferentes queproduzem a mesma mensagem digerir, caso se uma mensagem for mudadaaté mesmo por um único personagem, o resultado será uma mensagemcompletamente 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. 21one-way hash função. One-way funções são caracterizados por duaspropriedades. A primeira é que eles são uma via de sentido. Isto significa quevocê pode ter uma mensagem e calcular um valor hash, mas você não pode terum 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 fluxomais usado no software e utilizado nos protocolos mais conhecidos, comoSecure Socket Layers (SSL) (para proteger o tráfego Internet) e WEP (para asegurança de redes sem fios). RC4 não é considerado um dos melhoressistemas criptográficos pelos adeptos da criptografia e em algumas aplicaçõespode converter-se em sistemas muito inseguros. No entanto, alguns sistemasbaseados em RC4 são seguros o bastante num contexto prático. Em 1987 Ron Rivest desenvolveu o algoritmo RC4 para a empresa RSAData Security, Inc., líder mundial em algoritmos de criptografia. Foi, durantetempos, um segredo comercial muito bem guardado, muito popular, e utilizadolargamente em software, como Lotus Notes, Apple Computer’s AOCE, OracleSecure SQL, Internet Explorer, Netscape e Adobe Acrobat. Sete anos depois, surge num mailing list dedicado à criptografia –Cypherpunks - código alegadamente equivalente ao RC4. Utilizadores comcópias legais puderam confirmar a compatibilidade. É importante ressaltar, noentanto, que esta não é a implementação comercial, e, como tal, éhabitualmente referida como ARC4 (Alleged RC4).
  • 22. 22 As transformações neste algoritmo são lineares, por isso não sãonecessários cálculos complexos, já que o sistema funciona basicamente porpermutações e somas de valores inteiros, o que torna este algoritmo muitosimples e rápido. Um raro exemplo de Barato, Rápido e Bom. De uma forma geral, o algoritmo consiste em utilizar um array que acada utilização tem os seus valores permutados, e misturados com a chave, oque provoca que seja muito dependente desta. Esta chave, utilizada nainicialização do array, pode ter até 256 bytes (2048 bits), embora o algoritmoseja mais eficiente quando é menor, pois a perturbação aleatória induzida noarray é superior. 3.5. Codificação de chaves De acordo com a história antiga, enviar uma mensagem de forma segurafoi sempre uma preocupação que persistiu aos primeiros estrategistas emsegurança da informação que se têm notícia. Houve época em que soldados tinham mensagens escritas em seucouro cabeludo como estratégia para passar uma informação pelas linhasinimigas, bastando chegar ao seu destino e ter sua cabeça raspada. (livro doscódigos). Na Segunda Guerra Mundial, a Alemanha tinha um sistema deinformações criptografadas. A base de todo esse sistema era uma máquinaeletro-mecânica conhecida como enigma, semelhante à apresentada na figura,capaz de gerar mensagens criptografadas com enorme facilidade.
  • 23. 23 A garantia de dados secretos é à base da criptografia essencial para otráfego de informações seguras, especialmente nos dias atuais. Neste mundo capitalista e corrido de hoje em dia, onde profissionais sãopressionados a agir com velocidade, onde meios de pagamento eletrônico sãouma solução muito conveniente. As pessoas pagam suas contas e compras eletronicamente pelainternet, usando cartões de débito ou crédito, transferências de valores ousistemas eletrônicos instantâneos como PayPal. Emitir um cheque éconsiderado antiquado e arcaico por muitos, além de consumir muito tempo erepresentar custo. Pagamentos eletronicos ia internet, seguem regulamentações bancáriase governamentais restritas visando a segurança do sistema. Fraudes sãoprevenidos através do uso conjunto de tecnologia avançada e processos dedesições bem estabelecidas. Processamento de cheques eletrônicos usavárias ferramentas tecnológicas, chaves criptograficas, codificação de dados,assinaturas digitais, certificados, email seguro, e tecnologia de cartãointeligente 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 chaveprivada tiver uma cópia dela e souber a senha, a codificação é quebradaficando vulneravel os seus dados e informações. Fichas de codificação sãousadas em conjunto com a codificação da chave pública para solucionar estaabertura na segurança. Estas fichas fornecem uma maneira segura de gerar e
  • 24. 24armazenar 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 atuaisoriginou-se dos estudos de Ronald Rivest, Adi Shamir e Leonard Adleman, umtrio de Matemáticos brilhantes que mudaram a história da Criptografia. O princípio do algoritmo é construir chaves públicas e privadas utilizandonúmeros primos. Uma chave é uma informação restrita que controla toda aoperação dos algoritmos de criptografia. No processo de codificação umachave é quem dita a transformação do texto puro (original) em um textocriptografado.Chave Privada: É uma informação pessoal que permanece em posse dapessoa - 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 é atransmissão de mensagens entre Alice e Bob. Alice e Bob são personagens fictícios que precisam trocar mensagensseguras sem interceptação. O algoritmo RSA permite essa troca segura demensagens 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. 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 chaveprivada de Alice é capaz de decifrar um texto criptografado com a sua chavepública. É importante destacar que se aplicarmos a chave pública de Alice sobreo texto criptografado não teremos a mensagem original de Bob. Dessa forma,mesmo que a mensagem seja interceptada é impossível decifrá-la sem a chaveprivada de Alice.
  • 26. 264. VERIFICAÇÃO DE SEGURANÇA 4.1. Introdução Grande parte do desenvolvimento de aplicações web gira em torno darede mundial de computadores, a World Wide Web (Internet), conectando-sevia hyperlinks para englobar ambientes de aplicativos complexos e locais dearmazenamento virtuais, com a grande utilização dessas aplicações surgiramproblemas 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 dainternet para transações financeiras de grande porte, e a transação com dadossensíveis como o uso de números de cartões de crédito, pagamentos decontas, acompanhamento de informações privadas e outras informações deidentificação que trafegam através da Web atualmente, os crackers e scriptkiddies têm um grande incentivo para descobrir esses "buracos". Na maioria dos casos, é simplesmente impossível para os usuáriosgerenciar a própria segurança; os problemas são muitos complexos, oambiente é muito flexível e a maioria dos navegadores não permite que osusuários tenham acesso fácil a informações de segurança importantes. Grandeparte da responsabilidade pela segurança deve, conseqüentemente, recairsobre o desenvolvedor de aplicativos Web, que precisam codificar de formadefensiva e segura para tentar impedir problemas relacionados à segurança. O aumento na utilização de vários recursos dos navegadores modernoslevou 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. 27de ataques além de scripts; trata-se de uma técnica usada para muitos tipos deataques que tentam explorar a confiança entre um usuário e um site. O problema surge quando um site outrora confiável incorpora em sipróprio, dados dinâmicos fornecidos pelos seus usuários sem verificarcompletamente essas entradas. Usuários mal-intencionados podem exploraresse problema fornecendo dados ao site que acabam apresentando efeitoscolaterais inesperados quando esses mesmos dados forem exibidos. Essesefeitos normalmente envolvem o envio de dados ao cracker por meio de outrosite menos seguro, embora eles possam, em casos raros, usar o site em sipara transmitir as informações. Isto é, através de um código em HTML ou XML, o atacante pode usartags maliciosos que podem trazer um sério comprometimento do sistema. Umatacante pode fazer uma vítima enviar os seus dados para o programa. Então oprograma tem que estar apto a proteger a vítima dele. Além disso, o cracker pode inserir referências em Java (inclusivereferê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 exporconexões SSL-codificadas, tendo acesso locais da rede restringidos pelocliente, violando políticas de segurança de domínio, fazendo a rede ficar forado ar, inserir um worm, criando DOS (Denial Of Service), enviandosimplesmente um código JavaScript para um loop infinito de aberturas dejanelas do browser, e até mesmo ataques muito destrutivos, inserindo ataques
  • 28. 28em vulnerabilidade de segurança em linguagens de script ou buffers overflowsem browsers. Usando tags maliciosas no lugar certo, um cracker pode até mesmoenganar os usuários em revelar informação sensível, modificando ocomportamento de uma forma existente. Existem providencias que podem ser tomadas para ajudá-lo a preveniresses tipos de ataques: a) Sempre faça as entradas provenientes de fontes externas passarempor um processo de validação. Isso inclui documentos extraídos de outrossites, como sumários de notícias RSS/RDF, qualquer entrada de formulários(mesmo proveniente de campos de formulários ocultos - é trivial POSTARvalores 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 oseu validador. c) Sempre valide a entrada após decodificá-la, e não antes. Isso impedeque 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 decaracteres (charsets) padrão diferentes dependendo de diversos fatores.Foram criadas explorações que se aproveitaram da ambigüidade do charset
  • 29. 29para enviar texto aparentemente inútil em seu site que, quando exibido em umdeterminado 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ãotratadas técnicas adotadas para verificar a segurança de sistemas tanto doponto 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çãoweb 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. 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 desistemas 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. Osprogramas seguros são seguros, por concepção durante seu desenvolvimento
  • 31. 31e por padrão. Existem no mínimo 300 problemas que afetam a segurança dasaplicações Web como um todo. [OWASP] Abaixo o top 10, das falhas de segurança em uma aplicação Websegundo 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. 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. 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 geralmentefalham na hora de encriptar este tráfego pela rede. A encriptação (geralmente SSL) especialmente para páginas web comacesso a internet e conexões com back-end deve ser usada em todas asconexões autenticadas, senão, o aplicativo irá expor uma autenticação ou otoken de sessão. A autenticação deve ser utilizada sempre que dados sensíveis, assimcomo cartões de crédito, são transmitidos. Aplicações cujo modo deencriptação possa ser subvertido são alvos de ataques. Os padrões PCI requerem que todas as informações de cartões decredito que são transmitidas pela internet sejam encriptadas.
  • 34. 34 Falha na hora de encriptar informações sensíveis significa que se uminvasor 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 aescuta. Entretanto, é importante notar que eventualmente um servidor serácomprometido em praticamente qualquer rede, e que invasores instalarãorapidamente 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 desessão para cada pedido, toda autenticação do tráfego deve ir para o SSL, nãosó os pedidos de login. O uso de encriptação de informações com servidores de back-endtambém é muito importante. Mesmo que estes servidores sejam naturalmentemais seguros, as informações e as credenciais que eles carregam são maissensíveis e mais impactantes. A encriptação de informação sensível, assimcomo de cartões de crédito se tornou um regulamento financeiro e deprivacidade para várias empresas. Negligenciar o uso de SSL para o manuseiode conexões de informações cria um risco de não conformidade. [OWASP,2007] O objetivo é verificar se as aplicações encriptam corretamente toda acomunicação autenticada e sensível.
  • 35. 35 Abordagens automatizadas: ferramentas de localização devulnerabilidade podem verificar se o SSL é utilizado na interface do sistema epode localizar muitas falhas relacionadas à SSL. Entretanto, elas não têmacesso à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 algumasligações no back-end, mas provavelmente não entenderão a lógicacustomizada requerida para todos os tipos de sistemas. [OWASP, 2007] Abordagens manuais: testes podem verificar se o SSL é utilizado elocalizar muitas falhas relacionadas à SSL na interface, mas as abordagensautomatizadas são provavelmente mais eficientes. A revisão de código é muitoeficiente 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 oSSL em todas as conexões autenticadas ou em qualquer informação sensívelem transmissão. Existem inúmeros detalhes envolvendo a configuração doSSL, então é importante entender e analisar seu ambiente. Por exemplo, o IE7(internet Explorer 7) provê uma barra verde para certificados SSL altamenteconfiáveis, mas isto não é um controle apropriado que demonstre por si só ouso seguro da criptografia. [OWASP, 2007] Cuidados que devem ser observados para a proteção de dadossensíveis em sistemas de armazenamento:
  • 36. 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 parausuários não autorizados. No entanto, um usuário motivado, hábil ou apenasum 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 permitiruma solicitação uma função sensível, na qual garante que somente o usuárioautorizado acesse a respectiva função. [OWASP, 2007].
  • 37. 37 O principal método de ataque para esta vulnerabilidade é chamado de“navegação forçada” (“forced browsing”), na qual envolve técnicas deadivinhação de links (“guessing”) e força bruta (“brute force”) para acharpáginas desprotegidas. É comum que aplicações utilizem códigos de controlede acesso por toda a aplicação, resultando em um modelo complexo quedificulta 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ãoserão validadas, deixando a aplicação vulnerável. [OWASP, 2007]. Mas não é somente nos domínios da organização que dados podem serviolados. Deve-se ter um cuidado especial com a computação móvel e otrabalho remoto. Convém que seja adotada uma política formal levando emconta os riscos de trabalhar com estes recursos. Esta política deve conter osrequisitos para proteção física, controles de acesso, criptografia e etc. Énecessário que os usuários que se beneficiam deste recurso recebamtreinamento específico. (RODRIGUES, 2009) É importante que os sistemas sejam monitorados para detectardivergências entre a política de controle de acesso e os registros de eventosmonitorados, fornecendo evidências no caso de incidentes de segurança.(RODRIGUES, 2009) Registro de eventos de segurança relevantes é mantido por um períodode tempo para auxiliar em investigações futuras. (RODRIGUES, 2009)
  • 38. 38 4.4. Pesquisa de vulnerabilidades Os ataques a sistemas computacionais têm se tornado mais freqüentese cada vez mais complexos, distribuídos e em larga escala tanto através dainternet quanto dentro da própria infra-estrutura. Códigos maliciososautomatizados que trabalham de forma aleatória e pessoas com motivaçõesespecificas exploram vulnerabilidades em aplicações e fragilidades emarquiteturas de rede. Para endereçar estas ameaças efetivamente, não éprudente esperar que a exploração seja efetuada, e sim antecipar os possíveisataques de forma a aumentar o nível de segurança e estar preparadoadequadamente. [Barbato] Ataques como phishing, podem explorar várias vulnerabilidades,particularmente, XSS e problemas de autenticação e autorização. Violação deprivacidade devido à validação fraca, regras de negócio e verificações deautorizações fracas. Roubo de identidade por meio de controles de criptografiafracos ou não existentes, inclusão de arquivo remoto e autenticação, regras denegócio e verificação de autorização. Comprometimento de sistema, alteraçãode informações e destruição de dados por ataques de injeção e inclusão dearquivo remoto. Perda financeira por meio de transações não autorizadas eataques CSRF. Perda de reputação devido à exploração de qualquer uma dasvulnerabilidades anteriormente citadas. Uma vez que a organização sedistancie da preocupação de controles reativos e vai de encontro à pro-atividade na redução de riscos de seu negócio, ela melhorará a conformidadecom regimes regulatórios, reduzirá custos operacionais, e certamente terá umsistema mais robusto e seguro como resultado. (Barbato 2008)
  • 39. 39 O XSS, mencionado em parágrafos anteriores, Cross Site Scripting, é defato um subconjunto de inserções HTML. XSS é a questão de segurança emaplicações Web mais prevalente e perniciosa. Os furos XSS ocorrem emaplicações quaisquer que recebam dados originados do usuário e o envie aonavegador 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 malintencionado (malware). O script malicioso é freqüentemente em Java Script,mas qualquer linguagem de script suportada pelo navegador da vítima é umalvo potencial para este tipo de ataque. A forma de descobrir as falhas de um software é similar ao métodoutilizado 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á atraçar um rumo para melhorar a segurança de seu software. Todos os frameworks de aplicação web são vulneráveis a Cross SiteScripting (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á odado fornecido pelo usuário como retorno direto a ele: echo$_REQUEST[userinput].
  • 40. 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 umestá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 umagrande quantidade de usuários acessará entradas de outros usuários. Com ataques XSS baseados em DOM, o código Java Script do site e asvariáveis são manipulados ao invés dos elementos HTML. Alternativamente, os ataques podem ser, uma combinação dos trêstipos. O perigo com o XSS não está no tipo de ataque, mas na suapossibilidade. Comportamentos não padrão do navegador pode introduzirvetores de ataque sutis. O XSS é também potencialmente habilitado a partir dequaisquer 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 amanipular qualquer aspecto da página a ser renderizada, incluindo a adição denovos elementos, como um espaço para login que encaminha credenciais paraum site hostil, a manipulação de qualquer aspecto interno do DOM e a remoçãoou modificação de forma de apresentação da página. O Java Script permite ouso do XmlHttpRequest, que é tipicamente usado por sites que usam atecnologia 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íticado navegador conhecida como "same source origination" – assim,encaminhando dados da vítima para sites hostis e criar worms complexos e
  • 41. 41zumbis maliciosos que duram até o fechamento do navegador. Os ataquesAJAX não necessitam ser visíveis ou requerem interação com o usuário pararealizar os perigosos ataques cross site request forgery (CSRF). O objetivo é verificar que todos os parâmetros da aplicação sãovalidados e/ou recodificados antes de ser incluídos em páginas HTML. Abordagens automatizadas: ferramentas de teste de penetraçãoautomatizadas são capazes de detectar XSS de reflexão a partir de injeção deparâ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çãode autorização (como por exemplo, se um usuário fornece dados de entradasmaliciosos que são vistos posteriormente apenas pelos administradores).Ferramentas de análise de código fonte podem encontrar pontos APIs comfalhas ou perigosas, mas é comum não poderem determinar se a validação ourecodificação foram aplicadas, que pode resultar em falsos positivos. Nenhumaferramenta é capaz de encontrar XSS baseado em DOM, isso significa queaplicações em Ajax estarão sempre em risco se somente forem aplicadostestes 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 averificação demandará esforço adicional considerável. O teste demanda muitoesforço, pois a superfície de ataque da maioria das aplicações é muito grande.[OWASP]
  • 42. 42 A melhor proteção para XSS está na combinação de validação de “listabranca” de todos os dados de entrada e recodificação apropriada de todos osdados de entrada. A validação habilita a detecção de ataques e a recodificaçãoprevine qualquer injeção de script bem sucedida de ser executada nonavegador. A prevenção de XSS ao longo da aplicação como um todo requeruma abordagem arquitetural consistente. [OWASP] Validação de entrada: utilize mecanismo padrão de validação deentrada para validar todas as entradas quanto ao tamanho, tipo, sintaxe eregras 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”. Rejeiteentrada 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 dadosinválidos. [OWASP] Forte codificação de saída: garanta que qualquer dado de entrada dousuário esteja apropriadamente codificado (tanto para HTML ou XML,dependendo do mecanismo de saída) antes da renderização, usando aabordagem de codificação de todos os caracteres, com exceção de umsubconjunto 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áginaa 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. 43permita que o atacante escolha isso para seus usuários. [OWASP] Não use validação de “lista negra” para detectar XSS na entrada oucodificação de saída. A procura ou troca de poucos caracteres ("<" ">" e outroscaracteres similares ou frases como “script”) é fraco e tem sido explorado comsucesso. Mesmo uma tag “<b>” não verificada é insegura em alguns contextos.O XSS possui um conjunto surpreendente de variantes que torna simplesultrapassar validações de “lista negra” (Blacklist). [OWASP] Cuidado com os erros de conversão. As entradas devem serdecodificadas e convertidas para a representação interna corrente antes de servalidada. Certifique-se que sua aplicação não decodifica a mesma entradaduas vezes. Tais erros podem ser usados para ultrapassar esquemas de “listabranca” 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çãocriptográfica tem mecanismos de chaves corretamente implementados, noponto de vista de segurança, é muito importante que se tenham profissionaistreinados em identificar problemas relacionados à segurança, do que umnúmero grande de ferramentas especifica para isso. Isto porque alguns errosde segurança são difíceis de encontrar, e algumas vezes são considerados“soluções normais” pela maioria dos desenvolvedores. Por exemplo, autilização de variáveis globais em linguagens de programação para aplicaçõesweb é uma solução, que vários desenvolvedores consideraram, válida.
  • 44. 44 Levou algum tempo até que olhos treinados em segurançaidentificassem o problema e, lentamente, isso fosse se tornando uma práticaesquecida. O ponto é procurar problemas de segurança em código requerolhos que estejam especificamente procurando por erros e saibam como osidentificar. Existem várias ferramentas que podem ajudar no processo de revisão,logicamente nada é melhor que alguém ativamente analisando o código embusca de problemas, mas, ferramentas podem ajudar a apontar os erros maisgritantes e facilitar o trabalho de quem está fazendo a revisão. Nada substituiolhos ativamente revisando o código, ferramentas ajudam, mas nunca devemsubstituir o fator humano. O processo pode ser inclusive automatizado nosistema 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 ataquescomuns a aplicações web. A implantação de uma rotina de revisão de códigopode ser automatizada e se realizada desde o início do projeto é um trabalhonão muito pesado. Algumas ferramentas que podem ajudar na pesquisa detestes de segurança em aplicações são citadas abaixo. O Nessus é uma ferramenta de pesquisa remota de vulnerabilidadespara sistemas Linux, BSD, Solaris e outros Unixes. O seu funcionamento ébaseado em plugins, possui uma interface GTK e efectua mais de 1200verificações remotas de segurança. Produz relatórios em HTML, XML, LaTeX etexto simples que indicam as vulnerabilidades detectadas e os passos quedevem ser seguidos para elimina-los.
  • 45. 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 efetuaraná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 paradetectar diversos ataques e sondas, nomeadamente transbordamentos dememória (buffer overflows), levantamentos furtivos (stealth) de portos detransporte, ataques usando CGI, sondas para SMB, tentativas de identificaçãode sistemas operacionais, etc. O Snort usa uma linguagem flexível baseada emregras para descrever o tráfego que deverá ser considerado ou não paraposterior análise. Vários profissionais da área de segurança de dados sugeriram que aConsole de Análise de Bases de Dados de Intrusões (Analysis Console forIntrusion Databases, ACID) fosse usada com o Snort. GFI LANguard: Um pesquisador de problemas de segurança comercialpara Windows, o LANguard analisa redes e produz relatórios com informaçãoque inclui quais os nível de atualização (Service Packs level) do sistema decada máquina, as correções de falha de segurança , os recursos partilhadosdisponíveis, serviços/aplicações disponíveis no computador, entradas-chave doregisto (registry), senhas fracas, utilizadores e grupos e mais ainda. Osresultados da análise são apresentados num relatório em HTML, que pode seradaptado/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 permitedetectar muitos problemas de segurança, nomeadamente a presença de CGI
  • 46. 46perigosos. Libwhisker é uma biblioteca de perl (usada pelo Whisker) quepermite a criação de inspetores de HTTP específicos. Pretende-se auditar maisdo que servidores HTTP. Retina: pesquisador de vulnerabilidades comercial da eEye. Tal como oNessus e o ISS Internet Scanner previamente mencionados, a função doRetina é a de procurar vulnerabilidades em todas as máquinas de uma rede ede produzir um relatório de avaliação sobre as mesmas.
  • 47. 475. PROTEÇÃO 5.1. Introdução A Informação é tudo que pode ser armazenado ou transferindodestinado a um propósito e sendo de utilidade ao ser humano. A informaçãodigital pode ser visualizada de diversas maneiras, à medida que ela circula porvários ambientes, percorrendo diversos fluxos de trabalho, podendo serarmazenada para os variados fins, possibilidade ela ser lida, alterado eexcluída. A Segurança da informação é um conjunto de medidas que têm porobjetivo proteger e preservar informações de sistemas de informações,assegurando-lhes integridade, disponibilidade, não repúdio, autenticidade econfidencialidade. Esses elementos constituem os cinco pilares da proteção dasegurança da informação e logo são essenciais para assegurar a integridade ea confiabilidade em sistemas de informações. Os componentes criptográficosda segurança da informação cuidam da confidencialidade, integridade eautenticidade. Vale ressaltar que o uso dos pilares é feito de acordo com asnecessidades específicas de cada organização, que pode ir de certo nível deameaças a quaisquer outras decisões de gestão de riscos. Esses pilares sãoessenciais no mundo atual, onde se tem ambientes públicos e privadosconectados a nível mundial. Assim, é necessário dispor de uma tática, levandoem conta os pilares usados pela segurança de informação, com o objetivo decompor uma arquitetura de segurança que venha unificar os propósitos detodos eles.
  • 48. 48 Hoje em dia, onde conhecimento e informação e criptografia são fatoresde muita importância para qualquer organização ou nação, para que suasinformações e dados sensíveis sejam bem protegidos, a segurança dainformação é um pré-requisito para todo e qualquer sistema de informações. Uma proteção bem elaborada oferece suporte à prevenção de revelaçãonão autorizada de informações, além de manter os dados e recursos ocultos ausuários sem privilégio de acesso. A integridade trata que a modificação nãoautorizada de informações. As ameaças podem ser de diversos tipos, elas são, geralmente,classificadas como ativa, passiva, maliciosa, não maliciosa. Para combateressas ameaças, torna-se necessário a definição de políticas e mecanismos deseguranç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 desegurança; Recuperação – mecanismo para interromper a ameaça, avaliar e reparardanos, além de manter a operacionalidade do sistema caso ocorra invasão aosistema. 5.2. Mecanismos de segurança O suporte para as recomendações de segurança pode ser encontradoem:
  • 49. 49 Controles físicos: são barreiras que limitam o contato ou acesso direto ainformação ou a infra-estrutura, que garante a existência da informação que asuporta. 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 ainformação, que está em ambiente controlado, geralmente eletrônico, e que, deoutro modo, ficaria exposta a alteração não autorizada por elemento malintencionado. Existem mecanismos de segurança que apóiam os controleslógicos: Mecanismos de criptografia, que permitem a transformação reversível dainformaçã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 dedados não criptografados, produzir uma seqüência de dados criptografados. Aoperação inversa é a decifração. Assinatura digital: Um conjunto de dados criptografados, associados aum documento do qual são função, garantindo a integridade do documentoassociado, mas não a sua confidencialidade. Mecanismos de garantia da integridade da informação: Usando funçõesde "Hashing" ou de checagem, consistindo na adição. Mecanismos de controle de acesso: Palavras-chave, sistemasbiométricos, firewalls, cartões inteligentes. Mecanismos de certificação: Atesta a validade de um documento.
  • 50. 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 deimpedir a ação de um cracker, de um spammer, ou de qualquer agente externoestranho ao sistema, enganando-o, fazendo-o pensar que esteja de fatoexplorando uma vulnerabilidade daquele sistema. Protocolos seguros: uso de protocolos que garantem um grau desegurança e usam alguns dos mecanismos citados aqui existe hoje em dia umelevado 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 deuma determinada informação (ex: a senha de um usuário ou administrador desistema) permitindo com que sejam expostas informações restritas as quaisseriam acessíveis apenas por um determinado grupo de usuários. Perda de Integridade: aconteceria quando uma determinadainformação fica exposta a manuseio por uma pessoa não autorizada, queefetua alterações que não foram aprovadas e não estão sob o controle doproprietário (corporativo ou privado) da informação.
  • 51. 51 Perda de Disponibilidade: acontece quando a informação deixa deestar acessível por quem necessita dela. Seria o caso da perda decomunicação com um sistema importante para a empresa, que aconteceu coma queda de um servidor ou de uma aplicação crítica de negócio, queapresentou uma falha devido a um erro causado por motivo interno ou externoao 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, estaspodem vir de agentes maliciosos, muitas vezes conhecidos como crackers,(hackers não são agentes maliciosos, pois tentam ajudar a encontrar possíveisfalhas). Estas pessoas são motivadas para fazer esta ilegalidade por váriosmotivos. Os principais são: notoriedade, auto-estima, vingança e o dinheiro. Deacordo com pesquisa elaborada pelo CSI (Computer Security Institute), mais de70% dos ataques partem de usuários legítimos de sistemas de informação(Insiders), o que motiva corporações a investir largamente em controles deseguranç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ívelde 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 desegurança devem ser quantificados os custos associados aos ataques e osassociados à implementação de mecanismos de proteção para minimizar aprobabilidade de ocorrência de um ataque.
  • 52. 52 Segurança física: Considera as ameaças físicas como incêndios,desabamentos, relâmpagos, alagamento, acesso indevido de pessoas, formainadequada 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íticade segurança consiste num conjunto formal de regras que devem ser seguidaspelos utilizadores dos recursos de uma organização. As políticas de segurança devem ter implementação realista, e definirclaramente as áreas de responsabilidade dos utilizadores, do pessoal degestão de sistemas e redes e da direção. Deve também adaptar-se aalterações na organização. As políticas de segurança, definem procedimentosde segurança adequados, processos de auditoria à segurança e estabelecemuma base para procedimentos legais na sequência de ataques. O documento que define a política de segurança deve deixar de foratodos 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 umdocumento de fácil leitura e compreensão, além de resumido. Algumas normas definem aspectos que devem ser levados emconsideração ao elaborar políticas de segurança. Entre essas normas estão aBS 7799 (elaborada pela British Standards Institution) e a NBR ISO/IEC 17799
  • 53. 53(a versão brasileira desta primeira). A ISO começou a publicar a série denormas 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: aproibitiva - 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 quandoo usuário necessitar possa usar. Dados críticos devem estar disponíveisininterruptamente. A Utilização: o sistema deve ser utilizado apenas para os determinadosobjetivos. A Integridade: o sistema deve estar sempre íntegro e em condições deser usado. A Autenticidade: o sistema deve ter condições de verificar a identidadedos usuários, e este ter condições de analisar a identidade do sistema. A Confidencialidade: dados privados devem ser apresentados somenteaos donos dos dados ou ao grupo por ele liberado. ( Segadas, 2009 )
  • 54. 546. CONCLUSÃO O mundo de hoje fornece mecanismos facilitadores para adquirirprodutos e esse fato nos faz acreditar que podemos comprar soluções desegurança prontas para atender a nossa demanda. Nem sempre o que nósestamos procurando pode ser encontrado em prateleiras de lojas deinformática e também não podemos simplesmente gerar uma receita debolo na forma de algoritmo. Técnicas e procedimentos mais eficazes são desenvolvidos comotentativa de utilização de ferramentas na área de criptografia e chavesdigitais, atualmente conhecidos para a construção de mecanismoscriptográficos de dados digitais e de meios para que sejam integrados emsistemas de informação que queiram ser protegidos. Algumas áreas de conhecimento são diretamente correlacionadascom o nosso assunto de criptografia e chaves digitais. Podemos citar oconhecimento de aritmética modular (aritmética dos processadores digitais),do funcionamento básico de sistemas operacionais, conhecimento em redesde computadores e também noção de complexidade de algoritmos. Criptografia é uma especialização da matemática e engenharia queoferecem técnicas de proteção a mecanismos de acesso e a integridade dedados, e também de ferramentas para avaliação da eficácia dessastécnicas. Estas técnicas e ferramentas são relacionadas no sentido sintáticoe não podemos atribuir confiança no sentido semântico nas informaçõesdos dados veiculados.
  • 55. 55 Para uma boa política de segurança, esses três itens devem serrespeitados: • 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 deSeguranç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 é importantetambém saber o que fazer quando se ocorre algum problema nãoplanejado. Podemos citar algumas salvaguardas não computacionaisabaixo: • Segurança física - controle de acesso físico, blindagem, etc. • Segurança funcional - recrutamento, treinamento, motivação.
  • 56. 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árioatual. O aumento no número de aplicações, a distribuição dessas aplicaçõesatravés do uso maciço de redes de computadores e o número crescente deataques a esses sistemas retrata essa preocupação e justifica o esforço empesquisas voltadas a essa área. Novos mecanismos, técnicas mais eficientes enormas internacionais para a gestão da segurança da informação, sãoconstantemente desenvolvidos, incentivados por organismos governamentais eempresas preocupadas com o atual estágio de fragilidade da maioria dasinstalações computacionais. A disponibilidade dessas novas ferramentas, no entanto, não temrepresentado um aumento equivalente no nível de segurança dasorganizações, retrato, principalmente, da falta de uma abordagem correta naseleção e implementação dessas técnicas. A maioria dos profissionaisresponsáveis pela gerência de segurança, oriundos principalmente da área decomputação, possui uma formação técnica que os leva a partir da seleção demecanismos sem considerar as reais necessidades da organização. Essaprática causa distorções que vão desde o gasto desnecessário commecanismos desproporcionais ao problema enfrentado até a falta de proteção
  • 57. 57às informações realmente importantes, problemas abordados como pontoprincipal neste curso. Segurança é um atributo muito complexo e difícil de implementarconsistentemente em um sistema, principalmente em ambientescomputacionais. Projetar e implementar um sistema visando segurançasignifica analisar um conjunto complexo de situações adversas onde oprojetista e um oponente elaboram estratégias de modo completamenteindependente. O resultado desta análise depende fortemente das escolhas etécnicas feitas por cada um dos oponentes. Outra característica marcante é que segurança é essencialmente umatributo negativo. É fácil caracterizar um sistema inseguro, mas não existe umametodologia capaz de provar que um sistema é seguro. Assim, um sistema éconsiderado seguro se não foi possível, até o momento atual, determinar umamaneira de torná-lo inseguro. Com muita freqüência isto decorre simplesmente do fato que não foramtestados 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 umprédio sem planejar antecipadamente cada detalhe, é impossível pensar emsegurança como um apanhado de ferramentas dispostas sem uma avaliaçãoprévia, levando em consideração vulnerabilidades, riscos, importância dos bense relação custo/benefício. Isso representa a conjugação de três critériosfundamentais: política, cultura e mecanismos de segurança. O desequilíbrio
  • 58. 58causado pela falência de algum desses três aspectos pode representar aqueda significativa no nível de segurança esperado, cenário comum em muitasinstalações atuais. A política de segurança dita os princípios e as regras que regem asegurança da informação, importante para balizar a escolha de mecanismos ea adoção de procedimentos relacionados ao assunto. A cultura de segurança éum dos aspectos mais delicados e está ligada ao treinamento econscientização de todos os envolvidos no processo computacional, sejam elesfuncionários, técnicos ou mesmo acadêmicos. Sem essa preocupação,qualquer estratégia de segurança será ineficaz pela simples razão de estarsuscetível a ataques que explorem tal fragilidade, como os conhecidos ataquesde engenharia social, por exemplo. Por fim, mas não menos importante, osmecanismos de segurança garantem o cumprimento da política de segurançatraçada, e devem estar alinhados com as exigências da mesma. O grande problema observado atualmente é o excessivo enfoque emmecanismos de segurança, causando distorções já citadas e, em muitos casos,uma falsa sensação de segurança. Sistemas operacionais são selecionadossegundo características meramente comerciais, firewalls são mal configuradose instalados em pontos pouco eficazes e sistemas de detecção de intrusão sãocomprados e instalados sem um conhecimento mínimo da realidade de talorganização, entre outros problemas. Escolhas equivocadas como essas estãoligadas ao despreparo que a maioria dos profissionais responsáveis pelaadministraçã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. 59conhecimentos em mecanismos de segurança: é preciso levar emconsideração a política e a cultura de segurança. Isso reforça a importância de profissionais que tenham uma boa noçãode todos os aspectos que permeiam a verdadeira segurança, encarando-acomo uma política global dentro de uma organização e não como atitudesisoladas e mal planejadas. Além disso, vale ressaltar a importância daexperiência quando o assunto é segurança, o que pode ser adquirido com otempo ou através do contato com exemplos e situações práticas na criação depolíticas, no estabelecimento de uma cultura e na implementação demecanismos adequados.
  • 60. 607. 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. 618. 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/