As 10 Vulnerabilidades de Segurança Mais PDF

OWASP TOP 10
As 10 vulnerabilidades de segurana mais

crticas em aplicaes WEB

2007
VERSO: PORTUGUS (BRASIL)

2002-2007 OWASP Foundation
O contedo deste documento licenciado pela licena Creative Commons Attribution-ShareAlike 2.5.

OWASP TOP TEN 2007

Notas da verso
Esta verso do Top 10 2007 foi desenvolvida como parte das atividades do captulo Brasil da OWASP em
prol da comunidade de desenvolvedores e de segurana do Brasil. Participaram desta traduo:
Cleber Brando Clebeer - Analista de Controle de Qualidade - BRconnection
Fabricio Ataides Braz
Leonardo Cavallari Militelli Especialista de Segurana - E-val Tecnologia
Marcos Aurlio Rodrigues - Analista Segurana - BRconnection
Myke Hamada
Rodrigo Montoro Sp0oKer - Analista Segurana - BRconnection
Para saber mais sobre os eventos e atividades desenvolvidas pelo captulo Brasil, acesse o site ou
cadastre-se na lista de discusso OWASP-BR.

OWASP TOP TEN 2007

2

NDICE

ndice ............................................................................................................................................................. 2
Introduo ..................................................................................................................................................... 3
Sumrio ......................................................................................................................................................... 4
Metodologia .................................................................................................................................................. 5
A1 Cross Site Scripting ................................................................................................................................ 8
A2 Falhas de Injeo ................................................................................................................................ 11
A3 Execuo Maliciosa de Arquivo .......................................................................................................... 13
A4 Referncia Insegura Direta a objeto ................................................................................................... 16
A5 Cross Site Request Forgery (CSRF) ...................................................................................................... 18
A6 Vazamento de Informaes e Tratamento de erros inapropriado ..................................................... 21
A7 Furo de Autenticao e Gerncia de Sesso ....................................................................................... 23
A8 Armazenamento criptogrtafico inseguro............................................................................................ 25
A9 Comunicaes Inseguras..................................................................................................................... 27
A10 Falha ao Restringir Acesso URLs .................................................................................................... 29
Aonde ir a partir daqui ................................................................................................................................ 31
Referncias .................................................................................................................................................. 33

OWASP TOP TEN 2007

3

INTRODUO
Bem vindo ao OWASP TOP 10 2007! Esta edio completamente reescrita lista as mais srias
vulnerabilidades em aplicaes WEB, discute como se proteger contra elas e prov links para mais
detalhes.
OBJETIVO
O objetivo principal do OWASP TOP 10 educar desenvolvedores, designers, arquitetos e
organizaes a respeito das conseqncias das vulnerabilidades mais comuns encontradas em
aplicaes WEB. O TOP 10 prov mtodos bsicos para se proteger dessas vulnerabilidades um timo
comeo para a codificao segura de um programa de segurana.
Segurana no um evento nico. No suficiente considerar a segurana de cdigo uma nica vez.
Em 2008, esse Top 10 ser modificado e, caso no mude uma linha do cdigo de sua aplicao, voc
poder estar vulnervel. Portanto, revise as dicas em Where to go from here para mais detalhes.
Uma iniciativa de codificao segura deve abordar todos os estgios do ciclo de vida de um programa.
As aplicaes WEB seguras so possveis apenas quando um SDLC seguro utilizado. Os programas
seguros so seguros por concepo, durante seu desenvolvimento e por padro. Existem no mnimo 300
problemas que afetam a segurana das aplicaes WEB como um todo. Estes 300 ou mais so
detalhados no Guia OWASP, cuja leitura essencial para qualquer um que se interesse por desenvolver
aplicaes WEB.
Este documento , primeiramente, um recurso de estudo, no um padro. No adote este documento
como uma poltica ou padro sem falar conosco primeiro! Se voc precisa de uma poltica de codificao
e desenvolvimento seguro, a OWASP possui este tipo de documentos alm de projetos de padronizao
em andamento. Por favor, considere a possibilidade de se associar ou sustentar financeiramente estas
iniciativas.
AGRADECIMENTOS
Ns gostaramos de agradecer o MITRE por tornar pblico e gratuitamente os dados da Vulnerability
Type Distribution no CVE. O projeto OWASP Top 10 liderado e patrocinado pela Aspect Security.
Lider do projeto: Andrew van der Stock (Diretor Executivo, OWASP Foundation)
Coautores: Jeff Williams (Chair, OWASP Foundation), Dave Wichers (Conference Chair, OWASP
Foundation).
Ns gostaramos de agradecer nossos revisores:
Raoul Endres por ajudar em manter o Top 10 ativo novamente e por seus valiosos comentrios
Steve Christey (MITRE) por sua extensiva reviso e adio das informaes do MITRE CWE
Jeremiah Grossman (White Hat Security) pelas revises e contribuies valiosas sobre as formas
automatizadas de deteco.
Sylvan Von Stuppe por sua reviso exemplar
Colin Wong, Nigel Evans, Andre Gironda, Neil Smithline pelos comentrios enviados por email.

OWASP TOP TEN 2007

4

SUMRIO
A1 Cross Site Scripting (XSS) Os furos XSS ocorrem sempre que uma aplicao obtm as informaes fornecidas pelo
usurio e as envia de volta ao navegador sem realizar validao ou codificao daquele
contedo. O XSS permite aos atacantes executarem scripts no navegador da vtima, o qual
pode roubar sesses de usurio, pichar sites Web, introduzir worms, etc.
A2 Falhas de Injeo As falhas de injeo, em especial SQL Injection, so comuns em aplicaes Web. A injeo
ocorre quando os dados fornecidos pelo usurio so enviados a um interpretador com
parte do comando ou consulta. A informao maliciosa fornecida pelo atacante engana o
interpretador que ir executar comandos mal intencionados ou manipular informaes.
A3 Execuo maliciosa de
arquivos
Os cdigos vulnerveis incluso remota de arquivos (RFI) permite ao atacante incluir
cdigo e dados maliciosos, resultando em ataques devastadores, como o
comprometimento total do servidor. Os ataques de execuo de arquivos maliciosos afeta
PHP, XML e todos os frameworks que aceitem nomes de arquivo ou arquivos dos usurios.
A4 Referncia Insegura Direta
Objetos
Uma referncia direta objeto ocorre quando um desenvolvedor expe a referncia a um
objeto implementado internamente, como o caso de arquivos, diretrios, registros da
base de dados ou chaves, na forma de uma URL ou parmetro de formulrio. Os atacantes
podem manipular estas referncias para acessar outros objetos sem autorizao.
A5 Cross Site Request Forgery
(CSRF)
Um ataque CSRF fora o navegador da vtima, que esteja autenticado em uma aplicao, a
enviar uma requisio pr-autenticada um servidor Web vulnervel, que por sua vez
fora o navegador da vtima a executar uma ao maliciosa em prol do atacante. O CSRF
pode ser to poderoso quanto a aplicao Web que ele ataca.
A6 Vazamento de
Informaes e Tratamento de
Erros Inapropriado
As aplicaes podem divulgar informaes sobre suas configuraes, processos internos
ou violar a privacidade por meio de uma srie de problemas na aplicao, sem haver
qualquer inteno. Os atacantes podem usar esta fragilidade para roubar informaes
consideradas sensveis ou conduzir ataques mais estruturados.
A7 Autenticao falha e
Gerenciamento de Sesso
As credenciais de acesso e token de sesso no so protegidos apropriadamente com
bastante freqncia. Atacantes comprometem senhas, chaves ou tokens de autenticao
de forma a assumir a identidade de outros usurios.
A8 Armazenamento
Criptogrfico Inseguro
As aplicaes Web raramente utilizam funes criptogrficas de forma adequada para
proteo de informaes e credenciais. Os atacantes se aproveitam de informaes mal
protegidas para realizar roubo de identidade e outros crimes, como fraudes de cartes de
crdito.
A9 Comunicaes inseguras As aplicaes freqentemente falham em criptografar trfego de rede quando se faz
necessrio proteger comunicaes crticas/confidenciais.
A10 Falha de Restrio de
Acesso URL
Frequentemente, uma aplicao protege suas funcionalidades crticas somente pela
supresso de informaes como links ou URLs para usurios no autorizados. Os atacantes
podem fazer uso desta fragilidade para acessar e realizar operaes no autorizadas por
meio do acesso direto s URLs.
Tabela 1: TOP 10 vulnerabilidade de aplicaes Web para 2007

OWASP TOP TEN 2007

5

METODOLOGIA
Nossa metodologia para o TOP 10 de 2007 foi simples: pegamos o estudo de Tendncia de
Vulnerabilidades para 2006 do MITRE e extramos as 10 principais vulnerabilidade relativas aplicaes
Web. O resultado apresentado a seguir:

Figura 1: Dados do MITRE para as Top 10 vulnerabilidades de aplicaes Web para 2006
Apesar da tentativa de preservao do mapeamento um a um das estatsticas de vulnerabilidades do
MITRE para nomear cada seo do documento, ns mudamos deliberadamente algumas categorias com
o intuito de mapear de forma mais apropriada as causas principais. Se voc est interessado nas
estatsticas finais originais do MITRE, ns inclumos uma planilha Excel na pgina do projeto OWASP Top
10.
Todas as recomendaes de proteo provm solues para os trs mais prevalentes frameworks de
aplicao Web: Java EE, ASP .NET e PHP. Outros frameworks utilizados, como Ruby on Rails e Perl
podem adaptar facilmente as recomendaes para satisfazer necessidades especficas.
POR QUE NS DESCARTAMOS ALGUNS PROBLEMAS IMPORTANTES
Entrada de dados no validados o maior desafio para qualquer time de desenvolvimento e a origem
dos problemas de segurana de muitas aplicaes. De fato, muitos dos itens presentes na lista
recomendam a validao de entrada como parte da soluo. Ns recomendamos criar um mecanismo
de validao centralizado como parte de sua aplicao. Para maiores informaes, leia os seguintes
documentos de validao de dados da OWASP:
http://www.owasp.org/index.php/Data_Validation
http://www.owasp.org/index.php/Testing_for_Data_Validation
Problemas de estouro de pilhas, estouro de inteiros e formato de strings so vulnerabilidades
extremamente srias para programas escritos em linguagem C ou C++. A remediao para estes tipos de
problemas so tratados por comunidades de segurana de aplicaes tradicionais, como o SANS, CERT e
pelos fornecedores de linguagem de programao. Se o seu cdigo escrito em uma linguagem que
passvel a estouros de pilha, ns encorajamos voc a ler os contedos a este respeito no site da OWASP:

OWASP TOP TEN 2007

6

