Apostila v2 PDF

Segurana em Aplicaes Web
para desenvolvedores
CAT/CBPF
Segurana em Aplicaes Web para desenvolvedores

CAT/CBPF
25 - 27 de maro de 2013

Aluno: Manoel Fernando de Sousa Domingues Junior - Orientador: Marita Maestrelli
Coordenao de Atividades Tcnicas - CAT - CBPF
Comunicao, distribuio e reproduo no autorizada.
Sumrio
1 Introduo
1.1 Hypertext Transfer Protocol .
1.1.1 Exemplo de Requisio
1.1.2 Exemplo de Resposta .
1.1.3 URI . . . . . . . . . .
1.1.4 Mtodos . . . . . . . .
1.1.5 Cdigos de Resposta .
1.1.6 Cookies . . . . . . . .
1.1.7 Autenticao HTTP .
1.1.8 Controle de Sesso . .
1.1.9 HTTPS . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2 Auditorias Web
2.1 Segurana das Aplicaes versus Segurana da
2.2 Aplicaes Web mais comuns . . . . . . . . .
2.3 Tipos de Auditorias . . . . . . . . . . . . . . .
2.3.1 BlackBox vs WhiteBox . . . . . . . . .
2.4 Metodologia de ataque . . . . . . . . . . . . .
2.4.1 Reconhecimento . . . . . . . . . . . . .
2.4.2 Mapeamento . . . . . . . . . . . . . .
2.4.3 Descoberta . . . . . . . . . . . . . . .
2.4.4 Explorao . . . . . . . . . . . . . . .
2.5 Tipos de falhas . . . . . . . . . . . . . . . . .
2.5.1 Exposio de Informaes . . . . . . .
2.5.2 Falhas de Configurao e Manuteno .
2.5.3 Falhas de Validao de Dados . . . . .
2.5.4 Falhas de Disponibilidade . . . . . . .
3
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Comunicao
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7
7
7
8
9
10
13
14
14
15
17
.
.
.
.
.
.
.
.
.
.
.
.
.
.
21
21
21
22
22
22
23
23
23
23
23
24
24
24
24

3 Reconhecimento
25
3.1 WHOIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2 DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2.1 Exemplos com dig e nslookup . . . . . . . . . . . . . . . . . . . . . . 29
3.2.2 Tipos de registro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.3 Newsgroups e Anncios de Empregos . . . . . . . . . . . . . . . . . . . . . . 31
3.4 Redes Sociais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4 Mapeamento
4.1 Mapeamento de portas . . .
4.2 Identificao do SO e Verso
4.3 NSE Scripts . . . . . . . . .
4.3.1 Categorias de scripts
4.3.2 Fases . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5 Identificao da Aplicao
5.1 Infraestrutura Web . . . . . . . . . . . . . . . . .
5.1.1 Load Balancers . . . . . . . . . . . . . . .
5.1.2 WAF . . . . . . . . . . . . . . . . . . . . .
5.1.3 Servidores Web . . . . . . . . . . . . . . .
5.1.4 Servidores de Banco de Dados . . . . . . .
5.2 Verses e Configuraes . . . . . . . . . . . . . .
5.2.1 Google Hacking . . . . . . . . . . . . . . .
5.2.2 Anlise do SSL . . . . . . . . . . . . . . .
5.3 Verificando Virtual Hosts . . . . . . . . . . . . . .
5.4 Usando Nikto . . . . . . . . . . . . . . . . . . . .
5.5 Spidering . . . . . . . . . . . . . . . . . . . . . .
5.6 Fluxograma de funcionamento . . . . . . . . . . .
5.7 Identificao dos pontos de entrada de informao
5.7.1 Requisies . . . . . . . . . . . . . . . . .
5.7.2 Respostas . . . . . . . . . . . . . . . . . .
6 Identificao de Vulnerabilidades
6.1 Mtodos de Identificao . . . . . .
6.1.1 Ferramentas . . . . . . . . .
6.2 Tipos de Vulnerabilidades . . . . .
6.2.1 Exposio de Informao . .
6.2.2 Configuraes e Manuteno
6.2.3 Validao de Dados . . . . .
6.2.4 Disponibilidade . . . . . . .
4
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
35
36
37
38
38
39
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
41
41
41
44
45
46
47
47
47
47
48
50
51
51
53
53
.
.
.
.
.
.
.
55
55
55
58
59
66
70
77

7 OWASP ZAP
83
7.1
Histrico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
7.2
Preparao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
7.2.1
Desative a atualizao das extenses . . . . . . . . . . . . . . . . . .
84
7.2.2
Desative o SafeBrowsing . . . . . . . . . . . . . . . . . . . . . . . . .
84
7.2.3
Desative o HTTP Pipelining . . . . . . . . . . . . . . . . . . . . . . .
85
7.2.4
Desative o Prefetching . . . . . . . . . . . . . . . . . . . . . . . . . .
86
7.2.5
Mude a pgina inicial . . . . . . . . . . . . . . . . . . . . . . . . . . .
86
7.2.6
Desative as sugestes de pgina . . . . . . . . . . . . . . . . . . . . .
87
7.2.7
Desabilite os updates do navegador . . . . . . . . . . . . . . . . . . .
87
7.2.8
Habilitando a opo de proxy . . . . . . . . . . . . . . . . . . . . . .
88
Usando a ferramenta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
7.3.1
Configurao Inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . .
91
7.3.2
Funcionalidades Basicas . . . . . . . . . . . . . . . . . . . . . . . . .
93
7.3.3
Reenvio e Fuzzing . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
96
7.3.4
Decode e Encode . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
96
7.3
8 Consideraes finais
8.1
tica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
99
99
5

Prefcio
Desde nosso primeiro contato com computadores que tinham comunicao virtual com
outros em varias partes do mundo, na dcada de 80, atraves da rede BITNET - Because
Its Time NETwork, a vida acadmica ficou mais fcil e mais vulnervel. Mais fcil, pois
temos acesso a informao com muito mais agilidade; mais vulnervel, pois podemos perder
a privacidade com muito mais facilidade.
Seguindo alguns cuidados com as configuraes que fazemos em nossos sistemas e aplicaes, podemos ficar menos preocupados quando navegamos pela grande rede.
A inteno deste material deixar os internautas mais atentos e ao mesmo tempo mais
tranquilos. Quem aguentar ver!!
Captulo 1
Introduo
A introduo tem por objetivo nivelar a perspectiva sobre o contedo usado como base
para o desenvolvimento do curso. Nessa introduo veremos uma reviso sobre o protocolo
HTTP e seus recursos.
1.1
Hypertext Transfer Protocol
O Hypertext Transfer Protocol (HTTP) ou Protocolo de Transferncia de Hipertexto

um protocolo baseado em requisies e respostas usando um protocolo confivel, geralmente
o protocolo TCP. 12
1.1.1
Exemplo de Requisio
Acompanhe a seguir um exemplo de requisio HTTP.

1 GET http : / /www. c b p f . br / HTTP/ 1 . 1
2 Host : www. c b p f . br
3 User Agent : M o z i l l a / 5 . 0 ( Macintosh ; I n t e l Mac OS X 1 0 . 8 ; rv : 1 7 . 0 )
Gecko /20100101 F i r e f o x / 1 7 . 0
4 Accept : t e x t / html , a p p l i c a t i o n / xhtml+xml , a p p l i c a t i o n /xml ; q = 0 . 9 , / ;
q =0.8
5 Accept Language : en US , en ; q =0.5
6 Proxy Connection : keep a l i v e
7 Content l e n g t h : 0
Na primeira linha GET http://www.cbpf.br/ HTTP/1.1 temos uma requisio do tipo
GET, onde o cliente requisita a pgina web que gostaria de obter acesso. A requisio sempre
ser a primeira linha, sendo as demais cabealhos que servem para identificar os sistemas,
tanto de origem quando de destino.
1
2
RFC 2616 http://www.ietf.org/rfc/rfc2616.txt

Design Considerations http://www.w3.org/Protocols/DesignIssues.html

Platform token
Descrio
Windows NT 6.2
Windows 8
Windows NT 6.1
Windows 7
Windows NT 6.0
Windows Vista
Windows NT 5.2
Windows Server 2003; Windows XP x64 Edition
Windows NT 5.1
Windows XP
Windows NT 5.01
Windows 2000, Service Pack 1 (SP1)
Windows NT 5.0
Windows 2000
Windows NT 4.0
Microsoft Windows NT 4.0
Windows 98; Win 9x 4.90
Windows Millennium Edition (Windows Me)
Windows 98
Windows 98
Windows 95
Windows 95
Windows CE
Windows CE
Macintosh; Intel Mac OS X x.y
Mac OS X em Intel x86 ou x86_64
Macintosh; PPC Mac OS X x.y
Mac OS X em PowerPC
X11; Linux i686; rv:10.0
Linux i686
X11; Linux x86_64; rv:10.0
Linux x86_64
X11; Linux i686 on x86_64; rv:10.0 Linux i686 rodando sobre x86_64
Em seguida, temos a linha User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X
10.8; rv:17.0) Gecko/20100101 Firefox/17.0 que especifica o tipo de cliente que fez a
requisio e suas capacidades. No exemplo, temos um navegador compatvel com os padres
Netscape Mozilla 5.0.
Um campo user-agent formado pelos seguintes subcampos ou tokens: Mozilla/[version]
([system and browser information]) [platform] ([platform details]) [extensions].
O uso comum da expresso Mozilla se deve que durante a browser war 3 muitos servidores
web somente permitiam acesso a clientes compatveis com o padro Netscape Mozilla.
Para cada token existe uma gama de possveis valores que podem variar dependendo
do ambiente do cliente. Acompanhe, a seguir, uma lista dos possveis valores para cada
subcampo.
No site http://www.useragentstring.com/pages/useragentstring.php podemos encontrar uma lista de user agents com seus respectivos navegadores.
1.1.2
Exemplo de Resposta
Acompanhe a seguir um exemplo da resposta a requisio HTTP anteriormente analisada.

1
2
3
4
HTTP/ 1 . 1 200 OK
Date : Fri , 22 Mar 2013 0 1 : 3 1 : 1 7 GMT
S e r v e r : Apache
Accept Ranges : b y t e s
3
http://en.wikipedia.org/wiki/Browser_wars

5 Content Length : 266
6 Content Type : t e x t / html
Na primeira linha HTTP/1.1 200 OK temos o status code resultante da requisio. Como
podemos observar, recebemos um 200 OK que uma mensagem de sucesso.
Na linha 6 - Content-Type: text/html temos o tamanho total da resposta.
Na linha 3 - Date: Fri, 22 Mar 2013 01:31:17 GMT temos a data e horrio que a
resposta foi realizada. Isso especialmente til quando vamos realizar uma anlise correlacionando eventos.
Opcionalmente nessa resposta, podemos observar o campo Server: Apache que indica
o sistema pelo qual a resposta se originou.
1.1.3
URI
URI ou Uniform Resource Indicators o endereo e um recurso incluindo a forma de

acesso a ele. Atualmente (2013) mais comum o uso de URL Uniform Resource Locator
com esse significado.
O formato de uma URI :
protocol://[user:password@]host.domainname[:port]/resource?param=value
A seguir, acompanhe um exemplo de URI e sua formao:
http://portal.cbpf.br/index.php?page=home
http -> protocol
portal -> host
cbpf.br ->domain name
index.php -> resource
page -> param
home -> value
Ao manipularmos os elementos da URI estamos modificando como as requisies GET
sero realizadas para o servidor web. Geralmente, uma aplicao web comum passa seus
parmetros seguindo o seguinte padro: ?param=value&param2=value2.
Existem outras formas de passar esses mesmo dados para o servidor web, sem realizar o
uso dos caracteres ?, & e =, que so muito comuns. Para isso deve ser feito o uso de recursos no servidor web para tratar as requisies GET e repass-las de forma adequada a aplicao web. Como exemplo, temos o mod_rewrite presente no servidor web Apache que faz essa
funo, assim a URI vista anteriormente ficaria da forma: /param/value/param/value2.

1.1.4
Mtodos
Os clientes de um servidor web podem usar vrios mtodos disponveis para realizar suas
requisies a um servidor web. Ao todo existem 8 mtodos disponveis, sendo eles: GET,
POST, HEAD, TRACE, OPTIONS, CONNECT, PUT, DELETE.
Os mtodos mais importantes so: GET e POST.
O mtodo GET serve para solicitar pginas ao servidor web, podendo tambm enviar
dados como parmetros.
O mtodo POST serve para enviar dados ao servidor web para processamento. A diferena principal entre os mtodos que o mtodo GET envia os dados via URI e o mtodo
POST envia os dados usando o payload HTTP.
Os outros mtodos servem respectivamente para:
HEAD - Obtm somente o cabealho HTTP. uma variao do GET sem obter os recursos
solicitados.
Acompanhe o exemplo a seguir(requisio e resposta).
1 HEAD http : / / p o r t a l . c b p f . br HTTP/ 1 . 1
2 Host : p o r t a l . c b p f . br
Gecko /20100101 F i r e f o x / 1 7 . 0
q =0.8
1
2
3
4
5
6
7
HTTP/ 1 . 1 200 OK
Date : Fri , 22 Mar 2013 0 2 : 2 8 : 5 0 GMT
X Powered By : PHP/ 5 . 2 . 8
Set Cookie : CBPF=224 r75rcj3aumndbiv5ok1c5n3 ; path=/
E x p i r e s : Thu , 19 Nov 1981 0 8 : 5 2 : 0 0 GMT
Cache C o n t r o l : no s t o r e , no cache , must r e v a l i d a t e , post check =0,
pre check=0
8 Pragma : no c ac h e
9 Vary : Accept Encoding
10 Content Type : t e x t / html ; c h a r s e t=i s o 8859 1
PUT - Envia um recurso
Acompanhe o exemplo a seguir.
1 PUT http : / / p o r t a l . c b p f . br HTTP/ 1 . 1
Gecko /20100101 F i r e f o x / 1 7 . 0
10
4
5
6
7

Accept : t e x t / html , a p p l i c a t i o n / xhtml+xml , a p p l i c a t i o n /xml ; q = 0 . 9 , / ;
q =0.8
Accept Language : en US , en ; q =0.5
Proxy Connection : keep a l i v e
Content l e n g t h : 0
1
2
3
4
5
6
7
HTTP/ 1 . 1 200 OK
Date : Fri , 22 Mar 2013 0 2 : 2 8 : 5 0 GMT
Set Cookie : CBPF=l o t 9 g 3 8 0 q q k h e 0 8 c 6 9 s p c d t j 8 4 ; path=/
pre check=0
DELETE - Exclui um recurso
1 DELETE http : / / p o r t a l . c b p f . br HTTP/ 1 . 1
Gecko /20100101 F i r e f o x / 1 7 . 0
q =0.8
1
2
3
4
5
6
7
HTTP/ 1 . 1 200 OK
Date : Fri , 22 Mar 2013 0 2 : 2 8 : 5 0 GMT
Set Cookie : CBPF=1r8h5mvgp2be72u41s1ak04b33 ; path=/
pre check=0
TRACE - Ecoa o pedido, de maneira que o cliente possa saber o que os servidores
intermedirios esto mudando em seu pedido.
11

1 TRACE htt p : / / p o r t a l . c b p f . br HTTP/ 1 . 1
Gecko /20100101 F i r e f o x / 1 7 . 0
q =0.8
1
2
3
4
5
6
HTTP/ 1 . 1 403 Forbidden

Date : Fri , 22 Mar 2013 0 2 : 2 8 : 5 0 GMT
Vary : Accept Encoding
Content Length : 202
Content Type : t e x t / html ; c h a r s e t=i s o
8859 1
OPTIONS - Verifica os mtodos permitidos pelo servidor web.

1 OPTIONS http : / / p o r t a l . c b p f . br HTTP/ 1 . 1
Gecko /20100101 F i r e f o x / 1 7 . 0
q =0.8
1
2
3
4
5
6
7
HTTP/ 1 . 1 200 OK
Date : Fri , 22 Mar 2013 0 2 : 2 8 : 5 0 GMT
Set Cookie : CBPF=sfkeukpas8mte3nv57m858a5f2 ; path=/
pre check=0
CONNECT - Abre um tnel para o servidor ser usado como proxy
12
5
6

CONNECT http : / / p o r t a l . c b p f . br HTTP/ 1 . 1
Host : p o r t a l . c b p f . br
User Agent : M o z i l l a / 5 . 0 ( Macintosh ; I n t e l Mac OS X 1 0 . 8 ; rv : 1 7 . 0 )
Gecko /20100101 F i r e f o x / 1 7 . 0
Accept : t e x t / html , a p p l i c a t i o n / xhtml+xml , a p p l i c a t i o n /xml ; q = 0 . 9 , / ;
q =0.8
Accept Language : en US , en ; q =0.5
Content l e n g t h : 0
1
2
3
4
5
6
7
HTTP/ 1 . 1 400 Bad Request

Date : Fri , 22 Mar 2013 0 2 : 4 6 : 4 5 GMT
Vary : Accept Encoding
Content Length : 226
Connection : c l o s e
Content Type : t e x t / html ; c h a r s e t=i s o
1
2
3
4
1.1.5
8859 1
Cdigos de Resposta
O protocolo HTTP usa cdigos numricos para identificar o tipo de resposta. Existem 5
classes, com as seguintes designaes.
1xx Informational
100 Continue
2xx Success
200 OK
3xx Redirection
301 Moved Permanently
302 Redirect
304 Not Modified
4xx Client Error
400 Bad Request
401 Not Unauthorized
403 Forbidden
404 File not found
5xx Server Error
13

500 Server Error
502 Bad Gateway
Uma lista mais extensa dos Cdigos de Resposta pode ser encontrada em: http://www.
w3.org/Protocols/rfc2616/rfc2616-sec10.html.
1.1.6
Cookies
Os cookies so elementos do protocolo HTTP que so enviados ao navegador pelo servidor, com o objetivo de lembrar informaes de um usurio. formado por uma cadeia de
caracteres, organizados de forma cadeia/valor, separados por ponto-e-vrgula. Seus principais
usos so a manuteno de uma sesso (que no e suportado pelo protocolo) e a autenticao
de usurios.
A seguir, podemos observar essas caractersticas no cookie enviado pelo www.cbpf.br.
Set-Cookie:
CBPF=sfkeukpas8mte3nv57m858a5f2; path=/
Alguns atributos de um cookie so:

expires - define por quanto tempo o cookie valido
domain - define para quais domnios o cookie valido
path - define os caminhos para os quais o cookie vlido
secure - obriga o cookie a ser enviado somente em requisies via HTTPS
HttpOnly - impede que o cookie seja acessado por cdigo executado no lado do cliente
1.1.7
Autenticao HTTP
A autenticao serve para identificar o usurio para a aplicao web ou para o servidor
web. Geralmente usada uma combinao de usurio e senha, o que garante somente um
dos requisitos para uma boa autenticao.
Os requisitos para uma boa autenticao se baseiam em:
Algo que voc sabe - geralmente uma senha
Algo que voc - geralmente um ser humano (biometria)
Algo que voc tem - geralmente um token ou smartcard
O protocolo HTTP possui dois mtodos nativos para autenticao: Basic e Digest. Embora existam somente esses dois mtodos no protocolo, a autenticao geralmente pode ser
feita utilizando certificados no cliente, de forma integrada ao ambiente de rede (Single Sign
On 4 ), ou baseada em formulrios.
4
14
http://en.wikipedia.org/wiki/Single_sign-on

Autenticao Basic
A autenticao usando o mtodo Basic5 bem simples, no utilizando nem criptografia.
Seu contedo transmitido utilizando ofuscao, com a codificao dos dados em base646 .
No existe nenhum controle de fora bruta, isso possibilita,por exemplo, encher o disco
com os logs do servidor web.
Autenticao Digest
A autenticao usando o mtodo Digest7 bem simples tambm, porm utiliza MD5 que
um hash criptogrfico j em desuso devido sua fragilidade.
Como o MD5 faz apenas uma passagem sobre os dados, se dois prefixos com o mesmo
hash forem construdos, um sufixo comum pode ser adicionado a ambos para tornar uma
coliso mais provvel. Deste modo possvel que duas strings diferentes produzam o mesmo
hash. O que no garante que a partir de uma senha criptografada especfica consiga-se a
senha original, mas permite uma possibilidade de decifrar algumas senhas a partir de um
conjunto grande de senhas criptografadas.
Autenticao baseada em formulrio
a forma mais comum de autenticao atualmente, tanto pelo controle quanto pela
facilidade de uso.
recomendado que os programadores faam uso da API da OWASP8 devido sua maturidade e sua preocupao com a segurana em diversas camadas.
1.1.8
Controle de Sesso
O protocolo HTTP um protocolo sem controle de estado, logo a aplicao deve implementar uma forma de fazer o agrupamento de requisies em uma sesso, ou seja, a aplicao
deve fazer o controle de sesso.
Os mtodos mais usados para fazer o controle de sesso so atravs de:
cookies
codificao da URL
campos hidden em formulrios
5
RFC 2617
http://pt.wikipedia.org/wiki/Base64
7
RFC 2617
8
https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API
6
15

Tipos de Sesso
Existem dois tipos de sesso: client-side e server-side.
No tipo client-side todos os dados relativos a sesso so enviados para o cliente, o que
muito conveniente para um indivduo mal intencionado, pois a aplicao acredita que o
cliente no modificar os dados enviados.
No tipo server-side, a sesso mantida no servidor e controlada atravs do uso de
uma varivel, conhecida como session ID. Nesse ltimo caso, somente uma varivel pode ser
manipulada, a session ID.
Cookies
Como vimos anteriormente os cookies so elementos do protocolo HTTP que so enviados
ao navegador pelo servidor, com o objetivo de lembrar informaes de um usurio. Eles
possuem alguns recursos de segurana, de modo a permitir, por exemplo, que o cookie s
possa ser manipulado via HTTPS. Tambm podem receber marcaes para permitir seu
armazenamento somente em memria ou ter validade por um determinado tempo.9
Codificao de URL
Geralmente uma URI somente pode conter caracteres ASCII10 , sendo que alguns deles
apresentam funes especiais, como delimitadores ou com uso reservado. Para utiliz-los
como dados para a aplicao web necessrio codificar esses caracteres.
A seguir, veja uma lista dos caracteres reservados:
":"
"/"
"?"
"#"
"["
"]"
"@"
"!"
"$"
"&"
""
"("
")"
"*"
"+"
","
";"
9
10
16
RFC 2965
RFC 3986

"="
O mtodo padro de codificao de caracteres consiste no uso de um caractere % seguido
da representao em hexadecimal do caractere.
Confira em http://www.w3schools.com/tags/ref_urlencode.asp uma tabela com a
codificao de diversos caracteres.
A codificao realizada atravs da chave: parmetro=valor de modo que quando um
usurio clica em determinado link, o navegador envia os dados via GET para o servidor web.
Veja o prximo exemplo, onde o parmetro id recebe o valor 580. Mudando o valor para
579, por exemplo, encontramos outra pgina, com outro contexto.
http://portal.cbpf.br/index.php?page=Noticias.VerNoticia&id=580 -> Notcia sobre colquio
http://portal.cbpf.br/index.php?page=Noticias.VerNoticia&id=579 -> Notcia sobre prorrogao de prazo
Campos Hidden
Nesse caso, a aplicao retorna ao usurio formulrios com campos do tipo hidden que
no aparecem para os usurios. No somente, mas os fomulrios podem conter um mistura
de campos visveis com campos hidden.
No exemplo encontrado no site: http://www.rederio.br/site/contact encontramos
um campo do tipo hidden responsvel por fazer o controle do preenchimento do formulrio.
Veja-o a seguir.
<input name="captcha_token"value="91051e5ff489d1e5a06e3fdcd043eba0"/>
Em outros casos, aps o usurio estar autenticado em uma aplicao, possvel encontrar formulrios com um campo com a identificao do usurio, como, por exemplo, um
campo id. Nesse tipo de campo, podemos tentar subverter o sistema de controle de sesso,
alterando assim seu valor para tentar obter acesso a conta de outro usurio.
1.1.9
HTTPS
O protocolo HTTPS consiste na implementao de um canal SSL/TLS para o transporte

de dados HTTP. Com o uso do canal SSL/TLS a comunicao passa a trafegar de forma
encriptada. Sua segurana est baseada no conceito de Web of Trust 11 segundo a SANS,
mas da forma que conhecemos, ela est mais para o conceito hierrquico de PKI 12 .
O conceito de PKI est baseado na confiana de uma Autoridade Raiz que certifica
Autoridades Intermedirias atravs da gerao de certificados digitais. O comprometimento
de uma Autoridade Certificadora possui consequncias enormes pois a revogao de seus
11
12
http://en.wikipedia.org/wiki/Web_of_trust
http://en.wikipedia.org/wiki/Public_key_infrastructure
17

certificados pode ser muito demorada para evitar incidentes graves e muito custosa para
seus clientes.
Veja, a seguir, algumas notcias sobre um comprometimento que ocorreu em 2011.
http://www.gris.dcc.ufrj.br/news/apple-lanca-atualizacao-de-seguranca-para-certific
http://www.computerworld.com/s/article/9219663/Hackers_may_have_stolen_over_
200_SSL_certificates
http://technet.microsoft.com/en-us/security/advisory/2607712
Problemas do HTTPS
Alm do risco do comprometimento de uma autoridade certificadora, um outro problema
do uso de HTTP o uso cada vez mais frequentes de certificados auto-assinados. O uso
do certificado auto-assinado no um problema, mas as informaes que so passadas aos
usurios para contornar as mensagens de erro apresentados por seu uso so.
Veja na imagem 1.1 o exemplo de instrues para contornar o uso de certificados autoassinados.
18

Figura 1.1: Instrues de uso para certificados auto-assinados - Fonte: http://chicago.

itamaraty.gov.br/pt-br/maiores_18_anos_-_consulado.xml
19

20
Captulo 2
Auditorias Web
Se voc conhece o inimigo e conhece a si mesmo, no precisa temer o resultado de
cem batalhas. Se voc se conhece mas no conhece o inimigo, para cada vitria
ganha sofrer tambm uma derrota. Se voc no conhece nem o inimigo nem a
si mesmo, perder todas as batalhas...
Sun Tzu
2.1
Segurana das Aplicaes versus Segurana da Comunicao
Diversos desenvolvedores de solues web acreditam estar protegendo suas aplicaes com
atravs da implantao de certificados nos seus servidores. Existe no mercado, at empresas
que vendem sistemas que monitoram e testam a qualidade dos certificados SSL dizendo
oferecer aos seus clientes uma melhor segurana em suas aplicaes web. Na realidade, o
uso de certificados SSL somente atua na segurana da comunicao, garantindo assim a
confidencialidade dos dados trafegados.
Em nenhum momento o SSL protege a aplicao de falhas, at porque o SSL no
implantado na aplicao, e sim no servio que disponibilizar a aplicao.
2.2
Aplicaes Web mais comuns
O desenvolvimento de aplicaes web gerenalistas tem aumentado devido a grande demanda de aplicaes que tivessem um ncleo robusto juntamente com uma alta capacidade
de customizao.
Para isso, aplicaes web comearam a ser desenvolvidas como plataformas de contedo
e sua customizao comeou a ser feita com a instalao de mdulos.
Aplicaes Web comuns so:
CMS
21

Wikis
Lojas Virtuais
2.3
2.3.1
Tipos de Auditorias
BlackBox vs WhiteBox
Teste caixa-preta ou Teste BlackBox um teste de software para verificar a sada

dos dados usando entradas de vrios tipos. Tais entradas, geralmente, no so escolhidas
conforme a estrutura do programa.
Quanto mais entradas so fornecidas, mais rico ser o teste. Numa situao ideal todas
as entradas possveis seriam testadas, mas na ampla maioria dos casos isso impossvel.
O teste caixa preta um teste em que a principal caracterstica que seu testador
no possui conhecimento prvio sobre o funcionamento da aplicao.
Teste de caixa-branca ou teste WhiteBox uma tcnica de teste que usa a perspectiva
interna do sistema para modelar os casos de teste. No teste de software, a perspectiva interna
significa basicamente o cdigo-fonte.
A principal diferena do teste caixa-preta para o teste caixa-branca que a perspectiva
interna do sistema desconsiderada, sendo testadas e mensuradas somente as interfaces do
sistema. Entretanto, ambas as tcnicas podem ser usadas em conjunto, no que chamado
teste caixa-cinza. Dessa forma, o teste modelado conhecendo-se a estrutura interna do
sistema, mas a execuo ignora esse aspecto, como no teste caixa-preta.
2.4
Metodologia de ataque
A metodologia de ataque uma aplicao web cclica. Ele consiste de 4 fases1 , sendo
eles:
Reconhecimento - Fase de pesquisa sobre a aplicao
Mapeamento - Fase para entender como a aplicao funciona
Descoberta - Fase de busca por vulnerabilidades
Explorao - Fase de execuo dos ataques
So fases iterativas e realimentadas, pois a cada fase temos uma nova perspectiva sobre
a aplicao.
1
22
De acordo com a metodologia da SANS, uma das principais referencias no assunto.

2.4.1
Reconhecimento
A fase da pesquisa sobre a aplicao importante para determinar o foco dos ataques.
Nessa fase interessante determinar os diagramas de arquitetura da aplicao, informaes
sobre o procedimento de autenticao, informaes sobre o procedimento de recuperao de
senha, informaes sobre a infraestrutura, como caches, balanceadores de carga, firewall de
aplicao, entre outras informaes sobre a rede alvo.
2.4.2
Mapeamento
A fase para entender como a aplicao funciona em conjunto com sua infraestrutura.
Os primeiros passos envolvem a execuo de varreduras de portas, checagem de verso de
aplicaes e dependncias, assim como a determinao do sistema operacional e do servidor
web.
Nessa fase, tambm devero ser mapeados os relacionamentos da aplicao com outros
contedos, como, por exemplo, outras pginas dentro do mesmo servidor web. Diversas
aplicaes contam com recursos como o sitemap ou mapa do site, que fornece um bom
comeo para essa fase.
2.4.3
Descoberta
A fase de busca por vulnerabilidade importante para correlacionar os resultados no

mapeamento com as possveis ameaas que a aplicao web est exposta. Nessa fase, o foco
estar na procura de informaes sobre o desenvolvimento da aplicao, informaes sobre
os sistemas e arquivos da aplicao, sistemas de autenticao, APIs, mensagens de erros e
possveis problemas no uso da aplicao.
Algumas informaes so importantes nessa fase. como, por exemplo, nomes de usurios,
possveis IDs, possveis valores para parmetros, etc. Nessa fase, tambm vamos determinar
que ferramentas so interessantes para a fase de explorao.
2.4.4
Explorao
Na fase da execuo dos ataques importante lembrar de documentar todos os passos

dados e seus resultados. Durante a execuo dos ataques, cada ataque executado com sucesso
uma interface para descobrir mais informaes sobre a aplicao. Com isso, podem ser
descobertas novas partes da aplicao, outras aplicaes que compartilham recursos ou que
podem ser acessadas atravs dela.
2.5
Tipos de falhas
A seguir veremos algumas categorias de falhas esperadas em aplicaes web. Essa listagem no extensiva somente para termos uma noo antes de entrarmos mais profundamente nos prximos captulos.
23

2.5.1
Exposio de Informaes
Esse tipo de falha permite descobrir informaes sobre a aplicao. Esse tipo de informao pode ser: informaes sobre a infraestrutura, informaes sobre correes, informaes
sobre verso de dependncias externas, informaes sobre armazenamento de dados e informaes sobre usurios e senhas.
2.5.2
Falhas de Configurao e Manuteno
Esse tipo de falha comum em servidores web que no foram configurados de forma especfica para a aplicao. Assim, esses servidores web, com sua configurao padro expem
sua assinatura, verso, e outras informaes que podem ser teis para ataques direcionados.
2.5.3
Falhas de Validao de Dados
Vulnerabilidades relacionadas com a Validao de Dados costumam ser as mais presentes

em aplicaes, mesmo em aplicaes desktop.
Embora sejam as mais comuns, elas representam um grande risco para a aplicao. Primeiro, porque permitem a manipulao da informao presente na aplicao e segundo,
porque podem facilmente denegrir a imagem da organizao dona da aplicao.
2.5.4
Falhas de Disponibilidade
Categoriza vulnerabilidades que afetam a capacidade do sistema em responder s requisies feitas pelos clientes (usurios, outros sistemas, monitoramento, . . . ) conforme as regras
que so estabelecidas para cada sistema. Ou seja, afetam a capacidade do servio estar
disponvel quando requisitado.
24
Captulo 3
Reconhecimento
Essa a primeira fase das quatro existentes na metodologia de teste de invaso em
aplicaes web1 .
Existem diversas maneiras de iniciar o reconhecimento, entre elas pesquisas na Internet,
pesquisas direcionadas com o GHDB - Google Hacking Database 2 , pesquisas em forums,
mdias sociais e blogs pessoais.
Informaes que podem ser encontradas:
Nomes de funcionrios
Identificadores de usurios
Informaes diversas sobre usurios
Tecnologias empregadas
Servidores e Topologia de Rede
Configurao dos componentes
Recursos disponibilizados pelos servidores web
Arquivos robots.txt
Outras informaes importantes so relacionadas a infraestrutura. Exemplos so:
Balanceadores de Carga
Firewall de aplicao Web
Proxies
Informaes sobre o host, como vulnerabilidades e verses de sistema
1
2
SANS
http://www.hackersforcharity.org/ghdb/
25

3.1
WHOIS
O whois 3 um protocolo usado com a finalidade de prover um servio de identificao

para blocos de endereos IP.
Antes de realizar consultas whois interessante estipular sobre qual entidade de registro
o domnio ou bloco de IPs foi registrado. Internacionalmente, existem entidades para cada
continente ou parte do continente. A seguir, se encontra uma lista com as entidades e na
imagem 3.1, um mapa com a rea de atuao de cada uma.
AFRINIC (frica) - http://www.afrinic.net
APNIC (sia e Oceania) - http://www.apnic.net
ARIN (EUA, Canad e Antrtida) - http://ws.arin.net
LACNIC (Amrica Latina) - http://www.lacnic.net
RIPE (Europa, Rssia e Oriente Mdio) - http://www.ripe.net
Figura 3.1: Entidades em cada continente

Acompanhe alguns exemplos de uso do whois a seguir:
3
26
RFC 3912 - http://tools.ietf.org/html/rfc3912

