TCC Flavio Alexandre Micheletti

FLVIO ALEXANDRE MICHELETTI
ANLISE DAS PRINCIPAIS VULNERABILIDADES DE APLICAES WEB

TENDO COMO BASE A ARQUITETURA LAMP E AS
TOP 10 VULNERABILIDADES DA OWASP
SO CAETANO DO SUL/SP
NOVEMBRO/2011
FLVIO ALEXANDRE MICHELETTI
ANLISE DAS PRINCIPAIS VULNERABILIDADES DE APLICAES WEB

TENDO COMO BASE A ARQUITETURA LAMP E AS
TOP 10 VULNERABILIDADES DA OWASP
Trabalho
de
Concluso
de
Curso
apresentado Faculdade de Tecnologia de
So Caetano do Sul, sob a orientao do
Professor
Msc. Allan Carvalho, como
requisito parcial para a obteno do diploma
de Graduao no Curso de Tecnlogo em
Segurana da Informao.
Nome: MICHELETTI, Flvio Alexandre.

Ttulo: ANLISE DAS PRINCIPAIS VULNERABILIDADES DE APLICAES WEB
TENDO COMO BASE A ARQUITETURA LAMP E AS TOP 10 VULNERABILIDADES DA
OWASP
Trabalho de Concluso de Curso apresentado Faculdade de Tecnologia de So

Caetano do Sul para obteno do diploma de Graduao.
Aprovado em:
Banca Examinadora
Prof. Dr. ou MSc. _____________________Instituio: ________________________
Julgamento: _________________________Assinatura: ________________________
Dedicatria
Dedico este trabalho a todos os

amantes e entusiastas da
programao web.
Agradecimentos
Ao meu orientador Prof. Msc. Alan Henrique Pardo de Carvalho, pela confiana, incentivo,
pacincia e disponibilidade infinita eterno mestre cujos ensinamentos foram muito alm
do mbito deste trabalho, tornando-se inestimveis oportunidades de crescimento
intelectual.
Ao Prof. Msc Leandro Ramos da Silva pelas sugestes iluminadas na Banca de
qualificao e pelo acolhimento sincero.
Professora Raquel Silva pelas sugestes iluminadoras, pela pacincia e apoio e
principalmente pela disponibilidade sempre.
minha querida esposa Ingrid e filha Joana Gabriele por terem tantas vezes seu tempo
subtrado em consequncia da minha dedicao a este trabalho.
Resumo
Desenvolver software livre de vulnerabilidades um desafio para as equipes de
desenvolvimento. As aplicaes web, devido sua natureza, so mais suscetveis a todo
tipo de explorao. Poucos analistas se preocupam com a segurana da informao
relativa ao software e os clientes apenas se preocupam quando elas j foram exploradas.
Esse o cenrio que inspirou o presente trabalho: aprofundar-se nas dez maiores
vulnerabilidades apontadas pela projeto Top 10 (edio 2010) da entidade no
governamental OWASP e propor solues para tais vulnerabilidades. O escopo desse
trabalho focalizou a linguagem de programao PHP sob a arquitetura LAMP dada a
notria e ampla utilizao como plataforma de desenvolvimento e produes em
aplicaes web. Alm de explorar as Top 10 vulnerabilidades e apontar solues, o
trabalho
prope
cenrios
para
continuidade
da
pesquisa
em
segurana
desenvolvimento de aplicaes.
Palavras chaves: Top 10; OWASP, PHP, Aplicaes Web, Segurana da Informao.
MICHELETTI, Flvio Alexandre. Anlise das principais vulnerabilidades de Aplicaes Web tendo como
base a arquitetura LAMP e as Top 10 Vulnerabilidades da Owasp. 75 folhas.
Trabalho de Concluso de Curso Faculdade de Tecnologia de So Caetano do Sul, So
Caetano, 2011.
no
Abstract
Developing software without vulnerability is a challenge for development teams. The
web applications, by their nature, are more susceptible to all kinds of exploitation. Few
analysts are concerned about the security of information on the software and customers
only worry when they have been explored. This is the scenario that inspired this work:
delve into the top ten vulnerabilities identified by the project Top 10 (2010 edition) of nongovernmental entity OWASP and propose solutions to those vulnerabilities. The scope of
this work focused on the programming language PHP in LAMP architecture given the
notorious and widespread use as a development platform and production in web
applications. In addition to exploring the Top 10 vulnerabilities and point solutions, the
paper proposes scenarios for continuing research in the development of security
applications.
Palavras chaves: Top 10; OWASP, PHP, Web Applications, Information Security.
MICHELETTI, Flvio Alexandre. Anlise das principais vulnerabilidades de Aplicaes Web tendo como
base a arquitetura LAMP e as Top 10 Vulnerabilidades da Owasp. 75 folhas.
Trabalho de Concluso de Curso Faculdade de Tecnologia de So Caetano do Sul, So
Caetano, 2011.
Listas de tabelas
Tabela 01 Anlise de risco....................................................................................................................... 23

Tabela 02 Mapeamento do risco de injeo............................................................................................. 25
Tabela 03 Mapeamento do risco de XSS................................................................................................. 33
Tabela 04 Codificando caracteres............................................................................................................ 36
Tabela 05 Mapeamento do risco de Quebra de Autenticao.................................................................41
Tabela 06 Mapeamento do risco de Referncias Inseguras....................................................................45
Tabela 07 Mapeamento do risco de CSRF.............................................................................................. 50
Tabela 08 Mapeamento do risco de Configurao Incorreta de Segurana............................................55
Tabela 09 Mapeamento do risco de Armazenamento Criptogrfico Inseguro..........................................60
Tabela 10 Lista de algortimos para gerao de hash.............................................................................62
Tabela 11 Mapeamento do risco de Falha na restrio de acesso a URL...............................................63
Tabela 12 Mapeamento do risco de insuficincia de proteo da Camada de Transporte......................68
Tabela 13 Mapeamento do risco de Redirecionamento e Encaminhamentos Invlidos..........................71
Lista de ilustraes
Figura 01 Arquitetura cliente-servidor e tecnologias utilizada..................................................................21

Figura 02 Caminhos percorrido pelo atacante.........................................................................................24
Figura 03 Exemplo de formulrio web. Tela de login...............................................................................26
Figura 04 Exemplo de mensagem de certificado web invlido................................................................69
Lista de cdigo fontes

Cdigo 1.1 Exemplo de formulrio web................................................................................................... 26
Cdigo 1.2 Cdigo em PHP que recebe e processa os dados de um formulrio web.............................27
Cdigo 1.3 Prevenindo injeo com consultas parametrizadas..............................................................28
Cdigo 1.4 Prevenindo injeo com Stored Procedures.........................................................................30
Cdigo 1.5 Stored procedure utilizada na preveno de injeo SQL.....................................................30
Cdigo 1.6 Prevenindo injeo codificando os caracteres......................................................................31
Cdigo 2.1 Aplicao vulnervel XSS.................................................................................................. 34
Cdigo 2.2 Outro exemplo de aplicao vulnervel XSS.....................................................................34
Cdigo 2.3 Dado no confivel inserido na aplicao.............................................................................34
Cdigo 2.4 Preveno de XSS, regra 0(zero).........................................................................................35
Cdigo 2.5 Prevenindo XSS com uso da funo encodeForHTML(ESAPI)............................................36
Cdigo 2.6 Prevenindo XSS, regra 2....................................................................................................... 37
Cdigo 2.7 Prevenindo XSS utilizando-se a funo encode ForHTMLAttributes(ESAPI)........................35
Cdigo 2.8 Prevenindo XSS, regra 3....................................................................................................... 37
Cdigo 2.9 Prevenindo XSS utilizando-se a funo encode ForHTMLJavascript (ESAPI)......................38
Cdigo 2.10 Prevenindo XSS, regra 4..................................................................................................... 38
Cdigo 2.11 Prevenindo XSS utilizando-se a funo encode ForHTMLCSS(ESAPI).............................38
Cdigo 2.12 Prevenindo XSS, regra 5..................................................................................................... 39
Cdigo 2.13 Prevenindo XSS utilizando-se a funo encode ForURL(ESAPI).......................................39
Cdigo 2.14 Validao que completa a regra 5.......................................................................................39
Cdigo 2.15 Prevenindo XSS baseado no DOM, regra 7........................................................................40
Cdigo 2.16 Prevenindo XSS baseado no DOM segunda forma, regra 7............................................40
Cdigo 4.1 Aplicao vulnervel Referncias Inseguras Diretas a Objetos.........................................46
Cdigo 4.2 Exemplo de formulrio HTML ilustrando a vulnerabilidade Referncias Inseguras Diretas a
Objetos....................................................................................................................................................... 47
Cdigo 4.3 Aplicao vulnervel a Referncias Inseguras Diretas a Objeto...........................................47
Cdigo 4.4 Aplicao corrigida contra a vulnerabilidade Referncias Inseguras Diretas a Objetos........48
Cdigo 4.5 Aplicao corrigida contra a vulnerabilidade Referncias Inseguras Diretas a Objetos........49
Cdigo 5.1 Formulrio web vulnervel a CSRF.......................................................................................51
Cdigo 5.2 Script transferirFundos.php de forma vulnervel...................................................................51
Cdigo 5.3 URL que acionar a operao de transferncia....................................................................52
Cdigo 5.4 URL adulterada camuflada em uma imagem de byte zero....................................................52
Cdigo 5.5 Criando um token para umc ampo hidden.............................................................................53
Cdigo 5.6 Criando um token para uma URL..........................................................................................53
Cdigo 5.7 Script transferirFundos.php corrigido.....................................................................................53
Cdigo 6.1 Expondo erros de forma indevida.......................................................................................... 56
Cdigo 6.2 Expondo erros de forma indevida, dados do servidor...........................................................56
Cdigo 6.3 Configurao register_globals............................................................................................... 57
Cdigo 6.4 Exemplo de ataque aproveitando-se da diretiva allow_url_open..........................................58
Cdigo 7.1 Gerando Hash....................................................................................................................... 61
Cdigo 7.2 Listando os algortimos para gerao do hash......................................................................62
Cdigo 8.1 Exemplo de reas restritas que necessitam de autenticao................................................64
Cdigo 8.2 reas restritas muito comuns e por essa razo bastante vulnerveis...................................64
Cdigo 8.3 Exemplo de ataque path transversal...................................................................................65
Cdigo 8.4 Requisio de HTTP forjada.................................................................................................65
Cdigo 8.5 Expondo o arquivo /etc/passwd............................................................................................. 65
Cdigo 8.6 Exemplo de controle de acesso............................................................................................66
Cdigo 8.7 Protegendo diretrio com arquivos .htaccess........................................................................67
Cdigo 9.1 Ativando a opo secure na criao de cookies.................................................................70
Cdigo 10.1 Exemplo de aplicao vulnervel........................................................................................ 72
Cdigo10.2 URL maliciosa utilizada no redirecionamento invlido..........................................................72
Cdigo 10.3 Prevenindo redirecionamentos e encaminhamentos invlidos............................................72
Lista de siglas
AJAX - Asynchronous Javascript and XML

CSS -Cascading Style Sheet
XML - Extensilbe Markup Language
HTML - Hypertext Markup Language
HTTP - Hypertext Transfer Protocol
OWASP - Open Web Application Security Project
PHP - Personal Home Page.
PDO - PHP Data Object
SGBD - Sistema Gerenciador de Baco de Dados
SQL - Structured Query Language
URL - Uniform Resource Locator
Sumrio
Introduo....................................................................................................................................................... 15
1 Alguns conceitos prvios.......................................................................................................................... 21
1.1 - Aplicao web (web applicattion) e tecnologias correlatas................................................................21
1.2 - Arquitetura......................................................................................................................................... 22
1.3 OWASP (Open Web Application Security Projetc)...........................................................................23
2 -A1 Injeo(Injection)................................................................................................................................... 26
2.1 Conceitos Bsicos............................................................................................................................ 26
2.2 - Exemplo de aplicao vulnervel...................................................................................................... 26
2.3 - Preveno......................................................................................................................................... 28
3 - A2 XSS(Cross Site Scripting).................................................................................................................... 33
3.2 Exemplo de aplicao vulnervel..................................................................................................... 34
3.3 Preveno......................................................................................................................................... 36
4 - A3 Quebra de Autenticao e da Gesto de Sesso................................................................................42
4.3 Preveno......................................................................................................................................... 44
5 A4 Referncias Inseguras Diretas a Objetos............................................................................................ 46
5.3 Preveno......................................................................................................................................... 48
6 A5 CSRF(Cross Site Request Forgery).................................................................................................... 51
6.3 Preveno......................................................................................................................................... 53
7 A6 Configurao Incorreta de Segurana................................................................................................. 56
7.3 - Preveno......................................................................................................................................... 57
8 A7 Armazenamento Criptogrfico Inseguro..............................................................................................61
8.3 Preveno......................................................................................................................................... 62
9 A8 Falha na restrio de acesso a URL................................................................................................... 64
9.2 Exemplo de sistema aplicao vulnervel........................................................................................65
9.3 Preveno......................................................................................................................................... 67
10 A9 Insuficiente Proteo da Camada de Trasporte................................................................................69
10.1 Conceitos Bsicos.......................................................................................................................... 69
10.2 Exemplo de aplicao vulnervel................................................................................................... 70
10.3 Preveno....................................................................................................................................... 71
11 A10 Redirecionamento e Encaminhamentos Invlidos...........................................................................72
11.1 Conceitos Bsicos.......................................................................................................................... 72
11.2 Exemplo de aplicao vulnervel................................................................................................... 73
11.3 Preveno....................................................................................................................................... 73
12 - Consideraes finais............................................................................................................................... 74
Referncias..................................................................................................................................................... 75
Introduo
Atualmente no mais possvel imaginarmos uma organizao sem que a
mesma no utilize a Tecnologia da Informao (TI) de forma estratgica e
competitiva. Muitas vezes a TI utilizada como ferramenta bsica e de provento
para a existncia da organizao. Por exemplo, como seria possvel a existncia de
uma rede social como o Facebook sem o uso da TI? E uma empresa de vendas por
varejo on-line como a Amazon? A TI no s faz parte da estratgia da empresa
como um diferencial, mas tambm pode ser o principal combustvel por trs de uma
organizao. A procura pela TI tambm se faz por pessoas comuns; o uso de e-mail
est disseminado, muitos possuem uma pgina em uma rede de relacionamento,
compras e troca de mercadorias so realizadas pela internet, livros so lidos on-line.
A Internet sem dvida foi a fora propulsora para alavancar esse incrvel movimento
cultural.
Naturalmente, com a crescente demanda pela TI por parte das empresas e,
tambm, por parte das pessoas fsicas, os problemas no tardaram em surgir . O
prejuzo contabilizado por pessoas fsicas e jurdicas. Pginas na Internet so
fraudadas e falsificadas, imagens de empresas so comprometidas, dados
confidenciais das pessoas so expostos devido a um ataque e etc... A lista
bastante extensa.
Em 10/11/2010 o jornal eletrnico G1 publicou que nos EUA 7 pessoas,
sendo 6 estonianos, desviaram US$14 milhes em fraude de anncios on-line. Eles
atuaram livremente durante um perodo de 5 anos. Os suspeitos criaram seus
prprios servidores falsos para redirecionar o trfego da internet para sites onde eles
tinham uma fatia da receita de publicidade. O problema apenas foi identificado
quando eles infectaram 130 computadores da NASA. 1
Em 25/05/2009 o departamento jornalstico do portal Softpedia publicou que
um Gray-hat (hacker de chapu cinza que est entre um hacker de chapu branco e
o hacker de chapu preto, sendo um bem intencionado e outro mal intencionado
1 - G1. Criminosos roubam US$ 14 milhes em fraudes de ancios on-line. Disponvel em:
http://g1.globo.com/tecnologia/noticia/2011/11/criminosos-roubam-us-14-milhoes-em-fraude-deanuncios-line.html. Acesso em 25/11/2011
14
respectivamente) Romeno chamado Unu atravs de um ataque de injeo de