http://www.owasp.org/index.php/Buffer_overflow
http://www.owasp.org/index.php/Testing_for_Buffer_Overflow
Gerenciamento de configurao insegura afeta todos os sistemas em alguma extenso, particularmente
o PHP. No entanto, o ranking do MITRE no nos permite incluir este problema neste ano. Quando
implementando sua aplicao, voc deve consultar a ltima verso do OWASP Guide e o OWASP testing
Guide para informaes detalhadas a respeito do gerenciamento de configurao segura e testes:
http://www.owasp.org/index.php/Configuration
http://www.owasp.org/index.php/Testing_for_infrastructure_configuration_management
POR QUE NS ADICIONAMOS ALGUNS PROBLEMAS IMPORTANTES
Cross Site Request Forgery (CSRF) a maior nova incluso nesta edio do OWASP Top 10. Embora
ocupe a 36 posio na classificao original, ns acreditamos que ela seja de tamanha importncia, que
as aplicaes devem iniciar seus esforos de proteo hoje, particularmente para aplicaes de alto risco
e criticidade. O CSRF mais prevalente do que sua atual classificao e pode ser mais perigoso.
Criptografia. O uso incorreto da criptografia no ocupam as posies 8 e 9 da classificao, conforme as
informaes do MITRE, porm representam a origem de muitos problemas de quebra de privacidade e
conformidade (particularmente a conformidade com o PCI DSS 1.1).
VULNERABILIDADES, NO ATAQUES
A edio anterior do Top 10 continha um misto de ataques, vulnerabilidades e contramedidas. Esta vez,
ns focamos unicamente em vulnerabilidades, embora a terminologia utilizada comumente combine
vulnerabilidades e ataques. Se organizaes usam este documento para tornar suas aplicaes seguras
e, consequentemente, reduzir o risco para seus negcios, ser possvel observar uma reduo direta nos
seguintes pontos:
Ataques de phishing, que podem explorar qualquer uma dessas vulnerabilidades, particularmente, XSS
e problemas de autenticao e autorizao (A1,A4,A7,A10)
Violao de privacidade devido validao fraca, regras de negcio e verificaes de autorizao fracas
(A2, A4, A6, A7, A10)
Roubo de identidade por meio de controles de criptografia fracos ou no existentes (A8 e A9), incluso
de arquivo remoto (A3) e autenticao, regras de negcio e verificao de autorizao (A4, A7, A10)
Comprometimento de sistema, alterao de informaes e destruio de dados por ataques de injeo
(A2) e incluso de arquivo remoto (A3)
Perda financeira por meio de transaes no autorizadas e ataques CSRF (A4, A5, A7, A10)
Perda de reputao devido explorao de qualquer uma das vulnerabilidades acima (A1 A10)
Uma vez que a organizao se distancie da preocupao de controles reativos e vai de encontro pro -
atividade na reduo de riscos de seu negcio, ela melhorar a conformidade com regimes regulatrios,
reduzir custos operacionais, e certamente ter um sistema mais robusto e seguro como resultado.
DIRECIONAMENTO
A metodologia descrita acima necessariamente direciona o Top 10 a favor das descobertas da
comunidade de pesquisadores de segurana. A forma de descoberta de falhas similar ao mtodo
utilizado em ataques reais, em especial, no que se refere pseudo-atacantes (script kiddies).
Protegendo sua aplicao contra as vulnerabilidades do Top 10 prover uma proteo mdica contra as
formas mais comuns de ataque e mais, ajudar a traar um rumo para melhoria da segurana de seu
software.

OWASP TOP TEN 2007

7

MAPEAMENTO
Nesta verso do Top 10 houve mudanas nos ttulos das vulnerabilidades, mesmo quando o contedo se
relaciona fortemente ao contedo anterior. Ns no utilizamos mais o esquema de nomenclatura WAS
XML pelo fato deste no se manter atualizado com as vulnerabilidades modernas, ataques e
contramedidas. A tabela abaixo representa como esta edio se relaciona com o Top 10 2004 e a
classificao do MITRE:

OWASP Top 10 2007 OWASP Top 10 2004
Classificao do MITRE
2006
A1. Cross Site Scripting (XSS) A1. Cross Site Scripting (XSS) 1
A2. Falhas de Injeo A6. Falhas de Injeo 2
A3. Execuo Maliciosa de Arquivos (NOVO) 3
A4. Referncia Insegura Direta Objetos A2. Controle de Acesso Falho (dividido no TOP 10
2007)
5
A5. Cross Site Request Forgery (CSRF) (NOVO) 36
A6. Vazamento de Informaes e Tratamento de
Erros Inapropriados
A7. Tratamento inapropriado de erros 6
A7. Falha de Autenticao e Gerenciamento de
Sesso
A3. Falha de Autenticao e Gerenciamento de
Sesso
14
A8. Armazenamento Criptogrfico Inseguro A8. Armazenamento Inseguro 8
A9. Comunicaes inseguras Discutido em A10. Gerenciamento Inseguro de
Configurao
8
A10. Falha de Restrio de Acesso URL A2. Controle de Acesso Falho (dividido no TOP 10
2007)
14
<Removido em 2007> A1. Entrada no Validada 7
<Removido em 2007> A5. Estouro de buffer 4, 8, e 10
<Removido em 2007> A9. Negao de Servio 17
<Removido em 2007> A10. Gerenciamento Inseguro de Configurao 29
Tabela 2: Relacionamento das vulnerabilidades das edies 2004 e 2007 do Top 10 e a classificao do MITRE.

OWASP TOP TEN 2007

A1 CROSS SITE SCRIPTING
O Cross Site Scripting, mais conhecido como XSS, de fato um subconjunto de inseres HTML. XSS a
questo de segurana em aplicaes web mais prevalente e perniciosa. Os furos XSS ocorrem em
aplicaes quaisquer que receba dados originados do usurio e o envie ao navegador sem
primeiramente validar ou codificando aquele contedo.
O XSS permite atacantes executarem script no navegador da vtima, que pode seqestrar sesses de
usurios, desfigurar web sites, inserir contedo hostil, conduzir ataques de roubo de informaes
pessoais (phishing) e obter o controle do navegador do usurio usando um script mal intencionado
(malware). O script malicioso freqentemente em Java Script, mas qualquer linguagem de script
suportada pelo navegador da vtima um alvo potencial para este ataque.
AMBIENTES AFETADOS
Todos os frameworks de aplicao web so vulnerveis a Cross Site Scripting (XSS).
VULNERABILIDADE
Existem trs tipos bem conhecidos de XSS: refletido, armazenado e insero DOM. O XSS refletido o de
explorao mais fcil uma pgina refletir o dado fornecido pelo usurio como retorno direto a ele:
echo $_REQUEST['userinput'];
O XSS armazenado recebe o dado hostil, o armazena em arquivo, banco de dados ou outros sistemas de
suporte informao e ento, em um estgio avanado mostra o dado ao usurio, no filtrado. Isto
extremamente perigoso em sistemas como CMS, blogs ou fruns, onde uma grande quantidade de
usurios acessar entradas de outros usurios.
Com ataques XSS baseados em DOM, o cdigo Java Script do site e as variveis so manipulados ao invs
dos elementos HTML.
Alternativamente, os ataques podem ser uma mistura ou uma combinao dos trs tipos. O perigo com
o XSS no est no tipo de ataque, mas na sua possibilidade. Comportamentos no padro do navegador
pode introduzir vetores de ataque sutis. O XSS tambm potencialmente habilitado a partir de
quaisquer componentes que o browser utilize.
Os ataques so freqentemente implementados em Java Script, que uma ferramenta poderosa de
scripting. O uso do Java Script habilita atacante a manipular qualquer aspecto da pgina a ser
renderizada, incluindo a adio de novos elementos (como um espao para login que encaminha
credenciais para um site hostil), a manipulao de qualquer aspecto interno do DOM e a remoo ou
modificao de forma de apresentao da pgina. O Java Script permite o uso do XmlHttpRequest, que
tipicamente usado por sites que usam a tecnologia AJAX, mesmo se a vtima no use o AJAX no seu site.
O uso do XmlHttpRequest permite, em alguns casos, contornar a poltica do navegador conhecida como
"same source origination" assim, encaminhando dados da vtima para sites hostis e criar worms
complexos e zumbis maliciosos que duram at o fechamento do navegador. Os ataques AJAX no
necessitam ser visveis ou requerem interao com o usurio para realizar os perigosos ataques cross
site request forgery (CSRF) (vide A-5).
VERIFICAO DE SEGURANA
O objetivo verificar que todos os parmetros da aplicao so validados e/ou recodificados antes de
ser includos em pginas HTML.

OWASP TOP TEN 2007

9

Abordagens automatizadas: ferramentas de teste de penetrao automatizadas so capazes de
detectar XSS de reflexo a partir de injeo de parmetro, mas freqentemente falha na localizao de
XSS persistente, particularmente se a sada do vetor de injeo XSS prevenida via verificao de
autorizao (como por exemplo, se um usurio fornece dados de entradas maliciosos que so vistos
posteriormente apenas pelos administradores). Ferramentas de anlise de cdigo fonte podem
encontrar pontos APIs com falhas ou perigosas, mas comum no poderem determinar se a validao
ou recodificao foram aplicadas, que pode resultar em falsos positivos. Nenhuma ferramenta capaz
de encontrar XSS baseado em DOM, isso significa que aplicaes em Ajax estaro sempre em risco se
somente forem aplicados testes automatizados.
Abordagens manuais: caso um mecanismo centralizado de validao e recodificao for usado, a
maneira mais eficiente de verificar a segurana verificar o cdigo. Se uma implementao distribuda
for usada, ento a verificao demandar esforo adicional considervel. O teste demanda muito
esforo, pois a superfcie de ataque da maioria das aplicaes muito grande.
PROTEO
A melhor proteo para XSS est na combinao de validao de lista branca de todos os dados de
entrada e recodificao apropriada de todos os dados de entrada. A validao habilita a deteco de
ataques e a recodificao previne qualquer injeo de script bem sucedida de ser executada no
navegador. A preveno de XSS ao longo da aplicao como um todo requer uma abordagem
arquitetural consistente.
Validao de entrada: utilize mecanismo padro de validao de entrada para validar todas as entradas
quanto ao tamanho, tipo, sintaxe e regras de negcio antes de aceitar que o dado seja mostrado ou
armazenado. Use uma estratgia de validao aceite o conhecido como bom. Rejeite entrada invlida
ao invs da tentativa de corrigir dados potencialmente hostis. No se esquea que as mensagens de erro
podem tambm incluir dados invlidos.
Forte codificao de sada: garanta que qualquer dado de entrada do usurio esteja apropriadamente
codificado (tanto para HTML ou XML dependendo do mecanismo de sada) antes da renderizao, usando
a abordagem de codificao de todos os caracteres, com exceo de um subconjunto muito limitado. Esta
a abordagem da biblioteca Microsoft Anti-XSS e a biblioteca prevista OWASP PHP Anti-XSS.
Adicionalmente, configure a codificao de caracteres para cada pgina a ser produzida como sada, que
diminuir a exposio a algumas variaes.
Especifique a codificao de sada (como ISO 8859-1 ou UTF-8): No permita que o atacante escolha isso
para seus usurios.
No use validao de lista negra para detectar XSS na entrada ou codificao de sada. A procura ou
troca de poucos caracteres ("<" ">" e outros caracteres similares ou frases como script) fraco e tem
sido explorado com sucesso. Mesmo uma tag <b> no verificada insegura em alguns contextos. O XSS
possui um conjunto surpreendente de variantes que torna simples ultrapassar validaes de lista negra
(Blacklist).
Cuidado com os erros de converso. As entradas devem ser decodificadas e convertidas para a
representao interna corrente antes de ser validada. Certifique-se que sua aplicao no decodifica a
mesma entrada duas vezes. Tais erros podem ser usados para ultrapassar esquemas de lista branca pela
introduo de entradas perigosas aps serem checados.

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

