Owasp Top 10 2007 PT-BR - Seguranca Web

OWASP TOP 10
As 10 vulnerabilidades de segurana mais crticas em aplicaes WEB
2007
VERSO: PORTUGUS (BRASIL)
2002-2007 OWASP Foundation O contedo deste documento licenciado pela licena Creative Commons Attribution-ShareAlike 2.5.
OWASP TOP TEN 2007
Notas da verso Esta verso do Top 10 2007 foi desenvolvida como parte das atividades do captulo Brasil da OWASP em prol da comunidade de desenvolvedores e de segurana do Brasil. Participaram desta traduo:
Cleber Brando Clebeer - Analista de Controle de Qualidade - BRconnection Fabricio Ataides Braz Leonardo Cavallari Militelli Especialista de Segurana - E-val Tecnologia Marcos Aurlio Rodrigues - Analista Segurana - BRconnection Myke Hamada Rodrigo Montoro Sp0oKer - Analista Segurana - BRconnection
Para saber mais sobre os eventos e atividades desenvolvidas pelo captulo Brasil, acesse o site ou cadastre-se na lista de discusso OWASP-BR.
OWASP TOP TEN 2007 NDICE
ndice ............................................................................................................................................................. 2 Introduo..................................................................................................................................................... 3 Sumrio ......................................................................................................................................................... 4 Metodologia .................................................................................................................................................. 5 A1 Cross Site Scripting................................................................................................................................ 8 A2 Falhas de Injeo ................................................................................................................................ 11 A3 Execuo Maliciosa de Arquivo .......................................................................................................... 13 A4 Referncia Insegura Direta a objeto ................................................................................................... 16 A5 Cross Site Request Forgery (CSRF) ...................................................................................................... 18 A6 Vazamento de Informaes e Tratamento de erros inapropriado..................................................... 21 A7 Furo de Autenticao e Gerncia de Sesso....................................................................................... 23 A8 Armazenamento criptogrtafico inseguro............................................................................................ 25 A9 Comunicaes Inseguras..................................................................................................................... 27 A10 Falha ao Restringir Acesso URLs .................................................................................................... 29 Aonde ir a partir daqui ................................................................................................................................ 31 Referncias.................................................................................................................................................. 33
OWASP TOP TEN 2007
INTRODUO Bem vindo ao OWASP TOP 10 2007! Esta edio completamente reescrita lista as mais srias vulnerabilidades em aplicaes WEB, discute como se proteger contra elas e prov links para mais detalhes. OBJETIVO O objetivo principal do OWASP TOP 10 educar desenvolvedores, designers, arquitetos e organizaes a respeito das conseqncias das vulnerabilidades mais comuns encontradas em aplicaes WEB. O TOP 10 prov mtodos bsicos para se proteger dessas vulnerabilidades um timo comeo para a codificao segura de um programa de segurana. Segurana no um evento nico. No suficiente considerar a segurana de cdigo uma nica vez. Em 2008, esse Top 10 ser modificado e, caso no mude uma linha do cdigo de sua aplicao, voc poder estar vulnervel. Portanto, revise as dicas em Where to go from here para mais detalhes. Uma iniciativa de codificao segura deve abordar todos os estgios do ciclo de vida de um programa. As aplicaes WEB seguras so possveis apenas quando um SDLC seguro utilizado. Os programas seguros so seguros por concepo, durante seu desenvolvimento e por padro. Existem no mnimo 300 problemas que afetam a segurana das aplicaes WEB como um todo. Estes 300 ou mais so detalhados no Guia OWASP, cuja leitura essencial para qualquer um que se interesse por desenvolver aplicaes WEB. Este documento , primeiramente, um recurso de estudo, no um padro. No adote este documento como uma poltica ou padro sem falar conosco primeiro! Se voc precisa de uma poltica de codificao e desenvolvimento seguro, a OWASP possui este tipo de documentos alm de projetos de padronizao em andamento. Por favor, considere a possibilidade de se associar ou sustentar financeiramente estas iniciativas. AGRADECIMENTOS Ns gostaramos de agradecer o MITRE por tornar pblico e gratuitamente os dados da Vulnerability Type Distribution no CVE. O projeto OWASP Top 10 liderado e patrocinado pela Aspect Security. Lider do projeto: Andrew van der Stock (Diretor Executivo, OWASP Foundation) Coautores: Jeff Williams (Chair, OWASP Foundation), Dave Wichers (Conference Chair, OWASP Foundation). Ns gostaramos de agradecer nossos revisores:
Raoul Endres por ajudar em manter o Top 10 ativo novamente e por seus valiosos comentrios Steve Christey (MITRE) por sua extensiva reviso e adio das informaes do MITRE CWE Jeremiah Grossman (White Hat Security) pelas revises e contribuies valiosas sobre as formas automatizadas de deteco. Sylvan Von Stuppe por sua reviso exemplar Colin Wong, Nigel Evans, Andre Gironda, Neil Smithline pelos comentrios enviados por email.
OWASP TOP TEN 2007 SUMRIO

A1 Cross Site Scripting (XSS)
Os furos XSS ocorrem sempre que uma aplicao obtm as informaes fornecidas pelo usurio e as envia de volta ao navegador sem realizar validao ou codificao daquele contedo. O XSS permite aos atacantes executarem scripts no navegador da vtima, o qual pode roubar sesses de usurio, pichar sites Web, introduzir worms, etc. As falhas de injeo, em especial SQL Injection, so comuns em aplicaes Web. A injeo ocorre quando os dados fornecidos pelo usurio so enviados a um interpretador com parte do comando ou consulta. A informao maliciosa fornecida pelo atacante engana o interpretador que ir executar comandos mal intencionados ou manipular informaes. Os cdigos vulnerveis incluso remota de arquivos (RFI) permite ao atacante incluir cdigo e dados maliciosos, resultando em ataques devastadores, como o comprometimento total do servidor. Os ataques de execuo de arquivos maliciosos afeta PHP, XML e todos os frameworks que aceitem nomes de arquivo ou arquivos dos usurios.
A2 Falhas de Injeo
A3 Execuo maliciosa de arquivos
A4 Referncia Insegura Direta Uma referncia direta objeto ocorre quando um desenvolvedor expe a referncia a um objeto implementado internamente, como o caso de arquivos, diretrios, registros da Objetos
base de dados ou chaves, na forma de uma URL ou parmetro de formulrio. Os atacantes podem manipular estas referncias para acessar outros objetos sem autorizao.
A5 Cross Site Request Forgery Um ataque CSRF fora o navegador da vtima, que esteja autenticado em uma aplicao, a enviar uma requisio pr-autenticada um servidor Web vulnervel, que por sua vez (CSRF)
fora o navegador da vtima a executar uma ao maliciosa em prol do atacante. O CSRF pode ser to poderoso quanto a aplicao Web que ele ataca.
A6 Vazamento de Informaes e Tratamento de Erros Inapropriado A7 Autenticao falha e Gerenciamento de Sesso A8 Armazenamento Criptogrfico Inseguro
As aplicaes podem divulgar informaes sobre suas configuraes, processos internos ou violar a privacidade por meio de uma srie de problemas na aplicao, sem haver qualquer inteno. Os atacantes podem usar esta fragilidade para roubar informaes consideradas sensveis ou conduzir ataques mais estruturados. As credenciais de acesso e token de sesso no so protegidos apropriadamente com bastante freqncia. Atacantes comprometem senhas, chaves ou tokens de autenticao de forma a assumir a identidade de outros usurios. As aplicaes Web raramente utilizam funes criptogrficas de forma adequada para proteo de informaes e credenciais. Os atacantes se aproveitam de informaes mal protegidas para realizar roubo de identidade e outros crimes, como fraudes de cartes de crdito. As aplicaes freqentemente falham em criptografar trfego de rede quando se faz necessrio proteger comunicaes crticas/confidenciais. Frequentemente, uma aplicao protege suas funcionalidades crticas somente pela supresso de informaes como links ou URLs para usurios no autorizados. Os atacantes podem fazer uso desta fragilidade para acessar e realizar operaes no autorizadas por meio do acesso direto s URLs.
A9 Comunicaes inseguras
A10 Falha de Restrio de Acesso URL
Tabela 1: TOP 10 vulnerabilidade de aplicaes Web para 2007
OWASP TOP TEN 2007 METODOLOGIA Nossa metodologia para o TOP 10 de 2007 foi simples: pegamos o estudo de Tendncia de Vulnerabilidades para 2006 do MITRE e extramos as 10 principais vulnerabilidade relativas aplicaes Web. O resultado apresentado a seguir:
Figura 1: Dados do MITRE para as Top 10 vulnerabilidades de aplicaes Web para 2006
Apesar da tentativa de preservao do mapeamento um a um das estatsticas de vulnerabilidades do MITRE para nomear cada seo do documento, ns mudamos deliberadamente algumas categorias com o intuito de mapear de forma mais apropriada as causas principais. Se voc est interessado nas estatsticas finais originais do MITRE, ns inclumos uma planilha Excel na pgina do projeto OWASP Top 10. Todas as recomendaes de proteo provm solues para os trs mais prevalentes frameworks de aplicao Web: Java EE, ASP .NET e PHP. Outros frameworks utilizados, como Ruby on Rails e Perl podem adaptar facilmente as recomendaes para satisfazer necessidades especficas. POR QUE NS DESCARTAMOS ALGUNS PROBLEMAS IMPORTANTES Entrada de dados no validados o maior desafio para qualquer time de desenvolvimento e a origem dos problemas de segurana de muitas aplicaes. De fato, muitos dos itens presentes na lista recomendam a validao de entrada como parte da soluo. Ns recomendamos criar um mecanismo de validao centralizado como parte de sua aplicao. Para maiores informaes, leia os seguintes documentos de validao de dados da OWASP:
http://www.owasp.org/index.php/Data_Validation http://www.owasp.org/index.php/Testing_for_Data_Validation
Problemas de estouro de pilhas, estouro de inteiros e formato de strings so vulnerabilidades extremamente srias para programas escritos em linguagem C ou C++. A remediao para estes tipos de problemas so tratados por comunidades de segurana de aplicaes tradicionais, como o SANS, CERT e pelos fornecedores de linguagem de programao. Se o seu cdigo escrito em uma linguagem que passvel a estouros de pilha, ns encorajamos voc a ler os contedos a este respeito no site da OWASP: 5
OWASP TOP TEN 2007