SQL(vide captulo 2) exps as senhas de 245.000 usurios da empresa de
telecomunicaes francesa Orange. O sistema da Orange estava sob os cuidados
do estrategista-chefe de segurana da IBM Internet Security Systems. 2
Muito tem sido feito para fortalecer e proteger sistemas computacionais no
que se refere infraestrutura. Firewalls, IDS (Intrusion detecion system),
monitoramento de redes, DMZ (demilitarized zone), Biometria, etc... quando bem
aplicados, fazem seu trabalho de forma eficiente e pontual e garantem uma maior
proteo ao sistema computacional. possvel afirmar que todas as camadas da
rede esto bem desenvolvidas quanto a segurana exceto para a camada de
aplicao. Conforme Albuquerque e Ribeiro (2002, p. 1), o desenvolvimento de
sistemas uma das reas mais afetadas pelos aspectos da segurana. Muitos dos
problemas de segurana existentes hoje, no so, nem fsicos e nem de
procedimento, mas sim, devidos a erros de programao ou de arquitetura.
Existem dois motivos bsicos que justifica a razo da necessidade de
segurana em sistema computacionais:
1. Existem legislaes ou polticas de segurana a que preciso obedecer
2. Existem ameaas ao objetivo da aplicao que precisam ser eliminadas ou mitigadas.
A segurana da informao (SI) tambm deve considerar os aspectos do

software, porqu segurana no um parmetro nico. A SI sobre a ptica do
desenvolvimento de software possui trs preocupaes: a) Segurana no ambiente
de desenvolvimento, quando preciso manter os cdigo fontes seguros, b)
Segurana da aplicao desenvolvida, visando como objetivo desenvolver uma
aplicao que seja segura e que no contenha falhas que comprometam a
segurana e c) Garantia da segurana da aplicao desenvolvida, visa garantir ao
cliente a segurana da aplicao desenvolvida atravs de testes adequados.
(ALBUQUERQUE; RIBEIRO 2002, p. 10).
Neste cenrio onde a demanda por sistemas computacionais encontra-se em
2SOFTPEDIA. Orange French Portal Hacked. Disponvel em:
http://news.softpedia.com/news/Orange-French-Portal-Hacked-112437.shtml . Acesso em: 25/11/2011
15
franco crescimento e a oferta relativamente escassa, softwares dos mais variados

fins so desenvolvidos sem a devida preocupao com a segurana. So vrios os
setores afetados pelo desenvolvimento inseguro de software, preciso aumentar a
sensibilizao sobre a segurana das aplicaes web, esse o objetivo do projeto
Top 10. As vulnerabilidades e riscos estudados no projeto Top 10 no so
vulnerabilidades obscuras e de difcil entendimento, na verdade so erros crassos
cometido por empresas e profissionais da TI. Segundo o OWASP Top 10(2010):
O software inseguro est a minar a nossa sade financeira, a
rea da defesa, da energia e outras infraestruturas crticas.
medida que nossa infraestrutura digital fica cada vez mais
complexa e interligada, a dificuldade na construo de
aplicaes seguras aumenta exponencialmente. No
possvel tolerar mais os problemas de segurana
apresentados no Top Ten. (OWASP Top 10, 2010)
Os problemas podem ser resumidos em apenas uma questo: como proteger

os sistemas computacionais? A resposta abrangente e tema de discusso
calorosa. O desenvolvimento de software carece de se preocupar com a SI. Essa
carncia se deve em partes pela cultura competitiva na qual o profissional inserido.
Comumente, o profissional de TI escolhe uma carreira voltada para infraestrutura ou
para desenvolvimento de software e dessa forma ele cria seus grupos de afinidades
e estes, por sua vez, funcionam como pequenos exrcitos competindo entre si. O
problema no o exerccio da competio e sim os efeitos colaterais dessa atitude:
dificilmente encontra-se equipes de TI integradas e com um nico objetivo. Em
outras palavras, a SI vem sendo praticada de forma isolada tanto pela equipe da
infraestrutura quanto pela equipe de desenvolvimento, quando um ambiente mais
produtivo seria a unificao de ambos os grupos.
O presente trabalho foca seus esforos na segurana da aplicao
desenvolvida, tendo como objetivo contribuir para o desenvolvimento seguro de
aplicaes web escritas em PHP e que usam como banco de dados o MySql. De
forma mais especfica, os objetivos so: identificar e estudar as principais
vulnerabilidades e riscos que podem comprometer um aplicao web e alm de
propor meios para mitig-los.. As vulnerabilidades so apontadas pelo projeto
OWASP Top 10 (2010), que ser apresentado no captulo 1. Cada vulnerabilidade
16
ter seu prprio captulo no qual sero discutidos conceitos bsicos a respeito da
vulnerabilidade, cdigo fonte de exemplo ser construdo e, por fim, como aplicar a
devida preveno. Apesar do presente estudo fechar o escopo em torno da
arquitetura LAMP (Linux, Apache, MySql e PHP) ele pode servir como base de
compreenso dos fundamentos expostos pelo projeto Top 10 sendo facilmente
traduzido para outra arquitetura.
Para atingir tais objetivos, utilizou-se uma abordagem qualitativa no
desenvolvimento desta pesquisa, uma vez que nesta o intuito compreender mais
profundamente os fenmenos estudados e interpret-los de acordo com uma
determinada perspectiva sem a preocupao com representatividade numrica ou
mesmo relaes de causa e efeito. (TERENCE; ESCRIVO FILHO, 2006).
No que se refere ao mtodo de abordagem utilizado, buscou-se adotar o
raciocnio hipottico-dedutivo pois buscou-se construir e testar possveis respostas
ou solues para problemas decorrentes de fatos ou conhecimentos tericos, algo
diretamente relacionado com a experimentao, como mostra Marques et al (2006,
p. 43-44).
Quanto aos objetivos da pesquisa, a mesma pode ser classificada como
analtica pois, como mostram Marques et al (2006, p. 52), trata-se de um "tipo de
estudo que visa (...) analisar uma dada situao (objeto de estudo), mediante
procedimentos de decomposio do todo estudado, visando no apenas conhecer
seus elementos constituintes, mas sobretudo como eles se articulam entre si.". No
caso, o objeto de estudo so as aplicaes Web.
Em relao participao do pesquisador, esta pode ser classificada como
pesquisa-ao, j que nela o pesquisador desenvolve aes para resolver os
problemas
fundamentais
identificados,
desempenhando
"papel
ativo
no
equacionamento dos problemas encontrados, no s faz a investigao, mas

procura desencadear aes e avali-las" (Marques et al. 2006, p. 54)
Sobre os mtodos utilizados para coleta de dados, foram utilizadas a
pesquisa bibliogrfica e a anlise documental no sentido de buscar fontes de
informao a respeito da arquitetura de aplicaes Web, bem como das
17
vulnerabilidades mais presentes nessas aplicaes, base deste trabalho. E pode-se

dizer que esta pesquisa constitui um estudo de caso pois, ainda apropriando-se das
palavras de Marques et al (2006, p. 55), este mtodo "consiste no estudo de
determinados
indivduos,
profisses,
condies,
instituies,
grupos
ou
comunidades, com a finalidade de obter generalizaes". No caso desta pesquisa,

so estudadas as condies de vulnerabilidade de aplicaes Web.
O presente trabalho est organizado em 12 captulos, sendo que a maior
parte desses captulos ser dedicada a apresentao das Top 10 vulnerabilidades e
medidas que visam mitig-las.
O captulo 1 de carter introdutrio e estabelece conceitos necessrio para
o bom entendimento deste trabalho, traz tambm informaes sobre a OWASP e
sore a arquitetura LAMP.
O captulo 2 tratar da Injeo de instrues SQL(A1), mtodo com o qual um
usurio mal intencionado pode executar cdigos em linguagem SQL danificando
banco de dados e comprometendo, dessa forma, a aplicao web.
O captulo 3 tratar das 3 formas de XSS(A2): refletido, armazenado e
baseado no modelo DOM. Ambas permitem ao atacante a execuo de scripts no
navegador da vtima com o intuito de roubar a sesso de navegao, alterar sites
da internet (pichar) ou, at mesmo, redirecionar os usurios para sites maliciosos.
O captulo 4 tratar da quebra de autenticao(A3) que explora as funes de
autenticao e gesto de sesses. Quando essas funes so implementadas de
forma incorreta e exploradas, permite ao atacante assumir a identidade de outro
utilizador devido a descoberta de senhas, chaves e identificadores de sesso.
O captulo 5 tratar de referncias inseguras diretas a objetos (A4), a
explorao dessa vulnerabilidade permite ao atacante acessar informaes noautorizadas ferindo, dessa forma, a confidencialidade da informao.
O captulo 6 tratar de CSRF (A5), tal falha permite ao atacante forar o
navegador da vtima a criar requisies HTTP forjados, no qual a aplicao web
aceita como requisies legtimas oriundas da vtima.
18
O captulo 7 abordar a vulnerabilidade de Configurao Incorreta de

Segurana (A6). A segurana da aplicao depende, tambm, da existncia de
configuraes adequadas e boas prticas na manuteno do ambiente no qual a
aplicao web estar alojada.
O captulo 8 tratar do assunto criptografia (A7). O ponto chave dessa
vulnerabilidade (armazenamento criptogrfico inseguro) est, no somente nos
dados criptografados, mas nas chaves de criptografia, pois comumente elas so mal
protegidas.
O captulo 9 tratar de falhas nas restries de acesso(A8). Esconder uma
URL e validar apenas do lado do cliente so erros comuns encontrados nas
aplicaes web, no obstante, a explorao dessa vulnerabilidade seja considerada
de nvel fcil. A aplicao no pode permitir que pginas sejam acessadas sem a
devida autenticao.
O captulo 10 tratar da insuficiente proteo da camada de transporte(A9)e
sensibiliza quanto a correta utilizao do protocolo SSL, em outras palavras, auxilia
na correta implementao de um certificado digital. A explorao dessa
vulnerabilidade, normalmente, realizada atravs de monitoramento da rede.
O captulo 11 tratar de redirecionamento invlidos(A10). Aproveitando-se de
validaes inadequadas, os atacantes redirecionam a vtima para sites de maliciosos
(caracterizando ataque de phishing ou de malware) ou aproveitam-se do
encaminhamento para acessar pginas no autorizadas e, finalmente, o captulo 12
trar consideraes finais e reflexes sobre o trabalho.
19
1 Alguns conceitos prvios.

1.1 - Aplicao web (web applicattion) e tecnologias correlatas.
A World Wide Web (WWW) iniciou-se na dcada de 1990 com a construo
de websites estticos; havia muito texto, alguns links e algumas poucas imagens.
Evolutivamente, a linguagem Hypertext Markup Language (HTML) que era usada
para desenhar e estruturar as pginas da internet e ainda hoje o faz, desenvolveu-se
permitindo que novos recursos fossem adicionados e explorados. Atualmente a
linguagem de marcao de contedo HTML encontra-se na verso 5 e conta com
recursos que eram somente encontrados em softwares de animaes interativas
como o Flash (da Adobe) e o Silverlight (da Microsoft).
Concomitante com a HTML novas tecnologias apareceram. A CSS tem a
funo de estilizar o HTML auxiliando na organizao, manuteno e legibilidade do
cdigo. Javascript outra linguagem que se tornou popular quando a Netscape
embutiu-o em seus navegadores. O Javascript pode executar cdigo do lado do
cliente melhorando, dessa forma, a usabilidade e experincia do usurio e ajuda a
diminuir viagens desnecessrias ao servidor. XML uma tecnologia de marcao de
contedo utilizada para diversos fins como, por exemplo, a integrao de sistemas
ou um armazenamento rpido e independente de um Sistema Gerenciador de Baco
de Dados (SGBD). Uma das tecnologias mais surpreendentes e revolucionrias que
surgiu fora o AJAX, que se utiliza da combinao de Javascript e XML para
recuperar dados do servidor e renderizar na tela do navegador web sem a
necessidade de um recarregamento total da pgina.
A Internet mudou a forma como interagimos com o mundo; compramos
produtos via comrcio eletrnico, os relacionamentos pessoais acontecem atravs
de redes sociais, expressamos nossas opinies atravs de blogs, vemos notcias
on-line, nos divertimos on-line e at aprendemos on-line. Essas formas de interao
possuem algo em comum um veculo de entrega que apanhe as informaes
brutas, estruture de maneira significativa e devolva ao navegador web de uma
maneira que inicie uma conversa. Pressman e Lowe concluem que:
20
O veculo que adquire a informao, a estrutura, monta uma

apresentao empacotada e a entrega chamado de
aplicao web. Quando uma aplicao web combinada com
hardware cliente e servidor, sistemas operacionais, software
de rede e navegadores surge um sistema baseado na web.
(PRESSMAN E LOWE, 2009, p. 2)
O funcionamento bsico de uma aplicao web pode ser compreendido da