OWASP TOP TEN 2007

10

.NET: use a biblioteca Microsoft Anti-XSS 1.5 disponvel sem custo do MSDN. No atribua campos de
formulrio diretamente do objeto Request: username.Text = Request.QueryString("username"); sem usar
esta biblioteca. Entenda quais controles .NET codificam automaticamente o dado de sada.
PHP: garanta que a sada passe pelo htmlentities() ou htmlspecialchars() ou use a biblioteca PHP Anti-XSS
que est para ser lanada pela OWASP. Desabilite register_globals, caso este no tenha sido desabilitado.
EXEMPLOS
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4206
REFRENCIAS
CWE: CWE-79, Cross-Site scripting (XSS)
WASC Threat Classification: http://www.webappsec.org/projects/threat/classes/cross-site_scripting.shtml
OWASP Cross site scripting, http://www.owasp.org/index.php/Cross_Site_Scripting
OWASP Testing for XSS, http://www.owasp.org/index.php/Testing_for_Cross_site_scripting
OWASP Stinger Project (A Java EE validation filter)
http://www.owasp.org/index.php/Category:OWASP_Stinger_Project
OWASP PHP Filter Project - http://www.owasp.org/index.php/OWASP_PHP_Filters
OWASP Encoding Project - http://www.owasp.org/index.php/Category:OWASP_Encoding_Project
RSnake, XSS Cheat Sheet, http://ha.ckers.org/xss.html
Klein, A., DOM Based Cross Site Scripting, http://www.webappsec.org/projects/articles/071105.shtml
.NET Anti-XSS Library - http://www.microsoft.com/downloads/details.aspx?FamilyID=efb9c819-53ff-4f82-
bfaf-e11625130c25&DisplayLang=en

OWASP TOP TEN 2007

11