http://www.owasp.org/index.php/Buffer_overflow http://www.owasp.org/index.php/Testing_for_Buffer_Overflow
Gerenciamento de configurao insegura afeta todos os sistemas em alguma extenso, particularmente o PHP. No entanto, o ranking do MITRE no nos permite incluir este problema neste ano. Quando implementando sua aplicao, voc deve consultar a ltima verso do OWASP Guide e o OWASP testing Guide para informaes detalhadas a respeito do gerenciamento de configurao segura e testes:
http://www.owasp.org/index.php/Configuration http://www.owasp.org/index.php/Testing_for_infrastructure_configuration_management
POR QUE NS ADICIONAMOS ALGUNS PROBLEMAS IMPORTANTES Cross Site Request Forgery (CSRF) a maior nova incluso nesta edio do OWASP Top 10. Embora ocupe a 36 posio na classificao original, ns acreditamos que ela seja de tamanha importncia, que as aplicaes devem iniciar seus esforos de proteo hoje, particularmente para aplicaes de alto risco e criticidade. O CSRF mais prevalente do que sua atual classificao e pode ser mais perigoso. Criptografia. O uso incorreto da criptografia no ocupam as posies 8 e 9 da classificao, conforme as informaes do MITRE, porm representam a origem de muitos problemas de quebra de privacidade e conformidade (particularmente a conformidade com o PCI DSS 1.1). VULNERABILIDADES, NO ATAQUES A edio anterior do Top 10 continha um misto de ataques, vulnerabilidades e contramedidas. Esta vez, ns focamos unicamente em vulnerabilidades, embora a terminologia utilizada comumente combine vulnerabilidades e ataques. Se organizaes usam este documento para tornar suas aplicaes seguras e, consequentemente, reduzir o risco para seus negcios, ser possvel observar uma reduo direta nos seguintes pontos: Ataques de phishing, que podem explorar qualquer uma dessas vulnerabilidades, particularmente, XSS e problemas de autenticao e autorizao (A1,A4,A7,A10) Violao de privacidade devido validao fraca, regras de negcio e verificaes de autorizao fracas (A2, A4, A6, A7, A10) Roubo de identidade por meio de controles de criptografia fracos ou no existentes (A8 e A9), incluso de arquivo remoto (A3) e autenticao, regras de negcio e verificao de autorizao (A4, A7, A10) Comprometimento de sistema, alterao de informaes e destruio de dados por ataques de injeo (A2) e incluso de arquivo remoto (A3) Perda financeira por meio de transaes no autorizadas e ataques CSRF (A4, A5, A7, A10) Perda de reputao devido explorao de qualquer uma das vulnerabilidades acima (A1 A10) Uma vez que a organizao se distancie da preocupao de controles reativos e vai de encontro pro atividade na reduo de riscos de seu negcio, ela melhorar a conformidade com regimes regulatrios, reduzir custos operacionais, e certamente ter um sistema mais robusto e seguro como resultado. DIRECIONAMENTO A metodologia descrita acima necessariamente direciona o Top 10 a favor das descobertas da comunidade de pesquisadores de segurana. A forma de descoberta de falhas similar ao mtodo utilizado em ataques reais, em especial, no que se refere pseudo-atacantes (script kiddies). Protegendo sua aplicao contra as vulnerabilidades do Top 10 prover uma proteo mdica contra as formas mais comuns de ataque e mais, ajudar a traar um rumo para melhoria da segurana de seu software. 6
OWASP TOP TEN 2007 MAPEAMENTO Nesta verso do Top 10 houve mudanas nos ttulos das vulnerabilidades, mesmo quando o contedo se relaciona fortemente ao contedo anterior. Ns no utilizamos mais o esquema de nomenclatura WAS XML pelo fato deste no se manter atualizado com as vulnerabilidades modernas, ataques e contramedidas. A tabela abaixo representa como esta edio se relaciona com o Top 10 2004 e a classificao do MITRE:
Classificao do MITRE 2006 1 2 3 A2. Controle de Acesso Falho (dividido no TOP 10 2007) 5
OWASP Top 10 2007 A1. Cross Site Scripting (XSS) A2. Falhas de Injeo A3. Execuo Maliciosa de Arquivos (NOVO) A4. Referncia Insegura Direta Objetos
OWASP Top 10 2004 A1. Cross Site Scripting (XSS) A6. Falhas de Injeo
A5. Cross Site Request Forgery (CSRF) (NOVO) A6. Vazamento de Informaes e Tratamento de Erros Inapropriados A7. Falha de Autenticao e Gerenciamento de Sesso A8. Armazenamento Criptogrfico Inseguro A9. Comunicaes inseguras A7. Tratamento inapropriado de erros
36 6
A3. Falha de Autenticao e Gerenciamento de Sesso A8. Armazenamento Inseguro Discutido em A10. Gerenciamento Inseguro de Configurao A2. Controle de Acesso Falho (dividido no TOP 10 2007) A1. Entrada no Validada A5. Estouro de buffer A9. Negao de Servio A10. Gerenciamento Inseguro de Configurao
14
8 8
A10. Falha de Restrio de Acesso URL
14
<Removido em 2007> <Removido em 2007> <Removido em 2007> <Removido em 2007>
7 4, 8, e 10 17 29
Tabela 2: Relacionamento das vulnerabilidades das edies 2004 e 2007 do Top 10 e a classificao do MITRE.
OWASP TOP TEN 2007 A1 CROSS SITE SCRIPTING O Cross Site Scripting, mais conhecido como XSS, de fato um subconjunto de inseres HTML. XSS a questo de segurana em aplicaes web mais prevalente e perniciosa. Os furos XSS ocorrem em aplicaes quaisquer que receba dados originados do usurio e o envie ao navegador sem primeiramente validar ou codificando aquele contedo. O XSS permite atacantes executarem script no navegador da vtima, que pode seqestrar sesses de usurios, desfigurar web sites, inserir contedo hostil, conduzir ataques de roubo de informaes pessoais (phishing) e obter o controle do navegador do usurio usando um script mal intencionado (malware). O script malicioso freqentemente em Java Script, mas qualquer linguagem de script suportada pelo navegador da vtima um alvo potencial para este ataque. AMBIENTES AFETADOS Todos os frameworks de aplicao web so vulnerveis a Cross Site Scripting (XSS). VULNERABILIDADE Existem trs tipos bem conhecidos de XSS: refletido, armazenado e insero DOM. O XSS refletido o de explorao mais fcil uma pgina refletir o dado fornecido pelo usurio como retorno direto a ele:
echo $_REQUEST['userinput'];
O XSS armazenado recebe o dado hostil, o armazena em arquivo, banco de dados ou outros sistemas de suporte informao e ento, em um estgio avanado mostra o dado ao usurio, no filtrado. Isto extremamente perigoso em sistemas como CMS, blogs ou fruns, onde uma grande quantidade de usurios acessar entradas de outros usurios. Com ataques XSS baseados em DOM, o cdigo Java Script do site e as variveis so manipulados ao invs dos elementos HTML. Alternativamente, os ataques podem ser uma mistura ou uma combinao dos trs tipos. O perigo com o XSS no est no tipo de ataque, mas na sua possibilidade. Comportamentos no padro do navegador pode introduzir vetores de ataque sutis. O XSS tambm potencialmente habilitado a partir de quaisquer componentes que o browser utilize. Os ataques so freqentemente implementados em Java Script, que uma ferramenta poderosa de scripting. O uso do Java Script habilita atacante a manipular qualquer aspecto da pgina a ser renderizada, incluindo a adio de novos elementos (como um espao para login que encaminha credenciais para um site hostil), a manipulao de qualquer aspecto interno do DOM e a remoo ou modificao de forma de apresentao da pgina. O Java Script permite o uso do XmlHttpRequest, que tipicamente usado por sites que usam a tecnologia AJAX, mesmo se a vtima no use o AJAX no seu site. O uso do XmlHttpRequest permite, em alguns casos, contornar a poltica do navegador conhecida como "same source origination" assim, encaminhando dados da vtima para sites hostis e criar worms complexos e zumbis maliciosos que duram at o fechamento do navegador. Os ataques AJAX no necessitam ser visveis ou requerem interao com o usurio para realizar os perigosos ataques cross site request forgery (CSRF) (vide A-5). VERIFICAO DE SEGURANA O objetivo verificar que todos os parmetros da aplicao so validados e/ou recodificados antes de ser includos em pginas HTML.
OWASP TOP TEN 2007 Abordagens automatizadas: ferramentas de teste de penetrao automatizadas so capazes de detectar XSS de reflexo a partir de injeo de parmetro, mas freqentemente falha na localizao de XSS persistente, particularmente se a sada do vetor de injeo XSS prevenida via verificao de autorizao (como por exemplo, se um usurio fornece dados de entradas maliciosos que so vistos posteriormente apenas pelos administradores). Ferramentas de anlise de cdigo fonte podem encontrar pontos APIs com falhas ou perigosas, mas comum no poderem determinar se a validao ou recodificao foram aplicadas, que pode resultar em falsos positivos. Nenhuma ferramenta capaz de encontrar XSS baseado em DOM, isso significa que aplicaes em Ajax estaro sempre em risco se somente forem aplicados testes automatizados. Abordagens manuais: caso um mecanismo centralizado de validao e recodificao for usado, a maneira mais eficiente de verificar a segurana verificar o cdigo. Se uma implementao distribuda for usada, ento a verificao demandar esforo adicional considervel. O teste demanda muito esforo, pois a superfcie de ataque da maioria das aplicaes muito grande. PROTEO A melhor proteo para XSS est na combinao de validao de lista branca de todos os dados de entrada e recodificao apropriada de todos os dados de entrada. A validao habilita a deteco de ataques e a recodificao previne qualquer injeo de script bem sucedida de ser executada no navegador. A preveno de XSS ao longo da aplicao como um todo requer uma abordagem arquitetural consistente.
Validao de entrada: utilize mecanismo padro de validao de entrada para validar todas as entradas quanto ao tamanho, tipo, sintaxe e regras de negcio antes de aceitar que o dado seja mostrado ou armazenado. Use uma estratgia de validao aceite o conhecido como bom. Rejeite entrada invlida ao invs da tentativa de corrigir dados potencialmente hostis. No se esquea que as mensagens de erro podem tambm incluir dados invlidos. Forte codificao de sada: garanta que qualquer dado de entrada do usurio esteja apropriadamente codificado (tanto para HTML ou XML dependendo do mecanismo de sada) antes da renderizao, usando a abordagem de codificao de todos os caracteres, com exceo de um subconjunto muito limitado. Esta a abordagem da biblioteca Microsoft Anti-XSS e a biblioteca prevista OWASP PHP Anti-XSS. Adicionalmente, configure a codificao de caracteres para cada pgina a ser produzida como sada, que diminuir a exposio a algumas variaes. Especifique a codificao de sada (como ISO 8859-1 ou UTF-8): No permita que o atacante escolha isso para seus usurios. No use validao de lista negra para detectar XSS na entrada ou codificao de sada. A procura ou troca de poucos caracteres ("<" ">" e outros caracteres similares ou frases como script) fraco e tem sido explorado com sucesso. Mesmo uma tag <b> no verificada insegura em alguns contextos. O XSS possui um conjunto surpreendente de variantes que torna simples ultrapassar validaes de lista negra (Blacklist). Cuidado com os erros de converso. As entradas devem ser decodificadas e convertidas para a representao interna corrente antes de ser validada. Certifique-se que sua aplicao no decodifica a mesma entrada duas vezes. Tais erros podem ser usados para ultrapassar esquemas de lista branca pela introduo de entradas perigosas aps serem checados.
Recomendaes especficas por linguagem:

Java: use mecanismo de sada struts como <bean:write >, ou use o padro JSTL escapeXML="true" attribute in <c:out >. No use <%= %> no aninhado (isto , fora de um mecanismo de apropriado de sada codificada).
OWASP TOP TEN 2007