seguinte forma: o usurio abre um navegador web e acessa a um endereo
eletrnico (URL). O navegador, atravs da rede (que pode ser interna ou a prpria
Internet) faz uma requisio para o servidor web que interpreta o cdigo fonte,
processa a informao e devolve cdigo HTML (as vezes misturado com cdigo
CSS e Javascript) ao navegador do usurio. Para trafegar pela rede o sistema
utiliza-se do protocolo HTTP. O cdigo do lado do servidor (server script) pode ou no
acessar um SGBD como por exemplo, Mysql ou PostgreSql ou at mesmo um simples
arquivo de texto ou um arquivo XML. A linguagem de programao utilizada do lado do
servidor pode ser PHP, ASP, Java, Ruby, Python, etc...
1.2 - Arquitetura
A arquitetura utilizada para a elaborao, aplicao e testes de cdigos fontes
do tipo cliente-servidor. Do lado do servidor roda o servidor web Apache2 instalado
com o mdulo interpretador PHP compatvel com a verso 5 ou superior . Como
SGBD foi utilizado o MySql compatvel com a verso 5 ou superior A figura 01 ilustra
a organizao da arquitetura:
Figura 01 Arquitetura cliente-servidor e tecnologias utilizada
Fonte: MORIMOTO (2008, p. 358)
Morimoto (2008) esclarece:

...quando voc acessa uma pgina em PHP em um site que
roda sobre um servidor Apache, ele (Apache) l o arquivo no
disco e repassa a requisio para o mod_php, o mdulo
21
encarregado de processar arquivos PHP. Ele, por sua vez,

aciona o interpretador PHP, que processa a pgina e a
entrega, j processada, ao Apache, que, finalmente, a entrega
ao cliente. Caso seja necessrio acessar um banco de dados
(como no caso de um frum ou de um gestor de contedo),
entra em ao outro mdulo, como o php5-mysql, que permite
ao interpretador PHP acessar o banco de dados.
PHP uma linguagem de programao para web do tipo server-side. Criada

por Rasmus Lerdorf em 1995 com o simples objetivo de registrar estatisticamente o
acesso ao seu currculo online. Inicialmente chamada de PHP/FI (Personal Home
Page / Forms Interpreter) seu cdigo foi disponibilizado na Internet para que outros
desenvolvedores pudessem contribuir. Atualmente, na verso 5, uma bastante
madura e utilizada na maioria dos sites e provedores de Internet.
MySql um banco de dados (SGBD) construdo para aplicaes web. Em
torno de 1995 a empresa sua TcX iniciou o desenvolvimento do Mysql e lanou o
produto um ano depois sob licena open source. A empresa MySql AB, fundada pelo
seus criadores, mantiveram o projeto ativo. Em 2008 a Sun Microsystems comprou a
MySql AB e em 2009 a Oracle comprou a Sun e todos os seus produtos, incluindo o
MySql com a promessa de mant-lo sob a licena open source.
Apache um servidor web, sua primeira verso foi lanada em 1995 e sua
utilizao se disseminou pelos servidores mundo a fora. Atualmente encontra-se na
verso 2 (Apache2) e pode no apenas executar script PHP mas tambm Perl, Shell
script e at ASP.
Linux um sistema operacional open source criado em 1990 pelo finlands
Linus Torvalds. Reconhecido mundialmente por sua robustez e confiabilidade
muito utilizado como servidor para diversos fins. Cada vez mais est presente em
computadores pessoais como um sistema desktop, atualmente conta com mais de
500 distribuies (tipos).
1.3 OWASP (Open Web Application Security Projetc)

A OWASP uma comunidade aberta com o objetivo de capacitar as
organizaes a desenvolver, adquirir e manter, aplicaes que podem ser confiveis
e todos os seus projetos e contedos so distribudos de forma livre e aberta. Trata22
se de uma entidade sem fins lucrativos livre de presses comerciais o que garante
fornecimento de informao de forma imparcial. A OWASP mantm dezenas de
projetos no qual destacamos:
Top 10 Ranking com as 10 maiores vulnerabilidades web. A verso do Top 10 que este
trabalho se apoia a atualizao de 2010. O Top Ten foi lanado em 2003 e sofreram
pequenas atualizaes em 2004 e 2007 e mais recentemente em 2010. O projeto Top 10
referenciado por muitas normas, livros ferramentas e organizaes, incluindo MITRE, PCI
DSS, DISA, FTC e muitas outras. O objetivo do projeto Top 10 aumentar a sensibilizao
sobre a segurana das aplicaes atravs da identificao de alguns dos riscos mais crticos
e comuns que as organizaes enfrentam. Ainda como objetivo principal o Top 10 visa
educar programadores, designers, arquitetos e organizaes acerca das consequncias das
mais importantes deficincias de segurana em aplicaes Web.
ESAPI (The OWASP Enterprise Security API) biblioteca de cdigo fonte free e open source
escrita originalmente em Java. Prov uma interface de programao segura para ser
acoplado ao sistema web.
ASVS prov padres de controle de segurana para quando as vulnerabilidades forem

tratadas.
Guide Project (Development guide) guia de desenvolvimento de aplicaes web seguras.
A OWASP criou uma metodologia de classificao de riscos (Risk Rating

Methodology) para ajudar a definir riscos. Cada organizao e aplicao possui sua
prpria especifidade do ambiente, o que torna a anlise de risco particular para cada
caso ou organizao. A OWASP desenvolveu sua metodologia de classificao de
riscos de forma genrica, centrando-se na identificao dos riscos mais srios para
um leque variado de organizaes. A tabela 01 mostra os itens que compem a
metodologia:
Tabela 01 Anlise de risco segundo a OWASP
Prevalncia da
Vulnerabilidade
Agente de
Ameaa
Vector de
Ataque
Threat Agent
Attack Vector
Weakness
Prevalence
Fcil
Mdio
Difcil
Generalizada
Comum
Pouco comum
Facilidade de
Deteco da
Vulnerabilidade
Weakness
Detectability
Fcil
Mdio
Difcil
Impacto
Tcnico
Impacto
de Negcio
Technical Impact
Business Impact
Severo
Moderado
Menor
Fonte: OWASP Top 10 (2010)
O Agente de Ameaa e o Impacto de Negcio referem-se as

particularidades de cada organizao. O impacto de negcio mudar de uma
organizao para outra e da mesma forma o Agente de amea tambm particular
23
de cada organizao. Em outras palavras, quem define qual o impacto de negcio

e o agente de ameaa a prpria organizao. O vetor de ataque, as
vulnerabilidades (prevalncia e deteco) e o impacto tcnico servem de base ou
guia para facilitar e tornar assertivo a definio do agente de ameaa e do impacto
de negcio.
Um atacante poder percorrer caminhos diferentes atravs de uma aplicao
podendo causar danos organizao. Estes caminhos podem ser fceis ou
extremamente difceis de serem explorados de forma similar os danos causados
podem variar conforme exemplifica a figura 02.
Figura 02 Caminhos percorrido pelo atacante
Fonte: Top Ten(2010)
Para determinar o risco preciso avaliar a probabilidade associada ao agente

de ameaa, o vector de ataque e a vulnerabilidade de segurana e combin-los com
a estimativa de impacto tcnico e de negcio da organizao. Os elementos
referidos, todos juntos, determinam o risco global ou total.(OWASP Top 10, 2010)
24
2 -A1 Injeo(Injection)
2.1 Conceitos Bsicos
A Injeo caracteriza-se quando o atacante, incluindo utilizadores internos e
administradores, podem enviar dados no confiveis ao sistema, ou seja, sem
tratamento adequado. Esses dados (na verdade trata-se de strings que formam uma
consulta, queries) chegam at o sistema e atingem um interpretador de comandos. A
injeo pode ocorrer como consultas SQL, LDAP ou Xpath.
...este mtodo
particularmente perigoso, pois consiste na insero de cdigo SQL no previsto e,

de modo arbitrrio, compromete toda a funcionalidade do sistema e tambm da base
de dados. (SICA; REAL, 2007, p 65)
Segundo o projeto OWASP Top 10 (2010) a classificao do risco
enquadrado da seguinte forma: o vetor de ataque considerado fcil pois pode ser
constitudo por qualquer fonte de dados. A deteco considerada mdia porque
fcil encontr-la quando se faz uma verificao do cdigo fonte da aplicao, porm
mais difcil atravs de testes. Scanner e Fuzzers podero ajudar os atacantes a
encontr-las. O impacto para o negcio severo pois pode, por exemplo, prejudicar
toda a base de dados e pode tambm dar acesso total do sistema ao atacante. A
tabela 02 sintetiza a classificao do risco.
Tabela 02 Mapeamento do risco de injeo.
Agente de
Ameaa
Vector de
Ataque
Explorao
Fcil
Vulnerabilidade de Segurana
Prevalncia
Deteco
Comum
Mdio
Impacto
Tcnico
Impacto
de Negcio
Severo
Fonte: OWASP Top 10 (2010).
2.2 - Exemplo de aplicao vulnervel

Todo formulrio web pode servir como porta de entrada(uma vulnerabilidade)
para o ataque de Injeo de SQL. mais comum este ataque acontecer na tela de
login, pois este o primeiro formulrio do sistema e normalmente mais exposto do
que os demais formulrios. Mas isso no significa que os formulrio internos (os
posteriores tela de login) do sistema no precisem de preveno. importante
25
lembrar que o atacante pode ser externo (provavelmente atacando a tela de login) e
interno (usurio do sistema mal intencionado). O atacante tentar, atravs de vrias
tentativas, descobrir a estrutura do banco de dados, por isso importante que os
nomes de campos dos formulrios no lembrem os nomes dos campos do banco de
dados. conforme relata Pessoa (2007, p. 108)
necessrio que o atacante realize tentativas de acesso para
conhecer a estrutura do banco de dados. Essa tarefa se torna
mais fcil quando os nomes das variveis usadas em
formulrio HTML so usados na estrutura do banco de dados,
afinal o cdigo HTML legvel aos usurios da web.
Importante salientar que a utilizao de nomes de variveis diferentes no

impedir o ataque de injeo de SQL. Pessoa (2007, p. 108)
Como exemplo de aplicao vamos considerar o formulrio de login como o
apresentado na figura 03 e pelo cdigo 1.1.
Figura 03 Exemplo de formulrio web. Tela de login.
Cdigo 1.1 Exemplo de formulrio web.
26
O cdigo que interage com o formulrio da figura 02 deve receber os dados

vindo do formulrio, conectar-se com o banco de dados, montar a declarao SQL,
envi-la para o banco de dados (o interpretador) e checar se houve xito na
execuo da declarao.
Cdigo 1.2 Cdigo em PHP que recebe e processa os dados de um formulrio web
As linhas 2 e 3 recebem os dados vindos do formulrio via mtodo post e

armazenam em suas respectivas variveis. A linha 5 conecta-se com o banco de
dados. A linha 7 cria dinamicamente a declarao SQL. A linha 8 envia e executa a
declarao SQL para o banco de dados. A linha 10 testa o resultado e em caso
afirmativo permite acesso e registra credenciais do usurio no sistema. A linha 15
utiliza-se da funo PHP var_dump() para debugar o cdigo, ela mostra o contedo
e tipo da varivel. Neste exemplo, preciso ver o que aconteceu com a varivel
$sql.
O cdigo 1.2 se torna vulnervel, principalmente, pelo fato de construir a
declarao SQL dinamicamente (vide linha 7). Os dados que chegam do formulrio
no so tratados adequadamente e acabam por compor uma declarao SQL
maliciosa.
2.3 - Preveno
Segundo Wichers e Manico (2011) a vulnerabilidade de Injeo pode ser
prevenida de trs formas distintas: a) utilizando-se de consultas parametrizadas, b)
utilizando-se de procedimentos armazenados (stored procedures) e c) codificando
27
caracteres de entrada
A primeira forma (consultas parametrizadas) utilizam-se de recursos internos
do SGBD para preparar a declarao SQL. Essa abordagem no cria a declarao
SQL dinamicamente, garantindo assim, que a declarao no seja alterada
indevidamente.
No PHP possvel contar com a extenso PDO para utilizar-se de consultas
parametrizadas. Essa extenso define uma interface consistente para acesso a
banco de dados em PHP. Ela facilita a manuteno do cdigo fonte e auxilia a troca
de banco de dados utilizado na codificao. (GILMORE, 2008 p.631)
O cdigo 1.3 faz uso da extenso PDO, entre as linhas 2 e 10 ocorre a
conexo com o banco de dados, na linha 8 instanciada a classe PDO. As linhas 12
e 13 recebem os dados do formulrio. A linha 15 utiliza o mtodo prepare() do objeto
instanciado para preparar o comando SQL, repare que no passado os
parmetros diretamente na declarao SQL, em seu lugar esto apenas as
referncias :login e :senha. A funo principal a bindParam() que liga-se um
parmetro para o nome da varivel especificada (Manual Oficial do PHP, 2011)
ela quem faz todo o trabalho de sanitizao. A linha 19 executa o comando e, entre
as linhas 21 e 26, checado o resultado da consulta.
28
Cdigo 1.3 Prevenindo injeo com consultas parametrizadas
A segunda forma, stored procedures (SP), so procedimentos previamente

armazenados no SGBD. Seu funcionamento similar as funes em uma linguagem
de programao. SP podem receber ou no parmetros e podem retornar ou no
algum valor. A inconvenincia dessa abordagem que ela torna a aplicao pouco
portvel, pois diferentes SGBD utilizam diferentes implementaes da SP, ou seja,
uma SP funcionando em MYSQL, por exemplo, poder no funcionar em outro
SGBD e vice-versa.
As operaes da SP, por serem previamente elaboradas, no executaro
aquilo que elas no foram desenhadas para executar garantindo assim a integridade
da declarao SQL.
No cdigo 1.4, entre as linhas 2 e 6 o cdigo faz a conexo com o banco de
dados atravs do driver mysqli ( conjunto de cdigo com o objetivo de realizar e
gerenciar a conexo entre o cdigo fonte e o SGBD). As linhas 8 e 9 recebem os
dados vindos do formulrio. Entre as linhas 11 e 13 montado um array na varivel
$query onde o ndice 0(zero) contm o comando SQL que faz chamada para a SP
e o ndice 1 recupera o valor retornado pela SP. A linha 15 executa o comando SQL
29
do ndice o(zero). A linha 16 executa o comando SQL de ndice 1 e guarda o seu