A2 FALHAS DE INJEO
As falhas de Injeo, particularmente injeo SQL, so comuns em aplicaes web. Existem muitos tipos
de injeo: SQL, LDAP, XPath, XSLT, HTML, XML, comando de sistema operacional e muitas outras.
Falhas de Injeo acontecem quando os dados que o usurio d de entrada so enviados como parte de
um comando ou consulta. Os atacantes confundem o interpretador para o mesmo executar comandos
manipulados enviando dados modificados. As falhas de Injeo habilitam o atacante a criar, ler, atualizar
ou apagar arbitrariamente qualquer dado disponvel para a aplicao. No pior cenrio, estes furos
permitem ao atacante comprometer completamente a aplicao e os sistemas relacionados, at pelo
contorno de ambientes controlados por firewall.
AMBIENTES AFETADOS
Todos os frameworks de aplicao web que usem interpretadores ou invoquem outros processos so
vulnerveis a ataques por injeo. Isto inclui quaisquer componentes do framework que possam usar
interpretadores como back-end.
VULNERABILIDADE
Caso uma entrada de usurio seja fornecida a um interpretador sem validao ou codificao, a
aplicao vulnervel. Verifique se a entrada de usurio fornecida queries dinmicas, como por
exemplo:
PHP:
$sql = "SELECT * FROM table WHERE id = '" . $_REQUEST['id] . "";
Java:
String query = "SELECT user_id FROM user_data WHERE user_name = '" +
req.getParameter("userID") + "' and user_password = '" + req.getParameter("pwd") +"'";
O objetivo verificar se os dados do usurio no possam modificar os comandos e queries enviadas a
interpretadores invocadas para a aplicao.
Abordagens automatizadas: muitas ferramentas de varredura de vulnerabilidades localizam falhas de
Injeo, particularmente Injeo SQL. Ferramentas de anlise esttica que localizam o uso de APIs de
interpretadores no seguras so teis, mas freqentemente no podem verificar que uma validao ou
codificao adequada possa estar em uso para proteger contra tal ameaa. Caso a aplicao gerencie
erros internos de servidor 501 / 500 ou erros de banco de dados detalhados, isto pode atrapalhar a
varredura por ferramentas automatizadas, mas o cdigo ainda continuar em risco. Ferramentas
automatizadas so capazes de detectar injees LDAP / XML / XPath.
Abordagens manuais: a abordagem mais eficiente e precisa verificar o cdigo que invoca
interpretadores. O revisor deve verificar o uso de API segura ou que validao e/ou codificao
apropriada acontece. O teste pode ser extremamente demorado com baixa cobertura devido ao fato da
superfcie de ataque na maioria das aplicaes ser grande.
PROTEO
Evite o uso de interpretadores quando possvel. Caso invoque um interpretador, o mtodo chave para
evitar injees est no uso de APIs seguras, como por exemplo, queries parametrizadas e bibliotecas de
mapeamento objeto relacional (ORM).

OWASP TOP TEN 2007

12

Estas interfaces manipulam todas as fugas dados, ou aquelas que no demandam fuga. Note que
enquanto interfaces seguras resolvem o problema, validao ainda recomendada para detectar
ataques.
O uso de interpretadores perigoso, portanto so recomendados cuidados extras, como os seguintes:
Validao de entrada: utilize mecanismo padro de validao de entrada para validar todas as entradas
quanto ao tamanho, tipo, sintaxe e regras de negcio antes de aceitar que o dado seja mostrado ou
armazenado. Use uma estratgia de validao aceite o reconhecido como bom. Rejeite entrada invlida
ao invs da tentativa de checar dados potencialmente hostis. No se esquea que as mensagens de erro
podem tambm incluir dados invlidos.
Use APIs de query fortemente tipado com substituidores de espaos reservados, mesmo quando usar
stored procedures.
Imponha o menor privilgio quando conectar a banco de dados ou outros sistemas de suporte.
Evite mensagens de erros detalhadas que sejam teis ao atacante.
Use stored procedures uma vez que elas so geralmente seguras contra injeo SQL. Entretanto, seja
cuidadoso, pois elas podem ser injetveis (como por exemplo, via o uso do exec() ) ou pela concatenao
de argumentos dentro da stored procedured.
No use interfaces de query dinmicas (como por exemplo, mysql_query() ou similares).
No use funes de fuga simples, como a addslashes() do PHP ou funes de substituio de caracteres
como str_replace("", ""). Elas so fracas e tm sido exploradas com sucesso por atacantes. Para PHP, use
mysql_real_escape_string() para MySQL ou preferencialmente use PDO que no requer fuga.
Quando usar mecanismo simples de fuga, note que funes simples de fuga no podem escapar nomes
de tabelas! Os nomes de tabelas devem ser SQL legal e assim completamente sem sentido para entrada
fornecida pelo usurio.
Localize erros de converso. As entradas devem ser decodificadas e convertidas para a representao
interna corrente antes de ser validada. Certifique-se que sua aplicao no decodifica a mesma entrada
duas vezes. Tais erros podem ser usados para ultrapassar esquemas de lista branca pela introduo de
entradas perigosas aps sua validao.
Recomendaes especficas por linguagem:
Java EE use PreparedStatement fortemente tipado ou ORMs como Hibernate ou Spring.
NET use queries parametrizadas fortemente tipadas, como SqlCommand com SqlParameter ou um ORM
como o Hibernate.
PHP use PDO com parametrizao fortemente tipada (using bindParam())
EXEMPLOS
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4592 REFERENCES
CWE: CWE-89 (SQL Injection), CWE-77 (Command Injection), CWE-90 (LDAP Injection), CWE-91 (XML
Injection), CWE-93 (CRLF Injection), others.
WASC Threat Classification:
http://www.webappsec.org/projects/threat/classes/ldap_injection.shtml
http://www.webappsec.org/projects/threat/classes/sql_injection.shtml
http://www.webappsec.org/projects/threat/classes/os_commanding.shtml
OWASP, http://www.owasp.org/index.php/SQL_Injection
OWASP Guide, http://www.owasp.org/index.php/Guide_to_SQL_Injection

OWASP TOP TEN 2007

13

A3 EXECUO MALICIOSA DE ARQUIVO
As vulnerabilidades de execuo de arquivos so encontradas em muitas aplicaes. Os
desenvolvedores tm por hbito usar diretamente ou concatenar entradas potencialmente hostis com
funes de arquivo ou stream, ou confiar de maneira imprpria em arquivos de entrada. Em muitas
plataformas, frameworks permitem o uso de referncias a objetos externos, como referncias a URLs ou
a arquivos de sistema. Quando o dado insuficiente verificado, isto pode levar a uma incluso arbitrria
remota que ser processado ou invocado um contedo hostil pelo servidor web.
Isto permite ao atacante realizar:
Execuo de cdigo remoto.
Instalao remota de rootkit e comprometimento total do sistema.
Em Windows, comprometimento interno do sistema pode ser possvel a partir do uso de PHPs SMB file
wrappers.
Este ataque particularmente prevalecente em PHP e cuidado extremo deve ser aplicado com qualquer
sistema ou funo de arquivo para garantir que a entrada fornecida pelo usurio no influencie os
nomes de arquivos.
AMBIENTES AFETADOS
Todos os frameworks de aplicao web so vulnerveis a execuo maliciosa de arquivo se eles aceitam
nomes de arquivos ou arquivos do usurio. Exemplos tpicos incluem: assemblies .NET que permitem
argumentos de nome de arquivos ou cdigo que aceita a escolha do arquivo pelo usurio de modo a
incluir arquivos locais.
O PHP particularmente vulnervel a ataque de incluso de arquivo remota (RFI) a partir de
manipulao de parmetro com qualquer API baseada em arquivo ou streams.
VULNERABILIDADE
Uma vulnerabilidade comum construda :
include $_REQUEST['filename];
Isto no somente permite a avaliao de scripts hostis remotos, mas pode ser usado para acessar
arquivos locais do servidor (caso o PHP seja hospedado no Windows) devido ao suporte SMB nos PHPs
file system wrappers. Outros mtodos de ataque incluem:
Upload de dados hostis a arquivos de sesses, dados de log e via imagens (tpico de software de frum).
Uso de compresso ou streams de udio, como por exemplo, zlib:// ou ogg:// que no inspecione a flag
interna do PHP e ento permite o acesso remoto a recursos, mesmo que allow_url_fopen ou
allow_url_include esteja desabilitado.
Usando PHP wrappers, como por exemplo, php://input e outros para coletar entrada da requisio de
dados POST ao invs de um arquivo.
Usando o PHPs data: wrapper, como por exemplo, data:;base64,PD9waHAgcGhwaW5mbygpOz8+.
Uma vez que essa lista extensa (e muda com periodicidade), vital que o uso de uma arquitetura
desenhada apropriado para segurana e design robusto quando manipulamos entradas fornecidas pelo
usurio que influenciem a escolha de nomes de arquivos e acesso no lado do servidor.
Apesar de fornecidos alguns exemplos em PHP, este ataque tambm aplicvel de maneiras diferentes
em .NET e J2EE. As aplicaes desenvolvidas nestes frameworks necessitam de ateno particular aos
mecanismos de segurana de acesso ao cdigo para garantir que os nomes de arquivos fornecidos ou

OWASP TOP TEN 2007

14

influenciados pelos usurios no habilitem que controles de segurana sejam desativados. Por exemplo,
possvel que documentos XML submetidos por um atacante ter um DTD hostil que force o analisador
XML a carregar um DTD remoto e analisar e processar os resultados. Uma empresa Australiana de
segurana demonstrou esta abordagem para varredura portas para firewalls. Veja [SIF01] nas
referncias deste artigo para maiores informaes.
O dano causado por essa vulnerabilidade est diretamente associado com os pontos fortes dos
controles de isolamento da plataforma no framework. Como o PHP raramente isolado e no possui o
conceito de caixa de areia "sandbox" ou arquitetura segura, o dano muito pior do que comparado com
outras plataformas com limitao ou confiana parcial, ou so contidos em uma sandbox confivel
como, por exemplo, quando uma aplicao web executada sob um JVM com um gerenciador de
segurana apropriado habilitado e configurado (que raramente o padro).
Abordagens automatizadas: ferramentas de localizao de vulnerabilidades possuem dificuldades em
identificar os parmetros que so usados para entrada do arquivo ou a sintaxe que os faam isso. As
ferramentas de anlise esttica podem localizar o uso de APIs perigosas, mas no podem verificar se a
validao ou codificao apropriada foi implementada para proteger contra a vulnerabilidade.
Abordagens manuais: uma reviso de cdigo pode localizar cdigo que possa permitir que um arquivo
seja includo na aplicao, mas existem muitos erros possveis de ser reconhecidos. Testes podem
detectar tais vulnerabilidades, mas identificar parmetros particulares e a sintaxe correta pode ser
difcil.
PROTEO
A preveno falhas de incluso de arquivos remotos exige um planejamento cuidadoso nas fases de
arquitetura e design, avanando para os testes. Em geral, uma aplicao bem desenvolvida no usa
entrada de usurio para nomes de arquivos para nenhum recurso de servidor (como imagens,
documentos XML e XSL ou incluso de script), e ter regras de firewall estabelecidas para prevenir
conexes de sada para a internet ou internamente como retorno a qualquer outro servidor.
Entretanto, muitas aplicaes legadas continuaro a ter a necessidade de aceitar entrada fornecida pelo
usurio.
Dentre as mais importantes consideraes, inclui-se:
Use um mapeamento indireto de objetos de referncia (veja a seo A4 para mais detalhes). Por
exemplo, quando um nome de arquivo parcial uma vez usado, considere um hash para a referncia
parcial. Ao invs de:
<select name=language>
<option value=English>English</option>
use
<select name=language>
<option value=78463a384a5aa4fad5fa73e2f506ecfc>English</option>
Considere o uso de salts para prevenir fora bruta em referncia indireta do objeto. Alternativamente,
use somente valores de ndices como 1, 2, 3 e garanta que os limites dos vetores so verificados para
detectar manipulao de parmetros.
Use mecanismos explcitos de verificao de corrupo, caso sua linguagem suporte isso. Caso contrrio,
considere um esquema de nomeao varivel para auxiliar na verificao de corrupo.
$hostile = &$_POST; // refer to POST variables, not $_REQUEST
$safe[filename]= validate_file_name($hostile[unsafe_filename]); // make it safe

OWASP TOP TEN 2007

15

Conseqentemente, qualquer operao baseada em entrada hostil se torna imediatamente bvia:
require_once($_POST[unsafe_filename] . inc.php);
require_once($safe[filename] . inc.php);
Forte validao de entrada de usurio usando uma estratgia de validao aceite o reconhecido como
bom.
Adicione regras no firewall para prevenir servidores web estabelecerem novas conexes externas com
sites web e sistemas internos. Para sistemas de alto valor, isole o servidor web em sua prpria VLAN ou
uma sub-rede privada.
Certifique-se que os arquivos ou nomes de arquivos fornecidos no desativam outros controles, como
por exemplo, dados corrompidos no objeto da sesso, avatares e imagens, relatrios PDF, arquivos
temporrios, etc.
Considere uma implementao de um chroot jail ou outros mecanismos de sandbox como
virtualizao para isolar aplicaes umas das outras.
PHP: desabilite allow_url_fopen e allow_url_include no php.ini e considere a construo de PHP
localmente sem a incluso dessa funcionalidade. Poucas aplicaes necessitam desta funcionalidade e
assim estas configuraes devem ser configuradas de acordo com a aplicao.
PHP: desabilite register_globals e use E_STRICT para localizar variveis no inicializadas.
PHP: garanta que todas as funes de arquivo ou de stream (stream_*) so cuidadosamente moderadas.
Certifique-se que a entrada do usurio no seja fornecida a qualquer funo que use o nome do arquivo
como argumento, incluindo:
include() include_once() require() require_once() fopen() imagecreatefromXXX() file()
file_get_contents() copy() delete() unlink() upload_tmp_dir() $_FILES move_uploaded_file()
PHP: Seja extremamente cauteloso caso o dado seja passado para system() eval() ou `.
Com o J2EE, certifique-se que o gestor de segurana seja habilitado e configurado apropriadamente e que
a aplicao demande as permisses apropriadas.
Com ASP.NET, recorra documentao referente confiana parcial e desenhe sua aplicao de forma a
ser segmentada por confiana, de forma que ela exista sob os estados mais baixos possveis de segurana.
EXEMPLOS
REFERNCIAS
CWE: CWE-98 (PHP File Inclusion), CWE-78 (OS Command Injection), CWE-95 (Eval injection), CWE-434
(Unrestricted file upload)
WASC Threat Classification: http://www.webappsec.org/projects/threat/classes/os_commanding.shtml
OWASP Guide, http://www.owasp.org/index.php/File_System#Includes_and_Remote_files
OWASP Testing Guide, http://www.owasp.org/index.php/Testing_for_Directory_Traversal
OWASP PHP Top 5, http://www.owasp.org/index.php/PHP_Top_5#P1:_Remote_Code_Execution
Stefan Esser, http://blog.php-security.org/archives/45-PHP-5.2.0-and-allow_url_include.html
[SIF01] SIFT, Web Services: Teaching an old dog new tricks,
http://www.ruxcon.org.au/files/2006/web_services_security.ppt
http://www.owasp.org/index.php/OWASP_Java_Table_of_Contents#Defining_a_Java_Security_Policy
Microsoft - Programming for Partial Trust, http://msdn2.microsoft.com/en-
us/library/ms364059(VS.80).aspx

OWASP TOP TEN 2007

16

A4 REFERNCIA INSEGURA DIRETA A OBJETO
Uma referncia direta a um objeto acontece quando um desenvolvedor expe uma referncia a um
objeto de implementao interna, como por exemplo, um arquivo, diretrio, registro na base de dados
ou chave, uma URL ou um parmetro de um formulrio. Um atacante pode manipular diretamente
referncias a objetos para acessar outros objetos sem autorizao, a no ser que exista um mecanismo
de controle de acesso.
Por exemplo, em aplicaes de Internet Banking comum o uso do nmero da conta como a chave
primria. Conseqentemente, pode ser tentador usar o nmero da conta diretamente na interface web.
Mesmo que os desenvolvedores tenham usado queries SQL parametrizadas para prevenir inseres de
comandos SQL (SQL injection), e caso no exista uma verificao adicional para garantir que o usurio
o proprietrio da conta e que est autorizado a ver a conta, um atacante pode manipular a partir do
parmetro do nmero da conta e possivelmente pode ver e modificar todas as contas.
Este tipo de ataque aconteceu no site da Australian Taxation Offices GST Start Up Assistance em 2000,
onde um usurio legtimo, mas hostil, simplesmente modificou o ABN (identificador da empresa)
presente na URL. O usurio se apossou de cerca de 17.000 registros de empresas cadastrados no
sistema, e ento enviou para cada uma das 17.000 empresas detalhes do ataque. Este tipo de
vulnerabilidade muito comum, porm no testada largamente em muitas aplicaes.
AMBIENTES AFETADOS
Todos os frameworks de aplicaes web esto vulnerveis a ataques a referncias diretas inseguras a
objetos.
VULNERABILIDADE
Muitas aplicaes expem referncias a objetos internos aos usurios. Atacantes manipulam
parmetros a fim de modificar as referncias e violarem a poltica de controle de acesso de forma
intencionalmente e sem muito esforo. Freqentemente, estas referncias apontam para arquivos do
sistema e banco de dados, mas qualquer aplicao exposta pode estar vulnervel.
Por exemplo, se o cdigo permite especificao de nomes de arquivos ou caminhos a partir da entrada
do usurio, isto pode permitir que atacantes acessem diretrios da aplicao que no esto publicados
e acessem outros recursos.
<select name="language"><option value="fr">Franais</option></select>

require_once ($_REQUEST['language]."lang.php");
Tal cdigo pode ser atacado usando uma string como ../../../../etc/passwd%00 usando injeo de um
byte nulo (vide OWASP Guide para mais detalhes) para acessar qualquer arquivo no sistema de arquivo
do servidor web.
Similarmente, referncias as chaves de banco de dados so freqentemente expostas. Um atacante
pode atacar estes parmetros simplesmente chutando ou procurando por outra chave vlida.
Geralmente, elas so seqenciais por natureza. No exemplo a seguir, mesmo que a aplicao no
apresente um link qualquer para um carrinho no autorizado e nenhuma injeo SQL seja possvel, um
atacante pode ainda modificar o parmetro cartID para qualquer outro desejado.
int cartID = Integer.parseInt( request.getParameter( "cartID" ) );
String query = "SELECT * FROM table WHERE cartID=" + cartID;

OWASP TOP TEN 2007

17

O objetivo consiste em verificar se a aplicao no permite que referncias diretas a objetos sejam
manipuladas por atacantes.
Abordagens automatizadas: scanners de vulnerabilidades possuem dificuldades de identificar os
parmetros susceptveis a manipulao ou se a manipulao aconteceu. As ferramentas de anlise
esttica no podem saber quais parmetros devem ter uma verificao de controle de acesso antes de
ser usado.
Abordagens manuais: uma reviso de cdigo pode localizar parmetros crticos e identificar se eles so
susceptveis a manipulao em muitos casos. Testes de penetrao podem verificar tambm quando tal
manipulao possvel. Entretanto, ambas as tcnicas so dispendiosas e podem no ser suficientes.
PROTEO
A melhor proteo evitar a exposio direta de referncias a objetos a usurios usando um ndice,
mapa de referncia indireta ou outro mtodo indireto que seja fcil de validar. Caso uma referncia
direta a objeto pode ser usada, garanta que o usurio esteja autorizado ante do uso.
O estabelecimento de uma forma padro para referenciar objetos da aplicao importante, pois:
Evita a exposio de referncias de objetos privados a usurios sempre que possvel, como chaves
primrias e nomes de arquivos.
Valide cada referncia privada a objeto atravs da abordagem aceite o reconhecido como bom.
Verifique a autorizao de todos os objetos referenciados.
A melhor soluo usar um valor de ndice ou um mapa de referncia para prevenir ataques de
manipulao de parmetro.
http://www.example.com/application?file=1

Caso necessite expor diretamente referncias s estruturas de banco de dados, certifique-se que as
declaraes SQL e outros mtodos de acesso base de dados permitam somente sejam mostrados
registros autorizados:
int cartID = Integer.parseInt( request.getParameter( "cartID" ) );
User user = (User)request.getSession().getAttribute( "user" );
String query = "SELECT * FROM table WHERE cartID=" + cartID + " AND userID=" +
user.getID();
EXEMPLOS
REFERNCIAS
CWE: CWE-22 (Path Traversal), CWE-472 (Web Parameter Tampering)
http://www.webappsec.org/projects/threat/classes/abuse_of_functionality.shtml
http://www.webappsec.org/projects/threat/classes/insufficient_authorization.shtml
OWASP Testing Guide, http://www.owasp.org/index.php/Testing_for_business_logic
OWASP Testing Guide, http://www.owasp.org/index.php/Testing_for_Directory_Traversal
OWASP, http://www.owasp.org/index.php/Category:Access_Control_Vulnerability
GST Assist attack details, http://www.abc.net.au/7.30/stories/s146760.htm

OWASP TOP TEN 2007

18

A5 CROSS SITE REQUEST FORGERY (CSRF)
Cross site request forgery no um novo ataque, mas simples e devastador. Um ataque CSRF fora o
navegador logado da vtima a enviar uma requisio para uma aplicao web vulnervel, que realiza a
ao desejada em nome da vtima.
Esta vulnerabilidade extremamente disseminada, uma vez que qualquer aplicao web:
No tenha verificao de autorizao para aes vulnerveis
Execute uma ao caso um login padro seja enviado na requisio (ex.
http://www.example.com/admin/doSomething.ctl?username=admin&passwd=admin)
Autorize requisies baseadas somente em credenciais que so automaticamente submetidas como, por
exemplo, cookie de sesso, caso logada corretamente na aplicao, ou a funcionalidade Relembrar-me,
se no logado na aplicao, ou um token Kerberos, se parte de uma Intranet que tenha o logon integrado
com o Active Directory.
Este tipo de aplicao estar em risco. Infelizmente, hoje, a maioria das aplicaes web confia
exclusivamente em credenciais submetidas automaticamente, como por exemplo, cookies de seo,
credenciais de autenticao bsica, endereo de IP de origem, certificados SSL ou credenciais de um
domnio Windows.
Esta vulnerabilidade tambm conhecida por outros diversos nomes incluindo Session Riding, Ataques
One-Click, Cross Site Reference Forgery, Hostile Linking e Automation Attack. O acrnimo XSRF
freqentemente usado. Ambos a OWASP e o MITRE padronizaram o uso do termo Cross Site Request
Forgery e CSRF.
AMBIENTES AFETADOS
Todos os frameworks de aplicaes web esto vulnerveis CSRF.
VULNERABILIDADE
Um ataque tpico CSRF contra um frum pode ter a forma de direcionar o usurio a invocar alguma
funo, como por exemplo, a pgina de logout da aplicao. A seguinte tag em qualquer pgina web
vista pela vtima gerar uma requisio que encerra sua seo:

<img src="http://www.example.com/logout.php">

Caso um banco permita sua aplicao a processar requisies, como a transferncia de fundos, um
ataque similar pode permitir:
<img src="http://www.example.com/transfer.do?frmAcct=document.form.frmAcct
&toAcct=4345754&toSWIFTid=434343&amt=3434.43">
Jeremiah Grossman em sua palestra na BlackHat 2006 Hacking Intranet Sites from the outside,
demonstrou ser possvel forar o usurio a modificar seu roteador DSL sem seu consentimento; mesmo
que o usurio no saiba que o roteador possua uma interface web. Jeremiah usou um nome de conta
padro do roteador para realizar o ataque.
Todos estes ataques funcionam, pois a credencial de autorizao do usurio (tipicamente um cookie de
sesso) automaticamente includa em requisies do navegador, mesmo que o atacante no fornea
tal credencial.

OWASP TOP TEN 2007

19

Caso a tag contendo o ataque possa ser postada em uma aplicao vulnervel, ento a probabilidade de
encontrar vtimas autenticadas incrementada significativamente, similar ao incremento do risco entre
as falhas XSS armazenadas e refletidas. Falhas XSS no so necessrias para um ataque CSRF funcionar,
apesar de que qualquer aplicao com falhas XSS esteja susceptvel a CSRF, pois um ataque CSRF pode
explorar uma falha XSS para roubar qualquer credencial no fornecida de forma automtica que possa
estar em execuo para proteger contra um ataque CSRF. Muitos worms de aplicao tm usado ambas
as tcnicas de forma combinada.
Quando estiver construindo defesas contra ataques CSRF, deve-se focar tambm na eliminao de
vulnerabilidades XSS na aplicao, uma vez que tais vulnerabilidades podem ser usadas para subverter a
maioria das defesas contra CSRF aplicadas.
O objetivo verificar se a aplicao est protegida contra ataques CSRF pela gerao e ento requisio
de algum tipo de token de autorizao que no seja automaticamente submetido pelo browser.
Abordagens automatizadas: hoje poucos scanners podem detectar CSRF, mesmo que a deteco de
CSRF seja possvel para a inteligncia dos scanners de aplicao. Entretanto, caso seu scanner de
vulnerabilidade localize uma vulnerabilidade XSS e no haja protees anti-CSRF, muito provvel que
esteja em risco de ataques CSRF encubados.
Abordagens manuais: teste de penetrao uma maneira rpida de verificar que uma proteo CSRF
esteja em operao. A verificao de cdigo a maneira mais eficiente para se verificar que o
mecanismo est seguro e implementado apropriadamente.
PROTEO
As aplicaes devem se certificar que no esto se baseando em credenciais ou tokens que so
automaticamente submetidos pelos navegadores. A nica soluo utilizar um token personalizado que
o navegador no lembrar e ento incluir automaticamente em um ataque de CSRF.
As seguintes estratgias devem estar em todas as aplicaes web:
Garanta que no existam vulnerabilidades XSS em sua aplicao (Vide A1 XSS).
Insira tokens randmicos personalizados em todos os formulrios e URL que no seja automaticamente
submetido pelo browser. Por exemplo:
<form action="/transfer.do" method="post"> <input type="hidden" name="8438927730"
value="43847384383">

</form>
e ento verifique se o token submetido correto para o usurio corrente. Tais tokens podem ser nicos
para tal funo ou pgina particular para o referido usurio, ou simplesmente nico para a sesso como
um todo. Quanto mais focado o token for para uma funo particular e/ou conjunto particular de dados,
mais forte ser a proteo, mas mais complicado ser seu desenvolvimento e manuteno.
Para dados sensveis ou transaes de valores, re-autentique ou use assinatura de transao para
garantir que a requisio genuna. Configure mecanismos externos como, por exemplo, contato por e-
mail ou telefone de maneira a verificar requisies ou notificar o usurio das requisies.
No use requisies GET (URLs) para dados sensveis ou para realizar transaes de valores. Use somente
mtodos POST quando processar dados sensveis do usurio. Entretanto, a URL pode conter token
randmico medida que este cria uma URL nica, que torna o CSRF quase impossvel de se realizar.
Um nico POST insuficiente para proteo. Deve-se tambm combinar com tokens randmicos,
autenticao por outros meios ou re-autenticao para proteger apropriadamente contra CSRF.

OWASP TOP TEN 2007

20

Para ASP.NET, configure o valor ViewStateUserKey. (Vide referncias). Isto prove um tipo similar de
verificao a um token randmico como descrito anteriormente.
Enquanto estas sugestes diminuiro drasticamente a exposio, ataques avanados de CSRF podem
contornar muitas destas restries. A tcnica mais forte usar tokens nicos e eliminar todas as
vulnerabilidades XSS em sua aplicao.
EXEMPLOS
MySpace Samy Interview: http://blog.outer-court.com/archive/2005-10-14-n81.html
An attack which uses Quicktime to perform CSRF attacks
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9005607&intsr
c=hm_list
REFERNCIAS
CWE: CWE-352 (Cross-Site Request Forgery)
WASC Threat Classification: No direct mapping, but the following is a close match:
http://www.webappsec.org/projects/threat/classes/abuse_of_functionality.shtml
OWASP CSRF, http://www.owasp.org/index.php/Cross-Site_Request_Forgery
OWASP Testing Guide, https://www.owasp.org/index.php/Testing_for_CSRF
OWASP CSRF Guard, http://www.owasp.org/index.php/CSRF_Guard
OWASP PHP CSRF Guard, http://www.owasp.org/index.php/PHP_CSRF_Guard
RSnake, "What is CSRF?", http://ha.ckers.org/blog/20061030/what-is-csrf/
Jeremiah Grossman, slides and demos of Hacking Intranet sites from the outside
http://www.whitehatsec.com/presentations/whitehat_bh_pres_08032006.tar.gz
Microsoft, ViewStateUserKey details, http://msdn2.microsoft.com/en-
us/library/ms972969.aspx#securitybarriers_topic2

OWASP TOP TEN 2007

21

A6 VAZAMENTO DE INFORMAES E TRATAMENTO DE ERROS INAPROPRIADO
Diversas aplicaes podem sem inteno vazar informaes sobre suas configuraes, funcionamento
interno, ou violar privacidade atravs de diversos problemas. Aplicaes podem vazar o funcionamento
interno via tempo de resposta para executar determinados processos ou respostas diferentes para
entradas diversas, como exibindo mesma mensagem de erro mas com cdigo de erros diferentes.
Aplicaes Web freqentemente vazaro informaes sobre seu funcionamento interno atravs de
mensagens de erros detalhadas ou debug. Freqentemente, essa informao pode ser o caminho para
lanar ataques ou ferramentas automticas mais poderosas.
AMBIENTES AFETADOS
Todos os frameworks de aplicao web so vulnerveis ao vazamento de informaes e tratamento de
erros inapropriado.
VULNERABILIDADE
Aplicaes freqentemente geram mensagens de erros e as mostram para os usurios. Muitas vezes
essas informaes so teis para os atacantes, visto que elas revelam detalhes de implementaes ou
informaes teis para explorar uma vulnerabilidade. Existem diversos exemplos comuns disso:
Manipulao de erro detalhada, onde se induzirmos alguns erros sero mostradas muitas informaes,
como o rastreamento da pilha, validaes, falhas de SQL, ou outras informaes de debug.
Funes que produzem diferentes sadas baseado-se em diferentes entradas. Por exemplo, substituindo o
mesmo nome de usurio com senhas diferentes deveria produzir o mesmo texto como usurio
inexistente, ou password invlido. Entretanto, muitos sistemas geram diferentes cdigos de erros.

O objetivo verificar se a aplicao no vaza informaes via mensagens de erros ou outros meios.
Mtodos Automticos: Ferramentas de scanner de vulnerabilidades geralmente ocasionaro mensagens
de erros. Ferramentas de anlise esttica podem procurar pelo uso de API que vazam informaes, mas
no tero capacidade de verificar o significado dessas mensagens.
Mtodos manuais: Em uma reviso de cdigo podemos procurar por manipulaes inapropriadas de
erros e outros fatores que vazam informaes, mas demandar um consumo de tempo elevado.

PROTEO
Desenvolvedores deveriam usar ferramentas como OWASP's WebScarab para tentar fazer suas
aplicaes gerarem erros. Aplicaes que no foram testadas dessa maneira quase que certamente
geraro erros de sada inesperados. Aplicaes tambm deveriam incluir um padro de exceo de
manipulao para prevenir que informaes desnecessrias vazem para os atacantes.
Prevenir vazamento de informaes requer disciplina. As seguintes prticas tm provado ser eficientes:
Tenha certeza que toda a equipe de desenvolvimento de software compartilha o mesmo mtodo para
manipular erros.
Desabilite ou limite o detalhamento na manipulao de erros. Em particular, no mostre informaes de
debug, rastreamento de pilha ou informao de caminhos(path) para usurios finais.

OWASP TOP TEN 2007

22

Tenha certeza que caminhos (paths) seguros que tenha mltiplos resultados, retornem mensagens de
erros similares ou idnticas. Se no for possvel, considere colocar um tempo de espera randmico para
todas as transaes para esconder esse detalhe dos atacantes.
Vrias camadas podem retornar resultados excepcionais ou fatais, como camadas de banco de dados,
servidores web ( IIS, Apache, etc). vital que erros de todas as camadas sejam adequadamente checados
e configurados para prevenir que mensagens de erros sejam exploradas por atacantes.
Tenha conscincia que frameworks comuns retornam diferentes cdigos HTTP dependendo se um erro
customizado ou erro do framework . muito valioso criar um manipulador de erros padro que retorne
uma mensagem de erro j checada para maioria dos usurios em produo para os erros de
caminho(path).
Sobrepor o manipulador padro de erros para que ele sempre retorne 200 (OK) reduz a probabilidade
de ferramentas de testes automticos descobrirem se alguma falha grave ocorre. Isso segurana atravs
da obscuridade e pode se prover uma camada extra de defesa.
Algumas organizaes maiores tm escolhido incluir cdigos de erros randmicos / nicos em todas suas
aplicaes. Isto pode ajudar o suporte a encontrar a soluo correta para um erro particular, mas isso
pode tambm permitir que atacantes determinem exatamente onde a aplicao falhou.

EXEMPLOS
REFRENCIAS
CWE: CWE-200 (Information Leak), CWE-203 (Discrepancy Information Leak), CWE-215 (Information Leak
Through Debug Information), CWE-209 (Error Message Information Leak), others.
http://www.webappsec.org/projects/threat/classes/information_leakage.shtml
OWASP, http://www.owasp.org/index.php/Error_Handling
OWASP, http://www.owasp.org/index.php/Category:Sensitive_Data_Protection_Vulnerability

OWASP TOP TEN 2007

23

A7 FURO DE AUTENTICAO E GERNCIA DE SESSO
Autenticao e gerncia de sesso apropriadas so criticas para a segurana na web. Falhas nesta rea
geralmente envolvem a falha na proteo de credenciais e nos tokens da sesso durante seu tempo de
vida. Estas falhas podem estar ligadas roubo de contas de usurios ou administradores, contornando
controles de autorizao e de responsabilizao, causando violaes de privacidade.
AMBIENTES AFETADOS
Todos os frameworks de aplicaes web so vulnerveis a furos de autenticao e de gerncia de
sesso.
VULNERABILIDADE
Furos no mecanismo principal de autenticao no so incomuns, mas falhas so geralmente
introduzidas a partir de funes menos importantes de autenticao como logout, gerncia de senhas,
timeout, recordao de dados de logon, pergunta secreta e atualizao de conta.
O objetivo verificar se o aplicativo autentica corretamente os usurios e protege as identidades das
credenciais associadas.
Abordagens automatizadas: ferramentas de localizao de vulnerabilidade tm dificuldade em
esquemas de autenticao e de sesso personalizados. As ferramentas de anlise estticas
provavelmente tambm no detectaro problemas em cdigos personalizados para autenticao e
gerncia de sesso.
Abordagens manuais: reviso de cdigo e testes, especialmente combinados, so muito efetivos para a
verificao de autenticao, gerencia de sesso e funes secundrias esto todas implementadas
corretamente.
PROTEO
A autenticao depende da comunicao segura e de armazenamento de credenciais. Primeiramente,
assegure-se que o SSL a nica opo para todas as partes autenticadas do aplicativo (veja A9) e que
todas as credenciais esto guardadas de uma forma encriptada ou em hash (veja A8).
Prevenir falhas de autenticao requer um planejamento cuidadoso. Algumas das consideraes
importantes so:
Use somente mecanismos padro para gerncia de sesso. No escreva ou use gerenciadores
secundrios de sesso em qualquer situao.
No aceite novos identificadores de sesso, pr-configurados ou invlidos na URL ou em requisies. Isto
chamado de ataque de sesso fixada.
Limite ou limpe seu cdigo de cookies personalizados com propsito de autenticao de gerncia de
sesso, como funes lembrar do meu usurio ou funes domsticas de autenticao centralizadas
como o Single Sign-On (SSO). Isto no se aplica s solues de autenticao federadas robustas ou SSO
reconhecidas.
Use um mecanismo nico de autenticao com dimenso e nmero de fatores apropriados. Certifique-se
que este mecanismo no estar facilmente sujeito ataques ou fraudes. No faa esse mecanismo
complicado demais, pois ele pode se tornar alvo de seu prprio ataque.

OWASP TOP TEN 2007

24

No permita que o processo de login comece de uma pgina no encriptada. Sempre inicie o processo
de login de uma segunda pgina encriptada ou de um novo cdigo de sesso, para prevenir o roubo de
credenciais ou da sesso, phishing e ataques de fixao de sesso.
Considere gerar uma nova sesso aps uma autenticao que obteve sucesso ou mudana do nvel de
privilgio.
Assegure-se que todas as pginas tenham um link de logout. O logout deve destruir todas as sesses e
cookies de sesso. Considere os fatores humanos: no pergunte por confirmao, pois usurios acabaro
fechando a aba ou janela ao invs de sair com sucesso.
Use perodos de expirao de prazo que automaticamente do logout em sesses inativas, bem como o
contedo das informaes que esto sendo protegidas.
Use somente funes de proteo secundrias eficientes (perguntas e respostas, reset de senha), pois
estas credenciais so como senhas, nomes de usurios e tokens. Aplique one-way hash nas respostas para
prevenir ataques nos quais a informao pode ser descoberta.
No exponha nenhum identificador de sesso ou qualquer parte vlida das credenciais em URLs e logs
(no regrave ou armazene informaes de senhas de usurios em logs).
Verifique a senha antiga do usurio quando ele desejar mudar a senha.
No confie em credenciais falsificveis como forma de autenticao, como endereos de IP ou mscaras
de rede, endereo de DNS ou verificao reversa de DNS, cabealhos da origem ou similares.
Cuide-se quando enviar segredos para endereos de e-mail (procure por RSNAKE01 nas referncias)
como um mecanismo de reset de password. Use nmeros randmicos limited-time-only para resetar
acesso e envie um e-mail de retorno assim que a senha for reconfigurada. Cuide para quando permitir que
usurios registrados mudem seus endereos de e-mail envie uma mensagem para o e-mail anterior
antes de efetuar a mudana.
EXEMPLOS
REFERNCIAS
CWE: CWE-287 (Authentication Issues), CWE-522 (Insufficiently Protected Credentials), CWE-311
(Reflection attack in an authentication protocol), others.
http://www.webappsec.org/projects/threat/classes/insufficient_authentication.shtml
http://www.webappsec.org/projects/threat/classes/credential_session_prediction.shtml
http://www.webappsec.org/projects/threat/classes/session_fixation.shtml
OWASP Guide, http://www.owasp.org/index.php/Guide_to_Authentication
OWASP Code Review Guide, http://www.owasp.org/index.php/Reviewing_Code_for_Authentication
OWASP Testing Guide, http://www.owasp.org/index.php/Testing_for_authentication
RSNAKE01 - http://ha.ckers.org/blog/20070122/ip-trust-relationships-xss-and-you

OWASP TOP TEN 2007

25

A8 ARMAZENAMENTO CRIPTOGRTAFICO INSEGURO
Proteger dados sensveis com criptografia tem sido parte chave da maioria das aplicaes Web.
Simplesmente no criptografar dados sensveis muito comum. Ainda, aplicaes que adotam
criptografia freqentemente possuem algoritmos mal concebidos, usam mecanismos de cifragem
inapropriados ou cometem srios erros usando cifragem fortes.
AMBIENTES AFETADOS
Todos os frameworks de aplicao web so vulnerveis ao armazenamento criptogrfico inseguro.
VULNERABILIDADE
Prevenir falhas de criptografia requer planejamento cuidadoso. Os problemas mais comuns so:
No criptografar dados sensveis
Uso inseguro de algoritmos fortes
Uso de algoritmos caseiros
Continuar usando algoritmos que provadamente so fracos (MD5, SHA-1, RC3, RC4, etc.)
Difcil codificao de chaves, e armazenar chaves em sistemas de armazenamento desprotegidos
O objetivo verificar se as aplicaes corretamente armazenam informaes sensveis em sistemas de
armazenamento.
Abordagens automticas: Ferramentas de pesquisas de vulnerabilidades no verificam a criptografia em
sistemas de armazenamento em geral. Ferramentas de pesquisa de cdigos podem detectar o uso de
APIs de criptografias conhecidas, mas no podem detectar se ela esta sendo usada corretamente ou se a
criptografia realizada em um mecanismo externo.
Abordagem manual: Como ferramentas de pesquisas, testes no podem verificar o armazenamento
criptografado. Reviso de cdigo a melhor forma de verificar que a aplicao criptografa dados
sensveis e tem mecanismos e armazenamento de chaves corretamente implementados. Isto em alguns
casos pode envolver examinar as configuraes de sistemas externos.

PROTEO
O aspecto mais importante assegurar que tudo que deve ser criptografado est realmente
criptografado. Ento voc deve assegurar que a criptografia esta corretamente implementada. Como
existem vrios mtodos de incorretamente usar a criptografia, as seguintes recomendaes devem ser
seguidas como parte de seus testes para ajudar a assegurar o manuseamento seguro de mecanismos de
criptografia:
No crie algoritmos de criptografia. Somente use algoritmos aprovados publicamente como, AES,
Criptografia de chaves publicas RSA, SHA-256 ou melhores para hash.
No use algoritmos fracos, como MD5/SHA1. Use mecanismos mais seguros como SHA-256 ou melhores.
Crie chaves offline e armazene chaves privadas com extremo cuidado. Nunca transmita chaves privadas
em canais inseguros.
Assegure que credenciais de infra-estrutura como credenciais de banco de dados ou detalhes de filas de
acessos MQ esto corretamente seguras (por meio de rgidos sistemas de arquivos e controles),
criptografados de forma adequada e no podem ser decriptografados por usurios locais ou remotos.

OWASP TOP TEN 2007

26

Assegure que dados armazenados criptografados no disco no so fceis de decriptografar. Por
exemplo, criptografia de banco de dados intil se a conexo de banco de dados permite acessos no
criptografados.
Sobre o requisito 3, de Padres de Dados Seguros PCI, voc deve proteger dados dos titulares das
informaes. O cumprimento do PCI DDS obrigatrio at 2008 por comerciantes e qualquer um que
lidar com cartes de crdito. Uma boa prtica nunca armazenar dados desnecessrios, como
informaes sobre a fita magntica ou o nmero da conta primria (PAN, tambm conhecida como o
numero do carto de crdito). Se voc armazenar o PAN, o requisito para o cumprimento do DSS so
significativos. Por exemplo, NUNCA permitir armazenar o numero CVV ( O numero de trs dgitos nas
costas do carto) sobre quaisquer circunstncias. Para mais informaes, por favor leia o PCI DSS
Guidelines e implemente controles como necessrios.
EXEMPLOS
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-1999-1101 (True of most Java EE servlet
containers,too)
REFRENCIAS
CWE: CWE-311 (Failure to encrypt data), CWE-326 (Weak Encryption), CWE-321 (Use of hard-coded
Cryptographic key), CWE-325 (Missing Required Cryptographic Step), others.
WASC Threat Classification: No explicit mapping
OWASP, http://www.owasp.org/index.php/Cryptography
OWASP Guide, http://www.owasp.org/index.php/Guide_to_Cryptography
OWASP, http://www.owasp.org/index.php/Insecure_Storage
OWASP, http://www.owasp.org/index.php/How_to_protect_sensitive_data_in_URLs
PCI Data Security Standard v1.1,
https://www.pcisecuritystandards.org/pdfs/pci_dss_v1-1.pdf
Bruce Schneier, http://www.schneier.com/
CryptoAPI Next Generation, http://msdn2.microsoft.com/en-us/library/aa376210.aspx

OWASP TOP TEN 2007

A9 COMUNICAES INSEGURAS
Aplicaes geralmente falham na hora de encriptar trfego de rede quando necessrio proteger
comunicaes sensveis. A encriptao (geralmente SSL) deve ser usada em todas as conexes
autenticadas, especialmente pginas web com acesso via internet, mas tambm conexes com o back-
end. Seno, o aplicativo ir expor uma autenticao ou o token de sesso. Adicionalmente, a
autenticao deve ser usada sempre que dados sensveis, assim como cartes de crdito ou informaes
de sade so transmitidos. Aplicaes cujo modo de encriptao possa ser subvertido so alvos de
ataques.
Os padres PCI requerem que todas as informaes de cartes de credito que so transmitidas pela
internet sejam encriptadas.
AMBIENTES AFETADOS
Todos os frameworks de aplicaes web so vulnerveis s comunicaes inseguras.
VULNERABILIDADE
Falha na hora de encriptar informaes sensveis significa que um invasor que possa escutar o trfego da
rede poder ter acesso conversa, incluindo quaisquer credenciais ou informaes sensveis
transmitidas. Considerando que redes diferentes tero mais ou menos suscetibilidade a escuta.
Entretanto, importante notar que eventualmente um servidor ser comprometido em praticamente
qualquer rede, e que invasores instalaro rapidamente uma escuta para capturar as credenciais de
outros sistemas.
O uso de SSL para comunicao com usurios finais critico, pois muito provvel que eles utilizem
formas inseguras de acessar os aplicativos. Porque HTTP inclui credenciais de autenticao ou um token
de sesso para cada pedido, toda autenticao do trfego deve ir para o SSL, no s os pedidos de login.
A encriptao de informaes com servidores de back-end tambm importante. Mesmo que estes
servidores sejam naturalmente mais seguros, as informaes e as credenciais que elas carregam so
mais sensveis e mais impactantes. Portanto, usar SSL no back-end tambm muito importante.
A encriptao de informao sensvel, assim como cartes de crdito e informaes de previdncia, se
tornou um regulamento financeiro e de privacidade para vrias empresas. Negligenciar o uso de SSL
para o manuseio de conexes de informaes cria um risco de no conformidade.
O objetivo verificar se as aplicaes encriptam corretamente toda a comunicao autenticada e
sensvel.
Abordagens automatizadas: ferramentas de localizao de vulnerabilidade podem verificar se o SSL
utilizado na interface do sistema e pode localizar muitas falhas relacionadas SSL. Entretanto, elas no
tm acesso s conexes no back-end e no podem verificar se elas so seguras. As ferramentas de
anlise esttica podem ajudar com anlises de algumas ligaes no back-end, mas provavelmente no
entendero a lgica customizada requerida para todos os tipos de sistemas.
Abordagens manuais: testes podem verificar se o SSL utilizado e localizar muitas falhas relacionadas
SSL na interface, mas as abordagens automatizadas so provavelmente mais eficientes. A reviso de
cdigo muito eficiente para verificar o uso de SSL em conexes no back-end.

OWASP TOP TEN 2007

28

PROTEO
A parte mais importante da proteo usar o SSL em todas as conexes autenticadas ou em qualquer
informao sensvel em transmisso. H inmeros detalhes envolvendo a configurao do SSL para
aplicaes web, ento importante entender e analisar seu ambiente. Por exemplo, o IE7 (internet
Explorer 7) prov uma barra verde para certificados SSL altamente confiveis, mas isto no um
controle apropriado que demonstre por si s o uso seguro da criptografia.
Use SSL para todas as conexes que so autenticadas ou que transmitam informaes sensveis ou de
valor, assim como credenciais, cartes de crdito, e outros.
Assegure que as comunicaes entre os elementos da infra-estrutura, como servidores de web e sistemas
de banco de dados, esto propriamente protegidas pelo uso de camadas de transporte de segurana ou
de encriptao de nvel de protocolo para credenciais e informaes de valor intrnseco.
Dentro dos requisitos de segurana PCI 4, deve-se proteger as informaes dos proprietrios de cartes
de crdito em transmisso. A conformidade com as normas PCI DSS mandatria at 2008 para todos os
comerciantes e qualquer um que lide com cartes de crdito. Em geral, clientes, parceiros, funcionrios e
acesso administrativo online aos sistemas devem ser encriptados via SSL ou similar.
EXEMPLOS
http://www.schneier.com/blog/archives/2005/10/scandinavian_at_1.html
REFERNCIAS
CWE: CWE-311 (Failure to encrypt data), CWE-326 (Weak Encryption), CWE-321 (Use of hard-coded
cryptographic key), CWE-325 (Missing Required Cryptographic Step), others.
WASC Threat Classification: No explicit mapping
OWASP Testing Guide, Testing for SSL / TLS, https://www.owasp.org/index.php/Testing_for_SSL-TLS
OWASP Guide, http://www.owasp.org/index.php/Guide_to_Cryptography
Foundstone - SSL Digger,
http://www.foundstone.com/index.htm?subnav=services/navigation.htm&subcontent=/services/overvie
w_s3i_des.htm
NIST, SP 800-52 Guidelines for the selection and use of transport layer security (TLS) Implementations,
http://csrc.nist.gov/publications/nistpubs/800-52/SP800-52.pdf
NIST SP 800-95 Guide to secure web services, http://csrc.nist.gov/publications/drafts.html#sp800-95

OWASP TOP TEN 2007

29

A10 FALHA AO RESTRINGIR ACESSO URLS
Comumente, a nica proteo para uma URL no mostrar o link para usurios no autorizados.
No entanto, um motivado, hbil ou apenas um sortudo atacante pode ser capaz de achar e acessar estas
pginas, executar funes e visualizar dados. Segurana por obscuridade no suficiente para proteger
dados e funes sensveis em uma aplicao. Verificaes de controles de acesso devem ser executadas
antes de permitir uma solicitao a uma funo sensvel, na qual garante que somente o usurio
autorizado acesse a respectiva funo.
AMBIENTES AFETADOS
Todos os frameworks de aplicaes web esto vulnerveis a falhas de restrio de acesso a URLs.
VULNERABILIDADE
O principal mtodo de ataque para esta vulnerabilidade chamado de navegao forada (forced
browsing), na qual envolve tcnicas de adivinhao de links (guessing) e fora bruta (brute force)
para achar pginas desprotegidas. comum que aplicaes utilizem cdigos de controle de acesso por
toda a aplicao, resultando em um modelo complexo que dificulta a compreenso para
desenvolvedores e especialistas em segurana. Esta complexidade torna provvel a ocorrncia de erros
e algumas pginas no sero validadas, deixando a aplicao vulnervel.
Alguns exemplos destas falhas incluem:
URLS escondidas e especiais, mostradas apenas para administradores ou usurios privilegiados na
camada de apresentao, porm acessvel a todos os usurios caso tenham conhecimento que esta URL
existe, como /admin/adduser.php ou /approveTransfer.do. Estas so particularmente comuns em cdigos
de menus.
Aplicaes geralmente permitem acesso a arquivos escondidos, como arquivos XML estticos ou
relatrios gerados por sistemas, confiando toda segurana na obscuridade, escondendo-os.
Cdigos que foram uma poltica de controle de acesso desatualizada ou insuficiente. Por exemplo,
imagine que /approveTransfer.do foi disponibilizado uma vez para todos usurios, mas desde que os
controles da SOX foram adotados, ele supostamente s pode ser acessvel por usurios aprovadores. Uma
possvel correo seria no mostrar a URL para usurios no autorizados, no entanto o controle de acesso
ainda no estaria implementado na requisio para esta pgina.
Cdigos que validam privilgios no cliente (browser) e no no servidor, como neste ataque na MacWorld
2007, que aprovava para Platinum passes que valiam $1700 via Java Script no browser ao invs de
validar no servidor.
VERIFICANDO A SEGURANA
O objetivo verificar que o controle est forado constantemente na camada de apresentao e nas
regras de negcio para todas as URLs da aplicao.
Abordagem automatizada: Scanners de vulnerabilidades e ferramentas de anlise manual, ambos
possuem dificuldades em verificar o controle de acesso na URL por diferentes razes. Scanners de
vulnerabilidades possuem dificuldade em adivinhar pginas escondidas e determinar qual pgina
deveria ser permitida para cada usurio, enquanto mecanismos de anlise esttica tentam identificar
controles de acessos personalizados no cdigo e ligam a camada de apresentao com as regras de
negcios.
Abordagem manual: A abordagem mais eficiente e precisa est em utilizar a combinao da reviso do
cdigo e dos testes de segurana para verificar os mecanismos de controles de acesso. Se o mecanismo

OWASP TOP TEN 2007

30

centralizado, a verificao pode ser bastante eficiente. Se o mecanismo distribudo atravs de uma
completa base de cdigo, a verificao pode se tornar dispendiosa. Se o mecanismo est forado
externamente, a configurao deve ser examinada e testada.
PROTEO
Tendo o tempo para planejar a autorizao criando uma matriz para mapear as regras e as funes da
aplicao o passo primordial para alcanar a proteo contra acessos no autorizados. Aplicaes web
devem garantir controle de acesso em cada URL e funes de negcio. No suficiente colocar o
controle de acesso na camada de apresentao e deixar a regra de negcio desprotegida. Tambm no
suficiente verificar uma vez o usurio autorizado e no verificar novamente nos passos seguintes. De
outra forma, um atacante pode simplesmente burlar o passo onde a autorizao verificada e forjar o
valor do parmetro necessrio e continuar no passo seguinte.
Habilitar controle de acesso na URL necessita de um planejamento cuidadoso. Dentre as consideraes
mais importantes podemos destacar:
Garanta que a matriz do controle de acesso parte do negcio, da arquitetura e do design da aplicao
Garanta que todas URLs e funes de negcio so protegidas por um mecanismo de controle de acesso
efetivo que verifique as funes e direitos do usurio antes que qualquer processamento ocorra.
Certifique-se que este processo realizado em todos os passos do fluxo e no apenas no passo inicial de
um processo, pois pode haver vrios passos a serem verificados.
Realize um teste invaso (penetration test) antes do cdigo entrar em produo a fim de garantir que a
aplicao no poder ser utilizada de m f por um atacante motivado ou com conhecimentos avanados.
Preste muita ateno em arquivos de includes/bibliotecas, especialmente se eles possuem extenses
executveis como .php. Sempre que possvel, devem ser mantidos fora da raiz web. Devem ser verificados
se no esto sendo acessados diretamente, por exemplo, verificando por uma constante que pode
somente ser criada atravs de uma biblioteca do chamador.
No suponha que usurios no estaro atentos acessar URLs ou APIs escondidas ou especiais. Sempre se
assegure que aes com privilgios altos e administrativos estaro protegidos.
Bloqueie acesso a todos os tipos de arquivos que a sua aplicao no deva executar. Este filtro deve seguir
a abordagem accept known good na qual apenas so permitidos tipos de arquivos que a aplicao deva
executar, como por exemplo .html .pdf, .php. Isto ir bloquear qualquer tentativa de acesso a arquivos de
log, arquivos XML, entre outros, aos quais se espera nunca serem executados diretamente.
Mantenha o antivrus e as correes de segurana atualizados para componentes como processadores
XML, processadores de texto, processadores de imagem, entre outros que manipulam arquivos fornecidos
por usurios.
EXEMPLOS
REFERNCIAS
CWE: CWE-325 (Direct Request), CWE-288 (Authentication Bypass by Alternate Path), CWE-285 (Missing
or Inconsistent Access Control)
http://www.webappsec.org/projects/threat/classes/predictable_resource_location.shtml
OWASP, http://www.owasp.org/index.php/Forced_browsing
OWASP Guide, http://www.owasp.org/index.php/Guide_to_Authorization

OWASP TOP TEN 2007

31

AONDE IR A PARTIR DAQUI
O OWASP Top 10 apenas o primeiro passo rumo a segurana das suas aplicaes web.
Podemos dividir as 6 Milhes de pessoas que vivem no mundo em dois grupos: O primeiro grupo
formado pelas pessoas que sabem porque a grande maioria das empresas de software lanam seu
produtos com Bugs conhecidos e o segundo grupo formado pelas pessoas que no sabem porque isto
ocorre. As pessoas do primeiro grupo geralmente tm seu otimismo juvenil estragado pela dura
realidade. s vezes encontramos pessoas que pertencem aos dois grupos; so as pessoas que esto
chocadas por ver que existem empresas lanando seus produtos antes de test-los e corrigir todos os
bugs.
(http://www.guardian.co.uk/technology/2006/may/25/insideit.guardianweeklytechnologysection) Eric
Sink, Guardian 25 maio de 2006.
A maioria dos seus clientes e usurios est no primeiro grupo. O modo com o qual voc encara este
problema uma oportunidade de aumentar a segurana de suas aplicaes web no modo geral pois
Bilhes de dlares so perdidos todos os anos e milhes de pessoas sofrem com fraude e roubo de
identidade devido a vulnerabilidades discutidas neste documento.

AOS WEB-DESIGNERS
Para garantir a segurana das suas aplicaes voc precisa saber o que voc est protegendo, conhea
todas as ameaas e riscos de insegurana e classifique-os de forma estruturada. O Desenvolvimento de
qualquer tipo de aplicao requer uma boa dose de segurana.
Certifique-se que voc est aplicando segurana baseando-se no modelo de ameaa de risco, no entanto
como os modelos de normas (SOX, HIPAA, Basel,) esto cada vez mais caros torna-se mais conveniente
investir tempo e recurso para satisfazer o mnimo necessrio para os dias atuais, porm as normas mais
conhecidas so bem mais rgidas.
Faa perguntas sobre necessidades empresariais, principalmente sobre requisitos no funcionais.
Trabalhe seguindo o contrato de segurana de Software OWASP.
Incentivar o desenvolvimento de Software seguro inclui uma defesa profunda e uma construo simples
do cdigo utilizando o modelo de ameaa de risco. (ver [HOW1] no livro referncias)
Certifique-se de ter considerado a confidencialidade, integridade, disponibilidade e no-repdio.
Certifique-se de que seus Web-Designers so coerentes com a poltica de segurana e normas, tais como
COBIT ou PCI DSS 1,1.
AOS DESENVOLVEDORES
Muitos desenvolvedores j possuem uma boa base sobre segurana no desenvolvimento de aplicaes
Web porm para garantir uma segurana efetiva no desenvolvimento de aplicaes Web requer muita
experincia, pois qualquer leigo pode atacar um sistema.
Faa parte da comunidade e OWASP e freqente as reunies regionais.
Procure por treinamentos sobre desenvolvimento de cdigo seguro.
Desenvolva suas aplicaes com segurana, Crie cdigos simples e com profunda segurana.
Desenvolva com aplicaes que favoream a segurana do cdigo.
Reconstrua o cdigo de forma segura de acordo com a sua plataforma utilizando pesquisas otimizadas.
Leia o guia OWASP e comece a aplicar controles mais seguros a seu cdigo, diferente do outros guias ele
desenvolvido para ajud-lo a criar aplicaes seguras e no a quebr-las.
Faa os testes de segurana e defeitos do seu cdigo e torne esta prtica constante no seu dia-a-dia.

OWASP TOP TEN 2007

32

Revise o livro de referncias e veja se existem opes que se aplicam ao seu ambiente de trabalho.
PARA PROJETOS DE CDIGO ABERTO
O cdigo aberto um desafio particular para a segurana de aplicaes web. Existem milhares de
projetos de cdigo aberto tanto pessoais como o Apache (www.apache.org) e Tomcat
(tomcat.apache.org/) quanto em larga escala como PostNuke (www.postnuke.com).
Faa parte da comunidade e OWASP e freqente as reunies regionais.
Se o seu projeto possui mais de quatro desenvolvedores, deixe pelo menos um deles responsvel pela
segurana.
Desenvolva suas aplicaes com segurana, Crie cdigos simples e com boa segurana.
Desenvolva com normas que favoream a segurana do cdigo.
Divulgue a poltica de segurana de forma responsvel para garantir que os problemas de segurana esto
sendo tratados corretamente.
Revise o livro de referncias e veja se existem opes que se aplicam ao seu ambiente de trabalho.

PARA OS PROPRIETRIOS DE APLICAO
Os proprietrios de aplicaes comerciais geralmente tm tempo e recursos reduzidos. Os Proprietrios
de aplicaes devem:
Trabalhar com o contrato de segurana de software OWASP anexo com os produtores de softwares.
Garantir que os requisitos de negcio incluem requisitos no-funcionais (non-functional requirements,
NFRs), tais como requisitos de segurana.
Estimule os desenvolvedores a criar aplicaes com cdigo simples e com boa segurana.
Contrate (ou treine) desenvolvedores com bons conhecimentos em segurana.
Faa testes de segurana em todo o projeto, desenvolvimento, criao, testes e implementao.
Reserve recurso e tempo no oramento do projeto para cuidar de questes de segurana.

AOS DIRETORES EXECUTIVOS
Sua empresa precisa ter um ciclo de vida de desenvolvimento seguro. As vulnerabilidades so mais
fceis de serem corrigidas durante o desenvolvimento do que aps o produto j ter sido lanado.
Possuir um ciclo de vida de desenvolvimento seguro no inclui somente os testes para o Top 10,
tambm inclui:
Ao vender software assegure-se de estar incluindo polticas e contratos com termos de segurana.
Para cdigo customizado adote codificao segura, principalmente nas suas polticas e normas.
Notifique seus produtores de software sobre a importncia da segurana para os resultados da empresa.
Treine seus web-designers e projetistas nos fundamentos de segurana em aplicaes web.
Considere a possibilidade do cdigo ser auditado por terceiros para que haja uma anlise mais
independente.
Adote prticas responsveis de divulgao e construa um processo para responder adequadamente aos
relatrios de vulnerabilidade dos seus produtos.

OWASP TOP TEN 2007

33

REFERNCIAS
PROJETOS DA OWASP
OWASP o site principal sobre segurana de aplicaes web. O site da OWASP hospeda diversos
projetos, fruns, blogs, apresentaes, ferramentas e artigos. A OWASP organiza duas grandes
conferncias de segurana por ano e mais de 80 captulos locais.
Os seguintes projetos da OWASP so mais comuns de serem utilizados:
OWASP Guide to Building Secure Web Applications
OWASP Testing Guide
OWASP Code Review Project (in development)
OWASP PHP Project (in development)
OWASP Java Project
OWASP .NET Project
LIVROS
Por necessidade, esta no uma lista exaustiva. Use-a como referncia para encontrar a rea
apropriada em sua livraria local e selecione alguns ttulos (incluindo um ou mais dos seguintes) que
satisfaam suas necessidades:
[ALS1] Alshanetsky, I. php|architect's Guide to PHP Security, ISBN 0973862106
[BAI1] Developing more secure ASP.NET 2.0 Applications, ISBN 978-0-7356-2331-6
[GAL1] Gallagher T., Landauer L., Jeffries B., "Hunting Security Bugs", Microsoft Press, ISBN 073562187X
[GRO1] Fogie, Grossman, Hanse Cross Site Scripting Attacks: XSS Exploits and Defense, ISBN 1597491543
[HOW1] Howard M., Lipner S., "The Security Development Lifecycle", Microsoft Press, ISBN 0735622140
[SCH1] Schneier B., "Practical Cryptography", Wiley, ISBN 047122894X
[SHI1] Shiflett, C. Essential PHP Security, ISBN 059600656X
[WYS1] Wysopal et al, The Art of Software Security Testing: Identifying Software Security Flaws, ISBN
0321304861

WEB SITES
OWASP, http://www.owasp.org
MITRE, Common Weakness Enumeration Vulnerability Trends, http://cwe.mitre.org/documents/vuln-
trends.html
Web Application Security Consortium, http://www.webappsec.org/
SANS Top 20, http://www.sans.org/top20/
PCI Security Standards Council, publishers of the PCI standards, relevant to all organizations processing or
Holding credit card data, https://www.pcisecuritystandards.org/
PCI DSS v1.1, https://www.pcisecuritystandards.org/pdfs/pci_dss_v1-1.pdf
Build Security In, US CERT, https://buildsecurityin.us-cert.gov/daisy/bsi/home.html

As 10 Vulnerabilidades de Segurança Mais PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

As 10 Vulnerabilidades de Segurança Mais PDF

Enviado por

Direitos autorais:

Formatos disponíveis

OWASP TOP 10

As 10 vulnerabilidades de segurana mais

Você também pode gostar