.NET: use a biblioteca Microsoft Anti-XSS 1.5 disponvel sem custo do MSDN. No atribua campos de formulrio diretamente do objeto Request: username.Text = Request.QueryString("username"); sem usar esta biblioteca. Entenda quais controles .NET codificam automaticamente o dado de sada. PHP: garanta que a sada passe pelo htmlentities() ou htmlspecialchars() ou use a biblioteca PHP Anti-XSS que est para ser lanada pela OWASP. Desabilite register_globals, caso este no tenha sido desabilitado.
EXEMPLOS
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4206 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3966 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5204
REFRENCIAS
CWE: CWE-79, Cross-Site scripting (XSS) WASC Threat Classification: http://www.webappsec.org/projects/threat/classes/cross-site_scripting.shtml OWASP Cross site scripting, http://www.owasp.org/index.php/Cross_Site_Scripting OWASP Testing for XSS, http://www.owasp.org/index.php/Testing_for_Cross_site_scripting OWASP Stinger Project (A Java EE validation filter) http://www.owasp.org/index.php/Category:OWASP_Stinger_Project OWASP PHP Filter Project - http://www.owasp.org/index.php/OWASP_PHP_Filters OWASP Encoding Project - http://www.owasp.org/index.php/Category:OWASP_Encoding_Project RSnake, XSS Cheat Sheet, http://ha.ckers.org/xss.html Klein, A., DOM Based Cross Site Scripting, http://www.webappsec.org/projects/articles/071105.shtml .NET Anti-XSS Library - http://www.microsoft.com/downloads/details.aspx?FamilyID=efb9c819-53ff-4f82bfaf-e11625130c25&DisplayLang=en
10
OWASP TOP TEN 2007
A2 FALHAS DE INJEO As falhas de Injeo, particularmente injeo SQL, so comuns em aplicaes web. Existem muitos tipos de injeo: SQL, LDAP, XPath, XSLT, HTML, XML, comando de sistema operacional e muitas outras. Falhas de Injeo acontecem quando os dados que o usurio d de entrada so enviados como parte de um comando ou consulta. Os atacantes confundem o interpretador para o mesmo executar comandos manipulados enviando dados modificados. As falhas de Injeo habilitam o atacante a criar, ler, atualizar ou apagar arbitrariamente qualquer dado disponvel para a aplicao. No pior cenrio, estes furos permitem ao atacante comprometer completamente a aplicao e os sistemas relacionados, at pelo contorno de ambientes controlados por firewall. AMBIENTES AFETADOS Todos os frameworks de aplicao web que usem interpretadores ou invoquem outros processos so vulnerveis a ataques por injeo. Isto inclui quaisquer componentes do framework que possam usar interpretadores como back-end. VULNERABILIDADE Caso uma entrada de usurio seja fornecida a um interpretador sem validao ou codificao, a aplicao vulnervel. Verifique se a entrada de usurio fornecida queries dinmicas, como por exemplo:
PHP: $sql = "SELECT * FROM table WHERE id = '" . $_REQUEST['id] . ""; Java: String query = "SELECT user_id FROM user_data WHERE user_name = '" + req.getParameter("userID") + "' and user_password = '" + req.getParameter("pwd") +"'";
VERIFICAO DE SEGURANA O objetivo verificar se os dados do usurio no possam modificar os comandos e queries enviadas a interpretadores invocadas para a aplicao. Abordagens automatizadas: muitas ferramentas de varredura de vulnerabilidades localizam falhas de Injeo, particularmente Injeo SQL. Ferramentas de anlise esttica que localizam o uso de APIs de interpretadores no seguras so teis, mas freqentemente no podem verificar que uma validao ou codificao adequada possa estar em uso para proteger contra tal ameaa. Caso a aplicao gerencie erros internos de servidor 501 / 500 ou erros de banco de dados detalhados, isto pode atrapalhar a varredura por ferramentas automatizadas, mas o cdigo ainda continuar em risco. Ferramentas automatizadas so capazes de detectar injees LDAP / XML / XPath. Abordagens manuais: a abordagem mais eficiente e precisa verificar o cdigo que invoca interpretadores. O revisor deve verificar o uso de API segura ou que validao e/ou codificao apropriada acontece. O teste pode ser extremamente demorado com baixa cobertura devido ao fato da superfcie de ataque na maioria das aplicaes ser grande. PROTEO Evite o uso de interpretadores quando possvel. Caso invoque um interpretador, o mtodo chave para evitar injees est no uso de APIs seguras, como por exemplo, queries parametrizadas e bibliotecas de mapeamento objeto relacional (ORM).
11
OWASP TOP TEN 2007 Estas interfaces manipulam todas as fugas dados, ou aquelas que no demandam fuga. Note que enquanto interfaces seguras resolvem o problema, validao ainda recomendada para detectar ataques. O uso de interpretadores perigoso, portanto so recomendados cuidados extras, como os seguintes:
Validao de entrada: utilize mecanismo padro de validao de entrada para validar todas as entradas quanto ao tamanho, tipo, sintaxe e regras de negcio antes de aceitar que o dado seja mostrado ou armazenado. Use uma estratgia de validao aceite o reconhecido como bom. Rejeite entrada invlida ao invs da tentativa de checar dados potencialmente hostis. No se esquea que as mensagens de erro podem tambm incluir dados invlidos. Use APIs de query fortemente tipado com substituidores de espaos reservados, mesmo quando usar stored procedures. Imponha o menor privilgio quando conectar a banco de dados ou outros sistemas de suporte. Evite mensagens de erros detalhadas que sejam teis ao atacante. Use stored procedures uma vez que elas so geralmente seguras contra injeo SQL. Entretanto, seja cuidadoso, pois elas podem ser injetveis (como por exemplo, via o uso do exec() ) ou pela concatenao de argumentos dentro da stored procedured. No use interfaces de query dinmicas (como por exemplo, mysql_query() ou similares). No use funes de fuga simples, como a addslashes() do PHP ou funes de substituio de caracteres como str_replace("", ""). Elas so fracas e tm sido exploradas com sucesso por atacantes. Para PHP, use mysql_real_escape_string() para MySQL ou preferencialmente use PDO que no requer fuga. Quando usar mecanismo simples de fuga, note que funes simples de fuga no podem escapar nomes de tabelas! Os nomes de tabelas devem ser SQL legal e assim completamente sem sentido para entrada fornecida pelo usurio. Localize erros de converso. As entradas devem ser decodificadas e convertidas para a representao interna corrente antes de ser validada. Certifique-se que sua aplicao no decodifica a mesma entrada duas vezes. Tais erros podem ser usados para ultrapassar esquemas de lista branca pela introduo de entradas perigosas aps sua validao.
Recomendaes especficas por linguagem:

Java EE use PreparedStatement fortemente tipado ou ORMs como Hibernate ou Spring. NET use queries parametrizadas fortemente tipadas, como SqlCommand com SqlParameter ou um ORM como o Hibernate. PHP use PDO com parametrizao fortemente tipada (using bindParam())
EXEMPLOS
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5121 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4953 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4592 REFERENCES CWE: CWE-89 (SQL Injection), CWE-77 (Command Injection), CWE-90 (LDAP Injection), CWE-91 (XML Injection), CWE-93 (CRLF Injection), others. WASC Threat Classification: http://www.webappsec.org/projects/threat/classes/ldap_injection.shtml http://www.webappsec.org/projects/threat/classes/sql_injection.shtml http://www.webappsec.org/projects/threat/classes/os_commanding.shtml OWASP, http://www.owasp.org/index.php/SQL_Injection OWASP Guide, http://www.owasp.org/index.php/Guide_to_SQL_Injection
12
OWASP TOP TEN 2007 A3 EXECUO MALICIOSA DE ARQUIVO As vulnerabilidades de execuo de arquivos so encontradas em muitas aplicaes. Os desenvolvedores tm por hbito usar diretamente ou concatenar entradas potencialmente hostis com funes de arquivo ou stream, ou confiar de maneira imprpria em arquivos de entrada. Em muitas plataformas, frameworks permitem o uso de referncias a objetos externos, como referncias a URLs ou a arquivos de sistema. Quando o dado insuficiente verificado, isto pode levar a uma incluso arbitrria remota que ser processado ou invocado um contedo hostil pelo servidor web. Isto permite ao atacante realizar:
Execuo de cdigo remoto. Instalao remota de rootkit e comprometimento total do sistema. Em Windows, comprometimento interno do sistema pode ser possvel a partir do uso de PHPs SMB file wrappers.
Este ataque particularmente prevalecente em PHP e cuidado extremo deve ser aplicado com qualquer sistema ou funo de arquivo para garantir que a entrada fornecida pelo usurio no influencie os nomes de arquivos. AMBIENTES AFETADOS Todos os frameworks de aplicao web so vulnerveis a execuo maliciosa de arquivo se eles aceitam nomes de arquivos ou arquivos do usurio. Exemplos tpicos incluem: assemblies .NET que permitem argumentos de nome de arquivos ou cdigo que aceita a escolha do arquivo pelo usurio de modo a incluir arquivos locais. O PHP particularmente vulnervel a ataque de incluso de arquivo remota (RFI) a partir de manipulao de parmetro com qualquer API baseada em arquivo ou streams. VULNERABILIDADE Uma vulnerabilidade comum construda :
include $_REQUEST['filename];
Isto no somente permite a avaliao de scripts hostis remotos, mas pode ser usado para acessar arquivos locais do servidor (caso o PHP seja hospedado no Windows) devido ao suporte SMB nos PHPs file system wrappers. Outros mtodos de ataque incluem:
Upload de dados hostis a arquivos de sesses, dados de log e via imagens (tpico de software de frum). Uso de compresso ou streams de udio, como por exemplo, zlib:// ou ogg:// que no inspecione a flag interna do PHP e ento permite o acesso remoto a recursos, mesmo que allow_url_fopen ou allow_url_include esteja desabilitado. Usando PHP wrappers, como por exemplo, php://input e outros para coletar entrada da requisio de dados POST ao invs de um arquivo. Usando o PHPs data: wrapper, como por exemplo, data:;base64,PD9waHAgcGhwaW5mbygpOz8+.
Uma vez que essa lista extensa (e muda com periodicidade), vital que o uso de uma arquitetura desenhada apropriado para segurana e design robusto quando manipulamos entradas fornecidas pelo usurio que influenciem a escolha de nomes de arquivos e acesso no lado do servidor. Apesar de fornecidos alguns exemplos em PHP, este ataque tambm aplicvel de maneiras diferentes em .NET e J2EE. As aplicaes desenvolvidas nestes frameworks necessitam de ateno particular aos mecanismos de segurana de acesso ao cdigo para garantir que os nomes de arquivos fornecidos ou 13
OWASP TOP TEN 2007 influenciados pelos usurios no habilitem que controles de segurana sejam desativados. Por exemplo, possvel que documentos XML submetidos por um atacante ter um DTD hostil que force o analisador XML a carregar um DTD remoto e analisar e processar os resultados. Uma empresa Australiana de segurana demonstrou esta abordagem para varredura portas para firewalls. Veja [SIF01] nas referncias deste artigo para maiores informaes. O dano causado por essa vulnerabilidade est diretamente associado com os pontos fortes dos controles de isolamento da plataforma no framework. Como o PHP raramente isolado e no possui o conceito de caixa de areia "sandbox" ou arquitetura segura, o dano muito pior do que comparado com outras plataformas com limitao ou confiana parcial, ou so contidos em uma sandbox confivel como, por exemplo, quando uma aplicao web executada sob um JVM com um gerenciador de segurana apropriado habilitado e configurado (que raramente o padro). VERIFICAO DE SEGURANA Abordagens automatizadas: ferramentas de localizao de vulnerabilidades possuem dificuldades em identificar os parmetros que so usados para entrada do arquivo ou a sintaxe que os faam isso. As ferramentas de anlise esttica podem localizar o uso de APIs perigosas, mas no podem verificar se a validao ou codificao apropriada foi implementada para proteger contra a vulnerabilidade. Abordagens manuais: uma reviso de cdigo pode localizar cdigo que possa permitir que um arquivo seja includo na aplicao, mas existem muitos erros possveis de ser reconhecidos. Testes podem detectar tais vulnerabilidades, mas identificar parmetros particulares e a sintaxe correta pode ser difcil. PROTEO A preveno falhas de incluso de arquivos remotos exige um planejamento cuidadoso nas fases de arquitetura e design, avanando para os testes. Em geral, uma aplicao bem desenvolvida no usa entrada de usurio para nomes de arquivos para nenhum recurso de servidor (como imagens, documentos XML e XSL ou incluso de script), e ter regras de firewall estabelecidas para prevenir conexes de sada para a internet ou internamente como retorno a qualquer outro servidor. Entretanto, muitas aplicaes legadas continuaro a ter a necessidade de aceitar entrada fornecida pelo usurio. Dentre as mais importantes consideraes, inclui-se:
Use um mapeamento indireto de objetos de referncia (veja a seo A4 para mais detalhes). Por exemplo, quando um nome de arquivo parcial uma vez usado, considere um hash para a referncia parcial. Ao invs de:
<select name=language> <option value=English>English</option>
use
<select name=language> <option value=78463a384a5aa4fad5fa73e2f506ecfc>English</option>
Considere o uso de salts para prevenir fora bruta em referncia indireta do objeto. Alternativamente, use somente valores de ndices como 1, 2, 3 e garanta que os limites dos vetores so verificados para detectar manipulao de parmetros. Use mecanismos explcitos de verificao de corrupo, caso sua linguagem suporte isso. Caso contrrio, considere um esquema de nomeao varivel para auxiliar na verificao de corrupo.
$hostile = &$_POST; // refer to POST variables, not $_REQUEST $safe[filename]= validate_file_name($hostile[unsafe_filename]); // make it safe
14
OWASP TOP TEN 2007 Conseqentemente, qualquer operao baseada em entrada hostil se torna imediatamente bvia:
require_once($_POST[unsafe_filename] . inc.php); require_once($safe[filename] . inc.php);
Forte validao de entrada de usurio usando uma estratgia de validao aceite o reconhecido como bom. Adicione regras no firewall para prevenir servidores web estabelecerem novas conexes externas com sites web e sistemas internos. Para sistemas de alto valor, isole o servidor web em sua prpria VLAN ou uma sub-rede privada. Certifique-se que os arquivos ou nomes de arquivos fornecidos no desativam outros controles, como por exemplo, dados corrompidos no objeto da sesso, avatares e imagens, relatrios PDF, arquivos temporrios, etc. Considere uma implementao de um chroot jail ou outros mecanismos de sandbox como virtualizao para isolar aplicaes umas das outras. PHP: desabilite allow_url_fopen e allow_url_include no php.ini e considere a construo de PHP localmente sem a incluso dessa funcionalidade. Poucas aplicaes necessitam desta funcionalidade e assim estas configuraes devem ser configuradas de acordo com a aplicao. PHP: desabilite register_globals e use E_STRICT para localizar variveis no inicializadas. PHP: garanta que todas as funes de arquivo ou de stream (stream_*) so cuidadosamente moderadas. Certifique-se que a entrada do usurio no seja fornecida a qualquer funo que use o nome do arquivo como argumento, incluindo:
include() include_once() require() require_once() fopen() imagecreatefromXXX() file() file_get_contents() copy() delete() unlink() upload_tmp_dir() $_FILES move_uploaded_file()
PHP: Seja extremamente cauteloso caso o dado seja passado para system() eval() ou `. Com o J2EE, certifique-se que o gestor de segurana seja habilitado e configurado apropriadamente e que a aplicao demande as permisses apropriadas. Com ASP.NET, recorra documentao referente confiana parcial e desenhe sua aplicao de forma a ser segmentada por confiana, de forma que ela exista sob os estados mais baixos possveis de segurana.
EXEMPLOS
REFERNCIAS
CWE: CWE-98 (PHP File Inclusion), CWE-78 (OS Command Injection), CWE-95 (Eval injection), CWE-434 (Unrestricted file upload) WASC Threat Classification: http://www.webappsec.org/projects/threat/classes/os_commanding.shtml OWASP Guide, http://www.owasp.org/index.php/File_System#Includes_and_Remote_files OWASP Testing Guide, http://www.owasp.org/index.php/Testing_for_Directory_Traversal OWASP PHP Top 5, http://www.owasp.org/index.php/PHP_Top_5#P1:_Remote_Code_Execution Stefan Esser, http://blog.php-security.org/archives/45-PHP-5.2.0-and-allow_url_include.html [SIF01] SIFT, Web Services: Teaching an old dog new tricks, http://www.ruxcon.org.au/files/2006/web_services_security.ppt http://www.owasp.org/index.php/OWASP_Java_Table_of_Contents#Defining_a_Java_Security_Policy Microsoft - Programming for Partial Trust, http://msdn2.microsoft.com/enus/library/ms364059(VS.80).aspx
15
OWASP TOP TEN 2007 A4 REFERNCIA INSEGURA DIRETA A OBJETO Uma referncia direta a um objeto acontece quando um desenvolvedor expe uma referncia a um objeto de implementao interna, como por exemplo, um arquivo, diretrio, registro na base de dados ou chave, uma URL ou um parmetro de um formulrio. Um atacante pode manipular diretamente referncias a objetos para acessar outros objetos sem autorizao, a no ser que exista um mecanismo de controle de acesso. Por exemplo, em aplicaes de Internet Banking comum o uso do nmero da conta como a chave primria. Conseqentemente, pode ser tentador usar o nmero da conta diretamente na interface web. Mesmo que os desenvolvedores tenham usado queries SQL parametrizadas para prevenir inseres de comandos SQL (SQL injection), e caso no exista uma verificao adicional para garantir que o usurio o proprietrio da conta e que est autorizado a ver a conta, um atacante pode manipular a partir do parmetro do nmero da conta e possivelmente pode ver e modificar todas as contas. Este tipo de ataque aconteceu no site da Australian Taxation Offices GST Start Up Assistance em 2000, onde um usurio legtimo, mas hostil, simplesmente modificou o ABN (identificador da empresa) presente na URL. O usurio se apossou de cerca de 17.000 registros de empresas cadastrados no sistema, e ento enviou para cada uma das 17.000 empresas detalhes do ataque. Este tipo de vulnerabilidade muito comum, porm no testada largamente em muitas aplicaes. AMBIENTES AFETADOS Todos os frameworks de aplicaes web esto vulnerveis a ataques a referncias diretas inseguras a objetos. VULNERABILIDADE Muitas aplicaes expem referncias a objetos internos aos usurios. Atacantes manipulam parmetros a fim de modificar as referncias e violarem a poltica de controle de acesso de forma intencionalmente e sem muito esforo. Freqentemente, estas referncias apontam para arquivos do sistema e banco de dados, mas qualquer aplicao exposta pode estar vulnervel. Por exemplo, se o cdigo permite especificao de nomes de arquivos ou caminhos a partir da entrada do usurio, isto pode permitir que atacantes acessem diretrios da aplicao que no esto publicados e acessem outros recursos.
<select name="language"><option value="fr">Franais</option></select> require_once ($_REQUEST['language]."lang.php");
Tal cdigo pode ser atacado usando uma string como ../../../../etc/passwd%00 usando injeo de um byte nulo (vide OWASP Guide para mais detalhes) para acessar qualquer arquivo no sistema de arquivo do servidor web. Similarmente, referncias as chaves de banco de dados so freqentemente expostas. Um atacante pode atacar estes parmetros simplesmente chutando ou procurando por outra chave vlida. Geralmente, elas so seqenciais por natureza. No exemplo a seguir, mesmo que a aplicao no apresente um link qualquer para um carrinho no autorizado e nenhuma injeo SQL seja possvel, um atacante pode ainda modificar o parmetro cartID para qualquer outro desejado.
int cartID = Integer.parseInt( request.getParameter( "cartID" ) ); String query = "SELECT * FROM table WHERE cartID=" + cartID;
16
OWASP TOP TEN 2007 VERIFICAO DE SEGURANA O objetivo consiste em verificar se a aplicao no permite que referncias diretas a objetos sejam manipuladas por atacantes. Abordagens automatizadas: scanners de vulnerabilidades possuem dificuldades de identificar os parmetros susceptveis a manipulao ou se a manipulao aconteceu. As ferramentas de anlise esttica no podem saber quais parmetros devem ter uma verificao de controle de acesso antes de ser usado. Abordagens manuais: uma reviso de cdigo pode localizar parmetros crticos e identificar se eles so susceptveis a manipulao em muitos casos. Testes de penetrao podem verificar tambm quando tal manipulao possvel. Entretanto, ambas as tcnicas so dispendiosas e podem no ser suficientes. PROTEO A melhor proteo evitar a exposio direta de referncias a objetos a usurios usando um ndice, mapa de referncia indireta ou outro mtodo indireto que seja fcil de validar. Caso uma referncia direta a objeto pode ser usada, garanta que o usurio esteja autorizado ante do uso. O estabelecimento de uma forma padro para referenciar objetos da aplicao importante, pois:
Evita a exposio de referncias de objetos privados a usurios sempre que possvel, como chaves primrias e nomes de arquivos. Valide cada referncia privada a objeto atravs da abordagem aceite o reconhecido como bom. Verifique a autorizao de todos os objetos referenciados. A melhor soluo usar um valor de ndice ou um mapa de referncia para prevenir ataques de manipulao de parmetro.
http://www.example.com/application?file=1
Caso necessite expor diretamente referncias s estruturas de banco de dados, certifique-se que as declaraes SQL e outros mtodos de acesso base de dados permitam somente sejam mostrados registros autorizados:
int cartID = Integer.parseInt( request.getParameter( "cartID" ) ); User user = (User)request.getSession().getAttribute( "user" ); String query = "SELECT * FROM table WHERE cartID=" + cartID + " AND userID=" + user.getID();
EXEMPLOS
REFERNCIAS
CWE: CWE-22 (Path Traversal), CWE-472 (Web Parameter Tampering) WASC Threat Classification: http://www.webappsec.org/projects/threat/classes/abuse_of_functionality.shtml http://www.webappsec.org/projects/threat/classes/insufficient_authorization.shtml OWASP Testing Guide, http://www.owasp.org/index.php/Testing_for_business_logic OWASP Testing Guide, http://www.owasp.org/index.php/Testing_for_Directory_Traversal OWASP, http://www.owasp.org/index.php/Category:Access_Control_Vulnerability GST Assist attack details, http://www.abc.net.au/7.30/stories/s146760.htm
17
OWASP TOP TEN 2007 A5 CROSS SITE REQUEST FORGERY (CSRF) Cross site request forgery no um novo ataque, mas simples e devastador. Um ataque CSRF fora o navegador logado da vtima a enviar uma requisio para uma aplicao web vulnervel, que realiza a ao desejada em nome da vtima. Esta vulnerabilidade extremamente disseminada, uma vez que qualquer aplicao web:
No tenha verificao de autorizao para aes vulnerveis Execute uma ao caso um login padro seja enviado na requisio (ex. http://www.example.com/admin/doSomething.ctl?username=admin&passwd=admin) Autorize requisies baseadas somente em credenciais que so automaticamente submetidas como, por exemplo, cookie de sesso, caso logada corretamente na aplicao, ou a funcionalidade Relembrar-me, se no logado na aplicao, ou um token Kerberos, se parte de uma Intranet que tenha o logon integrado com o Active Directory.
Este tipo de aplicao estar em risco. Infelizmente, hoje, a maioria das aplicaes web confia exclusivamente em credenciais submetidas automaticamente, como por exemplo, cookies de seo, credenciais de autenticao bsica, endereo de IP de origem, certificados SSL ou credenciais de um domnio Windows. Esta vulnerabilidade tambm conhecida por outros diversos nomes incluindo Session Riding, Ataques One-Click, Cross Site Reference Forgery, Hostile Linking e Automation Attack. O acrnimo XSRF freqentemente usado. Ambos a OWASP e o MITRE padronizaram o uso do termo Cross Site Request Forgery e CSRF. AMBIENTES AFETADOS Todos os frameworks de aplicaes web esto vulnerveis CSRF. VULNERABILIDADE Um ataque tpico CSRF contra um frum pode ter a forma de direcionar o usurio a invocar alguma funo, como por exemplo, a pgina de logout da aplicao. A seguinte tag em qualquer pgina web vista pela vtima gerar uma requisio que encerra sua seo:
<img src="http://www.example.com/logout.php">
Caso um banco permita sua aplicao a processar requisies, como a transferncia de fundos, um ataque similar pode permitir:
<img src="http://www.example.com/transfer.do?frmAcct=document.form.frmAcct &toAcct=4345754&toSWIFTid=434343&amt=3434.43">
Jeremiah Grossman em sua palestra na BlackHat 2006 Hacking Intranet Sites from the outside, demonstrou ser possvel forar o usurio a modificar seu roteador DSL sem seu consentimento; mesmo que o usurio no saiba que o roteador possua uma interface web. Jeremiah usou um nome de conta padro do roteador para realizar o ataque. Todos estes ataques funcionam, pois a credencial de autorizao do usurio (tipicamente um cookie de sesso) automaticamente includa em requisies do navegador, mesmo que o atacante no fornea tal credencial.
18
OWASP TOP TEN 2007 Caso a tag contendo o ataque possa ser postada em uma aplicao vulnervel, ento a probabilidade de encontrar vtimas autenticadas incrementada significativamente, similar ao incremento do risco entre as falhas XSS armazenadas e refletidas. Falhas XSS no so necessrias para um ataque CSRF funcionar, apesar de que qualquer aplicao com falhas XSS esteja susceptvel a CSRF, pois um ataque CSRF pode explorar uma falha XSS para roubar qualquer credencial no fornecida de forma automtica que possa estar em execuo para proteger contra um ataque CSRF. Muitos worms de aplicao tm usado ambas as tcnicas de forma combinada. Quando estiver construindo defesas contra ataques CSRF, deve-se focar tambm na eliminao de vulnerabilidades XSS na aplicao, uma vez que tais vulnerabilidades podem ser usadas para subverter a maioria das defesas contra CSRF aplicadas. VERIFICAO DE SEGURANA O objetivo verificar se a aplicao est protegida contra ataques CSRF pela gerao e ento requisio de algum tipo de token de autorizao que no seja automaticamente submetido pelo browser. Abordagens automatizadas: hoje poucos scanners podem detectar CSRF, mesmo que a deteco de CSRF seja possvel para a inteligncia dos scanners de aplicao. Entretanto, caso seu scanner de vulnerabilidade localize uma vulnerabilidade XSS e no haja protees anti-CSRF, muito provvel que esteja em risco de ataques CSRF encubados. Abordagens manuais: teste de penetrao uma maneira rpida de verificar que uma proteo CSRF esteja em operao. A verificao de cdigo a maneira mais eficiente para se verificar que o mecanismo est seguro e implementado apropriadamente. PROTEO As aplicaes devem se certificar que no esto se baseando em credenciais ou tokens que so automaticamente submetidos pelos navegadores. A nica soluo utilizar um token personalizado que o navegador no lembrar e ento incluir automaticamente em um ataque de CSRF. As seguintes estratgias devem estar em todas as aplicaes web:
Garanta que no existam vulnerabilidades XSS em sua aplicao (Vide A1 XSS). Insira tokens randmicos personalizados em todos os formulrios e URL que no seja automaticamente submetido pelo browser. Por exemplo:
<form action="/transfer.do" method="post"> <input type="hidden" name="8438927730" value="43847384383"> </form>
e ento verifique se o token submetido correto para o usurio corrente. Tais tokens podem ser nicos para tal funo ou pgina particular para o referido usurio, ou simplesmente nico para a sesso como um todo. Quanto mais focado o token for para uma funo particular e/ou conjunto particular de dados, mais forte ser a proteo, mas mais complicado ser seu desenvolvimento e manuteno. Para dados sensveis ou transaes de valores, re-autentique ou use assinatura de transao para garantir que a requisio genuna. Configure mecanismos externos como, por exemplo, contato por email ou telefone de maneira a verificar requisies ou notificar o usurio das requisies. No use requisies GET (URLs) para dados sensveis ou para realizar transaes de valores. Use somente mtodos POST quando processar dados sensveis do usurio. Entretanto, a URL pode conter token randmico medida que este cria uma URL nica, que torna o CSRF quase impossvel de se realizar. Um nico POST insuficiente para proteo. Deve-se tambm combinar com tokens randmicos, autenticao por outros meios ou re-autenticao para proteger apropriadamente contra CSRF.
19
OWASP TOP TEN 2007

Para ASP.NET, configure o valor ViewStateUserKey. (Vide referncias). Isto prove um tipo similar de verificao a um token randmico como descrito anteriormente. Enquanto estas sugestes diminuiro drasticamente a exposio, ataques avanados de CSRF podem contornar muitas destas restries. A tcnica mais forte usar tokens nicos e eliminar todas as vulnerabilidades XSS em sua aplicao.
EXEMPLOS
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0192 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5116 MySpace Samy Interview: http://blog.outer-court.com/archive/2005-10-14-n81.html An attack which uses Quicktime to perform CSRF attacks http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9005607&intsr c=hm_list
REFERNCIAS
CWE: CWE-352 (Cross-Site Request Forgery) WASC Threat Classification: No direct mapping, but the following is a close match: http://www.webappsec.org/projects/threat/classes/abuse_of_functionality.shtml OWASP CSRF, http://www.owasp.org/index.php/Cross-Site_Request_Forgery OWASP Testing Guide, https://www.owasp.org/index.php/Testing_for_CSRF OWASP CSRF Guard, http://www.owasp.org/index.php/CSRF_Guard OWASP PHP CSRF Guard, http://www.owasp.org/index.php/PHP_CSRF_Guard RSnake, "What is CSRF?", http://ha.ckers.org/blog/20061030/what-is-csrf/ Jeremiah Grossman, slides and demos of Hacking Intranet sites from the outside http://www.whitehatsec.com/presentations/whitehat_bh_pres_08032006.tar.gz Microsoft, ViewStateUserKey details, http://msdn2.microsoft.com/enus/library/ms972969.aspx#securitybarriers_topic2
20
OWASP TOP TEN 2007 A6 VAZAMENTO DE INFORMAES E TRATAMENTO DE ERROS INAPROPRIADO Diversas aplicaes podem sem inteno vazar informaes sobre suas configuraes, funcionamento interno, ou violar privacidade atravs de diversos problemas. Aplicaes podem vazar o funcionamento interno via tempo de resposta para executar determinados processos ou respostas diferentes para entradas diversas, como exibindo mesma mensagem de erro mas com cdigo de erros diferentes. Aplicaes Web freqentemente vazaro informaes sobre seu funcionamento interno atravs de mensagens de erros detalhadas ou debug. Freqentemente, essa informao pode ser o caminho para lanar ataques ou ferramentas automticas mais poderosas. AMBIENTES AFETADOS Todos os frameworks de aplicao web so vulnerveis ao vazamento de informaes e tratamento de erros inapropriado. VULNERABILIDADE Aplicaes freqentemente geram mensagens de erros e as mostram para os usurios. Muitas vezes essas informaes so teis para os atacantes, visto que elas revelam detalhes de implementaes ou informaes teis para explorar uma vulnerabilidade. Existem diversos exemplos comuns disso:
Manipulao de erro detalhada, onde se induzirmos alguns erros sero mostradas muitas informaes, como o rastreamento da pilha, validaes, falhas de SQL, ou outras informaes de debug. Funes que produzem diferentes sadas baseado-se em diferentes entradas. Por exemplo, substituindo o mesmo nome de usurio com senhas diferentes deveria produzir o mesmo texto como usurio inexistente, ou password invlido. Entretanto, muitos sistemas geram diferentes cdigos de erros.
VERIFICAO DE SEGURANA O objetivo verificar se a aplicao no vaza informaes via mensagens de erros ou outros meios. Mtodos Automticos: Ferramentas de scanner de vulnerabilidades geralmente ocasionaro mensagens de erros. Ferramentas de anlise esttica podem procurar pelo uso de API que vazam informaes, mas no tero capacidade de verificar o significado dessas mensagens. Mtodos manuais: Em uma reviso de cdigo podemos procurar por manipulaes inapropriadas de erros e outros fatores que vazam informaes, mas demandar um consumo de tempo elevado.
PROTEO Desenvolvedores deveriam usar ferramentas como OWASP's WebScarab para tentar fazer suas aplicaes gerarem erros. Aplicaes que no foram testadas dessa maneira quase que certamente geraro erros de sada inesperados. Aplicaes tambm deveriam incluir um padro de exceo de manipulao para prevenir que informaes desnecessrias vazem para os atacantes. Prevenir vazamento de informaes requer disciplina. As seguintes prticas tm provado ser eficientes:
Tenha certeza que toda a equipe de desenvolvimento de software compartilha o mesmo mtodo para manipular erros. Desabilite ou limite o detalhamento na manipulao de erros. Em particular, no mostre informaes de debug, rastreamento de pilha ou informao de caminhos(path) para usurios finais.
21
OWASP TOP TEN 2007

Tenha certeza que caminhos (paths) seguros que tenha mltiplos resultados, retornem mensagens de erros similares ou idnticas. Se no for possvel, considere colocar um tempo de espera randmico para todas as transaes para esconder esse detalhe dos atacantes. Vrias camadas podem retornar resultados excepcionais ou fatais, como camadas de banco de dados, servidores web ( IIS, Apache, etc). vital que erros de todas as camadas sejam adequadamente checados e configurados para prevenir que mensagens de erros sejam exploradas por atacantes. Tenha conscincia que frameworks comuns retornam diferentes cdigos HTTP dependendo se um erro customizado ou erro do framework . muito valioso criar um manipulador de erros padro que retorne uma mensagem de erro j checada para maioria dos usurios em produo para os erros de caminho(path). Sobrepor o manipulador padro de erros para que ele sempre retorne 200 (OK) reduz a probabilidade de ferramentas de testes automticos descobrirem se alguma falha grave ocorre. Isso segurana atravs da obscuridade e pode se prover uma camada extra de defesa. Algumas organizaes maiores tm escolhido incluir cdigos de erros randmicos / nicos em todas suas aplicaes. Isto pode ajudar o suporte a encontrar a soluo correta para um erro particular, mas isso pode tambm permitir que atacantes determinem exatamente onde a aplicao falhou.
EXEMPLOS
REFRENCIAS
CWE: CWE-200 (Information Leak), CWE-203 (Discrepancy Information Leak), CWE-215 (Information Leak Through Debug Information), CWE-209 (Error Message Information Leak), others. WASC Threat Classification: http://www.webappsec.org/projects/threat/classes/information_leakage.shtml OWASP, http://www.owasp.org/index.php/Error_Handling OWASP, http://www.owasp.org/index.php/Category:Sensitive_Data_Protection_Vulnerability
22
OWASP TOP TEN 2007 A7 FURO DE AUTENTICAO E GERNCIA DE SESSO Autenticao e gerncia de sesso apropriadas so criticas para a segurana na web. Falhas nesta rea geralmente envolvem a falha na proteo de credenciais e nos tokens da sesso durante seu tempo de vida. Estas falhas podem estar ligadas roubo de contas de usurios ou administradores, contornando controles de autorizao e de responsabilizao, causando violaes de privacidade. AMBIENTES AFETADOS Todos os frameworks de aplicaes web so vulnerveis a furos de autenticao e de gerncia de sesso. VULNERABILIDADE Furos no mecanismo principal de autenticao no so incomuns, mas falhas so geralmente introduzidas a partir de funes menos importantes de autenticao como logout, gerncia de senhas, timeout, recordao de dados de logon, pergunta secreta e atualizao de conta. VERIFICAO DE SEGURANA O objetivo verificar se o aplicativo autentica corretamente os usurios e protege as identidades das credenciais associadas. Abordagens automatizadas: ferramentas de localizao de vulnerabilidade tm dificuldade em esquemas de autenticao e de sesso personalizados. As ferramentas de anlise estticas provavelmente tambm no detectaro problemas em cdigos personalizados para autenticao e gerncia de sesso. Abordagens manuais: reviso de cdigo e testes, especialmente combinados, so muito efetivos para a verificao de autenticao, gerencia de sesso e funes secundrias esto todas implementadas corretamente. PROTEO A autenticao depende da comunicao segura e de armazenamento de credenciais. Primeiramente, assegure-se que o SSL a nica opo para todas as partes autenticadas do aplicativo (veja A9) e que todas as credenciais esto guardadas de uma forma encriptada ou em hash (veja A8). Prevenir falhas de autenticao requer um planejamento cuidadoso. Algumas das consideraes importantes so:
Use somente mecanismos padro para gerncia de sesso. No escreva ou use gerenciadores secundrios de sesso em qualquer situao. No aceite novos identificadores de sesso, pr-configurados ou invlidos na URL ou em requisies. Isto chamado de ataque de sesso fixada. Limite ou limpe seu cdigo de cookies personalizados com propsito de autenticao de gerncia de sesso, como funes lembrar do meu usurio ou funes domsticas de autenticao centralizadas como o Single Sign-On (SSO). Isto no se aplica s solues de autenticao federadas robustas ou SSO reconhecidas. Use um mecanismo nico de autenticao com dimenso e nmero de fatores apropriados. Certifique-se que este mecanismo no estar facilmente sujeito ataques ou fraudes. No faa esse mecanismo complicado demais, pois ele pode se tornar alvo de seu prprio ataque.
23
OWASP TOP TEN 2007

No permita que o processo de login comece de uma pgina no encriptada. Sempre inicie o processo de login de uma segunda pgina encriptada ou de um novo cdigo de sesso, para prevenir o roubo de credenciais ou da sesso, phishing e ataques de fixao de sesso. Considere gerar uma nova sesso aps uma autenticao que obteve sucesso ou mudana do nvel de privilgio. Assegure-se que todas as pginas tenham um link de logout. O logout deve destruir todas as sesses e cookies de sesso. Considere os fatores humanos: no pergunte por confirmao, pois usurios acabaro fechando a aba ou janela ao invs de sair com sucesso. Use perodos de expirao de prazo que automaticamente do logout em sesses inativas, bem como o contedo das informaes que esto sendo protegidas. Use somente funes de proteo secundrias eficientes (perguntas e respostas, reset de senha), pois estas credenciais so como senhas, nomes de usurios e tokens. Aplique one-way hash nas respostas para prevenir ataques nos quais a informao pode ser descoberta. No exponha nenhum identificador de sesso ou qualquer parte vlida das credenciais em URLs e logs (no regrave ou armazene informaes de senhas de usurios em logs). Verifique a senha antiga do usurio quando ele desejar mudar a senha. No confie em credenciais falsificveis como forma de autenticao, como endereos de IP ou mscaras de rede, endereo de DNS ou verificao reversa de DNS, cabealhos da origem ou similares. Cuide-se quando enviar segredos para endereos de e-mail (procure por RSNAKE01 nas referncias) como um mecanismo de reset de password. Use nmeros randmicos limited-time-only para resetar acesso e envie um e-mail de retorno assim que a senha for reconfigurada. Cuide para quando permitir que usurios registrados mudem seus endereos de e-mail envie uma mensagem para o e-mail anterior antes de efetuar a mudana.
EXEMPLOS
REFERNCIAS
CWE: CWE-287 (Authentication Issues), CWE-522 (Insufficiently Protected Credentials), CWE-311 (Reflection attack in an authentication protocol), others. WASC Threat Classification: http://www.webappsec.org/projects/threat/classes/insufficient_authentication.shtml http://www.webappsec.org/projects/threat/classes/credential_session_prediction.shtml http://www.webappsec.org/projects/threat/classes/session_fixation.shtml OWASP Guide, http://www.owasp.org/index.php/Guide_to_Authentication OWASP Code Review Guide, http://www.owasp.org/index.php/Reviewing_Code_for_Authentication OWASP Testing Guide, http://www.owasp.org/index.php/Testing_for_authentication RSNAKE01 - http://ha.ckers.org/blog/20070122/ip-trust-relationships-xss-and-you
24
OWASP TOP TEN 2007 A8 ARMAZENAMENTO CRIPTOGRTAFICO INSEGURO Proteger dados sensveis com criptografia tem sido parte chave da maioria das aplicaes Web. Simplesmente no criptografar dados sensveis muito comum. Ainda, aplicaes que adotam criptografia freqentemente possuem algoritmos mal concebidos, usam mecanismos de cifragem inapropriados ou cometem srios erros usando cifragem fortes. AMBIENTES AFETADOS Todos os frameworks de aplicao web so vulnerveis ao armazenamento criptogrfico inseguro. VULNERABILIDADE Prevenir falhas de criptografia requer planejamento cuidadoso. Os problemas mais comuns so:
No criptografar dados sensveis Uso inseguro de algoritmos fortes Uso de algoritmos caseiros Continuar usando algoritmos que provadamente so fracos (MD5, SHA-1, RC3, RC4, etc.) Difcil codificao de chaves, e armazenar chaves em sistemas de armazenamento desprotegidos
VERIFICAO DE SEGURANA O objetivo verificar se as aplicaes corretamente armazenam informaes sensveis em sistemas de armazenamento. Abordagens automticas: Ferramentas de pesquisas de vulnerabilidades no verificam a criptografia em sistemas de armazenamento em geral. Ferramentas de pesquisa de cdigos podem detectar o uso de APIs de criptografias conhecidas, mas no podem detectar se ela esta sendo usada corretamente ou se a criptografia realizada em um mecanismo externo. Abordagem manual: Como ferramentas de pesquisas, testes no podem verificar o armazenamento criptografado. Reviso de cdigo a melhor forma de verificar que a aplicao criptografa dados sensveis e tem mecanismos e armazenamento de chaves corretamente implementados. Isto em alguns casos pode envolver examinar as configuraes de sistemas externos.
PROTEO O aspecto mais importante assegurar que tudo que deve ser criptografado est realmente criptografado. Ento voc deve assegurar que a criptografia esta corretamente implementada. Como existem vrios mtodos de incorretamente usar a criptografia, as seguintes recomendaes devem ser seguidas como parte de seus testes para ajudar a assegurar o manuseamento seguro de mecanismos de criptografia:
No crie algoritmos de criptografia. Somente use algoritmos aprovados publicamente como, AES, Criptografia de chaves publicas RSA, SHA-256 ou melhores para hash. No use algoritmos fracos, como MD5/SHA1. Use mecanismos mais seguros como SHA-256 ou melhores. Crie chaves offline e armazene chaves privadas com extremo cuidado. Nunca transmita chaves privadas em canais inseguros. Assegure que credenciais de infra-estrutura como credenciais de banco de dados ou detalhes de filas de acessos MQ esto corretamente seguras (por meio de rgidos sistemas de arquivos e controles), criptografados de forma adequada e no podem ser decriptografados por usurios locais ou remotos.
25
OWASP TOP TEN 2007

Assegure que dados armazenados criptografados no disco no so fceis de decriptografar. Por exemplo, criptografia de banco de dados intil se a conexo de banco de dados permite acessos no criptografados. Sobre o requisito 3, de Padres de Dados Seguros PCI, voc deve proteger dados dos titulares das informaes. O cumprimento do PCI DDS obrigatrio at 2008 por comerciantes e qualquer um que lidar com cartes de crdito. Uma boa prtica nunca armazenar dados desnecessrios, como informaes sobre a fita magntica ou o nmero da conta primria (PAN, tambm conhecida como o numero do carto de crdito). Se voc armazenar o PAN, o requisito para o cumprimento do DSS so significativos. Por exemplo, NUNCA permitir armazenar o numero CVV ( O numero de trs dgitos nas costas do carto) sobre quaisquer circunstncias. Para mais informaes, por favor leia o PCI DSS Guidelines e implemente controles como necessrios.
EXEMPLOS
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6145 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1664 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-1999-1101 (True of most Java EE servlet containers,too)
REFRENCIAS
CWE: CWE-311 (Failure to encrypt data), CWE-326 (Weak Encryption), CWE-321 (Use of hard-coded Cryptographic key), CWE-325 (Missing Required Cryptographic Step), others. WASC Threat Classification: No explicit mapping OWASP, http://www.owasp.org/index.php/Cryptography OWASP Guide, http://www.owasp.org/index.php/Guide_to_Cryptography OWASP, http://www.owasp.org/index.php/Insecure_Storage OWASP, http://www.owasp.org/index.php/How_to_protect_sensitive_data_in_URLs PCI Data Security Standard v1.1, https://www.pcisecuritystandards.org/pdfs/pci_dss_v1-1.pdf Bruce Schneier, http://www.schneier.com/ CryptoAPI Next Generation, http://msdn2.microsoft.com/en-us/library/aa376210.aspx
26
OWASP TOP TEN 2007 A9 COMUNICAES INSEGURAS Aplicaes geralmente falham na hora de encriptar trfego de rede quando necessrio proteger comunicaes sensveis. A encriptao (geralmente SSL) deve ser usada em todas as conexes autenticadas, especialmente pginas web com acesso via internet, mas tambm conexes com o backend. Seno, o aplicativo ir expor uma autenticao ou o token de sesso. Adicionalmente, a autenticao deve ser usada sempre que dados sensveis, assim como cartes de crdito ou informaes de sade so transmitidos. Aplicaes cujo modo de encriptao possa ser subvertido so alvos de ataques. Os padres PCI requerem que todas as informaes de cartes de credito que so transmitidas pela internet sejam encriptadas. AMBIENTES AFETADOS Todos os frameworks de aplicaes web so vulnerveis s comunicaes inseguras. VULNERABILIDADE Falha na hora de encriptar informaes sensveis significa que um invasor que possa escutar o trfego da rede poder ter acesso conversa, incluindo quaisquer credenciais ou informaes sensveis transmitidas. Considerando que redes diferentes tero mais ou menos suscetibilidade a escuta. Entretanto, importante notar que eventualmente um servidor ser comprometido em praticamente qualquer rede, e que invasores instalaro rapidamente uma escuta para capturar as credenciais de outros sistemas. O uso de SSL para comunicao com usurios finais critico, pois muito provvel que eles utilizem formas inseguras de acessar os aplicativos. Porque HTTP inclui credenciais de autenticao ou um token de sesso para cada pedido, toda autenticao do trfego deve ir para o SSL, no s os pedidos de login. A encriptao de informaes com servidores de back-end tambm importante. Mesmo que estes servidores sejam naturalmente mais seguros, as informaes e as credenciais que elas carregam so mais sensveis e mais impactantes. Portanto, usar SSL no back-end tambm muito importante. A encriptao de informao sensvel, assim como cartes de crdito e informaes de previdncia, se tornou um regulamento financeiro e de privacidade para vrias empresas. Negligenciar o uso de SSL para o manuseio de conexes de informaes cria um risco de no conformidade. VERIFICAO DE SEGURANA O objetivo verificar se as aplicaes encriptam corretamente toda a comunicao autenticada e sensvel. Abordagens automatizadas: ferramentas de localizao de vulnerabilidade podem verificar se o SSL utilizado na interface do sistema e pode localizar muitas falhas relacionadas SSL. Entretanto, elas no tm acesso s conexes no back-end e no podem verificar se elas so seguras. As ferramentas de anlise esttica podem ajudar com anlises de algumas ligaes no back-end, mas provavelmente no entendero a lgica customizada requerida para todos os tipos de sistemas. Abordagens manuais: testes podem verificar se o SSL utilizado e localizar muitas falhas relacionadas SSL na interface, mas as abordagens automatizadas so provavelmente mais eficientes. A reviso de cdigo muito eficiente para verificar o uso de SSL em conexes no back-end.
OWASP TOP TEN 2007 PROTEO A parte mais importante da proteo usar o SSL em todas as conexes autenticadas ou em qualquer informao sensvel em transmisso. H inmeros detalhes envolvendo a configurao do SSL para aplicaes web, ento importante entender e analisar seu ambiente. Por exemplo, o IE7 (internet Explorer 7) prov uma barra verde para certificados SSL altamente confiveis, mas isto no um controle apropriado que demonstre por si s o uso seguro da criptografia.
Use SSL para todas as conexes que so autenticadas ou que transmitam informaes sensveis ou de valor, assim como credenciais, cartes de crdito, e outros. Assegure que as comunicaes entre os elementos da infra-estrutura, como servidores de web e sistemas de banco de dados, esto propriamente protegidas pelo uso de camadas de transporte de segurana ou de encriptao de nvel de protocolo para credenciais e informaes de valor intrnseco. Dentro dos requisitos de segurana PCI 4, deve-se proteger as informaes dos proprietrios de cartes de crdito em transmisso. A conformidade com as normas PCI DSS mandatria at 2008 para todos os comerciantes e qualquer um que lide com cartes de crdito. Em geral, clientes, parceiros, funcionrios e acesso administrativo online aos sistemas devem ser encriptados via SSL ou similar.
EXEMPLOS
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6430 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-4704 http://www.schneier.com/blog/archives/2005/10/scandinavian_at_1.html
REFERNCIAS
CWE: CWE-311 (Failure to encrypt data), CWE-326 (Weak Encryption), CWE-321 (Use of hard-coded cryptographic key), CWE-325 (Missing Required Cryptographic Step), others. WASC Threat Classification: No explicit mapping OWASP Testing Guide, Testing for SSL / TLS, https://www.owasp.org/index.php/Testing_for_SSL-TLS OWASP Guide, http://www.owasp.org/index.php/Guide_to_Cryptography Foundstone - SSL Digger, http://www.foundstone.com/index.htm?subnav=services/navigation.htm&subcontent=/services/overvie w_s3i_des.htm NIST, SP 800-52 Guidelines for the selection and use of transport layer security (TLS) Implementations, http://csrc.nist.gov/publications/nistpubs/800-52/SP800-52.pdf NIST SP 800-95 Guide to secure web services, http://csrc.nist.gov/publications/drafts.html#sp800-95
28
OWASP TOP TEN 2007 A10 FALHA AO RESTRINGIR ACESSO URLS Comumente, a nica proteo para uma URL no mostrar o link para usurios no autorizados. No entanto, um motivado, hbil ou apenas um sortudo atacante pode ser capaz de achar e acessar estas pginas, executar funes e visualizar dados. Segurana por obscuridade no suficiente para proteger dados e funes sensveis em uma aplicao. Verificaes de controles de acesso devem ser executadas antes de permitir uma solicitao a uma funo sensvel, na qual garante que somente o usurio autorizado acesse a respectiva funo. AMBIENTES AFETADOS Todos os frameworks de aplicaes web esto vulnerveis a falhas de restrio de acesso a URLs. VULNERABILIDADE O principal mtodo de ataque para esta vulnerabilidade chamado de navegao forada (forced browsing), na qual envolve tcnicas de adivinhao de links (guessing) e fora bruta (brute force) para achar pginas desprotegidas. comum que aplicaes utilizem cdigos de controle de acesso por toda a aplicao, resultando em um modelo complexo que dificulta a compreenso para desenvolvedores e especialistas em segurana. Esta complexidade torna provvel a ocorrncia de erros e algumas pginas no sero validadas, deixando a aplicao vulnervel. Alguns exemplos destas falhas incluem:
URLS escondidas e especiais, mostradas apenas para administradores ou usurios privilegiados na camada de apresentao, porm acessvel a todos os usurios caso tenham conhecimento que esta URL existe, como /admin/adduser.php ou /approveTransfer.do. Estas so particularmente comuns em cdigos de menus. Aplicaes geralmente permitem acesso a arquivos escondidos, como arquivos XML estticos ou relatrios gerados por sistemas, confiando toda segurana na obscuridade, escondendo-os. Cdigos que foram uma poltica de controle de acesso desatualizada ou insuficiente. Por exemplo, imagine que /approveTransfer.do foi disponibilizado uma vez para todos usurios, mas desde que os controles da SOX foram adotados, ele supostamente s pode ser acessvel por usurios aprovadores. Uma possvel correo seria no mostrar a URL para usurios no autorizados, no entanto o controle de acesso ainda no estaria implementado na requisio para esta pgina. Cdigos que validam privilgios no cliente (browser) e no no servidor, como neste ataque na MacWorld 2007, que aprovava para Platinum passes que valiam $1700 via Java Script no browser ao invs de validar no servidor.
VERIFICANDO A SEGURANA O objetivo verificar que o controle est forado constantemente na camada de apresentao e nas regras de negcio para todas as URLs da aplicao. Abordagem automatizada: Scanners de vulnerabilidades e ferramentas de anlise manual, ambos possuem dificuldades em verificar o controle de acesso na URL por diferentes razes. Scanners de vulnerabilidades possuem dificuldade em adivinhar pginas escondidas e determinar qual pgina deveria ser permitida para cada usurio, enquanto mecanismos de anlise esttica tentam identificar controles de acessos personalizados no cdigo e ligam a camada de apresentao com as regras de negcios. Abordagem manual: A abordagem mais eficiente e precisa est em utilizar a combinao da reviso do cdigo e dos testes de segurana para verificar os mecanismos de controles de acesso. Se o mecanismo 29
OWASP TOP TEN 2007 centralizado, a verificao pode ser bastante eficiente. Se o mecanismo distribudo atravs de uma completa base de cdigo, a verificao pode se tornar dispendiosa. Se o mecanismo est forado externamente, a configurao deve ser examinada e testada. PROTEO Tendo o tempo para planejar a autorizao criando uma matriz para mapear as regras e as funes da aplicao o passo primordial para alcanar a proteo contra acessos no autorizados. Aplicaes web devem garantir controle de acesso em cada URL e funes de negcio. No suficiente colocar o controle de acesso na camada de apresentao e deixar a regra de negcio desprotegida. Tambm no suficiente verificar uma vez o usurio autorizado e no verificar novamente nos passos seguintes. De outra forma, um atacante pode simplesmente burlar o passo onde a autorizao verificada e forjar o valor do parmetro necessrio e continuar no passo seguinte. Habilitar controle de acesso na URL necessita de um planejamento cuidadoso. Dentre as consideraes mais importantes podemos destacar:
Garanta que a matriz do controle de acesso parte do negcio, da arquitetura e do design da aplicao Garanta que todas URLs e funes de negcio so protegidas por um mecanismo de controle de acesso efetivo que verifique as funes e direitos do usurio antes que qualquer processamento ocorra. Certifique-se que este processo realizado em todos os passos do fluxo e no apenas no passo inicial de um processo, pois pode haver vrios passos a serem verificados. Realize um teste invaso (penetration test) antes do cdigo entrar em produo a fim de garantir que a aplicao no poder ser utilizada de m f por um atacante motivado ou com conhecimentos avanados. Preste muita ateno em arquivos de includes/bibliotecas, especialmente se eles possuem extenses executveis como .php. Sempre que possvel, devem ser mantidos fora da raiz web. Devem ser verificados se no esto sendo acessados diretamente, por exemplo, verificando por uma constante que pode somente ser criada atravs de uma biblioteca do chamador. No suponha que usurios no estaro atentos acessar URLs ou APIs escondidas ou especiais. Sempre se assegure que aes com privilgios altos e administrativos estaro protegidos. Bloqueie acesso a todos os tipos de arquivos que a sua aplicao no deva executar. Este filtro deve seguir a abordagem accept known good na qual apenas so permitidos tipos de arquivos que a aplicao deva executar, como por exemplo .html .pdf, .php. Isto ir bloquear qualquer tentativa de acesso a arquivos de log, arquivos XML, entre outros, aos quais se espera nunca serem executados diretamente. Mantenha o antivrus e as correes de segurana atualizados para componentes como processadores XML, processadores de texto, processadores de imagem, entre outros que manipulam arquivos fornecidos por usurios.
EXEMPLOS http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0147 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0131 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1227 REFERNCIAS

CWE: CWE-325 (Direct Request), CWE-288 (Authentication Bypass by Alternate Path), CWE-285 (Missing or Inconsistent Access Control) WASC Threat Classification: http://www.webappsec.org/projects/threat/classes/predictable_resource_location.shtml OWASP, http://www.owasp.org/index.php/Forced_browsing OWASP Guide, http://www.owasp.org/index.php/Guide_to_Authorization
30
OWASP TOP TEN 2007 AONDE IR A PARTIR DAQUI O OWASP Top 10 apenas o primeiro passo rumo a segurana das suas aplicaes web. Podemos dividir as 6 Milhes de pessoas que vivem no mundo em dois grupos: O primeiro grupo formado pelas pessoas que sabem porque a grande maioria das empresas de software lanam seu produtos com Bugs conhecidos e o segundo grupo formado pelas pessoas que no sabem porque isto ocorre. As pessoas do primeiro grupo geralmente tm seu otimismo juvenil estragado pela dura realidade. s vezes encontramos pessoas que pertencem aos dois grupos; so as pessoas que esto chocadas por ver que existem empresas lanando seus produtos antes de test-los e corrigir todos os bugs. (http://www.guardian.co.uk/technology/2006/may/25/insideit.guardianweeklytechnologysection) Eric Sink, Guardian 25 maio de 2006. A maioria dos seus clientes e usurios est no primeiro grupo. O modo com o qual voc encara este problema uma oportunidade de aumentar a segurana de suas aplicaes web no modo geral pois Bilhes de dlares so perdidos todos os anos e milhes de pessoas sofrem com fraude e roubo de identidade devido a vulnerabilidades discutidas neste documento.
AOS WEB-DESIGNERS Para garantir a segurana das suas aplicaes voc precisa saber o que voc est protegendo, conhea todas as ameaas e riscos de insegurana e classifique-os de forma estruturada. O Desenvolvimento de qualquer tipo de aplicao requer uma boa dose de segurana.
Certifique-se que voc est aplicando segurana baseando-se no modelo de ameaa de risco, no entanto como os modelos de normas (SOX, HIPAA, Basel,) esto cada vez mais caros torna-se mais conveniente investir tempo e recurso para satisfazer o mnimo necessrio para os dias atuais, porm as normas mais conhecidas so bem mais rgidas. Faa perguntas sobre necessidades empresariais, principalmente sobre requisitos no funcionais. Trabalhe seguindo o contrato de segurana de Software OWASP. Incentivar o desenvolvimento de Software seguro inclui uma defesa profunda e uma construo simples do cdigo utilizando o modelo de ameaa de risco. (ver [HOW1] no livro referncias) Certifique-se de ter considerado a confidencialidade, integridade, disponibilidade e no-repdio. Certifique-se de que seus Web-Designers so coerentes com a poltica de segurana e normas, tais como COBIT ou PCI DSS 1,1.
AOS DESENVOLVEDORES Muitos desenvolvedores j possuem uma boa base sobre segurana no desenvolvimento de aplicaes Web porm para garantir uma segurana efetiva no desenvolvimento de aplicaes Web requer muita experincia, pois qualquer leigo pode atacar um sistema.
Faa parte da comunidade e OWASP e freqente as reunies regionais. Procure por treinamentos sobre desenvolvimento de cdigo seguro. Desenvolva suas aplicaes com segurana, Crie cdigos simples e com profunda segurana. Desenvolva com aplicaes que favoream a segurana do cdigo. Reconstrua o cdigo de forma segura de acordo com a sua plataforma utilizando pesquisas otimizadas. Leia o guia OWASP e comece a aplicar controles mais seguros a seu cdigo, diferente do outros guias ele desenvolvido para ajud-lo a criar aplicaes seguras e no a quebr-las. Faa os testes de segurana e defeitos do seu cdigo e torne esta prtica constante no seu dia-a-dia.
31
OWASP TOP TEN 2007

Revise o livro de referncias e veja se existem opes que se aplicam ao seu ambiente de trabalho.
PARA PROJETOS DE CDIGO ABERTO O cdigo aberto um desafio particular para a segurana de aplicaes web. Existem milhares de projetos de cdigo aberto tanto pessoais como o Apache (www.apache.org) e Tomcat (tomcat.apache.org/) quanto em larga escala como PostNuke (www.postnuke.com).
Faa parte da comunidade e OWASP e freqente as reunies regionais. Se o seu projeto possui mais de quatro desenvolvedores, deixe pelo menos um deles responsvel pela segurana. Desenvolva suas aplicaes com segurana, Crie cdigos simples e com boa segurana. Desenvolva com normas que favoream a segurana do cdigo. Divulgue a poltica de segurana de forma responsvel para garantir que os problemas de segurana esto sendo tratados corretamente. Revise o livro de referncias e veja se existem opes que se aplicam ao seu ambiente de trabalho.
PARA OS PROPRIETRIOS DE APLICAO Os proprietrios de aplicaes comerciais geralmente tm tempo e recursos reduzidos. Os Proprietrios de aplicaes devem:
Trabalhar com o contrato de segurana de software OWASP anexo com os produtores de softwares. Garantir que os requisitos de negcio incluem requisitos no-funcionais (non-functional requirements, NFRs), tais como requisitos de segurana. Estimule os desenvolvedores a criar aplicaes com cdigo simples e com boa segurana. Contrate (ou treine) desenvolvedores com bons conhecimentos em segurana. Faa testes de segurana em todo o projeto, desenvolvimento, criao, testes e implementao. Reserve recurso e tempo no oramento do projeto para cuidar de questes de segurana.
AOS DIRETORES EXECUTIVOS Sua empresa precisa ter um ciclo de vida de desenvolvimento seguro. As vulnerabilidades so mais fceis de serem corrigidas durante o desenvolvimento do que aps o produto j ter sido lanado. Possuir um ciclo de vida de desenvolvimento seguro no inclui somente os testes para o Top 10, tambm inclui:
Ao vender software assegure-se de estar incluindo polticas e contratos com termos de segurana. Para cdigo customizado adote codificao segura, principalmente nas suas polticas e normas. Para cdigo customizado adote codificao segura, principalmente nas suas polticas e normas. Para cdigo customizado adote codificao segura, principalmente nas suas polticas e normas. Notifique seus produtores de software sobre a importncia da segurana para os resultados da empresa. Treine seus web-designers e projetistas nos fundamentos de segurana em aplicaes web. Considere a possibilidade do cdigo ser auditado por terceiros para que haja uma anlise mais independente. Adote prticas responsveis de divulgao e construa um processo para responder adequadamente aos relatrios de vulnerabilidade dos seus produtos.
32
OWASP TOP TEN 2007 REFERNCIAS PROJETOS DA OWASP OWASP o site principal sobre segurana de aplicaes web. O site da OWASP hospeda diversos projetos, fruns, blogs, apresentaes, ferramentas e artigos. A OWASP organiza duas grandes conferncias de segurana por ano e mais de 80 captulos locais. Os seguintes projetos da OWASP so mais comuns de serem utilizados:
OWASP Guide to Building Secure Web Applications OWASP Testing Guide OWASP Code Review Project (in development) OWASP PHP Project (in development) OWASP Java Project OWASP .NET Project
LIVROS Por necessidade, esta no uma lista exaustiva. Use-a como referncia para encontrar a rea apropriada em sua livraria local e selecione alguns ttulos (incluindo um ou mais dos seguintes) que satisfaam suas necessidades:
[ALS1] Alshanetsky, I. php|architect's Guide to PHP Security, ISBN 0973862106 [BAI1] Developing more secure ASP.NET 2.0 Applications, ISBN 978-0-7356-2331-6 [GAL1] Gallagher T., Landauer L., Jeffries B., "Hunting Security Bugs", Microsoft Press, ISBN 073562187X [GRO1] Fogie, Grossman, Hanse Cross Site Scripting Attacks: XSS Exploits and Defense, ISBN 1597491543 [HOW1] Howard M., Lipner S., "The Security Development Lifecycle", Microsoft Press, ISBN 0735622140 [SCH1] Schneier B., "Practical Cryptography", Wiley, ISBN 047122894X [SHI1] Shiflett, C. Essential PHP Security, ISBN 059600656X [WYS1] Wysopal et al, The Art of Software Security Testing: Identifying Software Security Flaws, ISBN 0321304861
WEB SITES
OWASP, http://www.owasp.org MITRE, Common Weakness Enumeration Vulnerability Trends, http://cwe.mitre.org/documents/vulntrends.html Web Application Security Consortium, http://www.webappsec.org/ SANS Top 20, http://www.sans.org/top20/ PCI Security Standards Council, publishers of the PCI standards, relevant to all organizations processing or Holding credit card data, https://www.pcisecuritystandards.org/ PCI DSS v1.1, https://www.pcisecuritystandards.org/pdfs/pci_dss_v1-1.pdf Build Security In, US CERT, https://buildsecurityin.us-cert.gov/daisy/bsi/home.html
33

Owasp Top 10 2007 PT-BR - Seguranca Web

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

Owasp Top 10 2007 PT-BR - Seguranca Web

Caricato da

Copyright:

Formati disponibili

OWASP TOP 10

As 10 vulnerabilidades de segurana mais crticas em aplicaes WEB

OWASP TOP TEN 2007

OWASP TOP TEN 2007 NDICE

OWASP TOP TEN 2007

OWASP TOP TEN 2007 SUMRIO

A3 Execuo maliciosa de arquivos

A10 Falha de Restrio de Acesso URL

Tabela 1: TOP 10 vulnerabilidade de aplicaes Web para 2007

OWASP TOP TEN 2007

A10. Falha de Restrio de Acesso URL

<Removido em 2007> <Removido em 2007> <Removido em 2007> <Removido em 2007>

Recomendaes especficas por linguagem:

OWASP TOP TEN 2007

OWASP TOP TEN 2007

Recomendaes especficas por linguagem:

OWASP TOP TEN 2007

OWASP TOP TEN 2007

OWASP TOP TEN 2007

OWASP TOP TEN 2007

EXEMPLOS http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0147 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0131 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1227 REFERNCIAS

OWASP TOP TEN 2007

Potrebbero piacerti anche