resultado na varivel $res. A linha 17 apenas transforma o resultado da consulta em
um objeto. Entre as linhas 20 e 24 checamos o resultado da consulta.
Cdigo 1.4 Prevenindo injeo com Stored Procedures
A stored procedure utilizada ilustrada pelo cdigo 1.5:
Cdigo 1.5 Stored procedure utilizada na preveno de injeo SQL
A terceira e ltima forma, codificao de sada de caractere, tambm

conhecida como escapar caractere, utilizar determinada funo com o objetivo de
codificar a sada de caracteres indesejados, no caso ' (aspa simples), '' (aspas
duplas), \ (barras), \n (quebra de linhas) e \r (recuo de carro). Existem vrias
funes com esse objetivo e tambm podem ser aplicadas diferentes abordagens
para codificao de sada de caracteres. Wichers (2011) Sugere que a funo nativa
30
do SGBD Mysql mysql_real_escape_string() seja utilizada para codificao de

caracteres. O uso dessa funo implementada no cdigo 1.6.
Cdigo 1.6 Prevenindo injeo codificando os caracteres
Observando o cdigo 1.6 nota-se que entre a linha 2 e 6 feita a conexo

com o banco de dados feito atravs do driver mysql. As linhas 8 e 9 recebem os
dados do formulrio. As linhas 11 e 12 fazem o trabalho de codificao de sada dos
caracteres utilizando-se da funo mysql_real_escape_string(). A linha 14 monta o
declarao SQL de forma dinmica, porm de forma segura pois foi feito o
tratamento de dados adequado. A linha 16 executa a declarao SQL e entre as
linhas 18 e 22 feita a checagem do resultado.
31
3 - A2 XSS(Cross Site Scripting)

A XSS ocorre quando a aplicao inclui dados fornecidos pelo atacante numa
pgina enviada para o navegador sem que alguma validao ou filtragem tenha sido
feita. Pode ser, tambm, considerado como insero HTML. O atacante utiliza-se da
linguagem do lado do cliente (client-side) como o Java Script, por ser uma poderosa
ferramenta de scripting, mas qualquer linguagem de script suportada pelo navegador
da vtima um alvo potencial para este ataque inclusive interpretadores como, por
exemplo, Flash, SilverLight, ActiveX, VBScript e at mesmo comportamentos no
padro do navegador podem introduzir vetores de ataques sutis, dificultando, dessa
forma, a deteco da vulnerabilidade.
Essa modalidade de ataque ocorre quando uma aplicao web
aceita dados do usurio sem nenhum tipo de tratamento.
Assim, um possvel atacante pode injetar um cdigo
JavaScript, SQL, ActiveX ou outro, para comprometer a
segurana da aplicao coletando dados ou burlando mtodos
de validao a reas restritas. (SICA; REAL, 2007, p. 62)
H trs tipos de ataques XSS: refletido (Reflected), armazenado (persistido,

Stored) e baseado no DOM (DOM Injection). O refletido caracteriza-se por receber
os dados no seguros de um usurio e retorn-los diretamente para o browser. O
XSS armazenado quando os dados no seguros so armazenados em algum meio
para que posteriormente seja recuperado. O baseado no DOM atua manipulando ou
criando cdigo client-side na pgina. O ataque pode utilizar apenas uma tcnica ou
uma combinao das trs.
Comumente, argumenta-se que o XSS refletido de qualquer forma, mas
essa afirmao nos ajuda apenas na ilustrao da vulnerabilidade: entendendo o
XSS refletido entende-se os dois ltimos, porm cada tipo de XSS reserva
consequncias e particularidades prprias como, por exemplo, no caso do XSS
armazenado o prejuzo pode ser aumentado pelo simples fato de que o ataque se
repetir automaticamente toda vez que a informao armazenada fora recuperada e
exibida no browser.
32
O processo ocorre da seguinte forma; de um lado temos uma pgina que

enviar dados no confiveis para o script php do lado do servidor, essa pgina
poder conter desde um nico link como at um formulrio web. Esse script, por sua
vez, recebe os dados sem valid-los nem filtr-los e renderiza uma nova pgina (no
caso do XSS refletido) novamente sem validar ou filtrar os dados.
Importante frisar que o Javascript permite o uso do protocolo XmlHttpRequest
que por sua vez permite o uso da tecnologia AJAX. O uso do XmlHttpRequest
permite, em alguns casos, contornar a poltica do navegador conhecida como same
source origination encaminhado os dados da vtima para sites hostis e criando
worms complexos e zumbis maliciosos.
Segundo o projeto OWASP Top 10 (2010) a classificao do risco
enquadrado da seguinte forma: o Impacto tcnico desta vulnerabilidade moderada
podendo o atacante executar scripts no navegador da vtima para sequestrar dados
de sesso, alterar a pgina de forma perniciosa, inserir contedo hostil, redirecionar
o utilizador e at sequestrar o navegador com o uso de malware e zumbis.
Para detectar as vulnerabilidades na aplicao deve-se fazer uso de
ferramentas estticas e dinmicas Os teste automatizados so capazes de detectar
os XSS de reflexo, mas frequentemente falham na deteco do XSS persistente. J
na deteco do XSS baseado no DOM nenhuma ferramenta foi capaz de obter xito.
Uma deteco completa requer um combinao de reviso manual do cdigo e teste
de penetrao manual. A tabela 03 sintetiza a classificao do risco.
Tabela 03 Mapeamento do risco de XSS
Agente de
Ameaa
Vector de
Ataque
Explorao
Prevalncia
Deteco
Mdia
Generalizada
Fcil
Impacto
Tcnico
Impacto
de Negcio
Moderado
3.2 Exemplo de aplicao vulnervel

Todo script que envia para o navegador dados no confiveis serve de
exemplo para este tipo de ataque. Uma nica linha de cdigo pode ser responsvel
pela vulnerabilidade. Vejamos este pequeno exemplo:
33
Cdigo 2.1 Aplicao vulnervel XSS
Importante notar que apesar do ataque ser efetuado em uma linguagem

client-side, o problema continua sendo da linguagem server-side, pois ela quem
faz o trabalho de receber e posteriormente enviar os dados ao navegador.
O ataque XSS se concretiza quando a aplicao no trata os dados quando
estes so enviados do navegador para o servidor (no sentido cliente servidor) e
novamente quando os dados no tratados partem do servidor para o navegador
(sentido servidor cliente).
Um exemplo mais concreto seria o mencionado no projeto OWASP Top 10
(2010). O atacante envia um trecho de cdigo escrito em Javascript que retorna o
cookie do navegador atravs da funo document.cookie e redireciona essa
informao utilizando-se da funo document.location para o site do atacante
denominado www.attacker.com . Neste site um script escrito em cgi denominado
cookie.cgi se encarregar de receber e armazenar o cookie roubado. Neste
ataque, o atacante est preocupado com o ID de sesso de navegao da vtima,
com posse dessa informao o atacante poder criar requisies para o site
verdadeiro como um usurio real. Os cdigos 2.2 e 2.3 ilustram este ataque:
Cdigo 2.2 Outro exemplo de aplicao vulnervel XSS
Cdigo 2.3 Dado no confivel inserido na aplicao
34
3.3 Preveno
Segundo Williams e Manico (2011) existem 8 regras (numeradas de 0 a 7)
para evitar este tipo de vulnerabilidade: Regra 0(zero) - Nunca insira dados no
confiveis, exceto em locais permitidos, Regra 1 - Codificar cdigo HTML antes de
inserir dados no confiveis em contedo de elementos HTML, Regra 2 - Codificar
atributos antes de inserir dados no confiveis em atributos HTML comuns, Regra 3
- Codificar cdigo Javascript antes de inserir dados no confiveis em valores HTML
de Javascript, Regra 4 - Codificar CSS antes de inserir dados no confiveis em
valores de propriedades de estilos de HTML, Regra 5 - Codificar URL antes de
inserir dados no confiveis em parmetros de URL, Regra 6 Utilizar API para
limpar e validar qualquer tipo de sada e Regra 7 Evitar XSS baseado em DOM.
A regra de numerao zero (Nunca insira dados no confiveis, exceto em
locais permitidos) nos diz para no colocarmos nenhum tipo de dados em nosso
HTML principalmente se estiverem entre tag's <script>, entre comentrios HTML,
como um atributo de uma tag <div> e quando o sistema escreve o nome da tag. A
regra especificada pelo trecho de cdigo HTML 2.4.
Cdigo 2.4 Preveno de XSS, regra 0(zero).
Fonte: Williams e Manico (2011)
Podemos traduzir a especificao do cdigo 2.4 da seguinte forma: linha 01

no criar cdigo Javascript dinamicamente, linha 02 no criar comentrios HTML
dinamicamente, linha 03 no criar atributos de tag HTML dinamicamente e linha 04
no criar tag HTML dinamicamente.
Esta regra diz ainda, que a nica exceo para colocarmos dados no
seguros nas regies destacadas pelo cdigo 2.4 esto definidas nas regras de
numerao 1 e 5 que ser abordada mais adiante. Diz tambm para evitar contextos
aninhados (nested contexts) como um URL dentro de um Javascript pois as regras
para esse contexto so demasiadas complicadas. Ainda como recomendao, esta
regra diz que a aplicao no deve aceitar um cdigo real de Javascript de uma
35
fonte no confivel e depois execut-lo.

A regra de numerao 1 (codificar cdigo HTML antes de inserir dados no
confiveis em contedo de elementos HTML) diz que quando incluso dados no
confiveis diretamente em algum lugar no corpo do HTML considerando as tag
normais como div, p, b, d e etc... ento preciso codificar os seis seguintes
caracteres: & ( comercial), '' (aspas duplas), ' (aspas simples), < (sinal de
menor), > (sinal de maior) e \ (barra invertida). Este sinais podem (devem) ser
trocados pelos indicados na tabela 04.
Caracter
Tabela 04 Codificando caracteres

Deve ser subistitudo por...
&
&
<
<
>
>
"
"
'
'
/
' no recomendado
possvel ainda fazer uso da ESAPI com mdulo HTML entity escaping and
unescaping conforme ilustrado no cdigo 2.5.
Cdigo 2.5 Prevenindo XSS com uso da funo encodeForHTML(ESAPI)
Fonte: OWASP Top 10(2010)
A regra de numerao 2 diz que preciso codificar os caracteres quando

incluso dados no confiveis em valores de atributos tpicos como largura, nome,
valor e etc... A regra salienta que no devem receber o mesmo tratamento os
atributo considerados complexos como href, src, estilos e qualquer um dos
tratadores de eventos como mouseover, onclick e etc...para esses atributos
preciso considerar a regra de numerao 3. A regra 2 especificada pelo trecho de
cdigo HTML 2.6 e pode ser compreendida da seguinte forma: No colocar dados
36
no confiveis em atributos de tag's HTML estejam eles dentro de aspas duplas,

simples ou mesmo sem aspas.
Cdigo 2.6 Prevenindo XSS, regra 2.
possvel ainda fazer uso da ESAPI com mdulo HTML entity escaping and
unescaping conforme de mosntrado no cdigo 2.7(repare que o mtodo chamado
difere do mtodo chamado na utilizao da ESAPI para a Regra 1).
Cdigo 2.7 Prevenindo XSS utilizando-se a funo encode ForHTMLAttributes(ESAPI)
Esta regra ainda salienta que prefervel utilizar os atributos com as aspas
duplas do que com sem as aspas uma vez que atributos sem aspas podem ser
facilmente quebrados por caracteres como
(espao), % (porcentagem), *
(asterisco), + (sinal de soma), - (sinal de subtrao), ; (ponto e vrgula), <

(sinal de menor), = (sinal de igualdade), > (sinal de maior), ^ (circunflexo) e
| (barra reta).
A regra de numerao 3 trata os dados que so inseridos como parmetros
em funes Javascript. Toda funo que utilize parmetros, atribuio variveis e
principalmente tratadores de eventos devem ter os dados tratados. A regra 3
especificada pelo trecho de cdigo HTML 2.8.
possvel fazer uso da ESAPI com mdulo HTML entity escaping and
37
unescaping conforme demonstrado no cdigo 2.9.

Cdigo 2.9 Prevenindo XSS utilizando-se a funo encode ForHTMLJavascript (ESAPI).
Fonte: Top 10 (2010)
A regra de numerao 4 (codificar CSS antes de inserir dados no confiveis

em valores de propriedades de estilos de HTML) diz respeito situao em que o
sistema precisa colocar dados no confiveis em um estilos CSS. O Importante
que o sistema use dados no confiveis somente em um valor de propriedade CSS
e no em outros lugares de estilo. A regra recomenda que estilos no devem ser
colocados em propriedades complexas como URL e comportamentos. O trecho de
cdigo HTML 2.10 ilustrada os locais que no devem ser colocados dados no
confiveis:
possvel fazer uso da ESAPI com mdulo HTML entity escaping and
unescaping conforme demonstrado no cdigo 2.11.
Cdigo 2.11 Prevenindo XSS utilizando-se a funo encode ForHTMLCSS(ESAPI)
Fonte:OWASP Top 10 (2010)
A regra de numerao 5 (codificar URL antes de inserir dados no confiveis

em parmetros de URL) diz respeito situao em que o sistema precisa incluir
ncoras em uma pgina que ser enviada para o navegador os dados devem ser
tratados apropriadamente. O cdigo abaixo demonstra o local que deve ser
38
considerado na aplicao codificando-se todos os dados no confiveis:

Para esta regra poder ser feito o uso da ESAPI com mdulo HTML entity
escaping and unescaping conforme demonstrado pelo cdigo 2.13.
Cdigo 2.13 Prevenindo XSS utilizando-se a funo encode ForURL(ESAPI)
A regra ainda recomenda que para ser completo o tratamento da URL deve
passar por uma validao antes conforme demostrado no cdigo 2.14:
Cdigo 2.14 Validao que completa a regra 5
A regra de numerao 6 diz respeito da API AntiSamy, um projeto da OWASP

que tem como finalidade garantir que o HTML/CSS fornecido pelo usurio est em
conformidade com o sistema web. Esta API foi escrita inicialmente na linguagem
Java e, por essa razo, no ser abordado o seu uso.
A regra de numerao 7 trata do XSS baseado no DOM. A principal diferena
entre o XSS baseado no DOM e os outros dois modos (refletido e armazenado)
que o XSS refletido e armazenado um problema que deve ser tratado do lado do
servidor enquanto o XSS baseado no DOM um problema que deve ser tratado no
lado do cliente. Porm, todo o cdigo gerado no servidor, por tanto de
39
responsabilidade dos desenvolvedores da aplicao web tornar o cdigo seguro