$ whois -h whois.registro.br cbpf.br
% Copyright (c) Nic.br
% The use of the data below is only permitted as described in
% full by the terms of use (http://registro.br/termo/en.html),
% being prohibited its distribution, comercialization or
% reproduction, in particular, to use it for advertising or
% any similar purpose.
% 2013-03-22 08:54:06 (BRT -03:00)
domain:
owner:
ownerid:
responsible:
country:
owner-c:
admin-c:
tech-c:
billing-c:
nserver:
nsstat:
nslastaa:
nserver:
nsstat:
nslastaa:
nserver:
nsstat:
nslastaa:
dsrecord:
dsstatus:
dslastok:
dsrecord:
dsstatus:
dslastok:
created:
changed:
status:
cbpf.br
CENTRO BRASILEIRO DE PESQUISAS FISICAS
033.654.831/0014-50
Marita Maestrelli
BR
MAM214
MAM214
MAM214
MAM214
cbpfsu1.cat.cbpf.br 152.84.253.2
20130320 AA
20130320
p0m1.cat.cbpf.br 152.84.253.220
20130320 AA
20130320
cbpfsu2.cat.cbpf.br 152.84.253.3
20130320 AA
20130320
22822 RSA/SHA-1 8D87F19358A2CD935A5FDD94016326CA42062764
20130320 DSOK
20130320
22822 RSA/SHA-1 299970DF51DDB96A5AC811B015C26CC981D44EBB32C6216CA1525153A31
20130320 DSOK
20130320
before 19950101
20121206
published
nic-hdl-br:
person:
e-mail:
created:
MAM214
Marita Maestrelli
marita@cbpf.br
19980904
27

changed:
20030811
%
%
%
%
%
%
%
Security and mail abuse issues should also be addressed to

cert.br, http://www.cert.br/, respectivelly to cert@cert.br
and mail-abuse@cert.br
whois.registro.br accepts only direct match queries. Types
of queries are: domain (.br), ticket, provider, ID, CIDR
block, IP and ASN.
Podemos fazer algumas consultas para obter mais informaes sobre domnios, acompanhe a seguir:
$ whois -h whois.registro.br 033.654.831/0014-50
% Copyright (c) Nic.br
% The use of the data below is only permitted as described in
% full by the terms of use (http://registro.br/termo/en.html),
% being prohibited its distribution, comercialization or
% reproduction, in particular, to use it for advertising or
% any similar purpose.
% 2013-03-22 08:57:33 (BRT -03:00)
owner:
ownerid:
responsible:
country:
owner-c:
created:
changed:
CENTRO BRASILEIRO DE PESQUISAS FISICAS

033.654.831/0014-50
Marita Maestrelli
BR
MAM214
19980904
20081007
nic-hdl-br:
person:
e-mail:
created:
changed:
MAM214
Marita Maestrelli
marita@cbpf.br
19980904
20030811
domain:
cbpf.br
% Security and mail abuse issues should also be addressed to

% cert.br, http://www.cert.br/, respectivelly to cert@cert.br
% and mail-abuse@cert.br
%
28

% whois.registro.br accepts only direct match queries. Types
% of queries are: domain (.br), ticket, provider, ID, CIDR
% block, IP and ASN.
Existem outras ferramentas mais dinmicas ou que fornecem mais informaes. Alguns
exemplos so:
http://www.team-cymru.org/Services/ip-to-asn.html (recomendado para scripts que
fazem muitas consultas)
http://www.geektools.com/whois.php
3.2
DNS
O sistema de nomes de domnio, do ingls Domain Name System - DNS um sistema

de gerenciamentos de nomes que tem por finalidade permitir a identificao dos hosts na
internet. Ou seja, o sistema de DNS traduz nomes de domnios em endereos IP e vice-versa
4
.
3.2.1
Exemplos com dig e nslookup
Vejamos a seguir um exemplo de uma consulta usando o nslookup:

$ nslookup www.cbpf.br
Server: 187.100.246.251
Address: 187.100.246.251#53
Non-authoritative answer:
Name: www.cbpf.br
Address: 152.84.253.9
Podemos realizar a mesma consulta utilizando a ferramenta dig que possui funcionalidades semelhantes, que enumeraremos mais adiante:
$ dig www.cbpf.br
; <<>> DiG 9.8.3-P1 <<>> www.cbpf.br
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25850
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
4
RFC 1034 e RFC 1035
29

Record Tipo
Uso
A
Registro de hosts
Associa um nome a um endereo IP
MX
Registro de servidores de email Associa um endereo IP ao servio de correio
PTR
Registro de ponteiro
Associa um endereo IP a um nome
NS
Registro de servidores de nome Associa um endereo IP ao servio de DNS
SOA
Registro de autoridade da zona Registro dos servidores autoritativos da zona
NS
Registro de servidores de nome Associa um endereo IP ao servio de DNS
SOA
Registro de autoridade da zona Registro dos servidores autoritativos da zona
Tabela 3.1: Tipos e Usos de registros DNS
;; QUESTION SECTION:
;www.cbpf.br. IN A
;; ANSWER SECTION:
www.cbpf.br. 600 IN A 152.84.253.9
;;
;;
;;
;;
Query time: 201 msec

SERVER: 187.100.246.251#53(187.100.246.251)
WHEN: Fri Mar 22 09:02:11 2013
MSG SIZE rcvd: 45
3.2.2
Tipos de registro
Outra caracterstica do sistema de nomes que cada registro, alm de um endereo IP e

um nome, tambm possui um tipo. O tipo chamado internamente pelo sistema de resource
records e cada tipo de registro serve para armazenar um tipo de informao.
Acompanhe na tabela 3.1 os tipos e usos para cada um.
Para realizar consultas por tipo usando a ferramenta dig faa conforme o exemplo a
seguir:
$ dig -t SOA www.cbpf.br
; <<>> DiG 9.8.3-P1 <<>> -t SOA www.cbpf.br
;; Got answer:
;www.cbpf.br. IN SOA
;; AUTHORITY SECTION:
30

cbpf.br. 600 IN SOA cbpfsu1.cat.cbpf.br. marita.cbpfsu1.cat.cbpf.br. 2013031900 3600 900
;;
;;
;;
;;

SERVER: 200.142.130.202#53(200.142.130.202)
WHEN: Fri Mar 22 09:10:16 2013
MSG SIZE rcvd: 84
3.3
Newsgroups e Anncios de Empregos
A participao de funcionrios de organizaes em newsgroups e listas de discusso

bem conhecida principalmente de funcionrios dos departamentos relacionados a Tecnologia
da Informao.
Atravs do uso de seus nomes ou at de seus emails corporativos (que podem ser obtidos
nas fases anteriores), possvel encontrar mensagens que podem revelar suas preferncias
de uso, preferncias por softwares especficos ou, em casos mais graves, pedidos de ajuda na
configurao de servios, incluindo a exposio de arquivos de configurao dos sistemas da
empresa.
Acompanhe o exemplo na imagem 3.2, onde se encontra um pedido de ajuda na configurao de um determinado servio.
Figura 3.2: Pedido de ajuda com informaes muito detalhadas

Outra forma de obter mais informaes atravs de anncios de emprego. Neles
possvel encontrar quais os domnios que determinado profissional precisa para atuar em um
departamento da empresa.
Diversos anncios tambm incluem quais softwares o possvel candidato deve ter conhecimento pois fazem parte do uso cotidiano da empresa. Veja o anncio na imagem 3.3 onde
possvel obter informaes sobre o sistema de banco de dados usado na empresa em questo.
3.4
Redes Sociais
As redes sociais so um dos destinos mais acessados na Internet. No somente para

permitir o intercmbio e troca de experincia entre pessoas, muitas redes sociais se tornaram
31

Figura 3.3: Anncio de emprego com informaes de diversos sistemas internos

mdias sociais de maneira a permitir um livre intercmbio de informaes.
Algumas redes ainda, possuem recursos como a criao de grupo ou comunidades de
pessoas com interesses em comum e at de pessoas que trabalham no mesmo lugar.
Dessa maneira essas redes ou mdias sociais fornecem um imenso portflio de informaes
sobre cargos, pesquisas, formao acadmica entre outras informaes. Veja na imagem 3.4
32

um exemplo.
Figura 3.4: Perfil do LinkedIn de um ex-aluno de Iniciacao Cientifica

Outro exemplo atravs de pesquisas e trabalhos apresentados em congressos. Estes
podem conter informaes privilegiadas. Trabalhos geralmente expostos em sites como o
slideshare, paginas pessoais ou prototipo de sistemas podem apresentar informaes muito
relevantes. Veja na imagem 3.5 informaes que ficaram expostas por diversos meses na
internet antes de serem retiradas.
33

Figura 3.5: Diagrama disponivel em prototipo de Repositrio Looking Glass
34
Captulo 4
Mapeamento
O mapeamento de uma aplicao web um processo divido em fases bem definidas. Esse
processo realizado de acordo com o diagrama 4.1.
Figura 4.1: Diagrama com fases do processo de mapeamento

Assim podemos notar que as fases sempre so retro-alimentadas pelas novas informaes
obtidas e o processo cclico.
35

4.1
Mapeamento de portas
Varreduras de portas, tradicionalmente, tm por objetivo identificar o estado das portas

dos sistemas alvo, isto , determinar se as portas dos sistemas alvos esto abertas, fechadas e
ou filtradas. A varredura de portas identifica quais portas aceitam e interpretam pacotes e,
por isto, podem ser pontos de entrada para ataques. Este tipo de varredura frequentemente
est associada identificao de servios providos, embora no precise estar necessariamente.
Com a identificao dos servios providos pelos sistemas alvo, possvel realizar varreduras exploratrias especficas para cada servio, a fim de obter mais informaes sobre o
sistema, o servio ou at os seus usurios.
Outra atividade importante desta etapa a identificao de sistemas operacionais (OS
fingerprinting), que, em primeira anlise, no teria relao com a varredura de portas. No
entanto, como a identificao de sistemas operacionais funciona de forma similar varredura de portas, comum executar as duas operaes na mesma etapa. A identificao
feita atravs da anlise comportamental das respostas recebidas quando pacotes com caractersticas especiais so enviados para portas abertas e fechadas, valendo se que as diferentes
implementaes das pilhas UDP, TCP e IP de cada sistema operacional respondem de forma
diferente, permitindo a identificao do mesmo.
A tcnica de varredura mais conhecida a de varreduras de portas lgicas de um sistema.
Uma porta lgica uma forma de um protocolo associar um servio a um meio de acesso,
dessa forma, por exemplo, um pacote que chega na porta 80 ser associado ao servio que
est nessa porta (geralmente o servidor web).
A importncia da varredura de portas est na descobertas dos servios habilitados e possivelmente vulnerveis que possam ser alvos de uma futura investida. Assim, o mapeamento
possibilita adicionar informaes s fases de reconhecimento do ambiente e criar um roteiro
dos possveis servios que podem ser alvos de ataques. Para entender de forma clara como
funciona uma varredura de portas, se faz necessrio um maior entendimento de como os
protocolos funcionam. No exemplo a seguir, ilustramos um protocolo de atendimento:
1. O cliente entra na loja e se dirige ao atendente;
2. O atendente o cumprimenta;
3. O cliente cumprimenta o atendente;
4. O cliente faz sua solicitao ao atendente;
5. O atendente responde a solicitao do cliente.
Podemos notar como funciona o protocolo de atendimento e com base nisto que os
protocolos de internet funcionam. As varreduras so baseadas principalmente em falhas ou
atitudes inesperadas que no esto previstas no protocolo, como o caso de um cliente armado
chegar na loja. Um exemplo que para saber se um atendente est disponvel basta se dirigir
a ele, aps ele cumprimentar o cliente podemos simplesmente ir embora. Na varredura
de portas, no diferente, como somente precisamos saber se as portas esto abertas ou
36

fechadas, filtradas ou no-filtradas, s precisamos cumprir o protocolo at determinarmos
isto, depois podemos interromper a conexo.
Podemos notar como funciona o protocolo de atendimento e com base nisto que os
protocolos de internet funcionam. As varreduras so baseadas principalmente em falhas ou
atitudes inesperadas que no esto previstas no protocolo, como o caso de um cliente armado
chegar na loja. Um exemplo que para saber se um atendente est disponvel basta se dirigir
a ele, aps ele cumprimentar o cliente podemos simplesmente ir embora. Na varredura
de portas, no diferente, como somente precisamos saber se as portas esto abertas ou
fechadas, filtradas ou no-filtradas, s precisamos cumprir o protocolo at determinarmos
isto, depois podemos interromper a conexo.
Acompanhe a seguir um exemplo de varredura TCP SYN com o nmap 1 .
$ sudo nmap -sS -sV 200.20.94.130
Starting Nmap 6.25 ( http://nmap.org ) at 2013-03-22 09:52 BRT
Nmap scan report for 200.20.94.130
Host is up (0.062s latency).
Not shown: 991 closed ports
PORT
STATE
SERVICE
VERSION
25/tcp
filtered smtp
80/tcp
open
http
Apache httpd 2.2.15 ((Fedora))
135/tcp filtered msrpc
139/tcp filtered netbios-ssn
443/tcp open
ssl/http
445/tcp filtered microsoft-ds
593/tcp filtered http-rpc-epmap
3306/tcp open
mysql
MySQL 5.1.47
4444/tcp filtered krb524
Service detection performed. Please report any incorrect results at http://nmap.org/subm

Nmap done: 1 IP address (1 host up) scanned in 125.11 seconds
4.2
Identificao do SO e Verso
A identificao do Sistema Operacional importante para determinar possveis vulnerabilidades no sistema anfitrio. Embora no seja esse o foco, essas vulnerabilidades podem
facilitar a descoberta de vulnerabilidades na aplicao web.
Acompanhe a seguir um exemplo com o nmap.
$ sudo nmap -sS -O 200.20.94.130
1
O Network Mapper um softwares mais usados para varreduras de portas. Mais informaes sobre
varreduras podem ser obtidas em: http://nmap.org/book/man-port-scanning-techniques.html
37

Not shown: 952 closed ports, 45 filtered ports
PORT
STATE SERVICE
80/tcp
open http
443/tcp open https
3306/tcp open mysql
Device type: general purpose
Running: Linux 2.6.X
OS CPE: cpe:/o:linux:linux_kernel:2.6
OS details: Linux 2.6.24 - 2.6.36
Network Distance: 12 hops
OS detection performed. Please report any incorrect results at http://nmap.org/submit/ .

4.3
NSE Scripts
O nmap tambm possui a possibilidade de uso de scripts, chamado Nmap Scripting Engine. Esse modo extende o uso da ferramente para algo alm de mapear redes e enumerao
de servios, ele aplica funes de bruteforce, ataques DoS e at mesmo descoberta de vulnerabilidades. Os scripts podem ser escritos e compartilhados por qualquer usurio no objetivo
de automatizar as tarefas dirias.
A linguagem utilizada a Lua, pequena e flexvel, geralmente utilizada para expandir
funes de programas e jogos. Esse post no mostrar como desenvolver os scripts, mas s
como eles so utilizados.
Os scripts por padro ficam no diretrio /usr/local/share/nmap/scripts com a extenso .nse.
4.3.1
Categorias de scripts
Auth: Scripts voltados para tentativa de autenticao ou bypass da mesma.

Broadcast: Realiza uma varredura de broadcast na rede atrs de hosts no listados por
varreduras normais.
Brute: Usam tcnicas de fora-bruta para realizar autenticao de servios.
Default: So os scripts padres do Nmap, utilizado com a opo -sC ou scripts=default.
As opes sero retratadas a seguir.
38

Discovery: Esses scripts realizam varreduras de descoberta na rede, como cabealhos HTML,
detalhes do servio SAMBA, etc.
DoS: Scripts utilizados para realizar negao de servio no alvo.
External: Utilizam aplicaes de terceiros, como consultas ao banco de dados do whois.
Fuzzer: Envia pacotes com dados randmicos para o alvo, a procura de bugs e vulnerabilidades.
Intrusive: No so considerados seguros pois podem derrubar o alvo ou invdi-lo.
Malware: Procura no alvo malwares ou backdoors.
Safe: So considerados scrips que no derrubam servios, no utilizam toda a banda e no
gera nenhum risco ao alvo.
Version: Scripts para detectar verses de servios especficos, como o Skype. S podem ser
usados cada o tipo de scan -sV for requerido.
Vuln: Usados para procurar vulnerabilidades. S so gerados relatrios se elas so encontradas.
4.3.2
Fases
Prerule scripts: So executados antes do Nmap recolher qualquer informao sobre o alvo.
Host scripts: Ocorre durante o processo de varredura, logo depois da varredura de portas,
servios e sistema operacional.
Service scripts: So executados em servios especficos no host.
Postrule scripts: Esses scripts rodam depois que toda a varredura for feita. Geralmente
auxiliam na formatao de relatrios.
Sabendo das informaes acima, vamos fazer uma verificao dos mtodos do protocolo
HTTP que so permitidos no www.cbpf.br.
$ nmap --script=http-methods.nse --script-args http-methods.retest=1 -p80 www.cbpf.br
Nmap scan report for www.cbpf.br (152.84.253.9)
rDNS record for 152.84.253.9: cbpfsu6.cat.cbpf.br
PORT
STATE SERVICE
80/tcp open http
| http-methods: GET HEAD POST OPTIONS
39

| GET / -> HTTP/1.1 200 OK
|
| HEAD / -> HTTP/1.1 200 OK
|
| POST / -> HTTP/1.1 200 OK
|
|_OPTIONS / -> HTTP/1.1 200 OK
40
Captulo 5
Identificao da Aplicao
5.1
Infraestrutura Web
A identificao da infraestrutura web importante para poder determinar por onde os

pacotes com as requisies podem ter passado com a finalidade de determinar alguma forma
de tratamento intermediaria.
Tambm importante pois pode ser possvel encontrar vulnerabilidades nos equipamentos
ou softwares instalados neles.
5.1.1
Load Balancers
O uso de Balanceadores de Carga ou Load Balancers uma realidade muito comum

hoje em aplicaes que necessitam de alta disponibilidade. Seu uso uma questo que deve
ser investigada pois pode causar diversas inconsistncias nos resultados de diversos testes,
principalmente quando os servidores que servem a aplicao possuem caractersticas, como:
gerncia de patches, correo de bugs, verses de software e arquitetura diferentes.
Existem diversas implementaes para prover caractersticas de balanceamento de carga.
Existem balanceamentos de carga com uso de DNS ou com o uso de equipamentos prprios
para esse fim.
Quando o balanceamento realizado atravs do sistema de DNS, relativamente simples
determinar os sistemas que fazem parte do grupo de balanceamento.
Veja a consulta, a seguir, realizada com o dig:
$ dig mail.google.com
; <<>> DiG 9.8.3-P1 <<>> mail.google.com
;; Got answer:
41

;mail.google.com. IN A
;; ANSWER SECTION:
mail.google.com. 296457 IN CNAME googlemail.l.google.com.
googlemail.l.google.com. 85 IN A 74.125.234.54
googlemail.l.google.com. 85 IN A 74.125.234.53
;;
;;
;;
;;

SERVER: 187.100.246.251#53(187.100.246.251)
WHEN: Fri Mar 22 10:20:54 2013
MSG SIZE rcvd: 92
Alm do balanceamento atravs dos sistemas de DNS, possvel realizar o balanceamento

atravs de equipamentos especficos. Esses equipamentos possuem mtodos de balanceamento um pouco mais eficientes, como, por exemplo:
Least Connections -> encaminha a conexo para o servidor com menos conexes
Round Robin -> encaminha a conexo de forma dinmica
Weighted Round Robin -> encaminha a conexo de forma dinmica, atribuindo pesos
para os servidores no grupo
O interessante dessas formas que o pacote chegue ao sistema de destino, sem a interveno do balanceador. Dessa forma com o uso da ferramenta hping3, podemos determinar
atravs do campo IPID. Acompanhe o exemplo a seguir, para mais detalhes.
$ sudo hping3 www.microsoft.com -S -p 80

HPING www.microsoft.com (en1 65.55.57.27): S set, 40 headers + 0 data bytes
len=44 ip=65.55.57.27 ttl=238 DF id=26820 sport=80 flags=SA seq=0 win=8190 rtt=214.7 m
len=44 ip=65.55.57.27 ttl=237 DF id=44411 sport=80 flags=SA seq=1 ...
42

^C
--- www.microsoft.com hping statistic --23 packets tramitted, 23 packets received, 0% packet loss
round-trip min/avg/max = 196.1/236.0/361.5 ms
Porm, nem sempre o balanceador permite tal interao. Muitas vezes o prprio balanceador que estabelece a conexo com o cliente, assim a sada do sistema seria:
$ sudo hping3 mail.google.com -S -p 80
HPING mail.google.com (ppp0 74.125.234.118): S set, 40 headers +
len=44 ip=74.125.234.118 ttl=52 id=18861 sport=80 flags=SA seq=0
^C
--- mail.google.com hping statistic --8 packets tramitted, 8 packets received, 0% packet loss
round-trip min/avg/max = 220.2/307.9/649.7 ms
0 data bytes
...
...
...
...
...
...
...
...
Alm de balancear a carga entre os servidores, por vezes necessrio que o balanceador seja responsvel pelos mtodos de persistncia de conexo. Este ocorre pois diversas
aplicaes necessitam, por exemplo, de autenticao ou de controle de sesso.
Os mtodos de persistncia mais utilizados so:
Persistncia por endereo IP de origem
Persistncia baseada em Cookie
Persistncia baseada no hash da URI
43

5.1.2
WAF
Um firewall de aplicao web (do ingls, Web Application Firewall - WAF) um aparelho,
plugin de servidor, ou filtro que aplica um conjunto de regras para uma conexo HTTP.
Geralmente, essas regras abrangem ataques comuns como Cross-site Scripting (XSS) e SQL
Injection. Ao personalizar as regras para a aplicao em questo, muitos ataques podem ser
identificadas e bloqueadas. O esforo para realizar esta personalizao pode ser significativo
e precisa ser mantido conforme a aplicao modificada.
A deteco de ferramentas WAF tambm pode ser realizada com o uso do nmap. Acompanhe alguns exemplos a seguir.
NSE HTTP-WAF-DETECT
$ nmap -p80,443 --script http-waf-detect www.phpids.org
Starting Nmap 6.01 ( http://nmap.org ) at 2012-10-24 18:16 BRST
Nmap scan report for www.phpids.org (188.40.98.186)
rDNS record for 188.40.98.186: nepal1.itratos.net
PORT
STATE SERVICE
80/tcp open http
443/tcp open https
| http-waf-detect: IDS/IPS/WAF detected:
|_www.phpids.org:443/?p4yl04d3=<script>alert(document.cookie)</script>
NSE HTTP-WAF-FINGERPRINT
$ nmap --script=http-waf-fingerprint <targets>
PORT
STATE SERVICE REASON
80/tcp open http
syn-ack
| http-waf-fingerprint:
|
Detected WAF
|_
BinarySec version 3.2.2
LBMAP
O lbmap1 uma prova de conceito (PoC) e tambm pode ser utilizada para esse fim.
Acompanhe um exemplo a seguir:
1
44
https://github.com/wireghoul/lbmap

mac159275:wireghoul-lbmap-ac964d1 manoel.junior$ ./lbmap login.globo.com
lbmap - http fingerprinting tool
Eldar "Wireghoul" Marcussen - Scanning login.globo.com
$VAR1 = signature;
$VAR2 = 01A2A2--99--99BCA2--A2A2A2A2L3BCA2A2A2BCA2BCBCA2BCBCA2A099--;
$VAR3 = webserver;
$VAR4 = {
Apache => 22
};
Diversos outros exemplos podem ser encontrados atraves, principalmente de apresentacoes em eventos e congressos especializados2 .
5.1.3
Servidores Web
APROF
A ferramenta aprof faz parte da suite da ferramenta lbmap, abordada anteriormente.
Ela permite, alm de identificar o servidor web, tambm permite identificar os mdulos
habilitados na instncia testada.
Veja um exemplo a seguir:
$ ./aprof www.cbpf.br
aprof - Apache profiler script v 0.2
Written by Eldar "Wireghoul" Marcussen - http://www.justanotherhacker.com
Analysing: www.cbpf.br/
Server signature: Apache
Attempting to identify modules:
mod_cgi detected
mod_info (restricted access) detected
mod_php detected
Checking what extensions have php bindings:
.php ... in use
.php3 ... in use
.php4 ... in use
.php5 ... not in use
.phtml ... not in use
.phps ... not in use
mod_status (restricted access) detected
Done!
2
www.defcon.org/images/defcon-16/dc16-presentations/defcon-16-henrique.pdf
http:
//media.blackhat.com/bh-us-12/Briefings/Ristic/BH_US_12_Ristic_Protocol_Level_WP.pdf
45

NMAP
Como j sabemos, a ferramenta NMAP tambm capaz de identificar com preciso
diversas verses de diversos servidores web. Acompanhe, a seguir, um exemplo.
$ sudo nmap -sV -p80,443 www.cbpf.br
Nmap scan report for www.cbpf.br (152.84.253.9)
rDNS record for 152.84.253.9: cbpfsu6.cat.cbpf.br
PORT
STATE SERVICE VERSION
80/tcp open http
Apache
443/tcp open http
Apache
Service Info: Host: www.cbpf.br

5.1.4
Servidores de Banco de Dados
NMAP
Atravs da mesma maneira que identificamos servidores web, podemos identificar servidores de banco de dados. Veja o exemplo a seguir:
$ sudo nmap -sS -sV 200.20.94.130
Not shown: 991 closed ports
PORT
STATE
SERVICE
VERSION
25/tcp
filtered smtp
80/tcp
open
http
135/tcp filtered msrpc
139/tcp filtered netbios-ssn
443/tcp open
ssl/http
445/tcp filtered microsoft-ds
593/tcp filtered http-rpc-epmap
3306/tcp open
mysql
MySQL 5.1.47
4444/tcp filtered krb524

46

5.2
5.2.1
Verses e Configuraes
Google Hacking
O GHDB ou Google Hacking Database um projeto que visa colecionar padres de busca
que, ao serem usadas no buscador do Google podem revelar informaes importantes sobre
determinado domnio.
Ele pode ser acessado atravs da URL http://www.hackersforcharity.org/ghdb/. No
site, possvel encontrar de forma organizada e categorizada como pesquisar no buscador do
Google determinadas informaes.
Um exemplo de informaes interessantes que podem ser obtidas com buscas usando
padres no GHDB como encontrar arquivos com possveis nomes de usurios. Basta ir
em Files containing usernames, e procurar o arquivo de interesse. Na terceira coluna,
possvel obter a sintaxe de procura no buscador do Google.
Embora o site seja bem organizado, existe uma iniciativa bem parecida que se chama
Google Dorks. Ela pode ser acessada atravs da URL http://www.exploit-db.com/
google-dorks/. No momento da redao desse resumo, ela estava mais atualizada que a
anterior.
5.2.2
Anlise do SSL
A anlise dos certificados SSL pode ser til para determinar possveis vulnerabilidades
tanto na aplicao, quanto no certificado emitido.
Veja, na imagem 5.1, um relatrio3 da ferramenta SSL Labs4 , da Qualys.
Embora no seja possvel ver os detalhes do relatrio na imagem, j podemos examinar
que o certificado SSL est sucetvel ao Ataque BEAST5 e que ele no atente completamente
nenhum dos quatro requisitos avaliados.
5.3
Verificando Virtual Hosts
Um Virtual Host uma maneira de servir mltiplos sites em um mesmo servidor fsico.
Essa tcnica utilizada na configurao do servidor web, no sendo portanto, uma virtualizao. Esta tcnica, geralmente, utilizada para alocar melhor os recursos e diminuir custos
com a hospedagem de sites, mas tambm apresenta problemas quanto a segurana, pois em
caso de uma vulnerabilidade no servidor, todos os sites estaro espostos a ela.
Existem duas formas de realizar Virtual Hosting. Elas so atravs de um nico endereo IP que serve todos os sites ou vrios endereos IP, um endereo para cada site, todos
associados no mesmo servidor.
3
Disponvelem:https://www.ssllabs.com/ssltest/analyze.html?d=p0m1.cat.cbpf.br
www.ssllabs.com
5
Mais informaes em:
https://community.qualys.com/blogs/securitylabs/2011/10/17/
mitigating-the-beast-attack-on-tls
4
47

Figura 5.1: Anlise do Certificado SSL do email do CBPF

Para realizar a identificao, basta fazer consultas de DNS. Podemos realizar a ferramenta
online Robtex 6 para agilizar a consulta. Acompanhe o exemplo na imagem 5.2.
5.4
Usando Nikto
Nikto 7 um scanner de servidor web que realiza testes abrangentes contra servidores para
identificar vrios itens, incluindo mais de 6.500 arquivos/CGIs potencialmente perigosos,
cheques de verses desatualizadas de mais de 1250 servidores, e os problemas especficos de
verso em mais de 270 servidores. Ele tambm verifica a existncia de itens de configurao
do servidor, tais como a presena de vrios arquivos de ndice, opes do servidor HTTP, e
vai tentar identificar o servidores web e o software instalado. Itens de verificao e plugins
so atualizados com freqncia e podem ser atualizado automaticamente.
Nikto no foi concebido como uma ferramenta muito furtiva. Ele ir testar um servidor
web no tempo mais rpido possvel, e bastante bvio em arquivos de log. No entanto, h
suporte para Libwhisker 8 , que usa mtodos anti-IDS no caso de voc querer experiment-lo
6
Disponvel em: http://robtex.com/

Disponvel em: http://www.cirt.net/nikto2
8
Disponvel em: http://sourceforge.net/projects/whisker/
7
48

Figura 5.2: Endereo IP servindo varios domnios

(ou testar seu sistema IDS).
Nem toda verificao um problema de segurana, embora a maioria seja. Existem alguns
itens que so apenas "informativos"verificaes desse tipo servem para averiguar coisas que
podem no ter uma falha de segurana, mas o webmaster ou o engenheiro de segurana pode
no saber esto presentes no servidor. Esses itens so geralmente marcados apropriadamente
na informao impressa.
Acompanhe a seguir um exemplo de uso da ferramenta Nikto em sua configurao padro.
49

$ sudo ./nikto.pl -host www.cbpf.br
- Nikto v2.1.5
--------------------------------------------------------------------------+ Target IP:
152.84.253.9
+ Target Hostname:
www.cbpf.br
+ Target Port:
80
+ Start Time:
2013-03-22 12:06:16 (GMT-3)
--------------------------------------------------------------------------+ Server: Apache
+ The anti-clickjacking X-Frame-Options header is not present.
+ OSVDB-637: Enumeration of users is possible by requesting ~username (responds with Fo
+ Server leaks inodes via ETags, header found with file /favicon.ico, inode: 75112357, s
+ Allowed HTTP Methods: GET, HEAD, POST, OPTIONS
+ /global.asa: The global.asa file was retrieved, which may contain sensitive informatio
+ OSVDB-3092: /_vti_pvt/deptodoc.btr: FrontPage file found. This may contain useful info
+ OSVDB-473: /_vti_pvt/botinfs.cnf: FrontPage file found. This may contain useful inform
+ OSVDB-473: /_vti_pvt/bots.cnf: FrontPage file found. This may contain useful informati
+ OSVDB-473: /_vti_pvt/service.cnf: Contains meta-information about the web server Remov
+ OSVDB-473: /_vti_pvt/writeto.cnf: Contains information about form handler result files
+ OSVDB-3268: /pdf/: Directory indexing found.
+ OSVDB-3268: /dir/: Directory indexing found.
+ OSVDB-3092: /dir/: This might be interesting...
+ Cookie PHPSESSID created without the httponly flag
+ Retrieved x-powered-by header: PHP/5.3.8
+ 6544 items checked: 4961 error(s) and 15 item(s) reported on remote host
+ End Time:
2013-03-22 12:24:34 (GMT-3) (1098 seconds)
--------------------------------------------------------------------------+ 1 host(s) tested
5.5
Spidering
O nosso objetivo o de criar um mapa da aplicao com todos os pontos de acesso para
a aplicao. Isto ser til para a segunda fase do teste de penetrao. Voc pode usar uma
ferramenta como o wget 9 para recuperar todas as informaes publicadas pela aplicao.
Acompanhe o exemplo a seguir, onde mapeamos o cabealho:
$ wget -S www.cbpf.br
--2013-03-22 12:08:51-- http://www.cbpf.br/
Resolving www.cbpf.br (www.cbpf.br)... 152.84.253.9
Connecting to www.cbpf.br (www.cbpf.br)|152.84.253.9|:80... connected.
HTTP request sent, awaiting response...
9
50
Disponvel em: http://www.gnu.org/software/wget/

HTTP/1.1 200 OK
Date: Fri, 22 Mar 2013 15:07:58 GMT
Server: Apache
Accept-Ranges: bytes
Content-Length: 266
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html
Length: 266 [text/html]
Saving to: index.html
100%[======================================>] 266
--.-K/s
in 0s
2013-03-22 12:08:52 (10.6 MB/s) - index.html saved [266/266]

O ideal ao utilizar o wget e especificar o parmetro -r de modo a realizar consultas
recursivas.
Mais adiante no captulo 7, veremos como executar o Spidering de forma mais automatizada.
5.6
Fluxograma de funcionamento
Nessa etapa, devemos focar na identificao dos componentes da aplicao. Mapear o

fluxo da aplicao importante para prover um melhor entendimento de como a aplicao
funciona inteiramente. O fluxo da aplicao dever deixar de forma clara a relao entre as
partes da aplicao, como eles interagem e identificar possveis interfaces de ataque.
Veja um exemplo de mapeamento de fluxo na imagem 5.3.
5.7
Identificao dos pontos de entrada de informao
A enumerao de um aplicativo e sua superfcie de ataque um passo chave antes que

qualquer teste completo possa ser realizado, pois permite identificar as reas susceptveis
a falhas. Esta seo tem como objetivo ajudar a identificar e mapear essas reas dentro
da aplicao que deve ser investigada, uma vez que a enumerao e o mapeamento foram
concludos.
Antes do incio de qualquer teste, sempre importante obter um bom entendimento da
aplicao e como o usurio ou browser se comunica com ele. Ao navegar pela aplicao,
preste ateno especial a todas as solicitaes HTTP ( mtodos GET e POST), bem como
todos os parmetros e campos de formulrios que so passados para a aplicao. Alm disso,
preste ateno quando requisies GET so usados e quando as solicitaes POST so usadas
para passar parmetros para a aplicao.
51

Figura 5.3: Fluxo de uma aplicao web

muito comum ter grande parte das solicitaes GET, mas quando uma informao
sensvel passada, muitas vezes feito dentro do corpo de uma solicitao POST. Note-se
que para ver os parmetros enviados em uma solicitao POST, voc precisar usar uma
ferramenta como um proxy de interceptao (por exemplo, OWASP ZAP ) ou um plug-in
para o navegador. Dentro da solicitao POST, tambm faa uma nota especial de todos
os campos de formulrio hidden que esto sendo passados para a aplicao, pois estes
geralmente contm informaes sensveis, tais como informaes de estado, quantidade de
itens, o preo de itens, campos que o desenvolvedor no quer que o usurio veja ou modifique.
Uma dica muito til usar um proxy de interceptao e uma planilha para esta fase do
teste. O proxy ir acompanhar cada pedido e resposta entre voc e a aplicao. Alm disso,
neste momento, comum se prender a cada solicitao e resposta de modo que se possa ver
exatamente cada cabealho, parmetro, etc, que est sendo passado para a aplicao e que
est sendo devolvido para o usurio. Isso pode ser bastante tedioso s vezes, especialmente
em grandes sites interativos (como em uma aplicao bancria). No entanto, a experincia
vai lhe ensinar o que procurar, e, portanto, esta fase pode ser reduzida significativamente.
Conforme voc navega pela da aplicao, tome nota de todos os parmetros interessantes
na URL, cabealhos personalizados, ou corpo das requisies ou respostas, e salve-os na
planilha. A planilha deve incluir a pgina que voc solicitou (que pode ser bom tambm para
adicionar o nmero de pedido doproxy, para futura referncia), os parmetros de interesse,
o tipo de solicitao (POST ou GET), se o acesso autenticado ou no autenticado, se SSL
usado, se parte de um processo de vrias etapas, e quaisquer outras notas relevantes.
Depois de ter todas as reas de aplicao traadas, ento voc pode ir at o aplicativo e
52

testar cada uma das reas que voc identificou e fazer anotaes para o que funcionou e o
que no funcionou. O restante deste guia vai identificar como testar cada uma dessas reas
de interesse, mas esta seo devem ser realizadas antes de qualquer teste real pode comear.
A seguir, esto alguns pontos de interesse para todos as requisies e respostas. Dentro
da seo de requisies, o foco sobre os mtodos GET e POST, como estes aparecem na
maioria das requisies. Note-se que outros mtodos, tais como PUT e DELETE, podem
ser usados. Muitas vezes, estes pedidos mais raros, se forem permitido, podem expor mais
vulnerabilidades.
5.7.1
Requisies
1. Identificar onde GETs so usados e onde POSTs so usados.

2. Identificar todos os parmetros utilizados num pedido POST (estes esto no corpo do
pedido).
3. Dentro da solicitao POST, preste ateno especial a quaisquer parmetros do tipo
hidden. Quando um POST enviado, todos os campos do formulrio (incluindo
parmetros ocultos) sero enviado no corpo da mensagem HTTP para a aplicao.
Estes geralmente no so vistos, a menos que voc est usando um proxy ou visualizar
o cdigo fonte HTML. Alm disso, a pgina seguinte pode ver os dados, e o seu acesso
podem ser diferente, dependendo do valor do parmetro escondido(s).
4. Identificar todos os parmetros utilizados em uma solicitao GET (ou seja, URL), em
uma determinada sequncia
5. Identificar todos os parmetros da cadeia de consulta. Estes geralmente so em pares,
como foo = bar. Observe tambm que muitos parmetros podem surgir em uma
sequncia, como separados por um &, ,:, ou qualquer outro carcter especial ou de
codificao.
6. Uma nota especial quando se trata de identificar vrios parmetros numa cadeia ou
num pedido POST, identificar todos os parmetros necessrios para executar os
ataques. Voc precisa identificar todos os parmetros (mesmo que estejam codificado
ou criptografados) e identificar quais so processados pela aplicao.
7. Tambm preste ateno a qualquer tipo cabealhos adicionais ou que no sejam tipicamente vistos (como debug = False).
5.7.2
Respostas
1. Identificar onde os cookies so definidos (cabealho Set-Cookie), modificados, ou adicionados.

53

2. Identificar onde h qualquer redirecionamento (cdigo de status HTTP 300), cdigos
de status (400), em especial: 403 (Forbidden) e erros internos do servidor (500) durante
respostas normais (ou seja, os pedidos no modificados).
3. Observe tambm que cabealhos interessantes podem ser usados. Por exemplo, Server:
BIG-IP"indica que o site utiliza load balance. Assim, se um site possui balanceamento
de carga e um servidor est configurado incorretamente, ento voc pode ter que fazer
vrias solicitaes para acessar o servidor vulnervel, dependendo do tipo de balanceamento de carga utilizado.
54
Captulo 6
Identificao de Vulnerabilidades
O processo de descoberta de vulnerabilidade, se assemelha ao processo de descoberta de
informao, sendo que nesse momento, a aplicao web passa a receber trfego malicioso.
Logo aps a descoberta da vulnerabilidade pode-se dar inicio a fase de explorao delas.
A seguir, veremos alguns mtodos de identificao de vulnerabilidade e logo aps seus
tipos e como identific-las.
6.1
Mtodos de Identificao
O principal mtodo de identificao de vulnerabilidades atravs do uso de ferramentas

automatizadas que realizam diversos testes e apontam os problemas encontrados para uma
verificao manual.
Os softwares usados para realizar buscas por vulnerabilidades em aplicaes Web so
diferentes dos softwares utilizados para buscas por vulnerabilidades em redes ou sistemas.
Isso ocorre pois as ferramentas que buscam vulnerabilidades em redes e sistemas manipulam
e enviam o trfego de rede de maneira a determinar se o sistema est vulnervel ou no com
base nas respostas fornecidas pelo sistema.
No caso de uma aplicao web, o software necessita se adequar a estrutura da aplicao,
alm de conseguir mapear os pontos onde seria possvel inserir informaes na aplicao.
Alm disso, com base nas informaes recolhidas, ele dever selecionar os possveis ataques
e execut-los, observando sua resposta para poder executar outros.
Geralmente, so executados scripts adicionais e, ao invs de usar apenas uma ferramenta
para realizar a busca por vulnerabilidades, so executadas uma suite de ferramentas. A ideia
por trs disto, utilizar as melhores caractersticas de cada ferramenta de forma a obter um
resultado mais relevante em algumas reas.
6.1.1
Ferramentas
Existem diversas ferramentas que podem automatizar a busca por vulnerabilidades em

sistemas. Vamos apresentar um pouco das caractersticas de algumas delas a seguir.
55

OWASP Zed Attack Proxy
O OWASP ZAP uma ferramenta open-source para busca de vulnerabilidades em aplicaes web.
Algumas de suas funes incluem:
1. Proxy de Interceptao
2. Scanner ativo e passivo
3. Scanner por fora-bruta
4. Spider
5. Fuzzer
6. Scanner de Portas
7. Ceritificados SSL dinmicos
8. API
9. Integrao com o Beanshell
10. Suporte para SmartCards
Algumas caractersticas do ZAP:
1. Fcil de instalar (requer Java)
2. Abrangentes pginas de ajuda
3. Totalmente internacionalizado
4. Em desenvolvimento ativo (em 2012)
5. Open-source
6. Multi-plataforma
Acompanhe na imagem 6.1 a tela de apresentao do ZAP.
56

Figura 6.1: Tela de apresentao do OWASP ZAP

Burp Suite
Burp Suite uma plataforma integrada para a realizao de testes de segurana de
aplicaes web. Suas vrias ferramentas trabalham em conjunto para apoiar o processo
de teste completo, desde o mapeamento inicial e anlise de superfcie de um aplicativo de
ataque, at encontrar e explorar vulnerabilidades de segurana.
O Burp lhe d total controle, permitindo combinar avanadas tcnicas manuais com o
estado-da-arte da automao, para tornar seu trabalho mais rpido, mais eficaz, e mais
divertido.
O Burp Suite contm os seguintes componentes-chave:
1. Um proxy de interceptao, que permite inspecionar e modificar o trfego entre o
navegador e o aplicativo de destino.
2. Spider, para rastreamento de contedo e funcionalidade.
3. Um scanner de aplicao web, para automatizar a deteco de vrios tipos de vulnerabilidade.
4. Uma ferramenta Intruder, para a realizao de poderosos ataques personalizados para
encontrar e explorar vulnerabilidades incomuns.
57

5. Uma ferramenta Repeater, para manipular e reenviar pedidos individuais.
6. Uma ferramenta Sequencer, para testar a aleatoriedade de tokens de sesso.
7. A capacidade de salvar o seu trabalho e continuar a trabalhar mais tarde.
8. Extensibilidade, permitindo que voc facilmente escrever seus prprios plugins, para
executar tarefas complexas e altamente personalizada dentro Burp Suite.
Acompanhe na imagem 6.2 a tela de apresentao do Burp Suite.
Figura 6.2: Tela de apresentao do Burp Suite
6.2
Tipos de Vulnerabilidades
A seguir, acompanharemos alguns tipos de vulnerabilidades que podem ser encontradas

em aplicaes web. Essas vulnerabilidades estaro categorizadas em grupos de acordo com
58

algumas de suas caractersticas, o que no significa que cada uma pertena a somente o
grupo que est alocado nesta seo.
Essa seo est organizada fornecendo para cada categoria uma descrio e para cada
vulnerabilidade uma breve explicao de sua ocorrncia, com um exemplo e tambm com
medidas para mitig-las.
6.2.1
Exposio de Informao
Esta categoria para vulnerabilidades que protegem dados sensveis de maneira insegura.
A proteo referida aqui inclui a confidencialidade e integridade dos dados durante seus ciclos
de vida, incluindo o armazenamento e transmisso dos dados.
Note que esta categoria destina-se a ser diferente de problemas de controle de acesso,
embora ambos falham para proteger os dados de forma apropriada. Normalmente, o objetivo
do controle de acesso a concesso de acesso a dados para alguns usurios, mas outros no.
Nesta categoria, estamos em vez preocupado com a proteo de dados sensveis que no se
destinam a ser revelado ou modificados por qualquer usurio da aplicao. Exemplos deste
tipo de dados sensveis podem ser chaves de criptografia, senhas, tokens de segurana ou
qualquer informao crtica de uma aplicao.
Comentrios HTML e versionamento
Comentrios em HTML ou informaes de versionamento podem expor informaes importantes sobre a aplicao, que, de certa maneira, podem acrescentar informaes para
viabilizar a descoberta de uma vulnerabilidade de maior gravidade.
Impacto As informaes contidas em comentrios HTML podem levar a descoberta de
itens como:
o fluxo de funcionamento da aplicao
rotinas de verificao de contedo
os mtodos de controle de sesso
observaes sobre a codificao
verses de frameworks de apoio utilizados
Exemplos Veja um exemplo na imagem 6.3.
Medidas Inspecione o cdigo da aplicao e dos templates buscando por comentrios
que possam ser impressos no cdigo HTML. interessante buscar tambm por possveis
comentrios em funes de debug ou que venham a descrever erros.
59

Figura 6.3: Comentrios HTML e versionamento

Base de dados locais
Base de dados locais podem expor completamente os dados armazenados na aplicao
web. Embora seja muito comum o uso de bancos SQLite devido sua simplicidade de implementao e manuteno, muitas vezes a proteo dos recursos do banco no so to bem
protegidos.
Impacto Um atacante com posse de uma base de dados pode, caso tenha sido encriptada,
realizar ataques de fora bruta localmente com a finalidade de descobrir os dados.
Caso consiga acesso a uma base sem criptografia, ou consiga descriptografar uma, ele
poder fazer uso indiscriminado dos dados nela, podendo assim, usar os dados para cometer
grande parte dos tipos de incidentes possveis, como:
Roubo de informaes pessoais, que podem ser usadas para compras, por exemplo
Acesso a informaes de configurao da aplicao
Acesso a estrutura interna da aplicao, entre outros acessos.
Medidas Realizar a proteo dos arquivos de base de dados atravs da configurao do
servidor web uma das possveis medidas. O uso de bases locais desencorajado, devido,
alm dos problemas de segurana, a problemas de performance.
60

Mensagens de Erro e de Exceo
Essa vulnerabilidade ocorre quando a aplicao web no realiza o tratamento adequado
das mensagens de erro geradas e, consequentemente, acaba expondo informaes da tecnologia e do ambiente usado no sistema. Analisando as informaes retornadas, possvel
identificar falhas na aplicao e mapear a estrutura interna da aplicao, por exemplo.
Impacto Diversas mensagens de erro podem ser expostas ao usurio de forma detalhada.
Dependendo da mensagem de erro, podem ser obtidos:
erros da aplicao
erros em requisies da aplicao
erros de componentes da aplicao
informaes sobre a arquitetura da aplicao
Figura 6.4: Mensagens de Erro e de Exceo

Medidas Recomenda-se remover as mensagens de erro da aplicao e o detalhamento de
erros. Isso pode ser feito, adicionando uma mensagem de erro genrica ou retornar a aplicao
para a sua pgina raiz.
Indexao de Diretrio e Leitura de Arquivos Locais (Local File Read)
Essa vulnerabilidade permite que diretrios e arquivos internos da aplicao fiquem acessveis externamente.
61

Impacto Esses arquivos internos da aplicao podem revelar informaes internas do servio ou do ambiente que podem ser utilizadas para a elaborao de ataques mais sofisticados.
Alm disso, informaes internas sobre o funcionamento da aplicao web podem ser descobertas ou divulgadas fora do previsto.
Figura 6.5: Indexao de Diretrio

Medidas O acesso a recursos desnecessrios do ambiente deve ser bloqueado. A listagem
de diretrios deve ser desativada no servidor web e sees com informaes internas da
aplicao devem estar restritas.
Descoberta de Path
A vulnerabilidade de Descoberta de Path ou Descoberta de Caminho permite a um
indivduo mal-intencionado saber em qual diretrio se encontram os arquivos da aplicao
Web. Algumas vulnerabilidades, como as que usam a funo load_file() podem permitir
a visualizao do cdigo da pgina, mas para isso o atacante tem que conhecer o caminho
completo do recurso que deseja acessar.
62

Mais informaes em podem ser obtidas em: https://www.owasp.org/index.php/Full_
Path_Disclosure e uma ferramenta para descoberta de path pode ser obtida em: https:
//code.google.com/p/inspathx/.
Impacto Atacantes podem abusar do conhecimento, por exemplo da raiz onde se encontra
o diretrio web, e us-lo em combinao com outras vulnerabilidades, como Leitura de Arquivos Locais para roubar arquivos de configurao da aplicao web ou do resto do sistema
operacional.
Medidas Recomenda-se remover as mensagens de erro da aplicao e o detalhamento de
erros. Isso pode ser feito, adicionando uma mensagem de erro genrica ou retornar a aplicao
para a sua pgina raiz.
Recomenda-se tambm o uso de bibliotecas seguras, que, por padro, no imprimam
mensagens e sim retornem cdigos de erro.
Incluso de Arquivos Remotos (Remote File Inclusion)
A Incluso de Arquivos Remotos uma das vulnerabilidades mais procuradas nos servidores web atualmente. Isso ocorre pois atravs dele, um indivduo mal-intencionado pode:
Realizar execuo de cdigo no servidor web
Executar cdigo client-side como um JavaScript, que pode levar a outros ataques, como
XSS
Causar Negao de Servio (DoS)
Pode realizar manipulaes nas informaes fornecidas
Impacto Alm de expor completamente informaes e contedo da aplicao, uma vulnerabilidade de Incluso de Arquivos Remota pode expor tambm todos os servios executados
no servidor por permitir a incluso de um arquivo que pode ser um shell via web1 .
Medidas Algumas medidas como:
Nunca use includes baseados em informaes fornecidas pelo usurio. Quando for o
caso, no use if/elseif/else use switch/case.
Independente dos dados, faa sempre trimming das strings de include, procurando
por http, /, //
Desabilite as opes registrer_global, allow_url_fopen e allow_url_include no arquivo
php.ini
Valide fortemente os dados fornecidos pelos usurios
1
Um exemplo de shell pode ser encontrado em http://laudanum.inguardians.com/
63

Path Traversal e Null Bytes
A vulnerabilidade de Path Traversal permite ao atacante acessar arquivos e diretrios
que so armazenados fora da pasta raiz da web. Ao navegar no aplicativo, o atacante procura
por links absolutos para arquivos armazenados no servidor web. Assim, eles manipulam o
valor das variveis para arquivos de referncia com ponto-ponto-barra (../)"sequncias e
suas variaes, verificando se possvel acessar arquivos arbitrrios e diretrios armazenados
no sistema de arquivos.
Impacto Um atacante explorando esse ataque pode ter acesso a informaes que podem
elevar seu privilgio e comprometer toda a aplicao.
Os dados que podem ser obtidos so:
cdigo fonte do aplicativo
configurao
arquivos do sistema
Este ataque pode ser executado com um cdigo externo malicioso injetado no caminho,
como um ataque de injeo de recursos. Para executar este ataque no necessrio o uso
de uma ferramenta especfica; atacantes costumam usar um rastreador/spider para detectar
todas as URLs disponveis.
Exemplos
http://some\_site.com.br/get-files.jsp?file=report.pdf
http://some\_site.com.br/get-page.php?home=aaa.html
http://some\_site.com.br/../../../../etc/shadow
http://some\_site.com.br/get-files?file=/etc/passwd
Medidas Algumas medidas como:
Independente dos dados, faa sempre trimming das strings de include, procurando
por http, /, //
Desabilite as opes registrer_global, allow_url_fopen e allow_url_include no arquivo
php.ini
Valide fortemente os dados fornecidos pelos usurios
Veja se existe a possibilidade de executar o servidor web em chroot2
2
Exemplo de implementao em: http://www.debian.org/doc/manuals/securing-debian-howto/
ap-chroot-apache-env.en.html
64

Injees
Falhas de injeo permitem que atacantes insiram cdigo malicioso atravs de uma aplicao web para outro sistema. Estes ataques incluem chamadas para o sistema operacional
atravs de chamadas do sistema, e tambm no uso de programas externos atravs de comandos de shell, bem como chamadas para back-ends de bancos de dados atravs de SQL (ou
seja, injeo de SQL). Geralmente scripts escritos em PHP, Perl, Python e outras linguagens
podem ser vulnerveis a contedo injetado quando usados em aplicaes web mal concebidas ou executadas. Toda vez que uma aplicao Web usa uma linguagem interpretada de
qualquer tipo existe o perigo de um ataque de injeo.
Muitas aplicaes Web usam recursos do sistema operacional e programas externos para
executar suas funes. O Sendmail provavelmente o programa mais frequentemente invocado externamente, mas muitos outros programas so usados tambm. Quando uma aplicao web passa informaes a partir de uma solicitao HTTP atravs como parte de um
pedido externo, este deve ser cuidadosamente validado e limpo. Caso contrrio, um atacante
pode injetar (meta)-caracteres ou caracteres especiais, comandos maliciosos, ou modificadores de comando para que a aplicao web, cegamente, transmita-os para o sistema externo
para execuo.
A Injeo de SQL uma forma particularmente comum e perigosa de injeo. Para
explorar uma falha de injeo SQL, o atacante deve encontrar um parmetro que a aplicao
web passa atravs de um banco de dados. Com cuidado, um atacante pode incorporar
comandos SQL maliciosos no contedo do parmetro, assim, o atacante pode enganar o
aplicativo web e encaminhar uma consulta maliciosa ao banco de dados.
Impacto Ataques de injeo podem ser descobertos e explorados de forma fcil, mas tambm podem ser extremamente obscuros. As consequncias do ataque podem pertencer a
uma gama de gravidade, do trivial at o comprometimento do sistema ou sua destruio.
Em qualquer caso, o uso de chamadas externas bastante difundida, por isso a probabilidade
de uma aplicao web com uma falha de injeo deve ser considerada elevada.
Medidas Para contornar esse problema, a principal recomendao realizar uma validao
de todos os dados de entrada, principalmente no lado do servidor, a fim de evitar a utilizao
de caracteres maliciosos. A validao de dados realizada somente no lado do cliente pode
ser facilmente contornada copiando a pgina e removendo o cdigo de validao, geralmente
feito em javascript3 .
Para realizar a filtragem dos dados recomenda-se utilizar uma abordagem positiva, que
consiste em negar todas as entradas com exceo dos dados previamente escolhidos. Por
exemplo, no h necessidade de um campo do tipo data no formulrio receber entradas com
valores diferentes de nmeros e talvez barras / (para separar dia, ms e ano). Dessa forma,
3
Informaes em: http://pt.wikipedia.org/wiki/JavaScript
65

Figura 6.6: Injees

o desenvolvedor no ter que adivinhar ou atualizar todas as formas de entradas maliciosas
para negar todos os caracteres especficos.
6.2.2
Configuraes e Manuteno
Arquivos de configurao
A vulnerabilidade relacionada a arquivos de configurao se concentra principalmente
nas informaes fornecidas por eles e o quanto isso pode impactar nos ativos da organizao
caso alguma brecha de segurana possa ser encontrada devido o no cumprimento de uma
boa prtica de configurao segura.
Impacto Informaes que podem ser encontradas em arquivos de configurao, podem
dizer respeito a:
informaes para acesso a servios externos (banco de dados, servios de log, etc)
comentrios sobre configuraes
verses de software, como ltima atualizao ou referncias externas
Medidas O cumprimento de boas prticas de segurana e recomendaes de configurao
feitas pelo fabricante desejado. necessrio verificar sempre se os arquivos de configurao
da aplicao esto protegidos contra acesso externo e tambm acesso interno de recursos no
autorizados da prrpia aplicao.
66

Arquivos de Backup ou de verses antigas
Enquanto a maioria dos arquivos em um servidor web so manuseados diretamente pelo
prprio servidor, no incomum encontrar arquivos sem referncia e/ou esquecidos que
podem ser usados para obter informaes importantes sobre qualquer infra-estrutura ou as
credenciais.
Os cenrios mais comuns incluem a presena de verses antigas renomeadas de arquivos
modificados, arquivos de incluso que so carregados para a lngua de escolha e pode ser
baixado como fonte, ou at mesmo backups automticos ou manuais em forma de arquivos
compactados. Os arquivos de backup tambm podem ser gerados automaticamente pelo
sistema de arquivos e estarem junto dos arquivos originais.
Impacto Todos esses arquivos podem conceder o acesso a um indivduo mal-intencionado
as funcionalidades internas da aplicao, backdoors, interfaces administrativas, ou at mesmo
as credenciais para se conectar interface administrativa ou o servidor de banco de dados.
Medidas Para garantir uma estratgia de proteo eficaz, o teste deve ser agravado por
uma poltica de segurana que probe claramente prticas perigosas, tais como:
Edio local dos arquivos da aplicao web. Este um hbito ruim, uma vez que
provvel que se gerem arquivos de backup dos editores. incrvel ver como muitas
vezes isso feito, mesmo em grandes organizaes. Se voc precisa editar arquivos
em um sistema de produo, voc precisa garantir que no est deixando nada que
absolutamente previsto para trs.
Verifique cuidadosamente qualquer outra atividade realizada em sistemas de arquivos
expostos pelo servidor web, tais como atividades de administrao local. Por exemplo,
se voc ocasionalmente precisa tirar um snapshot de alguns diretrios (que voc no
deve, em um sistema de produo ...), voc pode pensar em compact-los primeiro.
Tenha cuidado para no esquecer de retirar esses arquivos compactados!
Polticas de gesto e de configurao devem ajudar a no deixar soltos arquivos obsoletos e sem referncia.
Arquivos de dados, arquivos de log, arquivos de configurao, etc, devem ser armazenadas em diretrios no acessveis pelo servidor web, para contrariar a possibilidade
de divulgao de informaes (para no mencionar a modificao de dados se as permisses de diretrio web permitem escrever ...).
Instantneos do sistema de arquivos no devem ser acessveis via web, se a pasta raiz
da sua configurao do servidor web no permitir isso, configure o servidor web para
negar o acesso a esses arquivos, por exemplo.
67

Acesso Externo Interface de Administrao
Interfaces administrativas so um dos poucos controles dentro do Guia de Desenvolvimento, que legalmente obrigatria (dentro dos EUA). Para organizaes que desejam seguir
as normas SOX e ISO 17799, elas exigem que funes administrativas sejam separadas das
funcionalidades normais, pois um controle chave de fraudes.
Ao projetar aplicaes, necessrio mapear as funcionalidade administrativas e assegurar
que os controles de acesso e de auditoria so apropriados e esto em seu devido lugar.
Essa vulnerabilidade depende da poltica de segurana implementada, mas uma boa
prtica manter a interface de administrao sempre de maneira bem restrita.
Impacto O acesso no controlado a interface de administrao pode expor a aplicao a
diversos tipos de ataques, como ataques de fora bruta. Tentativas de explorao visando
contornar os mecanismos de autenticao, entre outros riscos.
Figura 6.7: Acesso Externo Interface de Administrao
Medidas Recomenda-se que a interface de administrao da aplicao web seja segregada

e com acesso restrito somente aos administradores da aplicao. Usurios da aplicao no
so administradores logo o acesso deles a interface de administrao no necessrio.
68

Quebra de Autenticao e Roubo de Sesso
Gerenciamento de autenticao e de sesso inclui todos os aspectos da manipulao de
autenticao de usurios e gerenciamento de sesses ativas.
O Gerenciamento de autenticao um dos fatores crticos de uma aplicao, em conjunto
com seus mecanismos, como, por exemplo, o Esqueci minha senha ou Lembre-me minha
senha e os mecanismos para alterao de senhas.
Ataques aos mecanismos de autenticao em aplicaes web so previstos e uma boa
prtica que todas as funes de gerenciamento de contas devem requerer re-autenticao,
mesmo na presena de outros mecanismos de segurana.
As aplicaes web tambm devem estabelecer sesses para acompanhar o fluxo de pedidos
de cada usurio. Como o HTTP no fornece esse recurso, a aplicao deve se encarregar
dele, e tambm deve fornecer meios de controlar o fluxo de requisies de seus usurios. Uma
alternativa a utilizao de tokens de sesso, mas muitos desesnvolvedores usam mtodos
prprios que permitemou que no sejam fortes o suficientes, de forma a manter a aplicao
vulnervel.
A menos que todas as credenciais de autenticao e identificadores de sesso sejam protegidos com SSL em todas as vezes, e tambm protegidos contra a divulgao de outras falhas,
tais como cross site scripting, um atacante pode seqestrar uma sesso do usurio e assumir
sua identidade.
Impacto Tais falhas podem permitir que algumas ou at mesmo todas as contas possam
ser atacadas. Uma vez bem sucedido, o atacante detem todas as credenciais e premisses de
sua vtima. Contas privilegiadas so freqentemente alvo desses ataques.
Medidas Para a proteo do ambiente, necessrio tomar algumas medidas como:
o uso de senhas fortes pelos usurios
a definio de uma poltica de senha, que possua a capacidade de bloquear o login do
usurio depois de certo nmero de conexes falhas
mecanismos de controle de mudanas, onde as funes relacionadas com o gerenciamento de contas sempre exijam a re-autenticao do usurio
armazenamento seguro das senhas, onde as senhas sero armazenadas com o uso de
um algoritmo de hash criptogrfico forte
proteo das credenciais em transito, onde as credenciais utilizadas so enviadas para
o usurio de forma segura
proteo do session ID ou do Identificador de Sesso de modo que, se alguma outra
pessoa no autorizado tiver posse dele, essa pessoa no consiga asssumir a identidade
de outra pessoa
69

no permita a enumerao das contas disponveis
remova todos os cdigos de demonstrao disponveis
elabore trinhas de auditoria e logs compretos do uso administrativo da aplicao
HTTP Response Splitting
A vulnerabilidade conhecida como HTTP Response Splitting proveniente de uma falha
da aplicao ou do seu ambiente quando ele no higieniza adequadamente os valores de
entrada.
O ataque consiste em fazer o servidor imprimir um carriage return (CR, ASCII 0x0D) e
um avano de linha (LF, ASCII 0x0A) seguido do contedo fornecido pelo atacante na seo
de cabealho da sua resposta, normalmente, incluindo-os em campos de entrada enviados
para a aplicao. De acordo com a norma HTTP (RFC 2616), os cabealhos so separados
por um CRLF e os cabealhos da resposta so separados a partir do seu corpo por dois. Portanto, falhando ao remover CRs e LFs, a aplicao permite que o atacante defina cabealhos
arbitrrios, assuma o controle do corpo, ou quebre a resposta em duas ou mais.
Impacto Um atacante em posse de uma vulnerabilidade de HTTP Response Splitting
obtem praticamente o controle total do que ser exibido para o cliente.
Os ataques que podem ser efetuados so:
Cross-site scripting (XSS)
Defacement
Envenenamento de cache
Hijacking, entre outros semelhantes
Medidas A soluo genrica codificar strings na URL antes da incluso no cabealhos
HTTP, como nos campos Location ou Set-Cookie.
Exemplos tpicos de sanitizao incluem a converso para inteiros ou substituio usando
expresses regulares. Apesar da diviso da resposta no ser especfica para PHP, o interpretador PHP contm proteo contra o ataque desde a verso 4.4.2 e 5.1.2.
6.2.3
Validao de Dados
Vulnerabilidades relacionadas com a Validao de Dados costumam ser as mais presentes

em aplicaes, mesmo em aplicaes desktop.
Embora sejam as mais comuns, elas representam um grande risco para a aplicao. Primeiro, porque permitem a manipulao da informao presente na aplicao e segundo,
porque podem facilmente denegrir a imagem da organizao dona da aplicao.
70

Cross-Site Scripting (XSS)
Ataques de Cross-Site Scripting (XSS) ocorrem quando scripts maliciosos so injetados
dentro do contexto de sees aparentemente confiveis de um site. Um atacante pode fazer
uso da aplicao para disseminar um cdigo malicioso, geralmente na forma de um script
que executado no navegador do usurio final. Essa falha ocorre geralmente em aplicaes
Web que no validam, interpretando as entradas que partem do lado do cliente sem o devido tratamento. Qualquer funcionalidade ou recurso disponvel para o navegador pode ser
explorada no ataque de XSS (cdigos HTML, JavaScript, Flash, applets Java).
Um XSS Reflected ocorre quando o cdigo injetado passado e refletido pelo Servidor
Web durante uma mensagem de erro, resultados de buscas ou quaisquer outra resposta que
inclui, parcial ou integralmente, os parmetros passados ao servidor.
Um Stored XSS ocorre quando o cdigo injetado armazenado persistentemente no lado
do servidor, dentro de um banco, frum de mensagens, campo de comentrios, e etc. A vtima
recebe os scripts maliciosos do servidor sempre que requisitar um endereo carregando as
informaes armazenadas.
importante observar que, apesar de vrios navegadores (Chrome e IE, por exemplo) j
inclurem filtros nativos contra Reflected Cross Site Scripting, existem tcnicas conhecidas
para contornar essas protees. No caso de um Stored Cross Site Scripting, o navegador no
consegue discernir o contedo original do contedo injetado, carregando automaticamente
as informaes.
Impacto Um atacante pode usar um XSS e enviar uma URL maliciosa para um usurio
final. O navegador recebe os parmetros e executa automaticamente os scripts, que podem
acessar cookies, sequestrar sees e reter informaes sensveis. Os scripts podem, inclusive,
manipular e modificar o contedo da pgina HTML, exibindo um contedo arbitrrio.
possvel criar frames maliciosos dentro do contexto original da pgina, manipular notcias,
controlar o navegador do usurio, entre outros.
Medidas Esta classe de vulnerabilidade pode ser evitada atravs de trs medidas principais:
Todo parmetro recebido pela aplicao deve ser validado quanto ao tipo e tamanho
para verificar se a entrada compatvel com o dado esperado. Recomenda-se a utilizao de uma abordagem "Whitelist"ao invs de "Blacklist- aceitar apenas caracteres
compatveis com o tipo de dado esperado. Todo tipo de entrada de dado invlida deve
ser rejeitada, ao invs de ser tratada e no deve ser retornada em mensagens de erro
da aplicao.
Todo dado entrado deve sofrer codificao HTML Encode"antes de ser copiado para
respostas da aplicao. Todos os meta-caracteres HTML, incluindo < > " e =, devem
71

Figura 6.8: Cross-Site Scripting (XSS)

ser substitudos pelas correspondentes entidades HTML (< > etc). Se o dado for
retornado dentro de cdigo JavaScript deve-se utilizar o formato \HH para codificar
os caracteres especiais.
importante que todo o cdigo da aplicao seja revisado para proteger a aplicao
contra falhas de XSS em outras URLs e pginas. A expresso regular de validao
de e-mail deve ser revalidada em todos os campos em que usada. Um controle de
tamanho das entradas e formulrios tambm til para mitigar e dificultar a elaborao
de ataques.
Caso a aplicao tenha funcionalidade que permita a incluso de algumas tags HTML
(o que deve ser evitado), a aplicao deve realizar uma validao rigorosa para garantir que
apenas algumas tags autorizadas so permitidas e que nenhuma tag perigosa aceita. Esta
validao deve ser realizada atravs de expresses regulares.
A OWASP ESAPI4 uma API consolidada que agrega filtros e controles para tratamento
de problemas desse tipo para vrias linguagens.
4
Mais informaes disponveis em: https://www.owasp.org/index.php/Category:OWASP_Enterprise_
Security_API
72

Para maiores informaes sobre como prevenir XSS consulte: https://www.owasp.org/
index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet
Comment Spam
Esses problemas podem ser relativos programao das sees de comentrios ou pode
estar relacionado uma vulnerabilidade qualquer do site. Os comentrios de Spam so
inseridos de maneira automatizada com o uso de scripts e robs que varrem a Internet e
inserem textos em pginas vulnerveis ou com sees de comentrios abertas. Isso mais
comum em sees de comentrios, mas tambm pode acontecer em pginas convencionais,
inserindo o spam na prpria pgina HTML (usando campos hidden por exemplo).
O mtodo usado por spammers para abusar da reputao e do ranking de SEO da
pgina original, fazendo com que seu site ganhe maior relevncia nas pesquisas. A maior
parte desse comment spam est relacionado a produtos farmacuticos (buy viagra, buy cialis
etc) e pornografia.
Impacto Contedo de Spam em comentrios podem denegrir fortemente a imagem de um
website. Eles so ruins pois interferem na interface do usurio de maneira agressiva, ocupam
espao e prejudicam a classificao em mecanismos de busca.
De forma resumida, a vulnerabilidade de comment spam permite:
diminuir a qualidade do site
reduzir a qualidade da experincia do usurio
afetar a disponibilidade da aplicao web, pois em alguns casos podem ser executados ataques automatizados com a finalidade de deixar a aplicao mais lenta, ou de
comprometer o mecanismo de armazenamento
afetar o posicionamento do website em mecanismos de busca
Medidas Algumas medidas para evitar esse tipo de problema:
Uso de CAPTCHAs, exigindo uma confirmao visual para verificar se um humano
est digitando o comentrio. claro que isso no impede que usurios insiram comentrios de spam manualmente, mas j reduz a quantidade de mensagens inseridas.
Existem mdulos que verificam o contedo da mensagem de comentrio, mas isso no
eficiente j que os spammers escondem as URLs com mensagens aparentemente
normais comentando o artigo (como no caso da revista).
Assegurar que o site no est comprometido. Quando o site est vulnervel, scripts automticos podem explorar falhas e acessar sees administrativas, inserindo mensagens
e auto-aprovando os comentrios, por exemplo.
73

Proibir a insero de URLs nos campos de comentrios (incluindo nas informaes de
usurio).
Em todos os casos, importante verificar e moderar o contedo das sees interativas,
removendo estas mensagens de spam. Caso as mensagens persistam, os mecanismos de busca
podem identificar e diminuir a confiana e o ranking SEO do domnio original.
Redirecionamento sem Validao
Uma vulnerabilidade de Redirecionamento sem Validao, ou Open Redirect ocorre quando
a aplicao web recebe um parmetro e redireciona o usurio sem qualquer tipo de validao.
Um parmetro HTTP pode conter um valor que permite aplicao redirecionar a requisio
para uma URL especfica. A aplicao recebe a entrada e usa esse valor como destino do
redirecionamento.
Caso o redirecionamento ocorra sem o devido tratamento e validao, qualquer usurio
pode abusar da aplicao para criar links maliciosos para campanhas de phishing ou pginas
falsas, por exemplo.
Impacto Como o nome e domnio do servidor o mesmo do site original, os ataques ganham maior credibilidade, conseguindo comprometer uma nmero maior de usurios. Estes
ataques podem ser usados para roubar dados, informaes e credenciais de usurios, por
exemplo.
Medidas Para prover um redirecionamento seguro, interessante adotar as seguintes prticas:
No usar dados provenientes do cliente
Usar uma codificao interna da aplicao para criptografar a URL e evitar que o
usurio consiga manipular os parmetros. Dessa forma, somente quem conhece a chave
interna da aplicao conseguiria descriptografar o contedo da aplicao.
Verificar se o usurio pode acessar o recurso que est tentando.
Cross-Site Request Forgery (CSRF)
O Cross-Site Request Forgery (CSRF) uma classe de ataques que explora a relao de
confiana entre uma aplicao Web e seu usurio legtimo. Para execuo do CSRF, o usurio
mal intencionado deve induzir o utilizador legtimo, seja por meio de engenharia social ou
outros artifcios como Cross-Site Scripting, a executar atividades arbitrrias no aplicativo,
permitindo que virtualmente qualquer ao especfica possa ser realizada no sistema sem o
consentimento do usurio final.
A explorao do CSRF se d por meio de aplicativos vulnerveis que no possuem tokens/controles especficos para garantir que todas as comunicaes com o usurio legtimo
74

sejam feitas dentro de um mesmo contexto, ou seja, utilizando um fluxo lgico de execuo.
Um bom exemplo seria a execuo de uma transao de movimentao financeira de crditos
para uma nova titularidade (usurio), sem que a tela para captura dos dados de origem e
destino seja solicitada pelo usurio (vtima do ataque).
O alvo do atacante geralmente so as transaes valiosas e mais comuns nos sistemas de
aplicativos web, tais como:
Alterao de e-mail ou dados pessoais;
Alterao de senha de acesso;
Movimentaes financeiras ou compras online.
Aplicaes vulnerveis so exploradas basicamente por meio das seguintes etapas:
O usurio se autentica ou est autenticado na aplicao alvo do ataque;
O usurio recebe um link ou utiliza o mesmo navegador para acessar um aplicativo
malicioso;
O link ou aplicativo malicioso navegado inclui uma requisio aplicao alvo, carregando todos os parmetros necessrios para a execuo da transao;
Pela SameOriginPolicy do navegador, como existe uma sesso autenticada vlida para
o usurio no aplicativo alvo, a aplicao recebe a requisio e executa a operao
conforme a solicitao enviada.
Impacto Com uma aplicao web vulnervel a CSRF possvel atravs de outra aplicao
web realizar requisies devido a existncia de uma sesso sem controle na aplicaes vulnervel a CSRF. Isso ocorre porque como no existe um controle de sesso, as requisies sero
sempre estticas, com os mesmos parmetros e valores, logo ser sempre possvel repeti-las
ao longo do tempo.
Para realizar um teste necessrio criar um cdigo em outra pgina, externa a aplicao
inicial, que ir fazer uma requisio a aplicao vulnervel sem nenhuma interao com o
usurio.
Sabendo que o navegador inclui automaticamente nas solicitaes para um mesmo aplicativo todas e quaisquer credenciais associadas a ele, seja um cookie de sesso do usurio,
token e credenciais de autenticao e como a aplicao no avalia o fluxo de execuo das
operaes, ela no tem condies de distinguir a solicitao maliciosa da solicitao legtima.
Dessa forma, ao fazer a requisio, o navegador ir possuir as credenciais necessrias, logo
a requisio ser processada e executada, pois nenhum controle para verificar a origem da
requisio foi feito.
Dentre as formas mais comuns que o atacante pode utilizar para explorar o CSRF em
aplicaes vulnerveis, destacam-se:
75

Por meio de tags HTML
Uso de IMG SRC <img src=http://host/?command>
Uso de SCRIPT SRC <script src=http://host/?command>
Uso de IFRAME SRC <iframe src=http://host/?command>
Por meio de objeto XmlHttpRequest (XMLHTTP).
Por meio de cdigo Javascript
Medidas Uma soluo comum adotada pelos desenvolvedores contra o CSRF o Synchronizer Token Pattern, que gera um token de desafio aleatrio associado com a sesso atual do
usurio. Esses tokens so inseridos nos formulrios HTML, links associados com operaes
sensiveis e includas nas solicitaes HTTP quando enviadas para o aplicativo web.
Quando o usurio gera uma solicitao por meio de um formulrio, um campo input do
tipo hidden dever conter o token de proteo CSRF. Toda vez que uma transao sensvel
for executada, o aplicativo ir comparar o token enviado com o valor armazenado em sesso.
Caso positivo, a transao ser realizada e um novo token gerado de maneira aleatrio. Em
caso negativo, o aplicativo dever recusar a execuo da transao.
Uma requisio externa no consegue tomar conhecimento deste token identificador sem
interagir com a pgina. importante usar valores complexos (que no podem ser facilmente
descobertos por fora bruta) e corrigir falhas de Cross-Site-Scripting, que podem ser abusadas
para encontrar o token e forar requisies maliciosas.
Alm disso, importante proteger todos os campos e formulrios interativos, revisando
todo o fluxo das telas para evitar a exposio dos usurios do aplicativo.
A OWASP possui um framework de preveno contra ataques de CSRF especfico para
Java, mas com espeficicaes para outras linguagens, que pode ser acessado em: https:
//www.owasp.org/index.php/Category:OWASP_CSRFGuard_Project
Referncia insegura objetos
Uma referncia insegura objeto ocorre quando o desenvolvedor expe uma referncia
a objeto usado internamente, como um arquivo, diretrio, dados de banco de dados, uma
chave primria, IDs, dentre outros. Um atacante pode manipular essas referncias objetos
para acessar outros objetos sem autorizao, caso no existia um controle de acesso.
Impacto Atravs da manipulao dos valores nos parmetros passados via requisies
GET, geralmente possvel encontrar essa vulnerabilidade. No somente encontrar, mas dependendo do objeto que est sendo manipulado, possvel explorar outras vulnerabilidades,
como, por exemplo:
Leitura de Arquivos Locais
76

Path Transversal
Algumas medidas geralmente implantadas para uma suposta proteo da aplicao
o uso no cdigo (hard-coded) da extenso do objeto que ser retornado. Uma forma de
contornar essa restrio, atravs da adio do carcter fim de linha - %0000 aps o novo
valor para o parmetro.
Exemplos
Medidas No se deve confiar nas informaes passadas pelo usurio, restringindo e limitando o acesso do sistema aos componentes realmente utilizados para seu funcionamento. A
aplicao deve verificar se o usurio est autorizado a exibir o que foi solicitado. O acesso a
arquivos deve ser bloqueado, limitando a visualizao para os objetos pertinentes.
6.2.4
Disponibilidade
Slow HTTP
Essa vulnerabilidade est relacionada a configurao do servidor web e ao contrrio de
outros ataques que podem comprometer a disponibilidade da aplicao, ele no se caracteriza
pelo envio de grande quantidades de informaes de forma a exaurir os recursos para a
aplicao.
A explorao da vulnerabilidade Slow HTTP feita atravs atravs do esgotamento das
conexes possveis do servidor web com o uso de conexes lentas, deixando as demais sem
resposta.
Impacto O ataque de Slow Headers ocorre quando um atacante mantm as conexes do
servidor abertas enviando requisies HTTP parciais, submetendo os cabealhos subsequentes em um intervalo de tempo que impossibilita o servidor de fechar os sockets. Desta
maneira, o servidor web fica indisponvel porque o nmero de sockets disponveis diminui,
aumentando o uso de memria (principalmente se o servidor aloca uma thread para cada
conexo).
Uma das razes para esse comportamento que alguns servidores tm temporizadores de
no data, que so reiniciados toda vez que algum byte chega no socket. O grande problema
que para grande parte dos servidores web no existe um tempo limite para a requisio
como um todo. Um atacante pode, desta maneira, enviar um byte da requisio por vez
durante vrios minutos, ao invs de enviar toda a requisio em um nico pacote, mantendo
a conexo presa por tempo indeterminado.
Ataques de Slow HTTP POST acontecem quando o atacante mantm as conexes abertas enviando cabealhos de HTTP POST codificados com um campo de Content- Length
legtimo, informando a quantidade de dados esperada ao servidor web. Depois de concluir
o envio dos cabealhos HTTP POST, o corpo da mensagem enviado em longos intervalos
de tempo para prolongar a concluso da conexo e consumir os recursos do servidor. Como
77

o servidor fica esperando pela concluso da requisio, os demais usurios do ambiente enfrentaro lentido, j que o ataque deixar as conexes intermitentes.
Medidas Dentre as medidas bsicas, recomenda-se rejeitar mtodos HTTP no utilizados,
limitar o tamanho do corpo das mensagens, dos POSTs, ajustar um timeout absoluto para as
requisies, no segurar conexes rejeitadas por longos perodos e definir um fluxo mnimo
de entrada de dados, matando sesses excessivamente lentas. Para exemplificar, campos
de formulrios que suportam entradas de at 256 caracteres no devem aceitar requisies
maiores que 1 KB.
Configuraes recomendadas para servidores web baseados em Apache:
Usar somente as diretrizes <Limit> e <LimitExcept> para rejeitar requisies com
mtodos no suportados no resolve o problema, j que o Apache aguarda a requisio
completar antes de processar as diretrizes. Esses parmetros devem ser usados juntamente com os parmetros LimitRequestFields, LimitRequestFieldSize, LimitRequestBody, LimitRequestLine e LimitXMLRequestBody. A configurao padro do Apache
aceita cabealhos com 8190 bytes, corpos com tamanho indefinido e at 100 cabealhos
por requisio, valores excessivos para servidores convencionais.
Reduzir os valores de TimeOut e KeepAliveTimeOut. O valor padro de 300 consideravelmente alto.
O valor padro de ListenBackLog (511) pode ser incrementado, ajudando nos casos em
que o servidor no consegue aceitar conexes rpido suficiente.
Ajustar o parmetro MaxRequestWorkers para que o servidor trate o nmero mximo
de conexes simultneas suportadas.
Ajustar a diretriz AcceptFilter, que permite o SO otimizar as sockets que escuta conforme o tipo de protocolo.
Vrios mdulos de Apache tambm esto disponveis para mitigar ataques de Slow
HTTP, como o mod_reqtimeout, que ajusta a entrada RequestReadTimeout para controlar conexes lentas, configurando um tempo limite e uma taxa mnima de dados
para as requisies.
Algumas configuraes recomendadas para servidores web baseados em Nginx:
Limitar os mtodos aceitos ajustando a varivel $request_method.
Ajustar valores baixos para client_max_body_size, client_body_buer_size, client_header_buer_s

large_client_header_buers.
Atribuir valores pequenos de client_body_timeout e client_header_timeout.
78

Editar HttpLimitReqModule e HttpLimitZoneModule para limitar o nmero de requisies e o nmero de conexes simultneas para uma dada sesso e/ou endereos iguais.
Configurar os parmetros worker_processes e worker_connections baseados no nmero
de CPUs / cores, contedo e volume de trfego. A frmula base adotada max_clients
= worker_processes * worker_connections.
Upload Irrestrito de Arquivos
A possibilidade de upload de arquivos arbitrrios pode representar srios riscos segurana da aplicao. A funcionalidade de subida de arquivos permite a criao de componentes
auxiliares para ataques.
As consequncias de upload irrestrito de arquivos pode variar, incluindo o controle total do sistema sobrecarregamento do sistema de arquivos, encaminhamento de ataques para
sistemas de backend ou at mesmo a pixao/modificao de contedo do site. A complexidade e a extenso do ataque depende de como a aplicao lida com os arquivos, seus
tipos/formatos e onde armazena os mesmos.
Existem duas classes diferentes de problemas. A primeira relacionado aos metadados
dos arquivos como o nome, extenso e caminho. Caso no exista um devido controle e
validao destes elementos, pode-se sobrescrever os componentes existentes ou armazen-los
em locais arbitrrios.
A segunda classe de problemas est relacionada ao contedo dos arquivos. Esta gama
de problemas depende diretamente do uso e formato de armazenamento dos arquivos por
parte da aplicao. Para proteger contra estes tipos de ataques, deve-se analisar o contedo
de todos arquivos recebidos pela aplicao, atentando para as operaes de processamento,
armazenamento e interpretao do contedo envolvido.
Impacto As consequncias do Upload Irrestrito de Arquivos podem variar, incluindo aquisio completa do sistema, o sobrecarregamento do sistema de arquivos, encaminhando ataques a sistemas de back-end, e defacement. O impacto tambm depender do que o aplicativo
faz com o arquivo enviado, incluindo onde ele armazenado.
Medidas Validao de tipo de arquivo: para determinadas situaes, aplicaes Web usam
implementaes internas para validar o formato de tipos de arquivos processados. Supondo
que a aplicao realize alguma operao com imagens (redimensionamento, por exemplo),
validar e reconhecer o arquivo enviado auxilia para bloquear um contedo no permitido.
Alguns reconhecedores lem os primeiros caracteres do arquivo (cabealho) para realizar
essa validao. Neste caso, um atacante pode inserir um contedo arbitrrio malicioso aps
esse cabealho aceito.
Existem alguns locais especficos da estrutura dos arquivos destinados a sees de comentrios que no afetam a estrutura bsica do arquivo. Esses campos tambm podem ser
abusados para inserir contedo malicioso. Deve-se atentar tambm para as bibliotecas que
79

realizam as operaes auxiliares nos arquivos (como a libmagick 5 ), que podem se deparar
com um cdigo malicioso e se comportar de maneira no esperada.
Outras medidas so:
Nunca deve-se aceitar extenses de tipos de arquivo no inclusos em um filtro prvio
(white-list).
Todos os caracteres de controle Unicode deve ser removidos dos nomes de arquivo e
suas extenses, sem exceo. Caracteres especiais como ;, :, >, <, / ,\, alm
de repetidos ., *, % e $ devem ser descartados. De maneira geral, recomenda-se
a restrio no nome para caracteres alfanumricos, no permitindo extenses vazias,
como na express regular [a-zA-Z0-9]1,200\.[a-zA-Z0-9]1,10.
Deve-se limitar o tamanho de nome do arquivo. O tamanho mximo permitido do
nome do arquivo com sua extenso no deve exceder 255 caracteres (desconsiderando
o diretrio) em uma partio NTFS, por exemplo. Caso a aplicao no saiba lidar
com nomes maiores que o permitido, ela pode causar uma condio de negao de
servio.
Recomenda-se usar um algoritmo/lgica interna para determinar os nomes de arquivos
a serem armazenados (um hash seguido da data/timestamp, por exemplo).
Os diretrios de Upload nunca devem ter a flag de execuo permitida.
Os tamanhos de arquivos devem ser limitados a um valor razovel para evitar ataques
de negao de servio (no uso de disco, banda, processamento).
Manter um controle de requisies, atravs de mtodos anti-XSRF (proteo contra
Cross Site Request Forgery).
Deve-se validar e no sobrescrever imagens com um mesmo hash.
Mtodos POST devem ser preferveis a PUT ou GET.
As atividades devem ser registradas, mantendo-se um log das operaes internamente.
Para maiores informaes: https://www.owasp.org/index.php/Unrestricted_File_
Upload
Ausncia de Controle de Requisies
A ausncia de controle de requisies ocorre, por exemplo, quando o usurio gera acessos
no banco de dados sem nenhuma limitao por parte da aplicao, possibilitando assim, que
um usurio envie mltiplas requisies com combinaes alternadas. O usurio pode abusar
enviando mltiplas perguntas e imagens para o banco de dados.
5
80
Mais informaes em: http://www.imagemagick.org/

Impacto O sistema no realiza nenhuma validao adicional durante a submisso de dados
do usurio. Um usurio malicioso pode explorar o ambiente de vrias maneiras:
possvel capturar o contedo do POST durante uma submisso e repetir as entradas
por um nmero indeterminado de vezes at sobrecarregar o ambiente, derrubando o
banco de dados e causando negao de servio. Outra possibilidade seria abusar da
interface administrativa de moderao enviando um nmero indefinido de perguntas,
dificultando o trabalho dos moderadores.
Como o contedo dos campos no verificado, possvel povoar a pgina com palavras arbitrrias, propagandas, URLs e scripts maliciosos, por exemplo. Estes termos
de propaganda podem ser indexados pelo Google e usados para comment spam.
importante observar que, caso o banco de dados seja compartilhado com outros ambientes, o abuso das requisies pode causar uma condio de negao de servio em
toda plataforma que faz uso das bases.
Medidas altamente recomendvel que exista um controle do nmero total de requisies partindo de um mesmo usurio. possvel criar controles internos na aplicao para
restringir e limitar requisies repetidas partindo de uma mesma combinao de endereo IP
e User Agent.
Uma soluo comum adotada pelos desenvolvedores contra CSRF e que pode ser aproveitada nesse caso o Synchronizer Token Pattern, que gera um token de desafio aleatrio
associado com a sesso atual do usurio. Esses tokens so inseridos nos formulrios HTML,
links associados com operaes sensiveis e includas nas solicitaes HTTP quando enviadas
para o aplicativo web.
Quando o usurio gera uma solicitao por meio de um formulrio, um campo input do
tipo hidden dever conter o token de proteo CSRF. Toda vez que uma transao sensvel
for executada, o aplicativo ir comparar o token enviado com o valor armazenado em sesso.
Caso positivo, a transao ser realizada e um novo token gerado de maneira aleatrio. Em
caso negativo, o aplicativo dever recusar a execuo da transao.
Uma requisio externa no consegue tomar conhecimento deste token identificador sem
interagir com a pgina. Nesse caso, o ataque precisaria ser mais elaborado para obter o token
desafio para ento submeter a requisio.
Outra possibilidade para esse caso seria usar a sesso associada dos usurios que entram e
autenticam. A partir da, pode-se limitar as requisies conforme a sesso nica, que expira
aps um determinado tempo.
O uso de CAPTCHAs 6 tambm auxilia limitando o uso de scripts e comandos automatizados para submisso de respostas. Para casos em que a interao do usurio deve
ser rpida e simples, possvel usar uma abordagem que exige a resoluo do CAPTCHA
6
CAPTCHA um acrnimo da expresso "Completely Automated Public Turing test to tell Computers
and Humans Apart"(teste de Turing pblico completamente automatizado para diferenciao entre computadores e humanos): um teste de desafio cognitivo, utilizado como ferramenta anti-spam. Mais informaes
em: http://www.captcha.net/
81

mediante situaes de estresse, quando partem vrias requisies de um mesmo endereo IP
por exemplo.
Falha na Restrio de Acesso URLs
Uma Falha na Restrio de Acesso URLs ocorre quando existe uma falha no controle de
acesso da aplicao e um usurio sem privilgios acessa recursos administrativos da aplicao.
Impacto Tais falhas podem permitir que algumas ou at mesmo todas as contas possam
ser comprometidas. Uma vez bem sucedido, o atacante pode fazer qualquer coisa com os
privilgios do usurio comprometido. Contas privilegiadas so frequentemente alvo desses
ataques.
Medidas Impedir o acesso no autorizado URL requer a devida autenticao e autorizao para cada pgina. Frequentemente, esta proteo proporcionada por um ou mais
componentes externos para o cdigo de aplicao. Independentemente do mecanismo, todos
os seguintes so recomendados:
As polticas de autenticao e autorizao devem ser baseada no papel de cada usurio,
minimizando assim o esforo necessrio para manter estas polticas.
As polticas devem ser altamente configurveis, a fim de minimizar quaisquer aspectos
difceis da poltica.
O mecanismo de aplicao deve negar todo o acesso por padro, exigindo subsdios
explcitos para os usurios e papis especficos para acesso a cada pgina.
Se a pgina est envolvido em um fluxo de trabalho, verifique se as condies esto no
estado adequado para permitir o acesso.
82
Captulo 7
OWASP ZAP
Conforme mencionamos na pgina 56 o OWASP ZAP um proxy de interceptao com
diversos recursos para auditoria de aplicaes web.
A principal filosofia envolta no desenvolvimento da ferramenta que Voc no pode
construir aplicaes seguras se no conhece como elas so atacadas. Assim, a soluo
encontrada foi desenvolver uma ferramenta de fcil usabilidade, onde os desenvolvedores
poderiam testar suas prprias aplicaes.
7.1
Histrico
O OWASP ZAP foi lanado em Setembro de 20101 com a premissa de ser uma ferramenta
com ampla facilidade de uso e boa documentao.
A ferramenta open-source, com suporte a internacionalizao e com diversos idiomas
em sua base, inclusive com suporte ao portugus.
Finalmente, a ferramenta multi-plataforma, escrita em Java. Possui verses lanadas
com regularidade e uma verso lanada toda semana com as ltimas modificaes. Tambm
possui uma ampla variedade de extenses2 que extendem suas verificaes, assim ampliando
sua cobertura de testes.
7.2
Preparao
Para utilizar o OWASP ZAP de forma efetiva, necessrio configurar o navegador de

maneira a no interferir no trfego. No exemplo de configurao, vamos abordar o navegador
Mozilla Firefox3
1
A apresentao completa do projeto est disponvel em: http://www.owasp.org/images/c/c8/
Conference_Style_slides_for_ZAP.ppt
2
Informaes sobre extenses podem ser encontradas em:
https://code.google.com/p/
zap-extensions/
3
Disponvel em: http://www.mozilla.org/pt-BR/firefox/new/
83

vlido lembrar que esse navegador deve ser atualizado manualmente e, sempre quando
possvel, no ser usado para uso cotidiano. O ideal que o navegador seja usado somente
para uso com o OWASP ZAP.
7.2.1
Desative a atualizao das extenses
Durante a navegao normal e ao iniciar o navegador, seu sistema de extenses busca por
atualizaes das mesmas de modo a proporcionar uma melhor experincia de uso. Para uso
com o OWASP ZAP, esse trfego de rede insere elementos que podem poluir a visibilidade
do funcionamento da aplicao web.
Para desativar esse recurso, v em about:config, use o recurso localizar para encontrar
os itens app.update.enabled e extensions.update.enabled. Em seguida coloque seus valores
para false, conforme demonstrado na imagem 7.1.
Figura 7.1: Parmetros de atualizao das extenses em negrito
7.2.2
Desative o SafeBrowsing
Durante a navegao cotidiana, o navegador verifica se os endereos requisitados pertencem a uma lista de endereos conhecidamente perigosos. Para uso com o OWASP ZAP,
esse trfego de rede insere elementos que podem poluir a visibilidade do funcionamento da
aplicao web.
Para desativar esse recurso, v em about:config, use o recurso localizar para encontrar os
itens browser.safebrowsing.enabled, browser.safebrowsing.malware.enabled, services.sync.prefs.sync.browser.
e services.sync.prefs.sync.browser.safebrowsing.malware.enabled. Em seguida coloque seus
valores para false, conforme demonstrado na imagem 7.2.
84

Figura 7.2: Parmetros do SafeBrowsing em negrito
7.2.3
Desative o HTTP Pipelining
O HTTP Pipelining uma tcnica que permite enviar mltiplas requisies atravs de
uma conexo TCP estabelecida com o servidor. Isso ocorre de maneira assncrona, ou seja, o
cliente no precisa esperar a resposta da requisio feita para enviar a prxima requisio4 .
O uso desse recurso em conjunto com o OWASP ZAP pode impactar na usabilidade da
ferramenta. Para desativar esse recurso, v em about:config, use o recurso localizar para
encontrar os itens network.http.pipelining e network.http.pipelining.ssl. Em seguida coloque
seus valores para false, conforme demonstrado na imagem 7.2.
4
Mais informaes disponveis em:
sec8.1.2.2
http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#
85

Figura 7.3: Parmetros do Pipelining em negrito
7.2.4
Desative o Prefetching
O Prefetching um recurso do navegador que usa o tempo ocioso do navegador para realizar o download de pginas e documentos que o usurio possa vir a clicar. Algumas pginas
fornecem configuraes especificando quais contedos podem ser descarregados atravs desse
recurso de modo que seu funcionamento pode ser involuntario, desde que o navegador esteja
ocioso5 .
O uso desse recurso em conjunto com o OWASP ZAP pode impactar na poluio dos
dados mostrados na ferramenta. Para desativar esse recurso, v em about:config, use o
recurso localizar para encontrar os itens network.dns.disablePrefetch e network.prefetch-next.
Em seguida coloque seus valores para true e false, respectivamente, conforme demonstrado
na imagem 7.2.
7.2.5
Mude a pgina inicial
Ao abrir o navegador ele automaticamente carrega a pgina inicial que foi previamente
configurada. Frequentemente, possvel que ao executarmos o navegador, o OWASP ZAP j
esteja em execuo, de modo que os dados carregados pela pgina poluam os dados coletados
anteriormente com o OWASP ZAP.
5
86
Mais informaes em: https://developer.mozilla.org/en-US/docs/Link_prefetching_FAQ

Figura 7.4: Parmetros do Pre-fetching em negrito

Para um melhor uso desse recurso interessante que o navegador no carregue pginas ao
iniciar, para isso v em Preferncias, na aba Geral e configure a funo inicial do navegador
para Abrir pgina em branco, conforme demonstrado na imagem 7.2.
7.2.6
Desative as sugestes de pgina
Para prover uma melhor experincia de uso, assim que o usurio comea a digitar algum
contedo, o navegador com base em suas preferncias sugere frases ou domnios que possam
ser de interesse do usurio.
Esses dados, obtidos atravs da coleta de informaes de navegao ou de informaes
de terceiros, como o Google, por exemplo, podem interferir nos dados que so enviados para
a aplicao web que estar sendo testada. Alm disso, caso esses dados sejam provenientes
de terceiros, o trfego envolvido ainda poder poluir os registros da aplicao.
Logo o uso desse recurso em conjunto com o OWASP ZAP pode impactar na poluio
dos dados mostrados na ferramenta assim como nos dados enviados para a aplicaes web
envolvida. Para desativar esse recurso, v em Preferncias, na aba Privacidade e configure
em Campo de endereo a opo Nada, conforme demonstrado na imagem 7.6.
7.2.7
Desabilite os updates do navegador
Periodicamente, o navegador entra em contato com seu fabricante de modo a obter informaes sobre atualizaes e novas verses. A finalidade desse recurso prover ao usurio
a melhor experincia possvel em navegao web, assim permitindo que ele sempre desfrute
dos ltimos recursos disponveis, tanto para a navegao quanto em termos de segurana.
O uso desse recurso em conjunto com o OWASP ZAP pode impactar na poluio dos
87

Figura 7.5: Configurao Geral do Firefox

dados mostrados na ferramenta, pois periodicamente o navegador poluir os dados com
requisies buscando informaes sobre atualizaes. Para desativar esse recurso, v em
Preferncias, na aba Avanado e configure em Atualizaes a opo Nunca verificar, conforme
demonstrado na imagem 7.7.
7.2.8
Habilitando a opo de proxy
Ao utilizar o Firefox com o OWASP ZAP, necessrio configurar o navegador para

encaminhar suas requisies para o OWASP ZAP de maneira que ele seja capaz de interceptar
o trfego HTTP.
Para utilizar esse recurso, v em Preferncias, na aba Avanado e configure em Rede a
88

Figura 7.6: Configurao de Privacidade do Firefox
opo Conexo para Configurao Manual de Proxy com os campos Endereo e Porta com
os valores localhost e 8080 6 , respectivamente.
6
Os valores podem alterar conforme a configurao do sistema. Consulte a seo 7.3.1 para saber qual a
porta que o OWASP ZAP estar usando em seu sistema
89

Figura 7.7: Configurao Avanada do Firefox
7.3
Usando a ferramenta
O OWASP ZAP uma ferramenta rica em recursos teis para auditoria em aplicaes
web. Veremos a seguir como utilizar alguns de seus recursos.
90

7.3.1
Configurao Inicial
Aps iniciar a ferramenta, o primeiro passo realizar sua configurao inicial. Para isso,
v no menu Ferramentas e selecione Opes 7 . Confira na imagem 7.8 a janela de opes.
Figura 7.8: Janela de opes do OWASP ZAP

A primeira configurao a ser realizada a verificao da porta de funcionamento da
ferramenta. Para isso, selecionaremos a opo Proxy local, conforme ilustrado na imangem
7.9.
Logo aps, devemos configurar a gerao de certificados SSL na ferramenta. Essa funcionalidade permite ao OWASP ZAP interceptar o trfego criptografado atravs da gerao de
certificados dinmicos. Para tal, devemos importar o certificado raiz gerado pela ferramenta
no nosso sistema e configurar tal certificado como confivel.
Na mesma janela, selecionaremos a opo Certificados SSL Dinmicos conforme ilustra
a figura 7.10.
Caso seja de interesse, o idioma da ferramenta pode ser alterado na opo Language,
conforme ilustrado na imagem 7.11.
Outra configurao interessante a de habilitar a transformao de campos do tipo hidden
em campos do tipo text, o que permite sua visualizao e alterao durante a navegao da
7
possvel realizar o mesmo procedimento selecionando na interface da ferramenta o icone com a figura
de uma engrenagem.
91

Figura 7.9: Opes de Proxy do OWASP ZAP
aplicao. Para habilitar esse recurso, selecione o boto na barra de ferramentas do OWASP
ZAP com a imagem de uma lmpada.
92

Figura 7.10: Opes de Certificados SSL Dinmicos do OWASP ZAP
7.3.2
Funcionalidades Basicas
Agora com a ferramenta configurada, veremos um pouco de sua funcionalidade como

proxy de interceptao. Para isso, basta navegar um pouco com o Firefox em algum site de
sua escolha.
Ao voltar para a janela do OWASP ZAP veremos que novas informaes esto disponveis. Todo o trfego HTTP utilizado na navegao estar disponvel para inspeo. Por
padro, o OWASP ZAP no mostra as imagens carregadas em sua interface de maneira a
reduzir a quantidade de informaes que devem ser analizadas. Caso a imagem receba algum
parmetro, ela ser mostrada.
Veja na imagem 7.12 como ficou a janela do OWASP ZAP aps navegar por alguns
minutos.
Agora com os dados da navegao, podemos verificar outras funcionalidades da ferramenta atravs da navegao entre suas abas. No canto superior direito, temos a opo de
ver a requisio e a resposta realizada para cada recurso que foi acessado, assim como os
dados enviados e recebidos no corpo da requisio e resposta.
No canto superior esquerdo podemos acompanhar de forma estruturada os recursos acessados durante a navegao.
No parte inferior, na aba Histrico podemos acompanhar as requisies realizadas por
ordem de execuo. Ainda na parte inferior, ao mudarmos para a aba:
93

Figura 7.11: Opes de Idioma do OWASP ZAP

Localizar podemos procurar por textos em todo o contedo presente, ou fazer buscas seletivas por textos presentes na URL, Requisio, Resposta, Cabealhos ou nos resultados
do Fuzz.
Alertas podemos acompanhar os alertas automticos emitidos pela ferramenta. Os alertas
ficam estruturados de acordo com seu risco, representado pela cor8 da bandeira que
acompanha sua descrio na coluna da esquerda.
Maiores detalhes podem ser obtidos selecionando o item e visualizando as informaes
na coluna da direita.
Ao clicar duas vezes no item da coluna da esquerda, possvel alterar seus parmetros
e opes, assim como os demais campos.
Spider podemos realizar uma varredura recursiva na aplicao de forma a mapearmos praticamente todo o seu contedo.
O spider funciona atravs do uso das URLs que aparecem nas pginas durante a
navegao. Elas so utlizadas para pegar o contedo de outras pginas e com isso
aumentar a base de URLs a serem visitadas. Para que o spider funcione de maneira
eficaz, necessrio uma navegao diversificada na aplicao.
8
94
Azul: Informao, Amarelo: Baixo, Laranja: Mdio e Vermelho: Alto.

Figura 7.12: Janela do OWASP ZAP aps navegar por alguns minutos
Tambm possvel usar essa funcionalidade atravs do quadro superior direito da
aplicao, selecionando o item e abrindo o menu de opes, selecionar Ataque e logo
em seguida Usar o sipder no site.
Navegao Forada podemos selecionar listas para descobrirmos diretorios e recursos at
ento no mapeados anteriomente. Esses recursos podem ser backups, versoes antigas
de arquivos renomeados, diretrios desprotegidos entre outros.
Tambm possvel usar essa funcionalidade atravs do quadro superior direito da
aplicao, selecionando o item e abrindo o menu de opes, selecionar Ataque e logo
em seguida Site com navegao forada.
Por padro so fornecidos com o OWASP ZAP algumas listas de diretrios que podem
ser usadas, mas a confeco de uma lista personalizada o ideal.
Parmetros podemos acompanhar os parmetros identificados pela ferramenta durante a
navegao e o spider. Esses itens so um ponto chave pois eles identificam os pontos
de entrada de informao da aplicao.
95

7.3.3
Reenvio e Fuzzing
O OWASP ZAP possui dois mecanismos interessantes para a alterao dos dados enviados
para a aplicao web. O reenvio feito de foma individual. O usurio deve selecionar a
requisio que gostaria de alterar e ento fazer o reenvio dela com parmetros escolhidos por
ele.
Confira na imagem 7.13 a utlilizao do recurso, que foi feita aps a seleo da requisio
(via histrico) e a seleo da opeo de Reenviar.
Figura 7.13: Uso da funcionalidade de reenvio no OWASP ZAP

Normalmente, desejamos fazer o reenvio diversas vezes de maneira a tentar cobrir o
mximo de possibilidades possveis. O OWASP ZAP implementa esse recurso atravs do uso
de listas que so confeccionadas com os valores que se deseja substituir no reenvio. Para fazer
uso desse recurso, selecione a requisio que deseja alterar os dados enviados. Em seguida,
na aba Requisies selecione o pedao do texto que gostaria de alterar. Clique sobre o texto
e selecione a opo Fuzz.... Acompanhe na imagem 7.14 a seleo de listas.
7.3.4
Decode e Encode
Frequentemente nos deparamos com informaes codificadas ao interagirmos com aplicaes web. Na grande maioria essas informaes esto codificadas em base64 9 . O OWASP
9
96
Mais informaes em: http://tools.ietf.org/html/rfc4648

Figura 7.14: Uso da funcionalidade de Fuzz no OWASP ZAP

ZAP fornece uma forma gil de decodificar essas informaes. Para utilizar tal recurso,
selecione a informo que deseja decodificar, ou codificar e com o menu auxiliar selecione
Codificar/Decodificar/Hash.
Acompanhe na imagem 7.15 o uso dessa funcionalidade no OWASP ZAP.
97

Figura 7.15: Uso da funcionalidade de Codificar/Decodificar/Hash no OWASP ZAP
98
Captulo 8
Consideraes finais
Uma auditoria fornece uma viso profunda sobre a segurana dos ativos contemplados,
fundamentada tanto por informaes obtidas durante a mesma ou fornecidas pelo prprio
solicitante. Por sua natureza, uma atividade que exige, do lado do solicitante, confiana
para revelar informaes sensveis e permitir a realizao da auditoria e, do lado do auditor,
tica para lidar com informaes fornecidas ou descobertas com responsabilidade.
Outra questo importante diz respeito a transparncia de todo o processo da auditoria
junto ao solicitante. No se pode esperar que o solicitante v confiar cegamente no auditor e
esperar pacientemente a concluso da auditoria para receber resultados. Assim, o solicitante
deve ser informado periodicamente sobre o andamento da auditoria incluindo informaes
como quais procedimentos j foram realizados e quais sero executados at prximo reporte,
sem nunca fugir da metodologia previamente discutida com o mesmo.
8.1
tica
A tica muito importante para a realizao de auditorias principalmente pelo volume

de informaes sensveis tratadas pelo auditor e deve ser levada em conta durante todo o
processo de auditoria. A divulgao, mesmo que parcial ou acidental, destas informaes
pode provocar incidentes de segurana srios nos ativos contemplados pela auditoria. O
propsito da revelao destas informaes especificamente avaliar a segurana dos ativos
do contratante, ento o uso destas informaes para qualquer outro propsito vai contra os
interesses do mesmo e, mesmo na ausncia do acordo, a divulgao destes dados configura
um conflito tico.
Outro conflito tico acontece quando so realizados auditorias no requisitadas. Esta
prtica consiste da realizao da auditoria sem o prvio conhecimento ou autorizao do
alvo da mesma. Sob uma tica puramente tcnica, as auditorias no-requisitada e caixa
preta se do exatamente da mesma forma, diferindo somente na apresentao do resultado.
Enquanto os resultados de auditorias caixa preta consistem principalmente da demonstrao de evidncias dos problemas de segurana encontrados e medidas de mitigao para
os mesmo, os resultados de auditorias no-requisitadas geralmente consistem somente das
99

evidncias dos problemas de segurana encontrados, de forma que a entrega do restante das
informaes fica condicionada uma ao determinada pelo autor da auditoria. Esta ao
varia muito dependendo dos interesses de quem realizou a auditoria, indo de pagamento do
servio sob pena de divulgao das informaes coletadas em meios de comunicao pblicos
at contratao do mesmo na empresa sob o pretexto de resolver os problemas de segurana
encontrados.
As prticas supracitadas so consideradas anti-ticas e, em alguns casos, at criminosas,
embora algumas nem sempre tenham sido classificadas assim. No mercado da segurana
da informao, a reputao de um profissional ou empresa algo valioso e fazer uso de
qualquer uma destas prticas deteriora esta reputao, em alguns casos irremediavelmente.
importante que o analista, ao se propor a fazer uma auditoria, tenha em mente que a tica
profissional o que o separa dos criminosos cibernticos e que o propsito da auditoria deve
ser medir a resistncia do sistema a ataque e nunca ver quanto dano se pode causar com um
ataque. Desta forma, quando uma simulao de ataque bem-sucedida, responsabilidade
do analista avaliar se deve utilizar o fruto desta para lanar outras ou se este resultado basta
para cumprir o objetivo da auditoria.
Aquele que se empenha a resolver as dificuldades resolve-as antes que elas surjam.
Aquele que se ultrapassa a vencer os inimigos triunfa antes que as suas ameaas
se concretizem.
Sun Tzu
100

Apostila v2 PDF

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Apostila v2 PDF

Caricato da

Copyright:

Formati disponibili

Segurana em Aplicaes Web

Segurana em Aplicaes Web para desenvolvedores

Segurana em Aplicaes Web para desenvolvedores

Comunicao, distribuio e reproduo no autorizada.

Segurana em Aplicaes Web para desenvolvedores

Comunicao, distribuio e reproduo no autorizada.

Segurana em Aplicaes Web para desenvolvedores

Desative a atualizao das extenses . . . . . . . . . . . . . . . . . .

Desative o HTTP Pipelining . . . . . . . . . . . . . . . . . . . . . . .

Mude a pgina inicial . . . . . . . . . . . . . . . . . . . . . . . . . . .

Desative as sugestes de pgina . . . . . . . . . . . . . . . . . . . . .

Desabilite os updates do navegador . . . . . . . . . . . . . . . . . . .

Habilitando a opo de proxy . . . . . . . . . . . . . . . . . . . . . .

Segurana em Aplicaes Web para desenvolvedores

Comunicao, distribuio e reproduo no autorizada.

Hypertext Transfer Protocol

O Hypertext Transfer Protocol (HTTP) ou Protocolo de Transferncia de Hipertexto

Acompanhe a seguir um exemplo de requisio HTTP.

RFC 2616 http://www.ietf.org/rfc/rfc2616.txt

Segurana em Aplicaes Web para desenvolvedores

Acompanhe a seguir um exemplo da resposta a requisio HTTP anteriormente analisada.

Comunicao, distribuio e reproduo no autorizada.

Segurana em Aplicaes Web para desenvolvedores

URI ou Uniform Resource Indicators o endereo e um recurso incluindo a forma de

Segurana em Aplicaes Web para desenvolvedores

Comunicao, distribuio e reproduo no autorizada.

Segurana em Aplicaes Web para desenvolvedores

Segurana em Aplicaes Web para desenvolvedores

HTTP/ 1 . 1 403 Forbidden

OPTIONS - Verifica os mtodos permitidos pelo servidor web.

Comunicao, distribuio e reproduo no autorizada.

Segurana em Aplicaes Web para desenvolvedores

HTTP/ 1 . 1 400 Bad Request

Segurana em Aplicaes Web para desenvolvedores

Alguns atributos de um cookie so:

Comunicao, distribuio e reproduo no autorizada.

Segurana em Aplicaes Web para desenvolvedores

Comunicao, distribuio e reproduo no autorizada.

Segurana em Aplicaes Web para desenvolvedores

Comunicao, distribuio e reproduo no autorizada.

Segurana em Aplicaes Web para desenvolvedores

O protocolo HTTPS consiste na implementao de um canal SSL/TLS para o transporte

Comunicao, distribuio e reproduo no autorizada.

Segurana em Aplicaes Web para desenvolvedores

Comunicao, distribuio e reproduo no autorizada.

Segurana em Aplicaes Web para desenvolvedores

Figura 1.1: Instrues de uso para certificados auto-assinados - Fonte: http://chicago.

Comunicao, distribuio e reproduo no autorizada.

Segurana em Aplicaes Web para desenvolvedores

Comunicao, distribuio e reproduo no autorizada.

Segurana das Aplicaes versus Segurana da Comunicao

Aplicaes Web mais comuns

Segurana em Aplicaes Web para desenvolvedores

Teste caixa-preta ou Teste BlackBox um teste de software para verificar a sada

De acordo com a metodologia da SANS, uma das principais referencias no assunto.

Comunicao, distribuio e reproduo no autorizada.

Segurana em Aplicaes Web para desenvolvedores

A fase de busca por vulnerabilidade importante para correlacionar os resultados no

Na fase da execuo dos ataques importante lembrar de documentar todos os passos

Segurana em Aplicaes Web para desenvolvedores

Falhas de Configurao e Manuteno

Falhas de Validao de Dados

Vulnerabilidades relacionadas com a Validao de Dados costumam ser as mais presentes