contra ataques XSS em geral.
Para a devida preveno de XSS baseado no DOM preciso utilizar a ESAPI,
porm no existe nenhum mtodo especfico contra XSS baseado em DOM.
preciso usar uma combinao dos mtodos encoders fornecida pela API. A
questo saber qual mtodo utilizar, pois cada subcontexto necessita de seu
mtodo de preveno. Por subcontexto compreendido que um ataque de XSS
baseado no DOM utiliza-se de cdigo Javascript concomitante uma tecnologia ou
particularidade desta tecnologia, por exemplo, possvel fazer um ataque que
utiliza-se de cdigo Javascript e cdigo HTML, no caso utilizaremos, na ordem, o
mtodo encoderHTML() da ESAPI para codificar o possvel cdigo malicioso escrito
em HTML e, em seguida, utilizamos o mtodo encoderForJs() da ESAPI conforme
demonstrado no cdigo 2.15. (MANICO et al., 2010)
Cdigo 2.15 Prevenindo XSS baseado no DOM, regra 7
Fonte: Manico(2010)
Se o subcontexto for, por exemplo, CSS ento preciso utilizar-se do mtodo

encodeForCSS(). Da mesma forma, se o subcontexto for um atributo de URL, ser
preciso ento utilizar-se do mtodo encodeForURL(). Se o subcontexto for um
atributo
de
uma
tag
HTML
ser
preciso
ento
utilizar-se
do
mtodo
encodeForHTMLattr(). Os exemplos so ilustrados no cdigo 2.16.

Cdigo 2.16 Prevenindo XSS baseado no DOM segunda forma, regra 7
Fonte: Manico(2010)
40
4 - A3 Quebra de Autenticao e da Gesto de Sesso

Esta vulnerabilidade est relacionada com a autenticao e o gerenciamento
de sesso da aplicao web. Esta vulnerabilidade se caracteriza quando a aplicao
apresenta falhas em reas como a sada de sesso (logout), gesto de palavras
chave, expirao de sesses, sistemas do tipo lembre- me (remember me),
questes secretas e atualizaes de conta. Dentro do universo de autenticao e
gerenciamento de sesses essas funes so consideradas menos importantes e,
por essa razo, as mais atacadas. No obstante, falhas no mecanismo principal no
so incomuns.
A deteco de nvel mdio, pois encontrar essas falhas pode ser difcil
tarefa, uma vez que cada implementao tem suas prprias caractersticas. As
ferramentas automatizadas dificilmente obtm sucesso com esta vulnerabilidade, da
mesma forma as ferramentas de anlise esttica no so eficazes. A anlise
manual, reviso de cdigo e teste so mais indicadas, especialmente se
combinadas. O nvel de explorao mediano, o atacante utiliza-se de falhas nas
funes de autenticao ou de gesto de sesses. O atacante pode ser um agente
externo annimo. Utilizadores internos que tentam furtar as contas(login) de outros
usurios ou que procuram disfarar suas aes tambm devem ser considerados.
Sendo o ataque bem sucedido o atacante poder fazer tudo como se fosse a vtima,
conta de acesso com maiores privilgios so, frequentemente, as mais visadas. A
tabela 05 sintetiza a classificao do risco.
Tabela 05 Mapeamento do risco de Quebra de Autenticao
Agente de
Ameaa
Vector de
Ataque
Explorao
Prevalncia
Deteco
Mdia
Comum
Mdia
Impacto
Tcnico
Impacto
de Negcio
Severo
41

Este tipo de vulnerabilidade no permite que seja elencado um nico cdigo
fonte como exemplo, pois o mesmo particular a cada aplicao web. Da mesma
forma sua preveno no se faz em apenas um cdigo ou em uma nica forma.
OWASP Top 10 (2010)
Quando os processos de expirao da sesso no esto implementados de
forma adequada o sistemas encontra-se vulnervel, por exemplo, o usurio utiliza
um computador pblico para acessar a um sistema web, ao termino de sua
utilizao ele em vez de selecionar a opo de logout para sair da sesso, ele
simplesmente fecha a janela do navegador web e vai-se embora. Um atacante pode
utilizar o mesmo navegador web uma hora mais tarde e mesmo assim a sesso
original continua ativa e devidamente autenticada
Outro exemplo quando a aplicao web suporta a reescrita de URL e coloca
os identificadores de sesso diretamente na URL. Um usurio autenticado poderia
querer que seus amigos soubessem da venda. Ele encaminha por e-mail o a URL
sem saber que o identificador da sesso acompanha a URL. Quando um de seus
amigos acessar a URL ele no s usar o identificar de sesso como tambm os
dados pertinentes sua conta de acesso, como por exemplo, nmero de carto de
crdito associado a sesso.
Um atacante mais experiente, notando que o sistema lhe pede para
responder a uma pergunta como por exemplo, Qual a sua cor favorita?, poder
recuperar a senha de acesso utilizando-se um aplicativo para aplicar um ataque do
tipo task force at que seja descoberta a cor correta que satisfaa a pergunta. O
aplicativo de task force configurado para realizar requisies subsequentes e em
cada uma delas uma cor ser testada, a cor correta descoberta pela resposta de
cabealho HTTP da aplicao que quando a cor est errada envia uma resposta
negativa e quando a cor est correta envia uma resposta afirmativa.
42
4.3 Preveno
O objetivo da preveno verificar se o aplicativo autentica corretamente os
usurios e protege as identidades das credenciais. A recomendao primria do
OWASP Top 10 (2010) :
a) Tornar disponvel para os programadores um conjunto nico de controles
de autenticao forte e de gesto de sesses. Este controles devem ser capazes de
atender a todos os requisitos para autenticao e gesto de sesses definidos no
documento Application Security Verification Standar(ASVS) em particular as
sees V2(Autenticao) e V3 (Gesto de Sesses) e tambm, ter uma interface
simples para os programadores. (considere o autenticador da ESAPI).
b) Grandes esforos devem ser igualmente realizados para evitar a
ocorrncia da falhas XSS que podem ser utilizadas para furto de identificadores de
sesso (Veja A2).
Enquanto que no OWASP Top 10 (2007) preciso considerar ainda as
seguintes recomendaes:3
1. Use somente mecanismos padro para gerenciamento de sesso. No escreva ou use
gerenciadores secundrios de sesso em qualquer situao.
2. No aceite novos identificadores de sesso, pr configurados ou invlidos na URL ou em
requisies. Isto conhecido como ataque de sesso fixada (session fixation attack ).
3. Limite ou limpe seu cdigo de cookies personalizados com propsito de autenticao de
gerenciamento de sesso, como funes lembrar 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
4. Use um mecanismo nico de autenticao com dimenso e nmeros 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.
5. 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.
6. Considere gerar uma nova sesso aps uma autenticao que obteve sucesso ou mudana
do nvel de privilgio.
7. 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,
3 Vale reinterar que os itens de 1 a 13 foram retirados do projeto Top 10 edio 2007.
43
pois usurios acabaro fechando a aba ou janela ao invs de sair com sucesso.
8. Use perodos de expirao de prazo que fazem automaticamente logout em sesses inativas,
bem como o contedo das informaes que esto sendo protegidas.
9. 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 oneway hasf nas respostas para prevenir ataques nos quais a informao possa ser descoberta.
10. 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).
11. Verifique a senha antiga do usurio quando ele desejar mudar a senha.
12. 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.
13. Atente para quando enviar segredos para endereos de e-mail como um mecanismo de reset
de passsword. Use nmeros randmicos limited-time-only para resetar acesso e envie um email de retorno assim que a senha for reconfigurada. Cuide para quando permitir que usrios
registrados mudem seus endereos de e-mail envie uma mensagem para o e-mail anterior
antes de efetuar a mudana.
44
5 A4 Referncias Inseguras Diretas a Objetos

A Referncias Inseguras Diretas a Objeto ocorre quando o desenvolvedor
expe uma referncia a objetos internos da aplicao web e o atacante consegue
alterar esse parmetro obtendo, dessa forma, acesso a informaes confidenciais.
Os objetos internos podem ser, por exemplo, um arquivo, um diretrio ou um registro
do banco de dados exposto atravs de uma URL ou formulrio O atacante um
usurio autorizado no sistema que altera o valor de um parmetro, que se refere
diretamente a um objeto no sistema, para um outro objeto na qual no teria
autorizao. O impacto considerado moderado pois a explorao desta
vulnerabilidade pode comprometer todos os dados que so referenciados atravs de
parmetros, a tabela 06 sintetiza a classificao do risco.
Tabela 06 Mapeamento do risco de Referncias Inseguras
Agente de
Ameaa
Vector de
Ataque
Explorao
Prevalncia
Deteco
Fcil
Comum
Fcil
Impacto
Tcnico
Impacto
de Negcio
Moderado
Para descobrir se uma aplicao vulnervel a Referncias Inseguras Diretas

a Objetos preciso verificar se todas as referncias a objetos possuem defesas
prprias. Essas defesas consistem em (a) verificar se o usurio est autorizado a
aceder o recurso que foi solicita e (b) se a referncia uma referncia indireta, o
mapeamento para a referncia direta deve ser limitada aos valores autorizados para
o usurio atual. Para que a reviso do cdigo seja eficiente preciso considerar as
duas abordagens de defesas. Teste manuais tambm so igualmente eficientes. Os
teste automticos no so indicados, pois no procuram este tipo de falha uma vez
que no reconhecem o que necessita de proteo.

O atacante acessa a pgina de cadastro de determinado cliente com chave
de identificao de nmero 1015, poe exemplo Ele percebe que o parmetro que
45
recupera o cliente da base de dados est sendo enviado via mtodo post e chamase id_cliente. A chave de registro da tabela clientes do tipo numrica e
sequencial, logo, o atacante percebe que se mudar o parmetro de 1015 para 1014
o sistema retorna o registro do cliente de chave nmero 1014. O atacante continua
testando outros valores, os que coincidirem com os da tabela clientes a aplicao
mostrar os registro, indevidamente. O cdigo 4.1 ilustra a aplicao vulnervel. Ele
apenas um trecho de cdigo, as demais partes foram suprimidas para
simplificao do entendimento. A linha 02 recebe os dados, no caso a chave de
cada registro de cliente. As linhas 4, 5 e 6 montam executam a instruo SQL.
Repare que mesmo a aplicao estando protegida contra Injeo(vide A1- Injeo)
ele no est, necessariamente, protegida contra Referncias Inseguras Diretas a
Objetos.
Cdigo 4.1 Aplicao vulnervel Referncias Inseguras Diretas a Objetos
Outro exemplo de aplicao vulnervel ilustrado pelo formulrio do cdigo

4.2. O formulrio envia atravs do mtodo get o valor do controle HTML do tipo
select denominado idioma. O script php responsvel por trocar o idioma faz acesso
direto ao objeto tornando, dessa forma, o cdigo vulnervel.
46
Cdigo 4.2 Exemplo de formulrio HTML ilustrando a vulnerabilidade Referncias Inseguras Diretas
a Objetos
O atacante poderia alterar o parmetro para, por exemplo, /etc/passwd e

assim obter acesso ao arquivo de usurios do sistema operacional Linux, conforme
ilustra o cdigo 4.3.
Cdigo 4.3 Aplicao vulnervel a Referncias Inseguras Diretas a Objeto
5.3 Preveno
Segundo o OWASP Top 10 (2010) h duas formas bsicas de evitar esta
vulnerabilidade: a) usar referncias indiretas a objetos e b) verificar o acesso ao
objeto, j o OWASP Top 10 (2007) nos diz que a proteo mais eficaz a esta
vulnerabilidade seria evitar a exposio direta de referncias a objetos a usurios
usando um ndice, mapa de referncia indireta ou outro mtodo indireto que seja
fcil validar. Ainda como preveno o OWASP Top 10 (2007) reitera que,
necessrio considerar as recomendaes como observamos abaixo:
Sempre que possvel, evitar a exposio de referncias de objetos privados a usurios, como
chaves primrias e nomes de arquivos.
Atravs da abordagem aceite o reconhecido como bom(whit list) validar cada referncia
47
privada a objetos.
Verificar a autorizao de todos os objetos referenciados. O mtodo mais indicado usar um

valor de ndice ou um mapa de referncia para prevenir ataques de manipulao de
parmetros
Se expor referncias diretas aos registros de banco de dados certifique-se que as

declaraes SQL e outros mtodos de acesso base de dados permitam que somente sejam
mostrados registros autorizados.
O cdigo 4.1 corrigido deve apresentar-se como o cdigo 4.4. A principal

alterao acontece na linha 5 onde construda a instruo SQL, na clausula
WHERE alm de filtrar por cliente a instruo filtra por usurio, ou seja, apenas o
usurio previsto para aquele registro poder realmente acess-lo.
Cdigo 4.4 Aplicao corrigida contra a vulnerabilidade Referncias Inseguras Diretas a Objetos
O cdigo 4.5 corrige o cdigo 4.3. A linha 2 cria um array com dois ndices e
armazena em $array_idiomas, trata-se do mapeamento ao objeto. A linha 4 recebe o
dado via mtodo post ou get e armazena em $ idioma_suspeito. A linha 5 apenas
inicializa a varivel $idioma_seguro. A Linha 7 utiliza-se expresso regular para
checar, atravs do mtodo white list o parmetro recebido. A linha 8 checa o
parmetro recebido com o mapa construdo na linha 2 e em caso positivo
concatena o valor de $idioma_suspeito com a string .php(linha 9). A linha 11
executa o cdigo normalmente.
48
Cdigo 4.5 Aplicao corrigida contra a vulnerabilidade Referncias Inseguras Diretas a Objetos
49
6 A5 CSRF(Cross Site Request Forgery)

O Cross Request Forgey(CSRF) ocorre quando um atacante consegue forjar
um pedido HTTP tornando indistinguvel do pedido original. Normalmente combina a
utilizao de cookies de sesso e engenharia social. Aproveita, principalmente, de
aplicaes que confiam excessivamente em credenciais de acesso geradas
automaticamente. Esta vulnerabilidade normalmente est associada ao uso de
cookies de sesso, mas tambm podem ocorrer com a utilizao de, por exemplo,
endereo IP de origem, certificados SSL (o SSL somente prov a confidencialidade
e a integridade dos dados trafegados), credenciais de autenticao bsicas e at
mesmo credenciais de um domnio Windows.
A prevalncia considerada generalizada pois o CSRF explora aplicaes
web que permitem aos atacantes prever todos os detalhes de determinada ao. A
deteco considerada fcil por ser razoavelmente fcil detectar atravs de teste de
penetrao ou atravs de anlise de cdigo. A tabela 07 sintetiza a classificao do
risco:
Tabela 07 Mapeamento do risco de CSRF
Agente de
Ameaa
Vector de
Ataque
Explorao
Prevalncia
Deteco
Mdia
Generalizada
Fcil
Impacto
Tcnico
Impacto
de Negcio
Moderado
Fonte: OWASP Top 10.
Esta vulnerabilidade tambm conhecida por outros nomes como Session

Riding, Ataques On-Click, Cross Site Reference Forgey, Hostile Linking e
Automation Attack. O acrnimo XSRF tambm comumente utilizado. Tanto a
OWASP quanto o MITRE padronizaram o uso do termo Cross Site Request
Forgey(CSRF).

Uma transferncia bancaria efetuada pelo scritp php denominado
transferirFundos.php.
Esse
script
est
armazenado
no
seguinte
local:
50
http://wwww.aplivacaovulneravel.com.br/app/ e aceita como entrada duas variveis

(montante e contaDestino) que so enviadas pelo formulrio web atravs do
mtodo get. O objetivo do script transferir, da conta corrente da vtima que est
logada no sistema) o valor da varivel montante para a conta registrada na varivel
contaDestino. A figura 5.1 ilustra o formulrio original que envia os dados para o
script encarregado de aplicar a ao. Note que o formulrio utiliza-se do mtodo get
o que facilita a explorao do CSRF e, note tambm a ausncia de um identificador
nico e imprevisvel
Cdigo 5.1 Formulrio web vulnervel a CSRF
O cdigo 5.2 responsvel por receber os dados vindo do formulrio e por

efetuar a operao de transao entre as contas. A vulnerabilidade encontra-se na
linha 2 que confia apenas no cookie de identificao, ou seja, estando o usurio
logado a requisio poder vir de qualquer parte e ser executada como uma
requisio autntica. A linha 2 recupera, atravs do array $_COOKIE o cookie
denominado cliente_autenticado. utilizado a funo isset que checa se uma
varivel foi inicializada retornando true em caso positivo e false em caso negativo.
Ainda na linha 2, se o retorno da funo isset for true o cdigo que efetua a
transao executado. As linhas 3 e 4 so hipotticas e por esta razo esto
comentadas (no surtem efeito algum), elas apenas ilustram como seria a operao
de transao entre contas.
Cdigo 5.2 Script transferirFundos.php de forma vulnervel

51
O atacante, conhecendo os detalhes da aplicao, poderia modificar e enviar

a url no corpo de um e-mail para uma vtima. O cdigo 5.3 demonstra como a url
pode ser alterada para executar a operao indevida.
Cdigo 5.3 URL que acionar a operao de transferncia
O atacante insere o contedo malicioso em uma tag img conhecida como

imagem de byte zero, veja cdigo 5.4. Sendo a tag de imagem includa no e-mail, a
vtima ver apenas uma pequena caixa que indica que o navegador no pde
processar a imagem. No entanto, o navegador continua a enviar a solicitao para
seu destino (www.aplicacaovulneravel.com.br). Dessa forma o cdigo camuflado e
no h qualquer indicao visual de que a transferncia tenha ocorrido.
Cdigo 5.4 URL adulterada camuflada em uma imagem de byte zero.
6.3 Preveno
A primeira forma de se prevenir contra XRSF atravs de Tokens de
validao, trata-se da incluso de um token que no seja transmitido via
URL(mtodo get) de modo que este no seja adivinhado pelo atacante nem
registrado pelo navegador. Ele pode ser inserido em um campo hidden, como
demonstra o cdigo 5.5. A linha 2 utiliza-se da funo getCSFRToken para gerar o
token que armazenado na varivel $token. A linha 3 atribui o valor de $token em
uma session denominada csrfToken. Essa session ser utilizada pelo script
seguinte. Entre a linha 5 e linha 16 renderizado o formulrio como visto no cdigo
5.3 com o acrscimo da linha 13. Um campo do tipo hidden (invisvel apenas no
layout da pgina HTML)armazenar o valor do token que por sua vez ser
submetido com os demais dados do formulrio.
52
Cdigo 5.5 Criando um token para um campo hidden.
Caso a submisso dos dados tenha qe ser feita via mtodo get possvel
utilizar-se, ento, de funo ESAPI.httpUtilities().addCSRFToken() da seguinte
forma:
Cdigo 5.6 Criando um token para uma URL.
Do lado do servidor, o script transferirFundos.php, tambm deve ser corrigido.

A linha 2 confere se o token enviado pelo formulrio o mesmo que o gerado
anteriormente. Em caso positivo a execuo segue como explicado no cdigo 5.2.
Em caso negativo recomendado que grave-se um log, o token deve ser
reinicializado e a solicitao deve ser abortada.
Cdigo 5.7 Script transferirFundos.php corrigido

53
Exigir a requisio de senhas.(reautenticar o usurio) tambm outra forma

de evitar o ataque por CSRF. Para tanto, a senha dever ser solicitada em todas as
requisies da aplicao reduzindo, desta forma, a usabilidade da aplicao. Para
minimizar este problema, a solicitao pode ser realizada apenas para operaes
sensveis.
Outra medida que ajuda a prevenir o ataque CSRF garantir que no existam
vulnerabilidades XSS, conforme o OWASP Top 10 (2007) Falha XSS no so
necessrias para um ataque CSRF ser bem sucedido, apesar de que qualquer
aplicao com falhas XSS esteja susceptvel a CSRF.
Conscientizar o usurio/cliente mais uma medida que, embora esteja fora
do escopo do desenvolvimento do software, podem ser aplicadas em polticas de
segurana e em treinamento para usurios com o objetivo de mitigar a
vulnerabilidade. So elas:
Fazer logoff da aplicao imediatamente aps seu uso.
No permita que o navegador grave e/ou lembre o nome do usurio(login) e a senha.
No utilizar o mesmo navegador para acessar aplicao sensveis (como acesso a banco
online) e navegao livre
A utilizao de Plugins do tipo NO-Script dificulta a explorao da vulnerabilidade. Isto

porque, assim que o cdigo de explorao(exploit) carregado, o Javascript pode enviar o
formulrio automaticamente. Sem o Javascript o atacante dependeria da ao manual do
usurio.
54
7 A6 Configurao Incorreta de Segurana

Configuraes incorretas de segurana podem ocorrer na aplicao web, no
servidor web, no mdulo do PHP, no framework, em bancos de dados e em todo
componente necessrio para que a aplicao funcione corretamente. Quando
atualizaes no so instaladas, quando os softwares no so devidamente
configurados, quando usurios e senhas que ativam o software so mantidas, temos
ento, a ocorrncia da vulnerabilidade de Configurao Incorreta de Segurana. Ela
deve ser evitada com os esforos conjuntos de programadores e administradores
uma vez que no diz respeitos apenas o cdigo fonte da aplicao.
A explorao considerada fcil pois o atacante utiliza-se, por exemplo, de
contas criadas por padro na instalao de sistemas. O impacto moderado pois,
uma vez que esta vulnerabilidade explorada, pode comprometer por completo todo
o sistema, a tabela 08 sintetiza a classificao do risco:
Tabela 08 Mapeamento do risco de Configurao Incorreta de Segurana
Agente de
Ameaa
Vector de
Ataque
Explorao
Prevalncia
Deteco
Fcil
Comum
Fcil
Impacto
Tcnico
Impacto
de Negcio
Moderado

Suponha que a aplicao utilize framework's como CODEIGNITER ou CAKE.
Vulnerabilidades XSS so encontradas e uma atualizao lanada para corrigir o
problema. At que o framework no seja atualizado, atacantes podero explorar as
vulnerabilidades da aplicao.
Outro exemplo seria quando os dados e os componentes padres
necessrios para a instalao de uma aplicao, banco de dados ou componente
so instalados automaticamente e no so removidos. Um atacante poder
descobrir as pginas de administrao no servidor e autenticar-se utilizando o
usurio e senha padro da instalao e tomar controle sobre a aplicao e/ou
55
servidor.
Mais um exemplo seria quando a listagem dos diretrios no fora desativada.
Um atacante, percebendo essa vulnerabilidade, poder listar os diretrios da
aplicao e encontrar outras vulnerabilidades.
Ainda como exemplo, a configurao e/ou codificao de uma aplicao
expe, indevidamente, os erros ou outras informaes sobre o sistema ou o
servidor. O atacante utilizar essa informao para encontrar e explorar
vulnerabilidades potenciais. O cdigo 6.1 ilustra a exposio desnecessria de erros.
Na linha 02 feita a tentativa de conexo com o banco de dados e o resultado
armazena na varivel $link. A linha 03 testa a varivel $link, caso o valor seja false
o script executa a linha 04 que, por sua vez, interrompe a execuo do script atravs
da funo die(). Esta funo aceita um parmetro do tipo string e exibe esse valor no
navegador. No exemplo ser enviado ao navegador o resultado da funo
mysql_error().
Cdigo 6.1 Expondo erros de forma indevida
Importante notar que no utilizao da funo die() no sanaria o problema

por completo. Se o mdulo de PHP estiver configurado para exibir erros, uma
mensagem como a mostrada no cdigo 6.2 a seguir seria exibida, entregando,
dessa forma, informaes valiosas para o atacante como o servidor e o usurio.
Cdigo 6.2 Expondo erros de forma indevida, dados do servidor
7.3 - Preveno
Para garantir a preveno da aplicao web contra esta vulnerabilidades preciso
entender e compreender as configuraes do mdulo PHP. O captulo de configuraes do
projeto Guia de Desenvolvimento da OWASP traz recomendaes especficas para cada
56
configurao do mdulo PHP (OWASP Development Guide: Chapter on Configuration,

2010).
A diretiva register_globals vem com valor padro off (desabilitado) desde a

verso 4.2.5. Ela tornou-se obsoleta a partir da verso 5.3.0 e foi removida na
verso 6.0.0. Essa diretiva, quando habilitada, cria variveis de vrios tipos, inclusive
variveis oriundas de formulrios HTML. Isso significa que possvel usar variveis
sem saber de onde elas vieram. Variveis internas que so definidas no script se
misturam com dados enviados pelos usurios. Segundo o manual do PHP, a diretiva em si
no insegura, o uso incorreto dela que . Conforme o cdigo 6.3, na linha 02 o
resultado da funo usuario_autenticado() testado. Se verdadeiro atribudo true

varivel $autorizado. Na linha 06 testado o valor da varivel $autorizado, se verdadeiro o
script segue sua execuo normalmente, acreditando-se que o usurio foi realmente
autenticado.
Cdigo 6.3 Configurao register_globals
Estando o valor da diretiva register_globals igual a on(habilitada) a varivel

$autorizado seria facilmente manipulada. Alterando o valor para off o cdigo
funcionrio corretamente (isento da vulnerabilidade). Outra forma de concertar o
cdigo seria inicializar a varivel antes do uso, neste caso o cdigo funcionaria
independentemente do estado de register_globals.
O safe_mode um conjunto de restries de funes e pode realmente
aumentar a segurana em um ambiente de servidor compartilhado. Ela foi removida
na verso 6.0.0 por ser considerado, arquiteturalmente, incorreto resolver esse
problema (servidores compartilhados) no nvel de mdulo do PHP.
A diretiva disable_functions permite desabilitar funes internas do PHP. Ela
recebe uma lista de nomes de funes separadas por virgula. Ela no afetada pela
57
diretiva safe_mode e deve ser configurada diretamente no arquivo php.ini no sendo

possvel efetuar a configurao no arquivo httpd.conf.
A diretiva open_basedir limita os arquivos que podem ser abertos ao diretrio
especificado e seus subdiretrios, incluindo o arquivo em si. Essa diretiva no afetada pelo
estado do modo seguro, seja este habilitada ou no.
A diretiva allow_url_fopen ativa o dispositivo URL-aware fopen wrappers que

permite o acesso a objetos URL como arquivos. Se esta diretiva estivar habilitada o
atacante poder executar arquivos externos como a demonstra o cdigo 6.4
Cdigo 6.4 Exemplo de ataque aproveitando-se da diretiva allow_url_open
Com a diretiva error_reporting possvel determinar quais os erros,

mensagens e avisos o PHP registrar. A recomendao E_ALL, dessa forma,
todos os erros e mensagens de alerta (exceto os de nvel E_SRICT) sero
reportados.
A diretiva log_errors refere-se ao nome do arquivo onde os erros do script
sero logados.
A diretiva display_errors Determina se os erros sero ou no exibidos em
tempo de execuo. A recomendao off (desabilitado) para ambiente de
produo e on (habilitado) para ambiente de desenvolvimento.
A diretiva magic_quotes_gpc define o estado para as aspas mgicas para
operaes do tipo GPC (get, post e cookie). Quando as aspas mgicas estiverem
em on, todas ' (aspas simples), " (aspas duplas), \ (barras invertidas) e NULL's so
codificados com uma barra invertida automaticamente. A recomendao da OWASP
que seu valor seja on(habilitado), porm esta funo est obsoleta na verso 5.3.0
e foi removida da verso 6.0
A diretiva post_max_size Determina o valor mximo de dados que poder
ser enviado para o servidor. Deve ser mantido o valor mnimo. Por padro 8mb.
A diretiva upload_max_filesize define o tamanho mximo de um arquivo
58
enviado, medido em bytes. Deve ser mantido o valor mnimo.

A diretiva memory_limit configura o tamanho mximo de memria utilizada
por um script. Isto evita, por exemplo, que um script malicioso consuma toda
memria disponvel em um servidor.
59
8 A7 Armazenamento Criptogrfico Inseguro

Quando dados sensveis no so cifrados. Quando a criptografia usada de
forma incorreta, seja pela m configurao ou pela escolha de algoritmo fraco.
Quando o armazenamento das chaves feito de forma imprudente. Quando, para
proteger senhas, utilizado um hash sem o salt. Todos esses fatores ou uma
combinao deles tornam a aplicao vulnervel Armazenamento Criptogrfico
Inseguro. Importante notar que esta vulnerabilidade relaciona-se mais com questes
de planejamento, infraestrutura e configuraes de servidores do que com a
linguagem de programao em si.
A explorao desta vulnerabilidade considerada difcil no pelo fato de que
a quebra da criptografia seja custosa e complicada (quando humanamente possvel)
mas sim pelo fato de que atacantes externos terem acesso limitado, normalmente
eles tentam outras alternativas primeiro. preciso observar tambm que dificilmente
a criptografia atacada, os atacantes quebram outros elementos tais como
encontrar as chaves geradoras, obter cpias em claro de dados e acessar dados
atravs de canais que decifram automaticamente. A tabela 09 sintetiza a
classificao do risco:
Tabela 09 Mapeamento do risco de Armazenamento Criptogrfico Inseguro
Agente de
Ameaa
Vector de
Ataque
Explorao
Difcil
Prevalncia
Deteco
Pouco Comum
Difcil
Impacto
Tcnico
Impacto
de Negcio
Severo

Uma aplicao cifra dados dos cartes de crditos numa base de dados para
prevenir que os mesmos sejam expostos ao utilizadores finais. No entanto, a base
de dados est configurada para automaticamente decifrar consultas nas colunas de
cartes de crdito, permitindo que uma falha de injeo por SQL possa listar todos
os cartes de crdito em claro. O sistema deveria ter sido configurado para permitir
60
que apenas aplicaes de back-end pudessem decifrar esses dados e no as

aplicaes web de front-end.
8.3 Preveno
Todos os perigos do uso inseguro da criptografia esto alm do mbito do
escopo deste trabalho e, portanto, a preveno se far parcialmente, atravs do uso
correto das funes de encriptao do PHP e com as recomendaes mnimas do
OWASP Top 10 (2010):
No crie algortimos de criptografia. Use somente algoritmos aprovados publicamente como,

AES, Criptografia de chaves publicas RSA, SHA-256 ou superior para hash.
No use algoritmos fracos como MD5/SHA-1. Utilize algoritmos mais seguros como SHA-256
ou superiores.
Crie chaves offline e armazene chaves privadas com extremo cuidado. Nunca transmita
chaves privadas em canais inseguros.
Assegure que credenciais de infraestrutura, como por exemplo credenciais de banco de

dados, esto corretamente seguras (por meio de rgidos sistemas de arquivos e controles),
criptografadas de forma adequada e no podem ser descriptografadas por usurios locais ou
remotos.
Dados armazenados criptografados no disco no devem ser fceis de descriptografar, por

exemplo, criptografia de banco de dados intil se a conexo de banco de dados permite
acessos no criptografados.
A funo hash do cdigo 7.1 utiliza dois parmetros. O primeiro escolhe o

algortimo utilizado para gerar o hash e o segundo o valor utilizado para gerar o
hash.
Cdigo 7.1 Gerando Hash
Se executarmos o cdigo 7.2 ele gerar um array contendo todos os

algortimos que podem ser utilizados como parmetro na funo hash();
61
Cdigo 7.2 Listando os algortimos para gerao do hash
A tabela 10 ilustra todos os algortimos que podem ser usados juntos com a
funo hash(). Sero listados os algoritmos que foram instalados.
Md2
md4
md5
sha1
sha224
sha256
sha384
sha512
ripemd128
ripemd160
ripemd256
ripemd320
whirlpool
tiger128,3
tiger160,3
tiger192,3
tiger128,4
tiger160,4
tiger192,4
snefru
snefru256
gost
adler32
crc32
crc32b
salsa10
salsa20
haval128,3
haval160,3
haval192,3
haval224,3
haval256,3
haval128,4
haval160,4
haval192,4
haval224,4
haval256,4
haval128,5
haval160,5
haval192,5
haval224,5
haval256,5
Tabela 10 Lista de algortimos para gerao de hash
62
9 A8 Falha na restrio de acesso a URL

Quando a aplicao web permite que pginas privadas sejam acessadas sem
a devida autenticao tanto para usurios annimos como para usurio
autenticados, ento ela vulnervel falhas na restries de acesso a URLs.
Aplicaes que validam privilgios apenas no lado cliente tambm esto,
igualmente, vulnerveis. Normalmente, o desenvolvedor, por inexperincia, acredita
que a nica proteo para uma URL no mostrar o link para usurios no
autorizados. No entanto um usurio hbil, motivado ou apenas um atacante com
sorte pode ser capaz de descobrir essas pginas, executar funes e visualizar
dados. Tal falha permite aos atacantes acessarem funcionalidades no autorizadas.
Funes de administrao so o alvo chave neste tipo de ataque.
A proteo da URL gerida tanto pelo cdigo fonte como pela configurao
do servidor web na qual a aplicao esta instalada (no caso do PHP o servidor o
Apache). A vulnerabilidade pelo cdigo fonte ocorre quando os desenvolvedores no
efetuam validaes apropriadas e a vulnerabilidade pela configurao ocorre quando
o servidor encontra-se mal configurado e/ou os componentes esto desatualizados.
A tabela 11 sintetiza a classificao do risco,
Tabela 11 Mapeamento do risco de Falha na restrio de acesso a URL
Agente de
Ameaa
Vector de
Ataque
Explorao
Fcil
Prevalncia
Deteco
Pouco comum
Mdio
Impacto
Tcnico
Impacto
de Negcio
Moderado
A melhor forma de saber se uma aplicao falha na restrio de acesso a

uma URL consiste em verificar todas as pginas. preciso observar a existncia de
autenticao e autorizao. Scanners de vulnerabilidades encontram dificuldade em
identificar quais so as pginas(URLs) vulnerveis, por tanto a deteco
classificada como nvel mdio.
A abordagem mais eficiente e precisa est em utilizar a combinao da
63
reviso do cdigo fonte e dos teste de segurana para verificar os mecanismos de

controles de acesso. A verificao se torna mais eficiente se o mecanismo for
desenvolvido de forma centralizada. Quando o mecanismo implementado de forma
distribuda a verificao pode se tornar dispendiosa.
9.2 Exemplo de sistema aplicao vulnervel

O principal mtodo de ataque chamado de navegao forada(forced
browsing), na qual envolve tcnicas de adivinhao de links(guessing) e fora
bruta(brute force) para achar pginas desprotegidas. O atacante pode forar a
navegao das URLs alvo. As URLs listadas no cdigo 8.1 exemplificam reas do
sistema que requerem autenticao.
Cdigo 8.1 - Exemplo de reas restritas que necessitam de autenticao
As reas listas no cdigo 8.2 so exemplos de pastas do Sistema Operacional

Linux. So muito conhecidas e por essa razo podem ser alvos fceis.
Cdigo 8.2 - reas restritas muito comuns e por essa razo bastante vulnerveis
Fonte:OWASP Top 10 (2010)
Este tipo de ataque tambm conhecido como path transversal, ele ataca
as pastas do sistema operacional atravs do sistema web vulnervel. O cdigo 8.3
exemplifica um sistema vulnervel. A linha 02 armazena na varivel $template o
valor referente ao templete padro blue.php. A linha 03 e 04 recebe os dados do
cookie 'template', parmetro este, acessvel ao usurio e que pode ser manipulado
pelo atacante. A linha 05 expressa a vulnerabilidade, ela concatena o valor do
parmetro(malicioso) e busca o arquivo no disco rgido.
64
Cdigo 8.3 Exemplo de ataque path transversal
O atacante poderia forjar a seguinte requisio ilustrada no cdigo 8.4.
Cdigo 8.4 Requisio de HTTP forjada
O servidor da aplicao geraria, ento, a seguinte informao:
Cdigo 8.5 - Expondo o arquivo /etc/passwd
As seguintes funes do PHP merecem ateno especial, quando for

realizada a reviso do cdigo :include(), include_once(), require(), require_once(),
fopen() e readfile().
Ouro exemplo de aplicao vulnervel quando URLS escondidos e
especiais so mostrados na camada de aplicao apenas para administradores e
usurios privilegiados, porm acessvel a todos os usurios que tenham
conhecimento da URL.
Mais um exemplo quando a aplicao permite acesso a arquivos
escondidos como, por exemplo arquivos de configurao(.ini ou .inc) confiando
toda segurana na obscuridade.
65
9.3 Preveno
A preveno contra esta vulnerabilidade requer a seleo de uma abordagem
que permita solicitar a autenticao adequada em cada pgina do sistema. O
OWASP Top 10 (2010) sugere as seguintes recomendaes:
As polticas de autenticao e autorizao devem ser baseadas em papis/perfis

minimizando, dessa forma, esforos de manuteno dos mesmo. Implementar perfis de
acesso criar papis que podem ser associados aos usurios, dessa forma a configurao
se faz no perfil e no em cada usurio o que torna o trabalho de permisso e restrio de
acesso mais preciso e menos penoso. Como exemplo um sistema pode ter dois perfis de
acesso: administradores e bsicos, esses papis so associados aos usurios e podem,
inclusive, ser utilizados para um grupo de usurios.
O mecanismo de controle de acesso deve proteger todas as URLs do sistema web

verificando as funes e direitos do usurio antes que qualquer processamento ocorra. Para
pulverizar o mecanismo de controle o mesmo deve ser de fcil implementao. O cdigo 8.6
demonstra um exemplo de implementao.
Cdigo 8.6 Exemplo de controle de acesso
As poltica de autenticao no devem ser codificadas diretamente nas aplicaes o que a

tornaria pouco flexvel. Deve-se evitar o uso distribudo das polticas, tal prtica aumenta a
complexidade da programao e probabilidade de ocorrncia de erros. As pginas podem
(devido ao erro) no serem validadas, deixando a aplicao vulnervel. prefervel utilizar os
recursos provenientes da programao orientada a objeto(OOP) e tambm fazer uso da do
padro MVC(model, view e controller)que resulta na separao da lgica da aplicao. Essas
tcnicas auxiliam na organizao do cdigo fonte elevando sua manutenibilidade e facilidade
de reviso.
A aplicao, por defeito, deve negar todos os acessos e requerer atribuies explicitas e
adequadas para acessar qualquer pgina do sistema.
O processo de verificao deve ser realizado em todos os passos do fluxo e no apenas no

passo inicial, pois no suficiente verificar uma vez o usurio autorizado e no verificar
novamente nos passos seguintes. Um atacante pode simplesmente burlar o passo onde a
autorizao verificada e forjar o valor do parmetro necessrio e continuar no passo
seguinte.
Realizar teste de invaso (penetration test) antes do cdigo entrar em produo.
Observar arquivos de includes/bibliotecas, eles devem ser mantidos, sempre que possvel,
66
fora da raiz da aplicao web (document root).
Proteo por obscuridade no suficiente para proteger dados e funes sensveis, no

suponha que as URLs estaro fora do alcance do atacante. Assegure-se que aes com
privilgios altos e administrativos destegam protegidos.
Bloquear acesso a todos os tipos de arquivos que no sejam do tipo executvel(.php). Este
filtro deve seguir a abordagem accept know good . Arquivos com extenses .xml, .ini, .txt,
arquivos de log e outros no devem ser executados diretamente. Essa proteo se faz
atravs da utilizao do arquivo .htaccess. O cdigo 8.7 exemplifica uma restrio aos tipos
de arquivos citados.
Cdigo 8.7 - Protegendo diretrio com arquivos .htaccess
Manter o antivrus atualizado e as correes de segurana principalmente para os

componentes que manipulam arquivos fornecidos por usurios.
67
10 A9 Insuficiente Proteo da Camada de Trasporte

Esta vulnerabilidade est mais relacionada com as configuraes do servidor
no qual a aplicao web est instalada do que com a aplicao em si. Servidores
Web que no protegem o trfego de rede so suscetveis a esta vulnerabilidade.
Servidores que utilizam o protocolo SSL (Secure Sockets Layer) ou o protocolo TLS
(Transport Layer Security) em partes especficas, como a autenticao, e no o
utilizam para as demais partes tambm esto, igualmente, vulnerveis. Eles expem
dados sensveis e identificadores de sesso interceptao. Servidores com
certificados mal configurados tambm esto vulnerveis.
Monitoramento do trfego da rede realizada atravs de um sniffer
(ferramenta que capaz de interceptar e registrar o trfego da rede), o que facilita a
sucesso no ataque, porm a explorao considerada como sendo de nvel difcil. A
dificuldade reside em monitorar o trfego no exato momento em que os usurios
acessam o sistema web. O impacto tcnico considerado moderado, esta
vulnerabilidade pode facilitar ataques de phishing e originar roubos de contas de
acesso. Se uma conta de administrador for comprometida toda aplicao estar
exposta. A tabela 12 sintetiza a classificao do risco:
Tabela 12 Mapeamento do risco de insuficincia de proteo da Camada de Transporte
Agente de
Ameaa
Vector de
Ataque
Explorao
Difcil
Prevalncia
Deteco
Comum
Fcil
Impacto
Tcnico
Impacto
de Negcio
Moderado
Para detectar as falhas basta monitorar o trfego de rede da aplicao.

Falhas mais sutis requerem inspeo da arquitetura da aplicao e da configurao
do servidor. Ferramentas automatizadas, comumente, localizam muitas falhas
relacionadas ao protocolo SSL mas dificilmente localizaro falhas nas conexes de
back-end. Abordagem manual tambm pode localizar falhas relacionadas ao
protocolo SSL na interface, entretanto as ferramentas automatizadas so mais
68
eficientes. Para localizar falha nas conexes de back-end a abordagem manual a

mais indicada. (OWASP Top 10; 2010)

A aplicao web no utiliza o protocolo SSL em nenhuma das suas pginas.
O atacante monitora o trfego de rede, como por exemplo, uma rede sem fios aberta
ou a rede de cabo do seus vizinho, e observa o cookie de sesso de uma vtima
autenticada. O atacante utiliza a informao deste cookie e rouba a sesso do
utilizador legtimo.
Outro exemplo de aplicao vulnervel quando o sistema possui um
certificado digital mal configurado que causa avisos de alerta no navegador do
usurio, conforme nos mostra a figura 04. Os usurios, tendo que aceitar os avisos
para poderem continuar o fluxo da aplicao, acabam por se habituarem a tais
avisos. Ataques do tipo phishing aplicao podero enganar os usurios a acessar
um servidor semelhante, que no possui certificado, construindo avisos de alerta
semelhantes. A vtima, estando acostumada com o alerta, proceder normalmente
fornecendo senhas ou outros dados privados utilizando, por fim, um servidor
malicioso.
Figura 04 Exemplo de mensagem de certificado web invlido
69
10.3 Preveno
A preveno primaria referente a camada de transporte poder ser feita
atravs das recomendaes do OWASP Top 10 (2010):
Solicitar SSL para todas as pginas sensveis. Pedidos no-SSL para estas pginas devero
ser redirecionados para a pgina SSL.
Colocar a opo secure em todos os cookies sensveis. A funo setcookie criar um cookie
caso nenhuma sada tenha sido enviada para o navegador. O quinto parmetro da funo
aceita um valor booleano e por padro false. Quando o valor desse parmetro for true, a
opo secure ser ativada, isto , o cookie s poder ser transimitido sob uma conexo
segura HTTPS do cliente. O cdigo 9.1 ilustra a utilizao da opo secure.
Cdigo 9.1 Ativando a opo secure na criao de cookies.
Configurar o fornecedor SSL para suportar apenas algoritmos robustos, preferencialmente os

compatveis com a FIPS 140-2
Assegurar que o certificado vlido, no expirado, no revogado e que mapeia todos

domnios utilizados pelo site web.
Demais ligaes de back-end, do lado do servidor, tambm devem utilizar SSL.
70
11 A10 Redirecionamento e Encaminhamentos Invlidos

Quando um atacante, por meio de engenharia social, ilude a vtima
conseguindo que esta acesse uma URL que redireciona, indevidamente, a vtima
para um site malicioso, permitindo, dessa forma, o ataque do tipo Phishing ou, at
mesmo,
que
um
malware
seja
instalado
no
computador
da
vtima.
redirecionamento pode ser interno (dentro da aplicao) como externo (apontando

para fora da aplicao, outro domnio). A tabela 13 sintetiza a classificao do risco:
Tabela 13 Mapeamento do risco de Redirecionamento e Encaminhamentos Invlidos
Agente de
Ameaa
Vector de
Ataque
Explorao
Prevalncia
Deteco
Mdio
Pouco comum
Fcil
Impacto
Tcnico
Impacto
de Negcio
Moderado
Para fazer com que a vtima acesse a URL maliciosa o atacante utiliza-se de
engenharia social. Ele escolhe a empresa com um sistema web que contm a
vulnerabilidade, reproduz um e-mail que ser enviado para vrias endereos
eletrnico com a URL maliciosa. A mensagem deste e-mail ilude a vtima pedindo,
por exemplo, que ela acesse o link para liberar novo mdulo de segurana para
acesso a conta corrente. Costumam ser mensagens que induzem a vtima a uma
ao imediata, fazendo-a agir primeiro e pensar depois.
Esta vulnerabilidade tambm pode ser explorada com o objetivo de burlar um
possvel sistema de Controle de Acesso existente na aplicao e acessar reas
restritas do sistema. Uma vez que a aplicao utiliza-se de parmetros para indicar
onde o utilizador deve ser encaminhado se determinada operao for executada
com sucesso, o atacante poder criar uma URL que ir passar pela verificao de
controle de acesso e, em seguida, encaminh-lo para uma rea restrita como, por
exemplo, uma rea com funes administrativas a qual ele normalmente no teria
acesso.
71

A aplicao possui um script(pgina) chamado redireciona.php que utiliza
apenas um parmetro denominado url_destino. O script tem como objetivo
redirecionar o usurio para determinada pgina dentro ou fora da aplicao.
Vejamos um exemplo no cdigo 10.1.
Cdigo 10.1 Exemplo de aplicao vulnervel
O atacante, percebendo este detalhe, criar uma URL maliciosa apontando

para um site(servidor) que, uma vez acessado, poder induzir vitima a realizar
operaes indesejadas, conforme demonstra o cdigo 10.2.
Cdigo10.2 URL maliciosa utilizada no redirecionamento invlido
11.3 Preveno
O OWASP Top 10 (2010) sugere como preveno: a) Evitar o uso de
redirecionamentos
encaminhamentos,
b)
Se
usar
redirecionamentos
encaminhamentos, no envolva parmetros do utilizador no clculo da URL de

destino, e c) Se os parmetros de destino no podem ser evitados, tenha certeza de
fornecer um valor vlido e autorizado para o utilizador. possvel fazer uso da
ESAPI conforme cdigo 10.3.
Cdigo 10.3 Prevenindo redirecionamentos e encaminhamentos invlidos
72
12 - Consideraes finais
Atualmente as aplicaes web so uma realidade para muitas empresas, seja
como um novo desenvolvimento de software ou at mesmo a migrao de uma
antiga aplicao para o paradigma das aplicaes web. preciso que a segurana
seja um requisito to importante como um requisito de funcionalidade, pois
desenvolver software (mesmo que no seja uma aplicao web) sem se preocupar
com sua segurana pode trazer prejuzos incalculveis para os envolvidos (clientes,
usurios, stackholders e etc...). Ter a conscincia de que necessrio desenvolver
aplicaes com segurana adequada um bom comeo, mas imprescindvel
conhecer e dominar os aspectos de segurana que envolve uma aplicao.
Pode-se dizer que este trabalho seja uma contribuio relevante para equipes
de desenvolvimento e projetistas de software que buscam como objetivo criar e
manter um sistema web seguro construdo sob a arquitetura LAMP. Este trabalho
traduziu e esmiuou o projeto OWASP Top 10(2010) para a realidade de um
desenvolvimento de aplicativo web baseado na linguagem PHP, de forma a
contribuir com o aprendizado e devido uso e implementao dessa linguagem.
Importante destacar que os 10 riscos indicados pelo Top 10 no suprem todos
os problemas relacionados segurana da aplicao. importante ir alm, a prpria
OWASP recomenda que as organizaes estabeleam uma base slida de
formao, normas e ferramentas que tornem a programao segura um objetivo
possvel. H centenas de questes que podem afetar, de forma geral, a segurana
de uma aplicao web.
A ttulo de continuidade desta pesquisa, pode-se sugerir um estudo mais
aprofundado da vulnerabilidade XSS baseada no DOM e dos projetos ASVS
(Application Security Verification Standard) e Development Guide, ambos da
OWASP.
Outras possibilidades podem ser exploradas com uma visita e leitura atenta
do contedo do site da OWASP, uma vez que a busca pela segurana um moto
perptuo.
73
Referncias
ALBUQUERQUE, Ricardo; RIBEIRO, Bruno. Segurana no Desenvolvimento de Software.
Rio de Janeiro: Campus, 2002.
GILMORE, W. Jason. Dominando PHP e MySql do iniciante ao profissional. Rio de Janeiro:
Alta Books, 2008.
G1. Criminosos roubam US$ 14 milhes em fraudes de anncios on-line. Disponvel em:
http://g1.globo.com/tecnologia/noticia/2011/11/criminosos-roubam-us-14-milhoes-em-fraudede-anuncios-line.html. Acesso em: 25/11/2011
MANUAL OFICIAL DO MySql. Disponvel em http://dev.mysql.com/doc/. Acesso em 01 ago.
2011.
MANICO, Jim. ; et. al. DOM based XSS Prevention Cheat Sheet. Disponvel em:
https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet . Acesso em:
01/08/2011.
MANUAL OFICIAL DO PHP. Disponvel em: http://www.php.net/manual/pt_BR/. Acesso em:
01/08/2011.
MARQUES, Heitor Romero et al. Metodologia da Pesquisa e do Trabalho Cientfico. 2.ed.
Campo Grande: Editora UCDB, 2006.
MORIMOTO, Carlos Eduardo. Servidores Linux, guia prtico. Porto Alegre: Sul Editores,
2008.
MITRE - Common Weakness Enumeration Vulnerability Trends. Disponvel em:
http://cwe.mitre.org/documents/vuln-trends.html. Acesso em: 01/08/2011
OWASP. Disponvel em: https://www.owasp.org/. Acesso em: 01/08/2011.
OWASP Application Security Verification Standard (ASVS) Project . Disponvel em:
https://www.owasp.org/index.php/ASVS#tab=Home . Acesso em: 01/08/2011.
OWASP Development Guide: Chapter on Configuration. Disponvel em:
https://www.owasp.org/index.php/Configuration. Acesso em: 01/08/2011
OWASP Enterprise Security API (ESAPI) Project. Disponvel em:
http://www.owasp.org/index.php/ESAPI. Acesso em: 01/08/2011.
OWASP Guide Project. Disponvel em:
https://www.owasp.org/index.php/Category:OWASP_Guide_Project. Acesso em: 01/08/2011
OWASP TOP 10 2007, The Ten Most Critical Web Application Security Vulnerabilities.
Disponvel em: https://www.owasp.org/index.php/Top_10_2007/. Acesso em 01 ago. 2011.
OWASP TOP 10 2010, The Ten Most Critical Web application Security Risks. Disponvel
em: https://www.owasp.org/index.php/Top_10_2010/>. Acesso em: 01/08/2011.
PETEFISH, Paul; SHERIDAN, Eric; WICHERS, Dave. Cross-Site Request Forgery (CSRF)
74
Prevention Cheat Sheet. Disponvel em: https://www.owasp.org/index.php/CrossSite_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet Acesso em: 01/08/2011.

PESSOA, Mrcio. Segurana em PHP: Desenvolva programas PHP com alto nvel de
segurana e aprenda como manter os servidores web livres de ameaas. So Paulo:
Novatec, 2007.
PRESSMAN, Roger S.; LOWE, David. Enegenharia WEB. Rio de Janeiro: Cincia
ModernaLTC, 2009.
RIVERA, Joey. Using MySQL Stored Procedures with PHP mysql/mysqli/pdo. Disponvel
em: http://www.joeyrivera.com/2009/using-mysql-stored-procedures-with-phpmysqlmysqlipdo/ . Acesso em 01/08/2011.
SICA, Carlos; REAL, Petter Villa. Programao Segura Utilizando PHP: Fale a Linguagem
da internet. Rio de Janeiro: Cincia Moderna, 2007.
SOFTPEDIA. Orange French Portal Hacked. Disponvel em:
http://news.softpedia.com/news/Orange-French-Portal-Hacked-112437.shtml . Acesso em:
25/11/2011
TERENCE, Ana Cludia Fernandes; ESCRIVO FILHO, Edmundo. Abordagem quantitativa,
qualitativa e a utilizao da pesquisa-ao nos estudos organizacionais. In: Anais do XXVI
ENEGEP - Fortaleza, CE, Brasil, 9 a 11 de Outubro de 2006. Disponvel em:
http://www.abepro.org.br/biblioteca/ENEGEP2006_TR540368_8017.pdf. Acesso em:
25/11/2011.
WICHERS, Dave; MANICO, Jim. SQL Injection Prevention Cheat Sheet. Disponvel em:
https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet. Acesso em:
01/08/2011.
WILLIAMS, Jeff; MANICO, Jim. XSS (Cross Site Scripting) Prevention Cheat Sheet.
Disponvel em:
https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet.
Acesso em: 01/08/2011.
75

TCC Flavio Alexandre Micheletti

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

TCC Flavio Alexandre Micheletti

Transféré par

Droits d'auteur :

Formats disponibles

FLVIO ALEXANDRE MICHELETTI

ANLISE DAS PRINCIPAIS VULNERABILIDADES DE APLICAES WEB

FLVIO ALEXANDRE MICHELETTI

ANLISE DAS PRINCIPAIS VULNERABILIDADES DE APLICAES WEB

Nome: MICHELETTI, Flvio Alexandre.

Trabalho de Concluso de Curso apresentado Faculdade de Tecnologia de So

Dedico este trabalho a todos os

Tabela 01 Anlise de risco....................................................................................................................... 23

Figura 01 Arquitetura cliente-servidor e tecnologias utilizada..................................................................21

Lista de cdigo fontes

AJAX - Asynchronous Javascript and XML

respectivamente) Romeno chamado Unu atravs de um ataque de injeo de

A segurana da informao (SI) tambm deve considerar os aspectos do

franco crescimento e a oferta relativamente escassa, softwares dos mais variados

Os problemas podem ser resumidos em apenas uma questo: como proteger

equacionamento dos problemas encontrados, no s faz a investigao, mas

vulnerabilidades mais presentes nessas aplicaes, base deste trabalho. E pode-se

comunidades, com a finalidade de obter generalizaes". No caso desta pesquisa,

O captulo 7 abordar a vulnerabilidade de Configurao Incorreta de

1 Alguns conceitos prvios.

O veculo que adquire a informao, a estrutura, monta uma

O funcionamento bsico de uma aplicao web pode ser compreendido da

Fonte: MORIMOTO (2008, p. 358)

Morimoto (2008) esclarece:

encarregado de processar arquivos PHP. Ele, por sua vez,

PHP uma linguagem de programao para web do tipo server-side. Criada

1.3 OWASP (Open Web Application Security Projetc)

ASVS prov padres de controle de segurana para quando as vulnerabilidades forem

Guide Project (Development guide) guia de desenvolvimento de aplicaes web seguras.

A OWASP criou uma metodologia de classificao de riscos (Risk Rating

Fonte: OWASP Top 10 (2010)

O Agente de Ameaa e o Impacto de Negcio referem-se as

de cada organizao. Em outras palavras, quem define qual o impacto de negcio

Fonte: Top Ten(2010)

Para determinar o risco preciso avaliar a probabilidade associada ao agente

particularmente perigoso, pois consiste na insero de cdigo SQL no previsto e,

Fonte: OWASP Top 10 (2010).

2.2 - Exemplo de aplicao vulnervel

Importante salientar que a utilizao de nomes de variveis diferentes no

Figura 03 Exemplo de formulrio web. Tela de login.

Cdigo 1.1 Exemplo de formulrio web.

O cdigo que interage com o formulrio da figura 02 deve receber os dados

As linhas 2 e 3 recebem os dados vindos do formulrio via mtodo post e

Cdigo 1.3 Prevenindo injeo com consultas parametrizadas

A segunda forma, stored procedures (SP), so procedimentos previamente

do ndice o(zero). A linha 16 executa o comando SQL de ndice 1 e guarda o seu

Cdigo 1.4 Prevenindo injeo com Stored Procedures

A stored procedure utilizada ilustrada pelo cdigo 1.5:

Cdigo 1.5 Stored procedure utilizada na preveno de injeo SQL

A terceira e ltima forma, codificao de sada de caractere, tambm

do SGBD Mysql mysql_real_escape_string() seja utilizada para codificao de

Cdigo 1.6 Prevenindo injeo codificando os caracteres

Observando o cdigo 1.6 nota-se que entre a linha 2 e 6 feita a conexo

3 - A2 XSS(Cross Site Scripting)

H trs tipos de ataques XSS: refletido (Reflected), armazenado (persistido,

O processo ocorre da seguinte forma; de um lado temos uma pgina que

Fonte: OWASP Top 10 (2010).

3.2 Exemplo de aplicao vulnervel

Cdigo 2.1 Aplicao vulnervel XSS

Importante notar que apesar do ataque ser efetuado em uma linguagem

Cdigo 2.2 Outro exemplo de aplicao vulnervel XSS

Cdigo 2.3 Dado no confivel inserido na aplicao