Segurança de Aplicações Na Web

Departamento de Computação
Trabalho de Conclusão de Curso
THIAGO AUGUSTO LOPES GENEZ
SEGURANÇA DE APLICAÇÕES NA WEB
Londrina
2009
Trabalho de Conclusão de Curso apresentado ao

Curso de Graduação em Ciência da Computação
da Universidade Estadual de Londrina, como re-
quisito parcial à obtenção do grau de Bacharel.
Orientador: Prof. Dr. Mario Lemes Proença Jr.
Londrina
2009
Trabalho de Conclusão de Curso apresentado

ao Curso de Graduação em Ciência da Com-
putação da Universidade Estadual de Lon-
drina, como requisito parcial à obtenção do
grau de Bacharel.
COMISSÃO EXAMINADORA
Prof. Dr. Mario Lemes Proença Jr.

Universidade Estadual de Londrina
Prof. Ms. Fábio Sakuray

Prof. Dr. Alan Salvany Felinto

Londrina, de de 2009
Ao finado pai Carlos Augusto Mungo Genez.
Agradecimentos
À Deus pelo desafio da vida.
A meus pais, Carlos Augusto M. Genez e Jandira Lopes Genez, por absolutamente tudo.
Ao meu irmão, Lucas, por acreditar e apoiar.
Ao professor e orientador Mario Lemes Proença Jr. que sempre deu apoio e me ensinou a
realizar uma pesquisa de forma correta.
À minha namorada Amanda que me apoiou e soube compreender quando tive que ficar estu-
dando durante os finais de semana.
Ao professor Fabio Sakuray, pela aportunidade de estagiar no laboratório Orion que ajudou no
meu crescimento profissional.
À todos os professores e funcionários do departamento de computação que ajudaram a concluir

a minha graduação em Ciência da Computação.
“Quero deixar uma marquinha no universo”.
Steve Jobs
Resumo
As aplicações WEB são os principais mecanismos para realizar transferências de dados ele-
trônicos. Criptografia e protocolos de segurança são os componentes essenciais para estabelecer
um comércio eletrônico. Atualmente, com o crescimento do número de transações de dados
sendo feitas por meio da Internet, a garantia da segurança das transferências de informações
é importante. Grandes quantidades de dados sigilosos estão sendo transferidos por intermé-
dio da Internet, através de aplicações e-commerce, bancos on-line e até sites governamentais.
Entretanto, várias aplicações WEB são desenvolvidas rapidamente, e com isso, não são feitos
testes apropriados de segurança, dessa forma o software torna-se vulnerável. Sendo assim, este
trabalho apresenta as técnicas e tecnologias sobre a segurança na WEB, para que as aplicações
estabeleçam uma comunicação segura, confiável e sem vulnerabilidade.
Palavras-Chaves: Aplicação, Criptografia, Protocolos, Segurança, Vulnerabilidade

Abstract
The web applications are the main mechanisms for transfers of electronic data. Crypto-
graphy and security protocols are essential components for establishing an e-commerce. Cur-
rently, with the growth in the number of data transactions being made through the Internet,
ensuring the safety of the transfer of information is important. Large amounts of sensitive data
being transferred via the Internet, through e-commerce applications, online banks and even go-
vernment websites. However, many web applications are developed quickly, and with it, are not
done proper testing of security, so the software becomes vulnerable. Therefore, this paper pre-
sents the techniques and technologies on safety on the web, for applications to establish secure
communications, reliable and vulnerability.
Keywords: Application, Cryptography , Protocol, Security, Vulnerability

Lista de Figuras
2.1 Tipos de ameaça à segurança. Adaptado de (STALLINGS, 1999) . . . . . . . p. 25
2.2 Ataque Ativo: Ataque de mensagens repetitivas. Adaptado de (STALLINGS,

2006) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 27
2.3 Ataque Ativo: Modification of Messages. Adaptado de (STALLINGS, 2006) p. 28
2.4 Ataque Ativo: Ataque DoS. Adaptado de (STALLINGS, 2006) . . . . . . . . p. 29
3.1 Modelo de Criptografia. Adaptado de (KRAUSE; TIPSON, 1998) . . . . . . p. 32
3.2 Esquema de uma criptografia simétrica. . . . . . . . . . . . . . . . . . . . . p. 34
4.1 Representação da pilha do protocolo SSL/TLS. Adaptado de (CISCO, 1998) . p. 48
4.2 Operação do SSL Record protocol. Adaptado de (CISCO, 1998) . . . . . . . p. 49
4.3 Tipos de protocolos do Handshake. Adaptado de (STALLINGS, 1999) . . . . p. 50
4.4 Estabelecimento da conexão entre cliente e servidor no SSL/TLS. Adaptado

de (CISCO, 1998) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 52
4.5 Protocolo HTTP sem segurança . . . . . . . . . . . . . . . . . . . . . . . . p. 56
4.6 Protocolo HTTP com segurança . . . . . . . . . . . . . . . . . . . . . . . . p. 57
4.7 Cenário de uma aplicação que depende da comunicação com diversos WEB
Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 59
4.8 Visão geral do Framework WS-Security . . . . . . . . . . . . . . . . . . . . p. 61
4.9 Camada da segurança usando SSL/TLS. . . . . . . . . . . . . . . . . . . . . p. 62
4.10 Camada da segurança usando WS-Security. . . . . . . . . . . . . . . . . . . p. 62
5.1 Aplicando assinatura digital. (1) Calculando hash. (2) Encriptando o hash
gerado. (3) Anexando o hash criptografado na mensagem . . . . . . . . . . . p. 66
5.2 Verificando a assinatura digital. (4) Destinatário recebe a mensagem assi-

nada. (5) Cálculo do novo hash. (6) Descriptografia da assinatura. (7) Com-
paração dos hashes gerados. . . . . . . . . . . . . . . . . . . . . . . . . . . p. 66
5.3 Gerando um Certificado Digital . . . . . . . . . . . . . . . . . . . . . . . . . p. 68
7.1 Arquitetura básica de Segurança na WEB . . . . . . . . . . . . . . . . . . . p. 80
7.2 Segurança: Parte do Ciclo de Vida do IBM Rational AppScan . . . . . . . . p. 81
7.3 Modelo de Teias. Fonte: (NAKAMURA; GEUS, 2004) . . . . . . . . . . . . p. 82
7.4 Os elementos de seguraça definem o nível do servidor. Fonte: (NAKA-

MURA; GEUS, 2004) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 84
Lista de Tabelas
1 Categoria para os algoritmos criptográficos de chave pública . . . . . . . . . p. 40
2 Tipos de mensagens do protocolo Handshake . . . . . . . . . . . . . . . . . p. 51
3 Cipher Suites do SSL v3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 54
4 Cipher Suites do TLS v1.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 55
5 Comparativo entre as Ferramentas de Auditoria . . . . . . . . . . . . . . . . p. 88

Lista de abreviaturas e siglas
3DES Triple Data Encryption Standard

AC Autoridade Certificadora
AES Advanced Encryption Standard
AJAX Asynchronous Javascript And XML
CPA Chosen Plaintext Attack
CSRF Cross-site reference forgery
CSS Cross Site Scripting
D-H Diffie-Hellman key exchange
DEA Data Encryption Algorithm
DES Data Encryption Standard
DNS Domain Name System
DNSCurve Domain Name System Curve
DNSSec Domain Name System Security Extensions
DoS attack Denial of Service Attack
DSA Digital Signature Algorithm
ECC Eliptic Curve Cryptography
ECDH Elliptic Curve Diffie-Hellman
ECDSA The Elliptic Curve Digital Signature Algorithm
EFF Electronic Frontier Foundation
FIPS Federal Information Processing Standard
FR Federal Register
FTP File Transfer Protocol
HTTP Hypertext Transfer Protocol
HTTPS HyperText Transfer Protocol Secure
ICP Infra-estruturas de Chaves Públicas
IDEA International Data Encryption Algorithm
IDS Intrusion Detection Systems
IETF Internet Engineering Task Force
IIS Internet Information Services
IKE Internet Key Exchange
IP Internet Protocol
IPES Improved Proposed Encryption Standard
IPS Intrusion Prevention Systems
IPsec Internet Protocol Security
ISO International Organization for Standardization
ITU International Telecommunications Union
ITU-T ITU Telecommunication Standardization Sector
KEA Key Exchange Algorithm
KHMAC Keyed-Hash Message Authentication Code
MAC Message Authentication Code
MD5 Message-Digest Algorithm 5
MD6 Message-Digest Algorithm 6
MIME Multipurpose Internet Mail Extensions
MITM Man in the Middle Attack
NIST National Institute of Standards and Technology
OASIS Organization for the Advancement of Structured Information Stan-
dards
OSI Open Systems Interconnection
PEM Privacy Enhanced Mail
PKI Public-Key Infrastructure
RC4 Rivest Cipher 4
RC5 Rivest Cipher 5
RC6 Rivest Cipher 6
RFC Request for Comments
SAML Security Assertion Markup Language
SHA-0 Secure Hash Algorithm
SHA-1 Secure Hash Algorithm 1
SMTP Simple Mail Transfer Protocol
SOAP Simple Object Access Protocol
SPML Service Provisioning Markup Language
SSL Security Socker Layer
STS Station-to-Station
TCP Transmission Control Protocol
TDEA Triple Data Encryption Algorithm
TDES Triple Data Encryption Standard
TLS Transport Layer Security
TOR The Onion Router
TLS Transport Layer Security
UDP User Datagram Protocol
URL Uniform Resource Locator
VPN Virtual Private Network
W3C World Wide Web Consortium
WAF Web Application Firewall
WASC Web Application Security Consortium
WEP Wired Equivalent Privacy
WPA Wi-Fi Protected Access
WS-Security Web Services Security
XKMS XML Key Management Specification
XML eXtensible Markup Language
XSL eXtended Sparse Linearization
XSS Cross-site Scripting
Sumário
1 Introdução p. 20
2 Conceitos Básicos de Segurança para Aplicações WEB p. 21
2.1 A necessidade de segurança . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 22
2.2 Os serviços disponibilizados pela segurança . . . . . . . . . . . . . . . . . . p. 23
2.2.1 Autenticação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 23
2.2.2 Confidencialidade . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 23
2.2.3 Integridade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 23
2.2.4 Não-repúdio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 24
2.2.5 Controle de Acesso . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 24
2.2.6 Disponibilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 24
2.3 Tipos de ataques contra a Segurança . . . . . . . . . . . . . . . . . . . . . . p. 24
2.3.1 Ataques Passivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 26
2.3.1.1 Liberação do Conteúdo da Mensagem . . . . . . . . . . . p. 26
2.3.1.2 Análise de Tráfego . . . . . . . . . . . . . . . . . . . . . . p. 26
2.3.2 Ataques Ativos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 27
2.3.2.1 Ataque Disfarçado . . . . . . . . . . . . . . . . . . . . . . p. 27
2.3.2.2 Ataque de mensagens repetitivas . . . . . . . . . . . . . . p. 27
2.3.2.3 Modificação de Mensagens . . . . . . . . . . . . . . . . . p. 27
2.3.2.4 Ataque de Negação de Serviço . . . . . . . . . . . . . . . p. 28
2.4 O Problema da segurança no Ambiente WEB . . . . . . . . . . . . . . . . . p. 29
2.4.1 Como solucionar o problema de segurança na WEB . . . . . . . . . . p. 30

3 Criptografia básica p. 32
3.1 Objetivos da Criptografia . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 33
3.2 Algoritmos Simétricos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 33
3.2.1 Codificação em Blocos . . . . . . . . . . . . . . . . . . . . . . . . . p. 34
3.2.1.1 RC5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 34
3.2.1.2 RC6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 35
3.2.1.3 DES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 35
3.2.1.4 TDES . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 36
3.2.1.5 AES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 36
3.2.1.6 Blowfish . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 37
3.2.1.7 Twofish . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 37
3.2.1.8 Serpent . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 37
3.2.2 Codificação em Fluxo . . . . . . . . . . . . . . . . . . . . . . . . . p. 38
3.2.2.1 RC4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 38
3.2.3 Codificação em Blocos ou Codificação em Fluxo . . . . . . . . . . . p. 38
3.3 Algoritmos Assimétricos . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 39
3.3.1 Aplicações para Sistemas Criptográficos de Chave Pública . . . . . . p. 40
3.3.2 Algoritmos criptográficos de chave pública . . . . . . . . . . . . . . p. 41
3.3.2.1 RSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 41
3.3.2.2 Diffie-Hellman . . . . . . . . . . . . . . . . . . . . . . . . p. 41
3.3.2.3 DSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 42
3.3.2.4 Elliptic-Curve Cryptography . . . . . . . . . . . . . . . . p. 42
3.3.2.5 Elliptic Curve DSA . . . . . . . . . . . . . . . . . . . . . p. 43
3.4 Função Hash . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 43
3.4.1 MD5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 43
3.4.2 MD6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 44
3.4.3 SHA-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 44
3.4.4 SHA-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 45
3.4.5 SHA-3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 45
4 Protocolos de Segurança p. 46
4.1 SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 46
4.1.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 47
4.1.2 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 47
4.1.2.1 Record protocol . . . . . . . . . . . . . . . . . . . . . . . p. 48
4.1.2.2 Charge Cipher Spec Protocol . . . . . . . . . . . . . . . . p. 49
4.1.2.3 Alert Protocol . . . . . . . . . . . . . . . . . . . . . . . . p. 50
4.1.2.4 Handshake Protocol . . . . . . . . . . . . . . . . . . . . . p. 50
4.1.3 Funcionamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 50
4.1.3.1 Fase 1: Estabelecimento dos Mecanismos de Segurança . . p. 51
4.1.3.2 Fase 2: Autenticação do Servidor e Trocas de Chaves . . . p. 51
4.1.3.3 Fase 3: Autenticação do Cliente e Trocas de Chaves . . . . p. 52
4.1.3.4 Fase 4: Estabelecimento da conexão segura . . . . . . . . . p. 53
4.1.4 Algoritmos Criptográficos utilizados pelo SSL . . . . . . . . . . . . p. 53
4.2 TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 54
4.2.1 Algoritmos Criptográficos utilizados pelo TLS . . . . . . . . . . . . p. 54
4.2.2 Comparação entre SSL e TLS . . . . . . . . . . . . . . . . . . . . . p. 55
4.3 Integrando SSL/TLS com os Protocolos da Camada de Aplicação . . . . . . p. 56
4.3.1 HTTPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 56
4.4 IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 57
4.4.1 Serviços . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 58
4.5 WS-Security Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 58
4.5.1 SOAP e WEB Services . . . . . . . . . . . . . . . . . . . . . . . . p. 58

4.5.2 WS-Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 59
4.6 SSL/TLS ou WS-Security para mensagens SOAP . . . . . . . . . . . . . . . p. 61
4.7 DNSSec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 62
4.8 DNSCurve . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 63
5 Identificação Digital p. 64
5.1 Certificação Digital . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 64
5.1.1 Assinatura Digital . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 64
5.2 Gerenciamentos de Chaves Públicas . . . . . . . . . . . . . . . . . . . . . . p. 65
5.2.1 Certificados Digitais . . . . . . . . . . . . . . . . . . . . . . . . . . p. 67
5.2.1.1 A Solução do Problema Inicial . . . . . . . . . . . . . . . p. 68
6 Os Ataques p. 69
6.1 Passo 1: Reconhecimento do Alvo . . . . . . . . . . . . . . . . . . . . . . . p. 69
6.2 Passo 2: Verificar a segurança da Rede . . . . . . . . . . . . . . . . . . . . . p. 70
6.3 Passo 3: O Ataque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 71
6.4 Passo 4: “Lá Dentro” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 72
6.5 Exemplos de Ataques Conhecidos . . . . . . . . . . . . . . . . . . . . . . . p. 72
6.5.1 Ataques de Força Bruta . . . . . . . . . . . . . . . . . . . . . . . . . p. 72
6.5.2 Ataque do “Homem do Meio” . . . . . . . . . . . . . . . . . . . . . p. 73
6.5.3 Ataques a Servidores Webs . . . . . . . . . . . . . . . . . . . . . . . p. 73
6.5.3.1 XSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 74
6.5.3.2 Injeção SQL . . . . . . . . . . . . . . . . . . . . . . . . . p. 75
6.5.3.3 CSRF . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 76
6.5.3.4 Phishing . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 76
6.5.3.5 DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . . p. 77
6.5.3.6 Clickjacking . . . . . . . . . . . . . . . . . . . . . . . . . p. 78
7 Auditoria de Segurança a Aplicações Web p. 79
7.1 Arquitetura básica de Segurança na WEB . . . . . . . . . . . . . . . . . . . p. 79
7.2 Modelo de Gerenciamento de Segurança . . . . . . . . . . . . . . . . . . . . p. 81
7.2.1 Modelo de Teias . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 81
7.2.2 A sete fases do modelo . . . . . . . . . . . . . . . . . . . . . . . . . p. 82
7.2.2.1 Fase 1: Definição dos elementos de segurança . . . . . . . p. 82
7.2.2.2 Fase 2: Definição dos recursos . . . . . . . . . . . . . . . p. 82
7.2.2.3 Fase 3: Análise de segurança . . . . . . . . . . . . . . . . p. 82
7.2.2.4 Fase 4: Classificação dos recursos . . . . . . . . . . . . . p. 83
7.2.2.5 Fase 5: Avaliação dos riscos . . . . . . . . . . . . . . . . . p. 83
7.2.2.6 Fase 6: Definição do nível de segurança desejado . . . . . p. 83
7.2.2.7 Fase 7: Definição das medidas de segurança . . . . . . . . p. 83
7.2.3 Resultados apresentados pelo Modelo de Teias . . . . . . . . . . . . p. 84
7.3 Ferramentas de auditoria de segurança . . . . . . . . . . . . . . . . . . . . . p. 84
7.3.1 Ratproxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 85
7.3.2 WebScarab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 85
7.3.3 Paros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 85
7.3.4 Burp Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 86
7.3.5 w3af . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 86
7.3.6 IBM Rational AppScan . . . . . . . . . . . . . . . . . . . . . . . . . p. 86
7.4 Comparativo entre as Ferramentas de Auditoria . . . . . . . . . . . . . . . . p. 88
8 Conclusão p. 89
Referências Bibliográficas p. 91
20
1 Introdução
Atualmente a Internet é um meio de comunicação constante na vida moderna. Esta depen-

dência tecnológica está cada vez mais estimulando o desenvolvimento de aplicações na WEB,
que, consequentemente, aumenta o volume de informações trafegadas na rede. Estas informa-
ções, porém, na maioria das vezes, não contêm uma camada de segurança apropriada e, com
isso, trafegam livremente, ou seja, desprotegidas. Paralelamente, os usuários mal intencionados
estão interessados nesse tráfego de dados, pois podem conter informações sensíveis e sigilo-
sas. Desse modo, o objetivo desse trabalho é determinar um ambiente seguro para as aplicações
WEB e minimizar as vulnerabilidades através das ferramentas de auditoria, como por exemplo o
Ratproxy, o qual realiza uma detecção precisa e sensível dos potenciais problemas de segurança.
Uma aplicação WEB é um termo usado para indicar, de forma geral, os programas proje-
tados para serem acessados através de um navegador WEB (browser). Entretanto, como cada
aplicação situa-se fisicamente em algum servidor de localidade geográfica desconhecida, a co-
municação torna-se totalmente realizada por meio de um canal que por padrão é inseguro — a
Internet. Desse modo, para resolver essas questões relacionadas à segurança existem inúmeros
algoritmos de criptografia e protocolos que provêem uma transmissão segura na WEB.
Infelizmente, a infraestrutura da WEB contém falhas na segurança que permitem os invaso-

res a comprometer o sistema, no qual as aplicações WEB estão em execução. No entanto, estas
falhas são raramente visualizadas quando o programa está sendo executado conforme o previsto.
Enfim, o requisito de segurança na WEB tornou-se uma exigência indispensável, especialmente
para entidades que dependem deste meio de comunicação.
Portanto, o enfoque desse trabalho será o estudo dos mecanismos de segurança aplicados
nas aplicações WEB. No capítulo 2 é abordado os problemas gerais de segurança existentes na
WEB. Já o capítulo 3 introduz o conceito da criptografia básica, o qual consiste a essência da
segurança no mundo virtual. O capítulo 4 descreve os protocolos criptográficos. A identifica-
ção digital, descrito no capítulo 5, apresenta os métodos de autenticação através dos certificados
digitais. O capítulo 6 contém as principais ameaças, vulnerabilidades e tipos de ataques prati-
cados atualmente. E por último, capítulo 7, apresenta modelos de gerenciamento da segurança
e ferramentas para verificar as vulnerabilidades das aplicações.
21
2 Conceitos Básicos de Segurança para

Aplicações WEB
A facilidade da comunicação por meio da Internet está permitindo o crescimento dessa

tecnologia e, simultaneamente, revolucionando os sistemas de informações. Com isso, surgem
oportunidades para o desenvolvimento de aplicações, em grande escala, na Internet. Entretanto,
paralelamente inicia uma preocupação com a segurança dos dados manipulados pelas aplicações
WEB, pois, por padrão a Internet é insegura.
A palavra segurança tornou-se uma obrigação imprescindível não somente no mundo real,
como também no mundo virtual. O universo da segurança é marcado por uma característica
cíclica, pois novas formas de ataque têm como consequência novas maneiras de proteção, o qual
induz à procura de novas vulnerabilidades que levam ao desenvolvimento de novos métodos de
ataque. Neste último passo é que o ciclo se completa. Em outras palavras, é no “ponto” mais
fraco das aplicações que os ataques ocorrem.
Por outro lado, a ausência de segurança nos sistemas, geralmente, tem como resultados
grandes prejuízos (como, por exemplo: interrupção do serviço; transações fraudulentas; roubo
ou modificação de dados; roubo de informações de clientes; perdas financeiras e danos físicos
do sistema) e queda de novas oportunidades de negócios (como, por exemplo: perda da con-
fiabilidade dos usuários resultando queda dos acessos nas aplicações que, consequentemente,
determinam falta de novas proposta de desenvolvimento). Entretanto, quando existe algum
modelo de segurança no ambiente da comunicação, muitas vezes, mostra-se insuficiente para
gerenciar o “complexo” mecanismo de trocas de dados na Internet.
De acordo com Jamsa e Klander (JAMSA; KLANDER, 2002), a Internet e o mundo real
possuem várias características em comum, tais como: paradigmas, problemas e soluções. O
requesito de segurança não podia ser diferente, ou seja, as mesmas atitudes de segurança do
mundo real são aplicadas na Internet. Alguns paralelos interessantes são:
• Firewalls: Funcionalidade equivalente “[. . . ] ao controle de acesso de propriedade (pri-

vada ou pública) no mundo real, por meio de vigias, porteiros, portas e limites físicos
[. . . ]” (Nakamura e Geus, 2004, p7).
2.1 A necessidade de segurança 22
• Política de Segurança: Funcionalidade equivalente “[. . . ] ao modelo de conduta do

cidadão visitante na loja e de procedimentos por parte dos funcionários para garantir o
bom comportamento social dos visitantes e da integridade do patrimônio da loja [. . . ]”
(Nakamura e Geus, 2004, p8).
• Separação entre rede pública (servidores externos) e rede interna: Funcionalidade

equivalente “[. . . ] à separação entre a parte pública da loja, onde os visitantes circulam, e
a parte privada, onde somente os funcionários transitam [. . . ]” (Nakamura e Geus, 2004,
p8).
2.1 A necessidade de segurança
Por meio da Internet é possível conectar-se com qualquer parte do mundo e obter muitas
informações. Porém, é neste mesmo caminho que muitos computadores são invadidos sim-
plesmente pela falta de segurança básica. Ao longo dos últimos anos, a rede virtual tem sido
frequentemente utilizada como “ferramenta” para fraudar os dados públicos e privados.
Segundo o autor Vivo (VIVO et al., 1998), a Internet foi desenvolvida por meio de esforços
acadêmicos com o principal objetivo de compartilhar informações. No entanto, dentre alguns
componentes da Internet, a segurança foi conscientemente tratada para facilitar o comparti-
lhamento dos dados. Entretanto, esta “liberdade” negociada estimula, indiretamente, a fraqueza
dos softwares. Dessa maneira, junto com a falta de conhecimento prévio do assunto, uma grande
quantidade de usuários está vulnerável aos ataques virtuais. Isto ocorre porque, na maioria das
vezes, os usuários não estão cientes da natureza das invasões e ainda acreditam que uma “boa”
senha é o único fator com que precisam se preocupar para se proteger dos intrusos.
De acordo com Salomon (SALOMON, 2003), a falta de segurança nas aplicações WEB
associado ao pensamento de que nenhum intruso irá descobrir as suas vulnerabilidades, pode
ou irá, resultar em um risco muito grande, pois é meramente questão de tempo para algum
indivíduo descobrir as brechas existentes na aplicação. Os prejuízos podem ser tanto danos
financeiros quanto morais. Por exemplo, qualquer incidente de segurança que ocorrer em um
bank-online, por mínimo que seja, fará com que os clientes percam a confiabilidade dos ser-
viços fornecidos deste banco, ou seja, o cliente terá receio de realizar transações bancárias
on-line. Além disso, se o intruso conseguir realizar um roubo virtual, o banco irá sofrer algu-
mas consequências como estornar o dinheiro roubado do cliente e se recompor moralmente aos
usuários.
Por isso que, atualmente, providenciar a camada de segurança nas aplicações WEB é uma
2.2 Os serviços disponibilizados pela segurança 23
questão de necessidade e não somente uma possibilidade. No entanto, somente a sua presença
não irá garantir a proteção propriamente dita, é necessário também gerenciá-la, devido ao fato
de que a cada dia novas vulnerabilidades são descobertas e, consequentemente, novos ataques
são realizados. Diante disso, é possível afirmar que não existe uma aplicação 100% segura.
Assim, o ideal é estabelecer o máximo de segurança possível para que as informações não
sejam apossadas pelos invasores, pois uma segurança planejada já é o suficiente para dificultar
os atos ilícitos.
2.2 Os serviços disponibilizados pela segurança
De acordo com Stallings (STALLINGS, 2007), o padrão Recomendation X.800 (ITU-T,

1991) junto com as especificações da ISO (ISO, 2009) (International Organization for Stan-
dardization) definem os serviços de segurança para garantir uma proteção adequada na transfe-
rência de dados entre sistemas.
2.2.1 Autenticação
O serviço de autenticação está estritamente relacionado para garantir a veracidade do ele-

mento da comunicação. Este serviço pode envolver: a confirmação da identidade de uma pes-
soa, as origens de um objeto ou assegurar se algum software é confiável. Em outras palavras,
deve garantir se cada entidade é realmente o que declara ser.
2.2.2 Confidencialidade
A confidencialidade é definida pela ISO (ISO, 2009) (International Organization for Stan-
dardization) como a garantia de que a informação seja somente acessível entre os indivíduos
autorizados. Este serviço é a essência dos sistemas criptográficos, colocando em prática as mo-
dernas técnicas de codificação. A confidencialidade é necessária, mas não o suficientemente
para manter a privacidade das informações.
2.2.3 Integridade
A integridade é o serviço que promove a garantia de que as informações trafegam até seu
destino de modo autêntico e genuíno, ou seja, significa que os dados não podem ser modifica-
dos sem autorização. A integridade é violada quando, por exemplo, um indivíduo com intenção
2.3 Tipos de ataques contra a Segurança 24
maliciosa modifica dados importantes ou mesmo quando um usuário não autorizado altera in-
formações confidenciais.
2.2.4 Não-repúdio
O serviço não repúdio impede, tanto o emissor quanto o receptor, de negar a transmissão das
mensagens. O processo funciona da seguinte maneira: (1) quando uma mensagem é enviada, o
destinatário consegue provar que a mensagem foi realmente expedida pelo suposto emissor; (2)
quando a mensagem é recebida, o emissor pode provar que a mensagem foi de fato aceita pelo
alegado receptor. Este serviço é muito utilizado nas assinaturas digitais.
2.2.5 Controle de Acesso
O acesso às informações protegidas é restrito às entidades que realmente possuem autori-

zação para acessá-los. O processo deste mecanismo funciona basicamente da seguinte maneira:
cada indivíduo que tenta realizar algum acesso na aplicação deve primeiro ser identificado pela
camada de autenticação, que posteriormente irá receber a lista dos direitos de acesso que lhe foi
designado.
2.2.6 Disponibilidade
O serviço de disponibilidade garante que toda informação tem a obrigatoriedade de estar

disponível quando for solicitada. Isto significa que os sistemas (utilizados para armazenar e
processar as informações), os controles de segurança (que as protegem) e os canais de comu-
nicação (como meio de acesso) devem estar funcionando corretamente. A alta disponibilidade
das aplicações indica que todos os recursos envolvidos no acesso de alguma informação, estão
disponíveis, evidenciando que as interrupções de serviço ocorrem com a mínima frequência.
Garantir a disponibilidade também indica a prevenção dos ataques denial-of-service.
2.3 Tipos de ataques contra a Segurança
Tecnicamente, através de uma visão macroscópica, toda aplicação WEB ou sistemas em

gerais são entidades caracterizadas por fornecer e receber informações. De acordo com Stalling
(STALLINGS, 2007), normalmente há um fluxo de dados entre uma fonte emissora e fonte re-
ceptora, e dependendo do ato praticado neste fluxo poderá ser classificado como um ataque. O
fluxo normal é ilustrado na figura 2.1a, e as demais ilustrações esquematizam às quatro catego-
rias gerais de ataque:
Fig. 2.1: Tipos de ameaça à segurança. Adaptado de (STALLINGS, 1999)
• Interrupção: É o ataque que afeta a disponibilidade do sistema, ou seja, quando o

sistema é destruído ou se torna indisponível ou inutilizável. Segundo Neumann (NEU-
MANN, 2008), existe um ataque chamado Phlashing que atua no mecanismo de atuali-
zação de firmware1 que pode ser realizado remotamente através da Internet, e se for bem
sucedido, obriga as vítimas a substituir os equipamentos;
• Intercepção: É o ataque que afeta a confidencialidade do sistema , isto é, entidades

(pessoas, programas ou computadores) sem autorização conseguem adquirir acesso em
algum recurso do sistema. Exemplos incluem “grampos” para capturar dados da rede, ou
seja, cópia não autorizada de arquivos ou de programa;
• Modificação: É o ataque que afeta a integridade do sistema, ou seja, terceiros sem

autorização não somente conseguem adquirir acesso em algum recurso do sistema, como
também modificá-los sem autorização com a intenção de causar danos;
• Fabricação: É o ataque que afeta a autenticidade,isto é, terceiros sem autorização inse-

rem objetos falsificados no sistema. Como por exemplo, inserção de falsas mensagens na
rede ou a adição de registros em algum arquivo.
1O termo firmware é o conjunto de instruções programadas diretamente no hardware de um equipamento
eletrônico.
Estes ataques são também classificados em duas vertentes, conhecidos como ataques passi-
vos e ataques ativos, termos utilizado nos padrões X.800 (ITU-T, 1991) e RFC 2828 (SHIREY,
2007).
2.3.1 Ataques Passivos
Os ataques passivos são caracterizados por apenas realizar escutas ou monitoramento não
autorizado das transmissões dos dados na rede, ou seja, caracteriza-se pela intercepção das men-
sagens sem modificá-las. Existem dois tipos de ataques passivos: release of message contents
(“liberação do conteúdo da mensagem”) e traffic analysis (“análise de tráfego”).
Por não implicar em qualquer alteração das informações, os ataques passivos são muito di-
fíceis de serem detectados. Isso acontece porque, tipicamente, a mensagem é enviada e recebida
normalmente, e nem o remetente nem receptor está ciente de que algum terceiro tenha feito a
leitura ou observação dos padrões de tráfego da mensagem. Entretanto, com o uso da cripto-
grafia tem a possibilidade de impedir o sucesso desses ataques. No entanto, deve-se priorizar a
prevenção ao invés do tratamento dos ataques passivos.
2.3.1.1 Liberação do Conteúdo da Mensagem
As trocas de informações realizadas por meio de mensagens eletrônicas (e-mail), conversas

telefônicas e transferência de arquivos, às vezes inclui dados sigilosos, e com isso, um intruso
qualquer pode estar apenas interessado no conhecimento prévio das informações secretas. Deve
evitar que os oponentes possam ler o conteúdo dessas transmissões.
2.3.1.2 Análise de Tráfego
Análise de tráfego é o processo de interceptar e analisar as mensagens, com objetivo de

deduzir informações a partir dos padrões de comunicação. Este método pode ser realizado até
mesmo quando as mensagens são criptografadas e não é preciso descriptografá-las. A essên-
cia deste ataque é feita por meio de acompanhamento da frequência, da periodicidade e do
tamanho dos pacotes trocados na rede. As informações analisadas são úteis para adivinhar os
dados originais. A análise de tráfego não é somente utilizada por intrusos, mas também por
um administrador de segurança com o objetivo de ter um profundo conhecimento da própria
rede, como: quais serviços estão disponíveis, quais os sistemas operativos que estão em uso, e
vulnerabilidades que a rede pode estar exposta.
2.3.2 Ataques Ativos
Diferentemente dos ataques passivos, os ataques ativos são caracterizados pela alteração
das informações transmitidas ou pela criação de novos fluxos de dados. Estes ataques podem
ser subdivididos em quatro categorias: masquerade attacks, message replay, modification of
messages e denial of service.
2.3.2.1 Ataque Disfarçado
O masquerade attacks (“ataque disfarçado”), como o próprio nome sugere, é o ataque onde
o invasor assume a identidade legítima, a fim de adquirir o controle de acesso ao sistema ou
as informações sigilosas. Em outras palavras, este ataque ocorre quando a entidade pretende
disfarçar-se por outra entidade já existente. O “ataque disfarçado” pode ser incorporado nas
outras categorias de ataques ativos.
2.3.2.2 Ataque de mensagens repetitivas
O ataque message replay (“mensagem repetitiva”) envolve a captura passiva de informações

válidas e sua subsequente retransmissão para produzir efeitos autorizados. Isto é, envolve a
reutilização dos dados capturados o qual depois de um intervalo de tempo são retransmitidos de
forma maliciosa, a fim de repetir alguma ação original válida recentemente feita pelo usuário
autorizado. Este ataque está ilustrado na figura 2.2.
Fig. 2.2: Ataque Ativo: Ataque de mensagens repetitivas. Adaptado de (STALLINGS, 2006)
2.3.2.3 Modificação de Mensagens
O modification of messages (“modificação de mensagens”) como o próprio nome sugere, é o

ataque no qual uma parte da mensagem legítima é alterada, ou as mensagens são atrasadas, com
objetivo de produzir um efeito não autorizado no sistema. Este ataque também pode envolver
a alteração do cabeçalho de endereço do pacote com o propósito de redirecioná-lo para um
destino não intencional ou modificar os dados do usuário. Observe a figura 2.3.
Fig. 2.3: Ataque Ativo: Modification of Messages. Adaptado de (STALLINGS, 2006)
Um exemplo deste método é “ataque do homem do meio”, cujo termo em inglês é Man-in-
the-Middle Attack. Este ataque é uma forma de escuta feita por meio de conexões indepen-
dentes com as vítimas e realizado pelo intruso. Após receber os dados o atacante retransmite
as mensagens entre as vítimas, fazendo-os acreditar que eles estão falando diretamente uns
aos outros durante a comunicação. Na realidade, toda a conversa é controlada pelo atacante.
A maioria dos protocolos criptográficos inclui alguma forma de autenticação especificamente
para impedir ataques MITM. Por exemplo, o SSL autentica o servidor usando uma autoridade
certificadora mutuamente confiável.
2.3.2.4 Ataque de Negação de Serviço
O denial of service attacks (DoS) é o ataque cujo objetivo é tentar tornar os recursos de um
sistema indisponíveis para seus utilizadores. Conhecido também pelo termo DoS Attacks, este
ataque não se trata de uma invasão do sistema, mas sim da sua invalidação pela sobrecarga. Veja
a ilustração2.4. Isto é, as obstruções dos serviços são realizadas pelo sobrecarregamento da rede
da vítima, devido ao envio de múltiplas mensagens (por exemplo, pedidos de serviços) resul-
tando no travamento ou na reinicialização forçada do sistema da vítima por causa do aumento
significativo do consumo de todos os recursos (por exemplo: memória ou processamento). O
resultado é um serviço com uma funcionalidade inadequada ou, no pior dos casos, a ausên-
cia temporária do mesmo. Os autores dos ataques DoS tipicamente preferem alvos como sites
ou serviços hospedados em servidores WEB de alta visibilidade (por exemplo: bank on-line,
cartões de crédito e aplicações e-commerce.
2.4 O Problema da segurança no Ambiente WEB 29
Fig. 2.4: Ataque Ativo: Ataque DoS. Adaptado de (STALLINGS, 2006)
2.4 O Problema da segurança no Ambiente WEB
Os usuários finais, ou seja, as pessoas que usufruem das aplicações WEB, estão expostas
a vários riscos de segurança e de privacidade quando utilizam a Internet. Outro problema é
a vulnerabilidades do browser o qual tem grande chances em comprometer a segurança dos
cliente na WEB, de acordo com os autores Garfinkel e Spafford (GARFINKEL; SPAFFORD,
2002). No entanto, o único contato que os usuários possuem com as aplicações é através dos
navegadores WEB. Em muitos casos, estes navegadores são utilizados sem a mínima precaução
e configurados pelo próprio proprietário do computador o qual não possui conhecimento prévio
de segurança. E, segundo Wadlow e Vlad (WADLOW; GORELIK, 2009), os browser são o
centro da experiência com a Internet e, consequentemente, o centro de muitos dos problemas
de segurança que afligem os usuários e desenvolvedores de aplicações WEB.
As informações sobre o usuário, como por exemplo: o login, o nome do computador, o

tipo do sistema operacional, o nome do navegador WEB, o número IP da máquina local; são
dados valiosos e frequentemente coletados pelos invasores com objetivo de gerar um perfil de
usuário válido. Estes dados são relativamente fáceis de serem capturados, porque a maioria
dos navegadores WEB trabalham com os cookies — um arquivo onde armazena os dados da
máquina do cliente e as informações trocadas entre o cliente e a aplicação WEB. Isto é, roubando
os cookies o invasor facilmente irá criar um perfil válido da vítima. Por este motivo que uma
das maiores preocupações de segurança na WEB é a garantia de que a privacidade do usuário
não seja violada.
Outro problema de segurança na WEB é a vulnerabilidade que ocorre através de conteúdos

executáveis, os quais são obtidos pela aplicação WEB e executados na própria máquina do cli-
ente, tais como: Applets2 , controles de ActiveX 3 , AJAX 4 . Estas ferramentas permitem, que uma
parte da página WEB, em chamar um procedimento remoto de um servidor através da Internet
e utilizar os resultados dessa chamada, no próprio contexto da própria inicial. São mecanismos
poderosos, mas que podem facilitar os ataques. Outra forma de roubar informações da vítima
é através das páginas quem “empurram” os conteúdos da WEB aos usuários finais. Esta atitude
pode resultar no envio de algum software capaz de explorar vulnerabilidades do navegador e,
posteriormente, o envio de outros códigos maliciosos executáveis para roubar as informações
desejadas, como, por exemplo, as aplicações desenvolvidas em Flash, JavaScript ou Java, os
quais permitem que softwares desenvolvidos nestas linguagens, por terceiros desconhecidos,
funcionem dentro do navegador WEB.
Segurança na WEB, então, é um conjunto de procedimentos, práticas e tecnologias cujo

objetivo é garantir a confiança entre as operações previsíveis entre os servidores WEBs, os
navegadores WEBs e outros programas que se comunicam entre si e, também, com as outras
infraestrutura ao redor da Internet. Assim, segundo Garfinkel e Spafford (GARFINKEL; SPAF-
FORD, 2002), infelizmente, a complexidade da WEB torna o seu problema de segurança mais
complexo do que o problema de segurança da Internet em geral. Portanto, há uma forte ne-
cessidade de desenvolver novos meios de controle de acesso, ou aprimorar os existentes, para
neutralizar as ameaças à segurança e resolver as diversas vulnerabilidades de segurança das
aplicações executadas na WEB.
2.4.1 Como solucionar o problema de segurança na WEB
Segundo o Lam (LAM et al., 2008), a maioria das vulnerabilidades em aplicações WEB
ocorre por permitir a entrada de dados sem respectiva validação e, o resultado, as vezes é o
controle total do sistema, pois as “informações” enviadas pelo invasor podem ser comandos
reais para danificar tanto o servidor quanto a aplicação WEB. Dessa maneira, o problema de
segurança da WEB pode ser solucionado, basicamente, através de três atividades, as quais de
acordo com Noureddine e Damodaran (NOUREDDINE; DAMODARAN, 2008):
1. Proteger o servidor WEB e os respectivos dados internos: Deve-se garantir que as ope-
rações do servidor não sejam interrompidas, e que as informações armazenadas interna-
2 Um applet é um componente de software que é executado no contexto de outro programa, por exemplo, um
navegador da WEB.
3 Os controles ActiveX são pequenos blocos de código que serve para criar aplicações distribuídas no qual a
execução ocorre por meio da Internet através dos browsers. Exemplos incluem aplicações personalizadas para
obter dados dos usuários, visualização de determinados tipos de arquivos e entre outras.
4 AJAX é o uso metodológico de tecnologias como Javascript e XML, providas por navegadores, para tornar
páginas Web mais interativas com o usuário, utilizando-se de solicitações assíncronas de informações.
mente não seja modificadas sem uma autorização legítima, e ainda, é somente permitido
distribuí-las para os usuários autorizados;
2. Proteger as informações que trafegam entre o servidor e o usuário: Todas as infor-

mações fornecidas pelo usuário para o servidor WEB quanto do servidor para o usuário
(usuário, senhas, informações financeiras, os nomes das páginas visitadas, dentre ou-
tras) não podem ser visualizadas, modificadas ou destruídas por terceiros não autorizados.
Também é importante garantir que a relação entre o usuário e o servidor WEB não seja
facilmente corrompível;
3. Planejar uma arquitetura de segurança: As aplicações WEB devem ser desenvolvidas

obedecendo um modelo de segurança;
4. Proteger os computadores do usuário final e outros dispositivos utilizados para aces-

sar a Internet: Finalmente, a segurança na Internet requer que o computador do usuário
esteja razoavelmente seguro. Isto é, os usuários precisam executar seus browsers e outros
softwares em uma plataforma de computação segura e livre de vírus e outros softwares
hostis.
As três primeiras atividade são fatores controláveis pela administração do sistema através
dos equipamentos de segurança (como, por exemplo, criptografia, protocolos criptográficos,
identificação digital), porém a última é de responsabilidade do usuário, e com isso, difícil de
garantir a proteção neste nível. Portanto, assegurar a proteção dos quatro itens acima é garantir
a segurança das aplicações na WEB e, assim, minimizará os problemas dos frequentes ataques
na Internet.
32
3 Criptografia básica
A criptografia está cada vez mais sendo utilizada para garantir a segurança e a privacidade
das informações. A partir do uso da Internet como um meio alternativo para transferir infor-
mações eletrônicas e junto com a falta de segurança da rede, inspiraram-se no estudo desta
ferramenta como uma maneira de proteção para os dados eletrônicos. Entretanto, a essência
criptografia é esconder o significado de mensagens e não a existência delas. De acordo com
Khalifa (KHALIFA et al., 2004), a criptografia é palavra de origem etimológica grega que pos-
sui o seguinte significado: ckryptós, “escondido” e gráphein, “escrever”.
Fig. 3.1: Modelo de Criptografia. Adaptado de (KRAUSE; TIPSON, 1998)
Considerado arte e ciência matemática, a criptografia consiste em transformar um texto ori-

ginal (plaintext) ou texto claro (cleartext) em um texto ilegível, ou seja, texto cifrado (cipher-
text) ou texto código (codetext), por meio de um algoritmo (cipher), dificultando a leitura da
mensagem original para que apenas o emissor e o receptor possam ter acesso aos dados com
segurança (SAKALLI et al., 2004). Às vezes, existe alguma entidade que pode não somente
ouvir a comunicação do canal — chamando de intruso passivo — mas também pode modificar
mensagens legítimas antes mesmo do receptor recebê-la — intruso ativo (ver figura 3.1).
3.1 Objetivos da Criptografia 33
3.1 Objetivos da Criptografia
Segundo Khalifa (KHALIFA et al., 2004), a criptografia é necessária no momento em que

há uma comunicação realizada através de um canal não confiável, como por exemplo, a Internet.
A principal característica da criptografia é assegur os requisitos básicos de segurança, dentre os
quais, os principais são:
1. Autenticação do emissor: O processo de comprovação de uma identidade. O receptor

tem que ter a capacidade de identificar o emissor e realizar uma verificação para garantir
que o próprio remetente enviou a mensagem.
2. Privacidade/confidencialidade da mensagem: Garantir que ninguém pode ler a mensa-

gem, exceto os receptores. Isto é, somente o destinatário autorizado possui a capacidade
de extrair o assunto da mensagem do modo codificado.
3. Integridade da mensagem: Estabelecer uma garantia ao receptor de que a mensagem

recebida não foi alterada desde o momento que o remetente a enviou. Caso ocorra a
modificação, o destinatário deverá ser capaz de reconhecer este ato.
4. Não-repúdio ou irretratabilidade do emissor: Propõem que o remetente realmente tem

enviado esta mensagem. Isto é, não deve haver a possibilidade do remetente rejeitar a
autoria da mensagem.
3.2 Algoritmos Simétricos
Nos algoritmos de chave única, também chamada de sistema de chave simétrica, os proces-
sos de codificação e de decodificação utilizam a mesma chave. Esta deve apenas ter conheci-
mento entre o emissor e o receptor, e também, ser armazenada num ambiente seguro. A figura
3.2 ilustra, esquematicamente, uma criptografia simétrica. No entanto, é necessário que a chave
seja transmitida de uma entidade à outra por meio de um canal seguro. Logo, se a segurança do
canal for comprometida e a chave interceptada, o usuário mal intencionado poderá decifrar as
mensagens facilmente.
Para que um algoritmo simétrico seja considerado eficiente são necessários os seguintes
aspectos, segundo Lima (LIMA, 2008): (1) ser resistente às técnicas de criptoanálise1 ; (2) ter a
capacidade de gerar uma chave com um tamanho grande de número de bits; (3) ser facilmente
1 Criptoanálise é o área da criptologia que descodifica ou decifra uma mensagem sem ter conhecimento da chave
secreta.
3.2 Algoritmos Simétricos 34
Fig. 3.2: Esquema de uma criptografia simétrica.
implementado em hardware; (4) o algoritmo pode ser de domínio público; (5) ser resistente à
ataque de força bruta2 ; (6) ser rápido — sendo que esta medição tem que ser realizada através da
comparação com outros algoritmos simétricos. A criptografia simétrica é divida em dois tipos
de algoritmos: codificação em blocos (Block ciphers) e codificação em fluxo (Stream Cipher).
3.2.1 Codificação em Blocos
Segundo Liskov (LISKOV et al., 2002), na criptografia, uma codificação em blocos é um

tipo de chave simétrica que trabalha com grupos de tamanho fixo de bits, frequentemente de
64 ou 128 bits, os quais são denominamos blocos. Assim, para realizar uma codificação de
uma mensagem qualquer, deve-se obter, por exemplo, um bloco de 128 bits do texto original
de entrada, e de saída um bloco correspondente, também de 128 bits, porém codificado. No
entanto, a transformação exata é controlada com a utilização de uma segunda entrada: a chave
secreta. Já o processo de decodificação é semelhante, porém o processo é invertido.
3.2.1.1 RC5
O algoritmo RC5 (RIVEST, 1994) foi projetado pelo professor Ron Rivest no Instituto
de Tecnologia de Massachusetts em 1994, o qual em 1997 foi registrado como RFC 2040
(BALDWIN; RIVEST, 1996). É uma cifra simples e rápida, cuja parametrização é realizada
pelas seguintes entidades: tamanho do bloco, iterações3 (the number of rounds) e comprimento
da chave, respectivamente. Estes parâmetros podem ser ajustados, de acordo com a necessidade
do usuário, tais como: segurança e desempenho. O RC5 pode conter blocos de tamanho variá-
vel (32, 64 ou 128 bits), e chave alternando de 0 a 2040 bits. No entanto, a especificação RFC
2040 sugere que os valores do bloco e da chave sejam de 64 e 128 bits.
A RSA Security ofereceu uma recompensa de U$$10.000 para quem conseguir quebrar
2 Em ciência da computação, força bruta (ou busca exaustiva) é uma algoritmo trivial mas de uso muito geral
que consiste em enumerar todos os possíveis candidatos de uma solução e verificar se cada um satisfaz o problema.
3 Número de repetições de um processo para uma mesma função
um texto codificado pelo RC5. No entanto, este concurso foi interrompido em maio de 2007,
pela organização denominada Distributed.net (DISTRIBUTED.NET, 2009)4 , a qual utilizando
ataques de força-bruta em mensagens codificada com chaves de 56 e 64 bits, afirmou que a
partir de janeiro de 2009 este ataque estaria 0,5% completado. Isto é, neste ritmo, seria neces-
sário pelo menos mil anos para testar todas as possibilidades de chaves, para então finalizar o
projeto(RIVEST, 1994).
3.2.1.2 RC6
O RC6(RIVEST et al., 1998) é um algoritmo simétrico derivado do antecessor, RC5, proje-

tado pelos professores Ron Rivest, Matt Robshaw, Ray Sidney, e Yiqun Lisa Yin para atender às
exigências da competição da AES (Advanced Encryption Standard, conseguindo alcançar um
dos cincos finalistas, porém não selecionado para o AES. As modificações feitas, entre o RC5 e
o RC6, foram para cumprir os requisitos AES: aumentar a segurança e melhorar o desempenho.
Uma utilização adequado do RC6 é com blocos de 128 bits de tamanho e chaves de 128, 192 e
256 bits de comprimento, porém, como o RC5, o RC6 pode ser parametrizado para apoiar uma
ampla variedade do tamanho do bloco, da iteração e do comprimento da chave. Lembrando que
RC6 é um algoritmo proprietário, patenteado pela RSA Security.
3.2.1.3 DES
O algoritmo de criptografia DES acrônimo para (Data Encryption Standard) (NIST, 1999)
surgiu em meados dos anos 1970 quando o governo norte americano sentiu a necessidade de
projetar um modelo federal de criptografia para garantir o sigilo de suas informações, represen-
tado pela sigla FIPS PUB 46-3. Assim, em 1976 o DES foi desenvolvido pela IBM. A chave
simétrica DES é formada por 64 dígitos binários, dos quais 56 bits são gerados aleatoriamente
e usada diretamente pelo próprio algoritmo – conhecido como DEA. Os oitos bits restantes
são utilizado com a finalidade de detecção de erros. Enfim, o DES foi projetado para cifrar e
decifrar blocos de dados de 64 bits sob o controle de uma chave de 64 bits ou 8 bytes.
O DES, atualmente, é considerado inseguro, pois em julho de 1998 a organização EFF 5
(EFF, 1998) conseguiu quebrar uma chave DES de 56 bits em coincidentes 56 horas, por meio
de uma máquina, fabricada pela própria EFF, denominada EFF DES cracker e apelidada como
“Deep Crack)”. O Deep Crack conseguiu romper a chave DES por meio de ataque de força
bruta, pois a finalidade da EFF era provar que as cifras DES não era suficientemente longa para
4A organização distributed.net foi o primeiro projeto da Internet para fins gerais de computação distribuída.
5A Electronic Frontier Foundation é uma das principais organizações de liberdades civis garantindo que a
privacidade e a segurança de todas as comunicações on-line devem ser preservados
se julgar seguro. No entanto, em janeiro de 1999, o tempo da violação da chave DES caiu para
22 horas e 15 minutos, façanha realizada pela EFF e distributed.net através do aprimoramento
do “Deep Crack”. Portanto, atualmente a criptografia DES não é mais utilizada porque sua
fragilidade compromete a segurança de uma aplicação.
3.2.1.4 TDES
O algoritmo de criptografia TDES (BARKER, 2004), também conhecido como 3DES, Tri-
ple DES, e por último TDES, foi desenvolvindo baseado no seu antecessor o DES. O algoritmo
criptográfico propriamente dito é denominado como Triple DEA ou TDEA. Segundo Stallings
(STALLINGS, 1999) o TDEA utiliza três chaves de 56 bits e três execuções do algoritmo DES.
O processo de codificação do Triple DES é realizada na seguinte sequência: Encrypt-Decrypt-
Encrypt — EDE (Cifrar-Decifrar-Cifrar). Basicamente, a cifragem ocorre da seguinte maneira:
C = EK3 [DK2 [EK1 [P]]], onde K1 , K2 e K3 são as respectivas chaves secretas; C é o texto ci-
frado e P o texto puro. Já o processo de decodificação é simplesmente a operação invertida:
Decrypt-Encrypt-Decrypt — DED (Decifrar-Cifrar-Decifrar), ou seja, P = DK1 [EK2 [DK3 [C]]].
Com três chaves distintas, o Triple DES, pensando como um todo, possui uma chave efetiva
de 168 bits. De acordo com FIPS 46-3 também possibilita a utilização do algoritmo TDEA
com apenas duas chaves (K1 = K3 ), resultando em uma chave única de 112 bits. Segundo Ba-
rison (BARISON, 2006) com o uso da técnica de criptoanálise, uma chave de tamanho efetivo
de 112 bits seria reduzido para 80 bits comprometendo a segurança das informações. No en-
tanto, Stallings (STALLINGS, 1999) afiram que com a utilização de uma cifra de 168 bits de
comprimento, os ataques de força-bruta são efetivamente impossíveis de acontecer.
3.2.1.5 AES
Como proposta de substituir o algoritmo TDES, a NIST anunciou um concurso criptográ-

fico em janeiro de 1997, no qual vários pesquisadores enviaram suas propostas para representar
o novo padrão criptográfico norte-americano: o AES (Advanced Encryption Standard). Depois
de 5 anos, em 26 novembro de 2001, a NIST anunciou o algoritmo vencedor, o qual foi padro-
nizado oficialmente como U.S. FIPS PUB (FIPS 197) (NIST, 2001). No entanto, somente em
26 de maio de 2002 que o AES foi efetivamente padronizado.
Os autores vencedores e responsáveis pelo novo padrão de criptografia avançada foram

dois belgas Vincent Rijmen e Joan Daemen — melhor conhecido como Rijndael (DAEMEN;
RIJMEN, 1999), resultado da fusão de seus sobrenomes. Rijndael é uma cifra de bloco simétrica
que processa bloco de dados com 128 bits de comprimento, utilizando chaves com tamanhos
de 128, 192 e 256 bits. Segundo Stallings (STALLINGS, 1999), a NIST estabeleceu alguns
critérios de avaliações, bem como: segurança, eficiência computacional, memória utilizada,
sustentabilidade do hardware e do software e flexibilidade. Todos requesitos foram garantidos
pelo algoritmo Rijndael.
De acordo com Lima (LIMA, 2008) o AES é mais rápido, requer pouca memória e pode
ser implantado com pouca dificuldade tanto hardware quanto em software. Atualmente, o AES
está sendo utilizado em inúmeras aplicações Web, como e-commerce, e oferece suporte aos
protocolos SSL/TSL. De acordo com Barison (BARISON, 2006) e até o presente momento não
se conhece nenhum ataque de criptoanálise que tem o poder de reduzir o tamanho da chave de
uma forma significativa.
3.2.1.6 Blowfish
O algoritmo criptográfico simétrico Blowfish (SCHNEIER, 1994) foi desenvolvido em

1993 por Bruce Schneier (SCHNEIER, 1993), um consultor independente e criptógrafo, e ra-
pidamente se tornou uma das mais populares alternativas para o DES. O Blowfish opera com
blocos de cifra de 64 bits de tamanho e pode gerar chaves de 32 a 448 bits de comprimento. No
entanto, na prática chaves de 128 bits são utilizadas, de acordo com Stallings. Na época que
o Blowfish foi liberado, muitos outros algoritmos eram proprietários, ou seja, sobrecarregados
por patentes. Entretanto, Schneier (SCHNEIER, 1993) afirmou que Blowfish é livre, isto é, não
possui qualquer patente e pode ser utilizado livremente por qualquer pessoa.
3.2.1.7 Twofish
O Twofish (SCHNEIER, 1998) é um algoritmo de chave simétrica projetado também pelo

Bruce Schneier (SCHNEIER et al., 1999). O Twofish opera com blocos de cifra de 128 bits de
tamanho e pode gerar chaves superiores a 256 bits de comprimento. Lima (LIMA, 2008) afirma
que o Twofish foi participante do concurso AES (NIST, 2001) proposto pela NIST e foi um dos
finalistas. No entanto, não foi selecionado para a padronização. O Twofish não possui patente e
sua licença de utilização é livre e disponibilizada em domínio público.
3.2.1.8 Serpent
O algoritmo de chave simétrica Serpent (ANDERSON et al., 1998) foi projetado em 1998
pelos autores: Ross Anderson, Eli Biham, e Lars Knudsen, e conseguiu ser um dos finalista do
concurso AES, ocupando a posição de segundo lugar. Serpent trabalha com bloco de cifra de
128 bits de tamanho e suporta chaves de 128, 192 or 256 bits de comprimento. A cifra Serpent
não foi patenteada. É completamente de domínio público e pode ser utilizada livremente por
qualquer pessoa. O ataque XLS 6 , se for eficaz, enfraqueceria Serpent – embora não tanto como
enfraqueceria o Rijndael, que se tornou AES. No entanto, muitos criptoanalistas acreditam que
um ataque XSL seria mais “caro” do que um ataque de força bruta.
3.2.2 Codificação em Fluxo
Os algoritmos de chave simétrica possuem o conjunto dos straem cipher (cifra de fluxo).
A principal característica desta é que a codificação do texto original ocorre byte por byte ou bit
por bit. Isto é, processa os elementos de entrada continuamente, produzindo um elemento de
saída por vez.
3.2.2.1 RC4
O algoritmo RC4 (KAUKONEN; THAYERS, 1999), foi desenvolvido pelo professor Ron
Rivest em 1987, assim como o RC2, RC5 e RC6. É utilizado nos protocolos SSL/TSL, WEP
e WPA; e possui grande utilização nos famosos softwares como Internet Explorer, Lotus No-
tes, Apple Computer’s AOCE, Oracle Secure SQL, Netscape e Adobe Acrobat. Mantido em
segredo comercial, o RC4 foi publicado na internet em setembro de 1994. Suporta chaves de
comprimentos de 1 a 256 bytes ou 8 à 2048 bits, embora notável pela sua simplicidade e rapi-
dez no software, o RC4 possui algumas fragilidades que argumentam contra a sua utilização no
projeto de novos sistemas, devido ao comprimento variável, algumas chaves geradas pode ser
consideradas muito fracas.
3.2.3 Codificação em Blocos ou Codificação em Fluxo
Os estudos dos algoritmos de chaves simétricas referem-se ao conhecimento da codificação

em blocos e codificação em fluxo. Entretanto, segundo Stallings (STALLINGS, 1999), para
cada tipo de aplicação é desejada uma determinada cifra, para que a criptografia ocorra da
melhor maneira possível. Assim, para um software que trabalha com grande fluxo de dados
e requer constantemente a codificação/decodificação das informações, a cifragem em fluxo é
mais apropriada. Por outro lado, para aplicações que operam com blocos de dados, tais como
transferência de arquivos, e-mail e banco de dados, a codificação em blocos pode ser mais
adequada. Entretanto, ambos os tipos podem ser utilizados em qualquer aplicação.
6O ataque XLS é um método de criptoanálise para cifras de blocos
3.3 Algoritmos Assimétricos 39
3.3 Algoritmos Assimétricos
A distribuição das chaves secretas no sistema criptográficos simétricos proporciona uma

vulnerabilidade na segurança. Não interessa quão seguro é o algoritmo de criptografia simé-
trica, o que realmente importa é se algum intruso conseguir roubar a chave secreta, o sistema
criptográfico torna-se automaticamente inseguro e inútil. Entretanto, existe um ponto fraco na
segurança da criptografia simétrica: a distribuição das chaves para todos os usuários do sistema.
Dessa forma, as chaves tinham que ser protegidas contra roubo e distribuídas aos usuários.
Desde então, em 1976, dois pesquisadores da Universidade de Stantford, Diffie e Hellman

(DIFFIE; HELLMAN, 1976a), revolucionaram o campo da criptografia, sugerindo uma nova
maneira de realizá-la. A nova proposta utilizava um algoritmo que gerava chaves diferentes
tanto no processo de codificação quanto na decodificação. Assim, a criptografia foi chamada
de assimétrica, pois envolve o uso de duas chaves: a pública e a privada. Por esta razão, a
criptografia assimétrica é também conhecida como criptografia de chave pública. De acordo
com a proposta de Diffie e Hellman, a chave do algoritmo de codificação, C, e a chave do
algoritmo de decodificação, D, tem que satisfazer três condições:
1. D[C[P]] = P , onde P = Plaintext
2. É difícil deduzir matematicamente D por meio de C;
3. C não pode ser quebrado por um ataque conhecido como Chosen Plaintext Attack7
Resumidamente, na criptografia assimétrica são geradas duas chaves para cada usuário, ou
seja, cada entidade tem um par de chaves criptográficas. A chave privada é mantida em se-
gredo com o proprietário, enquanto a chave pública pode ser livremente distribuída para outros
indivíduos ou armazenada em um diretório público. Dessa forma, os algoritmos de chave pú-
blica podem ser utilizados para dois objetivos: (1) confidencialidade e (2) autenticidade. De
acordo com Krause e Tipson (KRAUSE; TIPSON, 1998) a vantagem dos sistema criptográfico
de chave pública, em relação a confidencialidade, é a possibilidade da transmitir mensagens
codificadas sem a necessidade de trocar a chave privada. Isto é, uma vez codificada pela chave
pública, somente o seu par – a chave privada – poderá decifrar a mensagem. Em outras palavras,
apenas o proprietário da chave codificadora (chave pública) poderá decifrar a mensagem.
7 O ataque CPA, acrônimo para Chosen Plaintext Attack, em português “Ataque do Texto Puro Escolhido” é
um modelo de ataque em que o criptoanalista tem a capacidade de definir seu próprio plaintexts para ser codificado
e obter o correspondente ciphertexts. O objetivo do ataque é ganhar alguma informação adicional que reduz a
segurança da cifragem. Na pior das hipóteses, um ataque CPA poderia revelar o esquema da chave secreta.
Na autenticidade o processo é invertido. Isto é, agora a mensagem é codificada com a chave

privada, e somente o seu par – a chave pública – poderá decifrá-la. Em outras palavras, este mé-
todo serve para garantir que a pessoa que mandou a mensagem criptografada é realmente quem
diz ser. Enfim, para garantir os dois objetivos – autenticação e confidencialidade – o remetente
poderá primeiro assinar a mensagem usando sua chave privada e, em seguida, criptografá-la (a
mensagem e a assinatura) utilizando a chave pública do destinatário. O problema central da
utilização da criptografia assimétrica é a confiança se a chave pública é a “original”, isto é, se
pertence realmente a pessoa ou a entidade que chave foi solicitada, e que não foi adulterada ou
substituída por algum terceiro. Esse problema é descrito no capítulo 4: Identificação Digital.
3.3.1 Aplicações para Sistemas Criptográficos de Chave Pública
A criptografia de chave pública é caracterizada pelo uso de duas chaves, uma de posse
privada e outra disponível para o público. Dependendo do seu objetivo podemos classifica-la
em três categorias, segundo Stallings (STALLINGS, 2006):
• Codificação/decodificação: O remetente codifica a mensagem com a chave pública do

destinatário;
• Assinatura Digital: O emissor “assina” a mensagem com a sua chave privada. A assina-
tura é realizada através codificação de uma parte da mensagem;
• Troca de Chaves: Os dois lados da comunicação colaboram para uma sessão de troca de
chave. Várias abordagens diferentes são possíveis, envolvendo a chave privada de uma
ou ambas as partes.
Tab. 1: Categoria para os algoritmos criptográficos de chave pública

Algoritmo Codificação/Decodificação Assinatura Digital Troca de Chaves
RSA Sim Sim Sim
Diffie-Hellman Não Não Sim
DSS Não Sim Não
Elliptic Curve Sim Sim Sim
Alguns algoritmos são adequados para todas as três categorias, enquanto outros podem ser
utilizados apenas para uma ou duas. A tabela 1 indica quais categorias são suportadas pelos
algoritmos.
3.3.2 Algoritmos criptográficos de chave pública
3.3.2.1 RSA
O RSA (RIVEST et al., 1978) é um algoritmo de criptografia de chave pública descoberto

em 1978 e mundialmente conhecido pelas inicias dos sobrenomes dos três pesquisadores: Ron
Rivest, Adi Shamir e Leonard Adleman - RSA(LABORATORIES, 2002). Segundo Tenenbaum
(TANENBAUM, 2002), o RSA é resistente em todas as tentativas de ataque, e é impossível
de quebrá-lo na prática. As chaves RSA possui tipicamente o tamanho de 1024-2048 bits. O
RSA torna-se cada vez mais seguro caso o tamanho das chaves for suficientemente grande.
No entanto, como a velocidade do processo de criptografia é inversamente proporcional ao
comprimento da chave, o RSA ficaria suficientemente lento, segundo Rivest.
Isto é, comprimentos curtos ou longos podem ser utilizados de acordo com objetivo entre
a velocidade da criptografia com a segurança da aplicação. Lima (LIMA, 2008) afirma que,
o RSA é usado como um padrão para todas as aplicações que desejam oferecer serviços para
troca de chaves e certificados. É também muito utilizado nas aplicações bank on-line de alguns
bancos brasileiros, como Bradesco, Itaú e Banco do Brasil; Brasil, e em autenticação de serviços
de email – PEM (Privacy Enhanced Mail).
3.3.2.2 Diffie-Hellman
O primeiro algoritmo assimétrico surgiu através dos modelos de estudos dos pesquisadores
Whitfield Diffie e Martin Hellman, os quais, em 1976, deram início à criptografia de chave pú-
blica (DIFFIE; HELLMAN, 1976b), como a introdução do algoritmo conhecido como troca de
chaves Diffie-Hellman (DIFFIE; HELLMAN, 1976a) (Diffie-Hellman Key Exchange). Tam-
bém conhecido pela sigla D-H, o algoritmo é um protocolo criptográfico que possibilita duas
ou mais entidades, as quais não possuem nenhum conhecimento prévio uma das outras, a de-
terminarem o compartilhamento de uma chave secreta por meio de um canal de comunicações
inseguro. Essa chave – derivada de algoritmo simétrico – pode ser utilizada para criptogra-
far as comunicações posteriores. Segundo Dherik (BARISON, 2006), diferente do algoritmo
RSA, o Diffie-Hellman não possui a possibilidade de codificar/decodificar informações, e sim
a capacidade de apenas realizar a troca de chaves.
A solução proposta pelo D-H é baseado no modelo de cadeados. Por exemplo, Ana deseja
remeter uma mensagem secreta para José. Com isso, Ana guarda a mensagem em alguma
caixa, trancando-a por meio de um cadeado (lembrando que somente ela possui a chave deste
cadeado) e a remete para José. José recebe a caixa e coloca outro cadeado na caixa (o qual
somente José tem a chave) e reenvia para Ana que, ao receber, apenas retira o seu cadeado e
remete novamente para José. Assim, com apenas o cadeado de José, ele abre a caixa e consegue
visualizar secretamente a mensagem original.
Dessa maneira, o segredo do algoritmo Diffie-Hellman está nas funções matemáticas que
devem possuir comportamento semelhante ao dos cadeados citados. Entretanto, as funções ma-
temáticas necessitam ser “retiradas” na ordem inversa da maneira que foram “colocadas”, para
que a mensagem criptografada não seja alterada. O algoritmo D-H é vulnerável ao ataque “ho-
mem do meio”, e consiste na principal vulnerabilidade deste algoritmo. Esta vulnerabilidade
ocorre porque, na descrição original, o Diffie-Hellman não realiza a autenticação dos partici-
pantes. Assim, o uso do original D-H sozinho não tem a capacidade de garantir a confiabilidade
na comunicação. A correção dessa vulnerabilidade é realizada através da união com técnicas
de autenticação, tornando-o eficiente. Uma prova disso é a presença desse algoritmo na solução
de autenticação alguns importantes como: componente IKE (KAUFMAN, 2005) (Internet Key
Exchange) do IPsec (KENT; SEO, 2005) (Internet Protocol Security ); no MQV (LAW et al.,
1998) (Menezes-Qu-Vanstone) e no STS (Station-to-Station)
3.3.2.3 DSA
O DSA (GUTIERREZ; GALLAGHER, 2008) (Digital Signature Algorithm) foi especifi-

cado em 1993 como padrão para assinaturas digitais. De acordo com Krause e Tipson (KRAUSE;
TIPSON, 1998), diferente do RSA, o DSS é estritamente um sistema de assinatura, e assim, não
pode ser utilizado como um sistema de codificação para mensagens secretas, isto é, não possui
a capacidade de garantir a privacidade, somente a autenticidade. Atualmente, o DSA é pouco
utilizado pois o RSA pode tanto criptografar/descriptograr as mensagens quanto assiná-las.
3.3.2.4 Elliptic-Curve Cryptography
O sistema criptográfico desenvolvido para concorrer e desafiar o RSA foi a criptografia

de curvas elípticas – ECC (Eliptic Curve Cryptography)– o qual foi padronizado pela IEEE e
nomeado como IEEE P1363 (KALISKI, 1999). O ECC é uma abordagem baseadas na estrutura
algébrica de curvas elípticas 8 . O uso das curvas elípticas em criptografia foi projetado de
maneira independente, em 1985, por dois autores: Neal Koblitz e Victor Miller, segundo Saeki
(SAEKI, 1997). A principal vantagem entre o ECC e o RSA é que aquele proporciona um nível
equivalente de segurança com uma maior velocidade criptográfica através do uso de chaves de
8 Em matemática, as curvas elípticas são definidas por meio de equações cúbicas (de terceiro grau). Lembrando
que, as curvas referidas não são elipses, isto é, secção de um cone atravessado obliquamente por um plano.
3.4 Função Hash 43
menor comprimento. Esta vantagem reduz a sobrecarga do processamento. O ECC é ideal para
aplicações com pequenos recursos, tais como, smart cards, dispositivos móveis e nas conexões
de rede que possuem requisitos limitados de largura de banda.
3.3.2.5 Elliptic Curve DSA
O ECDSA (GUTIERREZ; GALLAGHER, 2008) (Elliptic Curve Digital Signature Al-

gorithm) é um algoritmo assimétrico baseado do algoritmo DSA que utiliza operações sobre
pontos de curvas elípticas no lugar das exponenciações do DSA. Desenvolvido pelo Instituto
Nacional Americano de Padronização (American National Standards Institute), também co-
nhecido por sua sigla ANSI (ANSI, 2009), e credenciado pelo Comitê de Padrões X9 (X9, )
(Accredited Standards Committee X9, Inc.), o ECDSA foi padronizado e é conhecido pela no-
menclatura ANSI X9.62:2005, Public Key Cryptography for the Financial Services Industry,
The Elliptic Curve Digital Signature Algorithm, o qual a versão mais recente é de 2005.
3.4 Função Hash
A função hash é método baseado na ideia de uma função que tem como entrada um longo
bloco arbitrário da mensagem e como saída uma única sequência de bits de comprimento fixo.
Para duas entradas distintas no algoritmo hash as respostas geradas são obrigatoriamente dis-
tintas. Em outras palavras, caso o retorno da função hash gere duas sequências de bits iguais é
que os blocos de entrada são iguais. A função hash possui propriedades importantes, segundo
Stallings (STALLINGS, 1999). Seja P e P0 respectivamente as entrada e saída da função hash,
MD(P) = P0 é efetivamente impossível encontrar P, ou seja, a função hash não é retornável. A
segunda propriedade é que este algoritmo é resistente à colisão, isto é, modificando apenas 1
bits de P a saída será totalmente diferente de P0 . Ou seja, é impossível encontrar duas entradas
diferentes que gerem a mesma saída.
3.4.1 MD5
O MD5 (Message-Digest Algorithm 5) é o quinto da série de algoritmos de funções hashes

desenvolvido pelo professor Ronald L. Rivest. Foi projetado em 1991 com objetivo de subs-
tituir o seu antecessor, o MD4. O algoritmo tem como entrada uma mensagem de tamanho
arbitrário e produz na saída uma message digest de 128 bits (16 bytes) de comprimento. A
entrada é dividida e processada em blocos de 512 bits de tamanho. De acordo com Tenenbaum
(TANENBAUM, 2002), o MD5 é baseado no funcionamento de “desfigurar” os bits, de uma

maneira suficientemente complicada que cada bit da saída é afetado por cada bit da entrada.
No entanto, os autores Wang e Yu (WANG; YU, 2008) demonstram que o MD5 infringe a
propriedade de resistência à colisão. Por causa desta violação, o MD5 não é adequado para ser
usado em aplicações que trabalham com certificados e/ou assinaturas digitais. Em 1996, uma
falha foi encontrada no projeto do MD5 e apesar de não tratar-se de uma vulnerabilidade de alto
riso, os criptógrafos da época aconselhavam o uso de algoritmos alternativos, por exemplo, o
SHA-1. No entanto, em 2004, foram descobertas falhas mais graves tornando-o questionável o
seu uso para fins de segurança, de acordo com Wang e Yu. Já em 2007, um grupo de pesquisa-
dores, Lenstra (STEVENS et al., 2007) descreveram como criar um par de arquivos que geram
hashes MD5 idênticos, ou seja, demonstraram que o MD5 não é resistência à colisão.
3.4.2 MD6
O MD6 (RIVEST, 2009) é um algoritmo criptográfico de função hash desenvolvida pela

MIT e liderada por uma equipe pelo professor Ronald L. Rivest, em resposta ao convite do con-
curso SHA-3 (ver o tópico 3.4.5) proposto pela NIST. De acordo com o documento (RIVEST et
al., 2008), o MD6 utiliza uma estrutura de dados denominado Hash trees ou Merkle trees para
permitir a computação paralela na criação de vários hashes à partir da entrada de informações
longas. No entanto, em 1 de julho de 2009, Rivest postou um comentário à NIST dizendo que
o MD6 ainda não está pronto para ser candidato ao concurso, devido aos problemas de veloci-
dade e pela falta de conhecimento de algum ataque eficaz contra o mesmo. Isto é, Rivest afirma
que “[. . . ] a ausência de evidência de deficiências não é evidência de ausência de deficiências”
(RIVEST, 2009). O MD6 não avançou para a segunda fase do concurso SHA-3.
3.4.3 SHA-1
O SHA-1 foi desenvolvido pela NSA (National Security Agency) e publicado como um
padrão do governo Norte-Americano. Este algoritmo tem como entrada mensagem de (264 −
1) bits de comprimento e produz como saída um hash de 160 bits. Assim como o MD5, o
SHA-1 não é considerado seguro, pois não é resistênte à colisão. O mais utilizado da família
SHA, o SHA-1 faz parte de vários protocolos e aplicações de segurança utilizado atualmente,
incluindo TLS e SSL, o PGP, SSH (Secure Shell), S/MIME(Secure / Multipurpose Internet Mail
Extensions), e IPsec.
3.4.4 SHA-2
A NIST publicou quatro funções hash adicionais na família SHA, os quais são nomeados
de acordo com o comprimento, em bits, da message digest produzido: SHA-224, SHA-256,
SHA-384, e SHA-512. Os algoritmos são coletivamente conhecido como Família SHA-2 ou
simplesmente SHA-2 (FIPS, 2002). Lançado como padrão oficial em agosto de 2002, o FIPS
PUB 180-2 (FIPS, 2002) também inclui o SHA-1. As quatros modalidades foram patenteadas
pelo governo americano como US patent 6829355, porém os Estados Unidos tem liberado a
patente somente sob uma licença livre de royalties (NEWBILL, 2007). Até o presente momento,
nenhum tipo de ataque aos membros do SHA-2 foi relatado, e com isso, segundo a NIST (NIST,
2005), as agências federais norte americana deve parar de utilizar o SHA-1 nas aplicações e irão
começar a utilizar o SHA-2 após 2010. Independentemente do propósito, a NIST incentiva os
programadores a utilizar no desenvolvimento de novas aplicações a família SHA-2.
3.4.5 SHA-3
No dia 2 de novembro de 2007, a NIST anunciou formalmente no FR9 (Federal Register) a

competição para a nova função hash SHA-3 (NIST, 2008), semelhante ao processo de desenvol-
vimento do AES. O algoritmo vencedor será chamado de SHA-3 e irá ser adicionado na atual
especificação FIPS 180-2. O processo para submissão dos novos algoritmos iniciou em 31 de
outubro de 2008 e a proclamação do vencedor e publicação do novo padrão estão programadas
para acontecer em 2012. Atualmente, a NIST selecionou os candidatos para a segunda fase
competição.
9O Federal Register, em português “Registro Federal”, é um é o jornal oficial do governo federal dos Estados
Unidos que contém informações sobre as publicações e avisos públicos das agências governamentais.
46
4 Protocolos de Segurança
Atualmente a maioria das organizações, desde entidades governamentais até particulares,

possuem alguma aplicação na WEB e, consequentemente, o uso da comunicação via Internet.
Em outras palavras, a quantidade de organizações com acesso à Internet está aumentando a cada
ano pela facilidade que a WEB propõem nos comércios eletrônicos. Por outro lado surgem as
preocupações com a segurança dos dados no mundo virtual. Os protocolos criptográficos têm
por objetivo garantir os requesitos de segurança em um tráfego de dados protegendo-o cripto-
graficamente contra terceiros que tentam interceptá-lo para acessar as informações transmitidas.
4.1 SSL
O SSL (Security Socket Layer) é um protocolo de segurança desenvolvido pela Netscape

Communications Corp em novembro de 1995, com o principal objetivo de proporcionar pri-
vacidade e confiança entre a comunicação de aplicações WEB de uma maneira transparente e
independente da plataforma. O SSL foi projetado para permitir a autenticação mútua entre o
cliente e o servidor através de uma conexão criptografada e autenticada. Atualmente, o proto-
colo encontra-se na versão 3, o qual foi publicado na Internet como um documento-rascunho
(FREIER PHILIP KARLTON, 1996), e especificado com a nomenclatura SSL 3.0 ou SSL v3.
De acordo com a especificação, o SSL utiliza os três tipos de criptografia existentes:
• A criptografia simétrica é utilizada para realizar a criptografia dos dados. A chave secreta
é negociada pelo protocolo na primeira fase do handshaking;
• A autenticação mútua entre o cliente e o servidor é feita por meio dos algoritmos assimé-
tricos;
• A confiabilidade da conexão é garantida pelo o transporte das mensagens que inclui a

verificação da integridade por meio do MAC (Message Authentication Code - MAC) por
meio do uso das funções hash.
4.1 SSL 47
Portanto,a essência do protocolo SSL é garantir que os três tipos de criptografia esteja
funcionando corretamente.
4.1.1 Objetivos
De acordo com sua especificação, os principais objetivos do protocolo SSL v3.0, em ordem
de prioridade, são:
1. Segurança criptográfica: O SSL deve ser utilizado para estabelecer uma conexão segura
entre duas entidades.
2. Interoperabilidade: As aplicações desenvolvidas o SSL 3.0 permitirá a permuta do

sistema criptográfico sem o conhecimento dos parâmetros de algum outro código. Em
outras palavras, não será necessário “re-codificar” o software para o SSL adaptar-se com
a novo modelo de criptografia escolhido.
3. Extensibilidade: O SSL visa proporcionar um framework para que as novas chaves pú-
blicas e novos métodos de criptografia em massa pode ser incorporada, caso necessário.
Isto também irá realizar dois sub-objetivos: evitar a necessidade de criar um novo proto-
colo (e arriscando a introdução de possíveis novas vulnerabilidades) e evitar a necessidade
de implementar uma nova biblioteca de segurança.
4. Eficiência relativa: Operações criptográficas exige um trabalho intensivo da CPU, parti-

cularmente operações de chave pública. Por este motivo, um sistema opcional sessão de
caching foi incorporado no protocolo SSL para reduzir o número de conexões que devem
ser criadas. Além disso, cuidados foram tomados para reduzir a atividade na rede.
Desse modo, segundo Tanenbaum (TANENBAUM, 2002), para que os objetivos descrito
acima seja realizado, uma conexão segura SSL estabelecida entre dois sockets1 , inclui: (1)
negociação de parâmetros entre o cliente e o servidor, (2) autenticação mútua entre cliente e
servidor, (3) comunicação secreta, (4) proteção da integridade dos dados.
4.1.2 Arquitetura
O SSL é projetado para atuar entre as camada TCP (Transmission Control Protocol) e a
camada de Aplicação, para proporcionar uma serviço seguro nas comunicações ponto a ponto
1 No ambiente de rede computacional, a palavra soquete é um ponto final de um fluxo de comunicação bidire-
cional entre protocolos baseados em rede de computadores.
4.1 SSL 48
(entre cliente e servidor). O TCP é um protocolo pertencente a camada de transporte (também

referenciado como a camada 4) do Modelo OSI2 que, por padrão, envia fluxo de informações
entre dois computadores sem autenticidade e segurança. Desse modo, por situar-se abaixo da
camada de aplicação, o SSL é independente do protocolo de alto nível estabelecido, ou seja,
pode ser executado sob diversos protocolos (HTTP, Telnet, FTP, SMTP) de forma transparente.
É composto por duas camadas de protocolos, conforme ilustrado na figura 4.1: o Handshake
protocol e o Record protocol.
Fig. 4.1: Representação da pilha do protocolo SSL/TLS. Adaptado de (CISCO, 1998)
A conexão e sessão são dois conceitos importantes no SSL. O primeiro é o mecanismo que
oferece o meio de transporte para as informações. As conexões são temporárias e todas estão
associadas com uma sessão. Já o segundo é uma associação entre um cliente e um servidor.
As sessões são criadas pelo protocolo Handshack para definir um conjunto de parâmetros de
segurança criptográfica, os quais podem ser compartilhados entre várias conexões. Em outras
palavras, as sessões são utilizadas para evitar o desperdício da banda ao negociar novos parâ-
metros de segurança para cada conexão.
4.1.2.1 Record protocol
O Record protocol é utilizado para transferir todas as informações dentro de uma sessão
SSL, desde a camada de aplicação até ao protocolo SSL. Também é usado para providenciar
dois serviços importantes de segurança:
• Confidencialidade: O Handshake protocol determina uma chave secreta que é utilizada

na criptografia simétrica das informações que trafegam pelo SSL.
2A ISO foi uma das pioneiras a definir uma arquitetura para realizar a conexão e a troca de informações entre
computadores. A arquitetura foi denominada como OSI (Open Systems Interconnection), Camadas OSI ou
Interconexão de Sistemas Abertos.
4.1 SSL 49
• Integridade das menssagens: O Handshake protocol determina outra chave secreta

compartilhada para ser usada para produzir o código de autenticação de mensagem (MAC).
A figura 4.2 esquematiza o processo completo do trabalho do record protocol. Resumida-

mente, a operação desse protocolo ocorre da seguinte maneira: o record protocol recebe uma
mensagem da camada de aplicação para ser transmitida. Posteriormente é realizado a fragmen-
tação dos dados em blocos gerenciáveis, como opção realiza-se a comprenssão das informação,
aplica um MAC (responsável pela integridade da informação) com o uso de uma função hash
(MD5 ou SHA-1), criptografa por meio de um algoritmo simétrico (DES ou TDES), acrescenta
um cabeçalho, e transmite resultando a em uma unidade do segmento do TCP.
Fig. 4.2: Operação do SSL Record protocol. Adaptado de (CISCO, 1998)
Quando um pacote chega ao destinatário, é realizado o processo inverso descrito anterio-

mente. Desse modo, recebido o pacote, os dados são descriptografado, verificado (calcula o
valor do MAC e compara-o com o MAC recebido, se os valores forem idênticos, os dados es-
tão íntegro), são descomprenssados, reagrupados e, em seguida, entregues às camadas de nível
superior.
4.1.2.2 Charge Cipher Spec Protocol
O Charge Cipher Spec Protocol é o protocolo cujo objetivo é armazenar os métodos que es-
tão sendo usados na comunicação entre cliente e servidor, negociados pelo protocolo handshake,
para que os mecanismo de segurança utilizados estão sincronizados, ou seja, garantir que tanto
o cliente quanto o servidor estejam usando os mesmas ferramentas. Outra funcionalidade deste
protocolo é a possibilidade de modificar a sessão SSL sem ter de renegociar a conexão.
4.1 SSL 50
4.1.2.3 Alert Protocol
O Alert Protocol é usado para transmitir alertas relacionados ao uso indevido do protocolo
(encerramento inesperado da sessão por uma das extremidade da conexão, falha da comuni-
cação). Cada mensagem deste protocolo é constituído por dois bytes, sendo que o primeiro
representa o nível do alerta (valor 1 para “aviso” e 2 para “erro fatal”, ver figura 4.3b). Se o
protocolo de alerta emitir um sinal de erro fatal, a sessão será encerrada imediatamente. Caso
for emitido o sinal de aviso uma decisão será tomada para o encerramento da sessão.
Fig. 4.3: Tipos de protocolos do Handshake. Adaptado de (STALLINGS, 1999)
4.1.2.4 Handshake Protocol
A negociação dos paramêtros usados na comunicação segura é de responsabilidade do

Handshake Protocol. De acordo com a figura 4.1, o handshake protocol é um conjunto de
protocolos composto por ele próprio e mais outros dois: o Charge Cipher Spec e o Alert. O
handshake é utilizado para inicializar uma sessão entre o servidor e o cliente. Nesta sessão são
negociados os principais mecanismos do SSL, como a chave secreta, o tamanho das chaves e os
algoritmos para codificar as informações. Também neste protocolo é realizado a autenticação
das entidades envolvida na comunicação. A figura 4.3c ilustra o formato do handshake que é
composto por três campos: (1) o tipo que indica os tipos das mensagens, (2) o comprimento
que fornece o comprimento da mensagem em bytes e (3) o conteúdo que informa os parâmetros
associados com a mensagem (ver tabela 2).
4.1.3 Funcionamento
Para trocar mensagens seguras é necessário estabelecer uma conexão entre o servidor e o
cliente, para que sejam combinados quais parâmetros serão utilizados entre eles. A ilustração
4.4 representa troca de mensagens inicial para estabelecer uma conexão segura. De acordo com
Stallings, o funcionamento do SSL é representada através de quatro fases de operações.
4.1 SSL 51
Tab. 2: Tipos de mensagens do protocolo Handshake
Tipo da Mensagem Parâmetros

hello_request Nulo
client_hello Versão, random, sessão, id, conjunto cifras, método compressão
server_hello Versão, random, sessão, id, conjunto cifras, método compressão
certificate Certificados X.509v3
server_key_exchange Parâmetros, assinatura
certificate_request Tipo, autoridade
server_done Nulo
certificate_verify Assinatura
cliente_key_exchange Parâmetros, assinatura
finished Valor hash
4.1.3.1 Fase 1: Estabelecimento dos Mecanismos de Segurança
Nesta fase é realizada para iniciar uma conexão entre o cliente e o servidor, e em seguida,
estabelecer infra-estrutura de segurança da comunicação. O processo é iniciado pelo cliente, por
meio do envio da mensagem cliente hello e o servidor responde com a mensagem server hello.
Estas mensagens são compostas pelo parâmetros: a versão do SSL que será utilizado, o ID da
sessão, a suíte de cifragem (cipher suite), o método de compressão e dois valores randômicos
que são gerados pelo cliente e servidor. O conjunto criptográfico (cipher suite) negociado de-
fine os algoritmos para troca de chaves, cifragem de dados e um algoritmo para inserção de
redundância nas mensagens.
4.1.3.2 Fase 2: Autenticação do Servidor e Trocas de Chaves
Caso haja necessidade da autenticação do servidor, a fase 2 é iniciado com o envio de

seu certificado para o cliente. Esta mensagem contém um ou mais certificados do conjunto
de certificados X.5093 . Entranto, a autenticação do servidor é opcional. A próxima mensa-
gem a ser enviada é server key exchange. Porém esta mensagem também é opcional se o
certificado enviado anteriormente for apenas de assinatura, ou seja, não contendo a chave pú-
blica. A terceira mensagem é solicitação do certificado do cliente pelo servidor, por meio da
mensagem certificate request o qual é composto por dois parâmetros: o certificate type e o
certificate authorities, porém este passo também é facultativo. O primeiro parâmetro indica o
tipo do algoritmo da chave pública, enquanto o segundo é uma lista de nomes das autoridades
certificadoras aceitáveis. E por último, é enviado ao cliente a mensagem server done, para
3O certificado X.509 é um padrão da ITU-T (Telecommunication Standardization Sector) para o ICP(Infra-
estruturas de Chaves Públicas) e especifica, entre várias outras definições, o formato dos certificados digitais
4.1 SSL 52
Fig. 4.4: Estabelecimento da conexão entre cliente e servidor no SSL/TLS. Adaptado de

(CISCO, 1998)
indicar o fim da fase 2. Em seguinda, o servidor aguarda a resposta do cliente.
4.1.3.3 Fase 3: Autenticação do Cliente e Trocas de Chaves
Após a receber a mensagem server done, o cliente verifica se ocertificado do servidor é

legítimo e, também, se todos os outros parâmetros enviados (através da mensagem server hello)
estão corretos. Agora, se o certificado do cliente também foi solicitado, este irá envia-lo, caso
contrário, enviará um alerta (no certificate) indicando que não o possui. A segunda mensagem
é a client key exchange que contém a chave secreta do cliente cifrada com a chave pública do
servidor — obtida através da fase 2, pelo certificado do servidor ou pela mensagem da troca
de chaves públicas. E por último, o cliente pode enviar uma mensagem certificate verify para
providenciar ao servidor uma verificação do seu certificado.
4.1 SSL 53
4.1.3.4 Fase 4: Estabelecimento da conexão segura
Nesta fase completa a sequência de passos para criar uma conexão segura. É iniciada com o
envio da mensagem de mudança de cifras — change cipher spec — do cliente para o servidor,
com objetivo de notificá-lo de que as próximas mensagens serão enviadas utilizando os algo-
ritmos e chaves estabelecidos nas fases anteriores. Posteriormente, o cliente envia em seguida
a mensagem finished com intuito de informar o servidor que os processos de trocas de chaves
e autenticações foram bem sucedidos. Em resposta, o servidor envia a sua própria mensagem
change cipher spec, notificando que também a partir deste momento, toda a comunicação serão
codificadas de acordo os algoritmos e chaves determinados. E por último, também envia a sua
mensagem finished para também informá-lo que o estabelecimento da conexão foi finalizado.
Portanto, depois da conclusão da fase 4, o cliente e o servidor podem comunicar-se de maneira
segura através do protocolo SSL.
4.1.4 Algoritmos Criptográficos utilizados pelo SSL
O SSL suporta diferentes tipos de criptografia, porém uma combinação aleatória não é per-
mitida. Assim para estabelecer uma padronização, foi definido, na especificação do protocolo,
combinações pré-estabelecidas as quais são denominadas de conjunto criptográfico (Cipher
Suites). A tabela 3 contém todas os Cipher Suites mencionados na especificação(FREIER PHI-
LIP KARLTON, 1996) do SSL.
De acordo com Barison (BARISON, 2006), dentre todos os Cipher Suites mencionados da
tabela 3, os que possuem a palavra EXPORT tem o uso limitado. Isto é, na época em que o
SSL foi proposto, o governo norte americano limitava por lei a utilização deste protocolo para
exportação, ou seja, o comprimento das chaves dos algoritmos exportáveis (que poderiam ser
utilizados em outros países) eram limitados somente para 40 bits, uma segurança relativamente
fraca. Atualmente este impasse não existe mais, segundo o (OPENSSL, 2009). Podemos obser-
var que a função hash MD5 é pouco utilizado, em relação ao SHA, por causa das descobertas
de vulnerabilidades em seu algoritmo, as quais comprometem a integridade das informações,
segundo Schneier (SCHNEIER, 2004).
4A palavra anon significa anônimo, isto é, ausência de assinatura digital
4.2 TLS 54
Tab. 3: Cipher Suites do SSL v3

Cipher Suite Troca de Chaves Cifragem Hash
SSL_NULL_WITH_NULL_NULL NULL NULL NULL
SSL_RSA_WITH_NULL_MD5 RSA NULL MD5
SSL_RSA_WITH_NULL_SHA RSA NULL SHA
SSL_RSA_EXPORT_WITH_RC4_40_MD5 RSA_EXPORT RC4_40 MD5
SSL_RSA_WITH_RC4_128_MD5 RSA RC4_128 MD5
SSL_RSA_WITH_RC4_128_SHA RSA RC4_128 SHA
SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 RSA_EXPORT RC2_CBC_40 MD5
SSL_RSA_WITH_IDEA_CBC_SHA RSA IDEA_CBC SHA
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA RSA_EXPORT DES40_CBC SHA
SSL_RSA_WITH_DES_CBC_SHA RSA DES_CBC SHA
SSL_RSA_WITH_3DES_EDE_CBC_SHA RSA 3DES_EDE_CBC SHA
SSL_DH_DSS_EXPORT_WITH_DES40_CBC_SHA DH_DSS_EXPORT DES40_CBC SHA
SSL_DH_DSS_WITH_DES_CBC_SHA DH_DSS DES_CBC SHA
SSL_DH_DSS_WITH_3DES_EDE_CBC_SHA DH_DSS 3DES_EDE_CBC SHA
SSL_DH_RSA_EXPORT_WITH_DES40_CBC_SHA DH_RSA_EXPORT DES40_CBC SHA
SSL_DH_RSA_WITH_DES_CBC_SHA DH_RSA DES_CBC SHA
SSL_DH_RSA_WITH_3DES_EDE_CBC_SHA DH_RSA 3DES_EDE_CBC SHA
SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA DHE_DSS_EXPORT DES40_CBC SHA
SSL_DHE_DSS_WITH_DES_CBC_SHA DHE_DSS DES_CBC SHA
SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA DHE_DSS 3DES_EDE_CBC SHA
SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA DHE_RSA_EXPORT DES40_CBC SHA
SSL_DHE_RSA_WITH_DES_CBC_SHA DHE_RSA DES_CBC SHA
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA DHE_RSA 3DES_EDE_CBC SHA
SSL_DH_anon4 _EXPORT_WITH_RC4_40_MD5 DH_anon_EXPORT RC4_40 MD5
SSL_DH_anon_WITH_RC4_128_MD5 DH_anon RC4_128 MD5
SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA DH_anon DES40_CBC SHA
SSL_DH_anon_WITH_DES_CBC_SHA DH_anon DES_CBC SHA
SSL_DH_anon_WITH_3DES_EDE_CBC_SHA DH_anon 3DES_EDE_CBC SHA
SSL_FORTEZZA_KEA_WITH_NULL_SHA FORTEZZA_KEA NULL SHA
SSL_FORTEZZA_KEA_WITH_FORTEZZA_CBC_SHA FORTEZZA_KEA FORTEZZA_CBC SHA
SSL_FORTEZZA_KEA_WITH_RC4_128_SHA FORTEZZA_KEA RC4_128 SHA
4.2 TLS
Em 1996, a organização Netscape Communications Corp liberou o SSL ao IETF com ob-
jetivo de estabelecer uma padronização. Assim, o resultado foi o desenvolvimento do proto-
colo TLS (Transport Layer Security), o qual a primeira versão, 1.0, é descrito no RFC 2246
(ALLEN; DIERKS, 1999) e muito similiar ao seu seu predecessor, o SSLv3. Entretanto, atual-
mente, o TLS encontra-se na versão 1.2 no RFC 5246 (RESCORLA; DIERKS, 2008) e também
é conhecido como: TLS1 ou ainda SSL3.1. Dessa maneira, o principal objetivo principal do
protocolo TLS é proporcionar privacidade e integridade dos dados entre a comunicação entre
as aplicações e a Internet e, automaticamente, tornar-se o sucessor do SSL. Por outro lado, o
funcionamento, os objetivos e os detalhes técnicos do TLS são semelhantes aos estudados no
SSL.
4.2.1 Algoritmos Criptográficos utilizados pelo TLS
De acordo com a especificação do TLSv1.2 (RESCORLA; DIERKS, 2008), os Cipher

Suites são semelhantes do SSLv3 (tabela 3), mas com a seguintes modificações: inclusão de
4.2 TLS 55
novos conjuntos de algoritmos que usam a função hash SHA-256, e a remoção dos que utilizam
as cifras simétricas IDEA e o DES, pois foram considerados ultrapasados. Veja a tabela 4.
Tab. 4: Cipher Suites do TLS v1.2

Cipher Suite Troca de Chaves Cifragem Hash
TLS_NULL_WITH_NULL_NULL NULL NULL NULL
TLS_RSA_WITH_NULL_MD5 RSA NULL MD5
TLS_RSA_WITH_NULL_SHA RSA NULL SHA
TLS_RSA_WITH_NULL_SHA256 RSA NULL SHA256
TLS_RSA_WITH_RC4_128_MD5 RSA RC4_128 MD5
TLS_RSA_WITH_RC4_128_SHA RSA RC4_128 SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA RSA 3DES_EDE_CBC SHA
TLS_RSA_WITH_AES_128_CBC_SHA RSA AES_128_CBC SHA
TLS_RSA_WITH_AES_256_CBC_SHA RSA AES_256_CBC SHA
TLS_RSA_WITH_AES_128_CBC_SHA256 RSA AES_128_CBC SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256 RSA AES_256_CBC SHA256
TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA DH_DSS 3DES_EDE_CBC SHA
TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA DH_RSA 3DES_EDE_CBC SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA DHE_DSS 3DES_EDE_CBC SHA
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA DHE_RSA 3DES_EDE_CBC SHA
TLS_DH_anon_WITH_RC4_128_MD5 DH_anon RC4_128 MD5
TLS_DH_anon_WITH_3DES_EDE_CBC_SHA DH_anon 3DES_EDE_CBC SHA
TLS_DH_DSS_WITH_AES_128_CBC_SHA DH_DSS AES_128_CBC SHA
TLS_DH_RSA_WITH_AES_128_CBC_SHA DH_RSA AES_128_CBC SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA DHE_DSS AES_128_CBC SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA DHE_RSA AES_128_CBC SHA
TLS_DH_anon_WITH_AES_128_CBC_SHA DH_anon AES_128_CBC SHA
TLS_DH_DSS_WITH_AES_256_CBC_SHA DH_DSS AES_256_CBC SHA
TLS_DH_RSA_WITH_AES_256_CBC_SHA DH_RSA AES_256_CBC SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA DHE_DSS AES_256_CBC SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA DHE_RSA AES_256_CBC SHA
TLS_DH_anon_WITH_AES_256_CBC_SHA DH_anon AES_256_CBC SHA
TLS_DH_DSS_WITH_AES_128_CBC_SHA256 DH_DSS AES_128_CBC SHA256
TLS_DH_RSA_WITH_AES_128_CBC_SHA256 DH_RSA AES_128_CBC SHA256
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 DHE_DSS AES_128_CBC SHA256
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 DHE_RSA AES_128_CBC SHA256
TLS_DH_anon_WITH_AES_128_CBC_SHA256 DH_anon AES_128_CBC SHA256
TLS_DH_DSS_WITH_AES_256_CBC_SHA256 DH_DSS AES_256_CBC SHA256
TLS_DH_RSA_WITH_AES_256_CBC_SHA256 DH_RSA AES_256_CBC SHA256
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 DHE_DSS AES_256_CBC SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 DHE_RSA AES_256_CBC SHA256
TLS_DH_anon_WITH_AES_256_CBC_SHA256 DH_anon AES_256_CBC SHA256
4.2.2 Comparação entre SSL e TLS
Segundo Tanenbaum (TANENBAUM, 2002), as alterações efetuadas no SSL foram rela-

tivamente pequenas, porém o suficiente para tornar os protocolos, SSLv3 e o TLS, não inte-
roperáveis. Por exemplo, a maneira como a chave da sessão é derivada da chave principal foi
alterada no TLS para tornar aquela mais forte (e.g., difícil de ser decodificada). Entretanto, de
acordo com a especificação, o protocolo TLS possui um mecanismo interno para negociação de
versão, ou seja, realiza um “retrocesso” para as versões do SSL (2.0 e 3.0) e entre as versões
anteriores do TLS usado (1.0, 1.1, 1.2).
A principal diferença entre o SSL e o TLS é o esquema do código de autenticação da

mensagem (em inglês Message Authentication Code - MAC), afirma Stallings (STALLINGS,
4.3 Integrando SSL/TLS com os Protocolos da Camada de Aplicação 56
1999). Enquanto o SSL utiliza o cálculo MAC propriamente dito, o TLS usa o algoritmo HMAC
(KeyedHashing for Message Authentication Code) definido no RFC 2104 (KRAWCZYK et al.,
1997). A diferença entre eles é que o MAC é gerado por meio de algoritmos simétricos (e.g.,
DES ou AES) e o HMAC atráves de qualquer funções hashes. No entanto, o HMAC proporci-
ona a vantagem de realizar as operações de forma rápida, e ainda garantindo, indiretamente, a
possibilidade de aumentar segurança das informações sem reduzir o desempenho da aplicação.
E por último, alguns Cipher Suites do TLS v1.2 possui algoritmos mais recentes e menos
defasados (e.g., o AES em vez do DES, o SHA-2 no lugar do SHA-1) em relação ao SSL v3.
Veja as respectivas tabelas 3 e 4 para maiores detalhes.
4.3 Integrando SSL/TLS com os Protocolos da Camada de

Aplicação
De acordo com a ilustração 4.1, a posição do SSL na pilha de protocolos favorece a garantia
de uma conexão segurança para os protocolos da camada de aplicações. Dentre as principais
integrações com o SSL temos o HTTPS (HyperText Transfer Protocol Secure).
4.3.1 HTTPS
O HTTPS (HyperText Transfer Protocol Secure) é a versão segura do HTTP. Implementado

e disponível em todos os principais browsers e servidores comerciais do mercado. De acordo
com Gourley (GOURLEY et al., 2002), o HTTPS é a combinação do protocolo HTTP com
um conjunto de ferramentas criptográficas (algoritmos simétricos e assimétricos, certificado
digitais) tornando-se um protocolo não somente seguro, como também muito flexível e fácil de
ser administrado.
Fig. 4.5: Protocolo HTTP sem segurança

4.4 IPsec 57
O HTTPS é a implementação do protocolo HTTP sobre a camada SSL/TLS, o qual foi

descrito no RFC 2818 (RESCORLA, 2000). A adição dessa camada ocorre porque o HTTP
foi inicialmente projetado com ausência de mecanismo de segurança. Dessa maneira, em vez
do HTTP enviar mensagens descriptografadas para a camada de transporte (TCP) o qual irá
remeter para a Internet (ver figura 4.5), o HTTPS enviará a mensagem HTTP para a camada
de segurança (SSL/TLS) que irá criptografa-la antes de enviá-la ao TCP. Então a mensagem
codificada será remetida normalmente pelo TCP para o seu destino (ver figura 4.6). De acordo
com Gourley (RESCORLA, 2000), a trocas de mensagens realiza pelo HTTP é feita em texto
legível. Já no protocolo no HTTPS o tráfego de dados é realizada no formato binário. Pelo fato
do tráfego dos protocolos SSL/TLS serem feitas por mensagens binárias, as informações HTTP
e HTTPS são realizadas em portas diferentes. Essa regra deve ser respeitada, porque se ambos
utilizarem a mesma porta (por exemplo, a porta 80), os servidores webs irá interpretar o tráfego
binários do SSL como mensagens-HTTP errôneas e fechará automaticamente a conexão com
usuário.
Fig. 4.6: Protocolo HTTP com segurança
4.4 IPsec
O protocolo de seguraça IPsec (Internet Protocol Security, também chamado de IP Secu-

rity), tem como objetivo solucionar a falta de segurança nas comunicações que utilizam o IP.
O IPsec é uma extensão do protocolo IP e para complementá-lo, oferece três tipos de serviços
básicos de segurança: autenticação, confiabilidade e gerenciamento de chaves; segundo Stal-
lings (STALLINGS, 1999). Em outras palavras, o segredo do IPsec é que todos estes serviços
4.5 WS-Security Framework 58
acontece na própria camada de rede, isto é, a segurança é garantida no momento da autenticação

e da codificação de cada pacote IP.
O IPsec oference uma proteção nativa para todos os protocolos que estão acima da camada
de rede (camada 3) do modelo OSI incluindo o próprio protocolo IP, de acordo com Tenenbaum
(TANENBAUM, 2002). Assim todos os pacotes já saem protegidos da sua origem, indepen-
dente da aplicação que a gerou. O processo é transparente para qualquer aplicação pois, até
então, a a camada de aplicação era responsável pela própria segurança. O IPsec é descrito na
especificação RFC 4301 (KENT; SEO, 2005), porém com auxílio de muitas outras padroniza-
ções, das quais, as mais importantes são: RFC 4302 (KENT, 2005), RFC 4306 (KAUFMAN,
2005) E RFC 4308 (HOFFMAN, 2005).
4.4.1 Serviços
Segundo Stallings (STALLINGS, 1999), todos os serviços de segurança disponibilizado

pelo IPsec existem graças ao uso de dois protocolos: Authentication Header5 (AH) e Encap-
sulating Security Payload6 (ESP). Os serviços providenciados por eles são: (1) controle de
acesso; (2) integridade sem orientação para conexão (Connectionless Integrity); (3) autentica-
ção; (4) rejeição ou descarte de pacotes repetitivos (para proteção contra ataque replay); (5)
confidencialidade dos pacotes IP. Entretanto, somente o ESP, realiza a criptografia dos pacotes
IPs.
4.5 WS-Security Framework
O WS-Security Framework, segundo Erl (ERL, 2008), estabelece uma especificação de se-
gurança para a camada de aplicação, também conhecido como segurança no nível de mensagem.
Assim, antes de apresentar o estudo desta ferramenta vamos realizar um breve comentário sobre
as entidades que se benefeciam desta proteção: SOAP e WEB Services.
4.5.1 SOAP e WEB Services
Os WEB services são componentes que permitem a comunicação através de mensagens no

formato XML (eXtensible Markup Language). Cada aplicação pode ser desenvolvida em lin-
guagues diferentes, pois o ambiente dos WEB Services é independente de plataforma e da lin-
5 Protocolo
destinado para o cabeçalhos dos protocolos
6 Uma combinação de protocolos de autenticação/criptografia destinado na formatação dos pacotes para os
protocolos
guagem de programação. Estes serviços comunicam-se por meio do protocolo SOAP (Simple
Object Access Protocol), que está se tornando o padrão para a troca de mensagens entre aplica-
ções e WEB Services. O SOAP prioriza a interoperabilidade e intercomunicação entre diferentes
sistemas de um ambiente distribuído, através do uso da linguagem XML e do mecanismo de
transporte HTTP. O principal objetivo do SOAP é fazer com que os recursos disponibilizados
estejam disponíveis sobre a rede de uma maneira normalizada. Atualmente, este protocolo é
definido pelo consórcio W3C e está na versão 1.2 (GUDGIN et al., 2007).
A ilustração 4.7 demonstra um típico cenário onde temos um cliente acessando uma apli-
cação no servidor pela Internet. Esta, por sua vez, realiza comunicação via SOAP com vários
WEB Services posicionado na Internet. Para finalizar, a aplicação WEB faz análise das mensa-
gens SOAP e, por fim, envia uma resposta ao cliente.
Fig. 4.7: Cenário de uma aplicação que depende da comunicação com diversos WEB Services
4.5.2 WS-Security
O WS-Security (LAWRENCE; KALER, 2006b) (WEB Services Security) é um protocolo

de comunicação que providência uma maneira de aplicar segurança para os WEB Services. De-
senvolvida, primeiramente, pela IBM, Microsoft e a VeriSign, o protocolo é agora oficialmente
chamado de WSS e gerenciada pala organização Oasis-Open7 (LAWRENCE; KALER, 2006a).
Em 19 de abril de 2004, a Oasis-Open liberou a especificação WS-Security 1.0, e em 17 fev
2006, foi lançada a versão 1.1, a qual vigora atualmente. A especificação prevê um conjunto de
mecanismos para ajudar desenvolvedores de WEB services trocar mensagens seguras.
7A OASIS (Organization for the Advancement of Structured Information Standards) sigla inglesa para, Orga-
nização para o Avanço de Padrões em Informação Estruturada, é uma organização global que conduz o desenvol-
vimento, convergência e adoção de padrões para e-business e WEB services.
O WS-Security descreve aperfeiçoamentos para mensagem SOAP com objetivo de

proporcioná-la proteção através dos mecanismos de integridade e confidencialidade, por meio
da assinatura XML e criptografia XML, respectivamente. Assim, para garantir as trocas de men-
sagens seguras, o WSS integra as funções de segurança no cabeçalho e no corpo das mensagem,
agindo como uma “extensão SOAP”. Tanto a criptografia XML quanto a assinatura digital XML
são especificações gerenciada pela W3C (W3C, 2009), entidade responsável pelo padrão XML.
Conhecido também como segurança no nível de mensagem, o WS-Security pode ser apli-
cados em toda a mensagem ou em partes selecionadas, com objetivo de utilizar várias camadas
de criptografia e/ou autenticação para controlar quais informações estarão acessíveis para cada
participante em uma troca de mensagens envolvendo diversos sistemas. Isto significa que os
intermediários conseguirão visualizar as partes da mensagem destinadas apenas à eles. Final-
mente, a mensagem protegida pode ser enviada através de vários protocolos diferentes (HTML,
SMTP, FTP e TCP) pois as informações confidenciais estão seguras na mensagem, ou seja, a
segurança não depende do canal da comunicação. Logo, a segurança é oferecida no próprio
protocolo de troca de mensagens – SOAP.
Também é incorporado no WS-Security os modelos de segurança para reforçar a integridade

e a confidencialidade das mensagens WEB Services (SAML 8 , Kerberos9 , SPML10 , XKMS11 ),
ver figura 4.8.
O framework WS-Security é ainda auxiliado por uma série de normas complementares, di-
vididos em duas camada: sendo a primeira composta pelos padrões: WS-Policy, WS-Trust, WS-
Privacy e a segunda: WS-Secure Conversation, WS-Federation, WS-Authorization. Segundo
Erl (ERL, 2008), a primeira é frequentemente referida como a “Camada de Política”, pois for-
nece informações para estabelecer as políticas de confiança e de privacidade. Já, a segunda,
é conhecida como a “Camada de Federação”, pois é baseada nas políticas com o objetivo de
unificar a confiança entre diferentes domínios. A palavra “política”, neste contexto, possui um
significado amplo, porque engloba uma série de medidas de segurança entre: confiabilidade,
transações e privacidade. Já a federação é uma coleção de domínios de segurança que estabe-
lece relações entre as entidades para compartilhar os recursos de uma maneira segura, segundo
8O SAML (Security Assertion Markup Language) é um padrão, baseado em XML, de autenticação e autoriza-
ção para o troca de dados entre os domínios da segurança, isto é, entre um provedor de identidade e um fornecedor
de serviços.
9 O Kerberos é um protocolo de transporte de rede, que permite comunicações individuais seguras e identifica-
das, em uma rede insegura. Utiliza criptografia simétria e previne ataques Eavesdropping e Replay.
10 O SPML, acrônimo inglês para Service Provisioning Markup Language, é um framework baseado em XML,
sendo desenvolvido pela OASIS, para troca de usuários, recursos, informações entre organizações.
11 O XKMS (XML Key Management Specification) , utiliza os serviços da WEB para tornar mais fácil para os
desenvolvedores utilizar a inter-comunicação entre as aplicações por meio da infra-estrutura de chaves públicas
(PKI)
4.6 SSL/TLS ou WS-Security para mensagens SOAP 61
Fig. 4.8: Visão geral do Framework WS-Security
(LAWRENCE; KALER, 2007).
4.6 SSL/TLS ou WS-Security para mensagens SOAP
A camada de segurança nas aplicações WEB pode ocorrer em duas maneiras: na camada de
transporte (rede) ou na camada de aplicação (mensagem). Entretanto, geralmente quando uma
aplicação WEB precisa de segurança a primeira tecnologia mencionada é o SSL/TLS. Estes,
sem dúvida, são conjuntos de ferramentas que garante uma proteção de informações em nível
de rede com eficiência. Todavia, dependendo do ambiente da aplicação, o uso do SSL/TLS nem
sempre consegue garantir a segurança da comunicação.
Através de uma análise mais detalhada em uma comunicação SSL/TLS entre dois com-
putadores, a informação é criptografada enquanto a mensagem trafega na rede, ou seja, entre
o cliente e o servidor. Depois que o dado chega no servidor, este é descriptografado e, caso
necessário, é repassado para algum serviço desejado. No entanto, caso a repassagem ocorra, a
mensagem não é re-criptografada. Portanto, a partir daquela decodificação, a informação trafega
legivelmente na rede. Enfim o SSL/TLS irá proteger a privacidade do conteúdo da mensagem
somente enquanto estiver sendo transmitida. Em outras palavras, a segurança na camada de
transporte não protege as mensagens durante o tempo que estão sendo analisádas pelos serviços
intermediários. Assim, o SSL/TLS garante somente a segurança em comunicações denomina-
das ponto a ponto (ver figura 4.9). O WS-Security resolve este problema mantendo a integridade
e confidencialidade dos dados em todos os estágios da comunicação. Isto é, o WSS expande a
segurança nos locais onde o SSL/TLS não protege e tem o objetivo de oferecer um modelo de
segurança para as comunicações conhecidas como fim a fim (ver figura 4.10).
4.7 DNSSec 62
Fig. 4.9: Camada da segurança usando SSL/TLS.
Fig. 4.10: Camada da segurança usando WS-Security.
4.7 DNSSec
O objetivo do servidor DNS é traduzir “nomes” para os respectivos “endereços IP” e “en-
dereços IP” para os respectivos “nomes”. Este processo é chamado de resolução do nome ou
resolução do domínio. A estrutura hierárquica da resolução do domínio, no qual um DNS
aponta para outro DNS, possui uma vulnerabilidade de segurança. Uma situação hipotética se-
ria: um usuário poderia solicitar o endereço eletrônico do Banco do Brasil (www.bb.com.br) e
por engano o servidor DNS responderia o endereço do banco da HSBC (www.hsbc.com.br). E
no pior caso seria o servidor DNS responder para um site phishing12 , o qual iria simular o site
do Banco do Brasil.
O DNSSec (TüNNISSEN, 2007) (DNS Security Extensions) é o nome dado às extensões

de segurança propostas ao protocolo DNS, o qual adiciona uma camada de segurança no meca-
nismo de resolução de nomes, reduzindo a manipulação de dados e domínios camuflados. Este
12 O termo phishing é uma forma nomear uma fraude eletrônica, determinada por tentar roubar informações
sigilosas.
4.8 DNSCurve 63
processo é baseado na assinatura digital com o uso da criptografia de chave pública. O DNSSec
realiza a autenticação dos pacotes DNS e assegura-os para que sejam autênticos e íntegros, se-
gundo Friedlander (FRIEDLANDER et al., 2007). No entanto, de acordo com Ballani e Francis
(BALLANI; FRANCIS, 2008), o DNSSec não fornece a confidencialidade dos dados, ou seja,
todos os pacotes DNSSec são autenticados mas não cripgrafado. Dessa maneira, DNSSec não
protege contra os ataques DoS (denial of service).
4.8 DNSCurve
O DNSCurve (BERNSTEIN., 2009) é um recente protocolo desenvolvido pelo professor

Daniel J. Bernstein da universidade norte-americana Illinois de Chigago, o qual anunciou, em
agosto de 2008, a proposta de garantir um DNS seguro. O DNSCurve utiliza a criptografia de
curva elíptica de alta velocidade e de alta segurança com objetivo de melhorar a segurança no
DNS incorporando-o com as seguintes propriedades: confidencialidade, integridade e disponi-
bilidade.
A confidencialidade é aplicada através da codificação de todos os pacotes DNS, pois, por

padrão, todos os pedidos e respostas DNS são transmitidos descriptografado e qualquer inva-
dor tem a possibilidade de lê-los. Esta criptografia adicionada elimina os ataques DoS. Já a
integridade é feita por meio da autenticação de cada pacote DNS, eliminando os falsos pacotes
DNS criados por terceros. Segundo Bernstein, a segurança dos protocolos alto nível (SMTP,
HTTP, HTTPS) é necessária, porém a proteção do DNS é o primeiro passo que deve ser tomado
para prevenir contra os ataques, porque o DNS é o primeiro servió utilizado para acessar uam
aplicação WEB. Portanto, a diferença entre o DNSSec e o DNSCurve é a proteção criptográfica
adicionada os pacotes DNS.
64
5 Identificação Digital
Diariamente muitos usuários utilizam meios como: assinaturas à caneta, carimbos, selos,
registro de identificação, reconhecimento de firma, simplesmente com o objetivo de confirmar a
autenticidade de documentos, declarar alguma responsabilidade, ou até mesmo, comprovar uma
identificação de pessoa física ou pessoa jurídica. Atualmente, graças à informatização, a maioria
dessas atividades pode ser realizada através da Internet. Assim, é neste exato momento que entra
em cena a identificação digital e conceitos relacionados, como por exemplo, a assinatura digital.
5.1 Certificação Digital
A certificação digital é um processo de identificação onde se torna possível as diversas tran-

sações eletrônicas respeitando as principais características de segurança – integridade, autenti-
cidade e confidencialidade – impedindo a ocorrência das adulterações e das interceptações das
informações. Portanto, esta tecnologia é baseada principalmente em um documento eletrônico
– certificado digital – junto com um recurso conhecido como assinatura digital.
5.1.1 Assinatura Digital
A assinatura digital é um esquema criptográfico desenvolvido para demonstrar a auten-

ticidade de uma mensagem ou de um documento digital. De acordo com Krause e Tipson
(KRAUSE; TIPSON, 1998), estruturamente, a assinatura digital é um bloco de dados anexado
a uma mensagem (por exemplo, um arquivo ou um registro) para um determinado indivíduo de
tal forma que a assinatura pode ser verificada pelo destinatário, ou por um terceiro qualquer,
com objetivo de verificar a identidade do emissor. Analogicamente, a assinatura digital é um
método de autenticação semelhante à assinatura manuscrita.
Uma assinatura digital válida fornece ao destinatário uma razão para acreditar que a men-
sagem foi criada por um remetente conhecido, e também, que a mesma não sofreu alterações
em trânsito. Em outras palavras, a assinatura digital dispõe uma prova inegável de que uma
mensagem foi realmente emitida pelo dono da assinatura, ou seja, o emissor. Para que todas
5.2 Gerenciamentos de Chaves Públicas 65
as vantagens descritas acima se tornem possíveis, é necessário que a assinatura digital tenha
a obrigação de cumprir as seguintes propriedades: autenticidade, integridade e não repúdio,
segundo Tenenbaum (TANENBAUM, 2002).
Uma importante observação é que a assinatura digital não garante a confidencialidade. Isto
é, a mensagem enviada é segura contra alterações, porém não contra a técnica de eavesdrop-
ping1 . Isto ocorre nos casos em que apenas uma porção da mensagem é utilizada para a assina-
tura digital, pois o restante da mensagem é transmitido em texto não criptografado. Entretanto,
mesmo nos casos onde a assinatura digital é aplicada em toda a mensagem, também não existe
a proteção da confidencialidade, pois qualquer observador poderá decifrá-la utilizando a chave
pública do emissor.
O processo da assinatura digital é baseado em dois processos criptográficos: (1) a geração

do código hash da mensagem e (2) a codificação deste hash através da criptografia assimé-
trica ou sistema de chave-pública. Dessa maneira, para assinar uma mensagem, o emissor deve
primeiramente gerar um resumo criptográfico (digest ou hash) em uma pequena porção da men-
sagem (em vez da mensagem por inteiro, pois resulta em um desempenho melhor e alcança os
mesmos resultados, segundo Stallings (STALLINGS, 1999)) utilizando uma função hash pú-
blica (por exemplo, MD5, SHA-1, SHA-256).
A segunda etapa do processo da assinatura digital é aplicar cifragem no digest utilizando

a chave-privada do emissor. Em outras palavras, é neste momento que ocorre a garantia da
autenticação propriamente dita. E por último, o remetente anexa o “hash criptografado” na
mensagem original, o qual é enviado para o destinatário. Ver ilustração 5.1. Na verificação da
autenticidade da mensagem, o receptor deve gerar um novo hash, utilizando a mesma função
hash do emissor. Posteriormente, a assinatura digital é descriptografar através da chave-pública
do remetente para obter aquele hash original – gerado anteriormente pelo emissor. Feito estas
duas tarefas, deve-se então fazer a comparação dos dois digestes em questão. Caso verifique-se
a igualdade, conclui-se que a mensagem foi realmente assinada pelo emissor. Ver ilustração
5.2.
5.2 Gerenciamentos de Chaves Públicas
Conforme descrito até agora, a criptografia de chave-pública possibilita a comunicação de

forma segura entre pessoas que não compartilham uma chave-secreta em comum. Tornou-se
possível também, a assinatura de mensagens sem a presença de uma terceira entidade confiá-
1A técnica eavesdropping é baseada na violação da confidencialidade. Uma analogia seria a ação de grampear
um telefone. Isto é, esta técnica hacking é nada mais do que realizar uma leitura não autorizada das mensagens.
Fig. 5.1: Aplicando assinatura digital. (1) Calculando hash. (2) Encriptando o hash gerado. (3)
Anexando o hash criptografado na mensagem
Fig. 5.2: Verificando a assinatura digital. (4) Destinatário recebe a mensagem assinada. (5)
Cálculo do novo hash. (6) Descriptografia da assinatura. (7) Comparação dos hashes gerados.
vel (por exemplo, a Autoridade Certificadora – AC). E consequentemente, a assinatura digital

possibilitou a verificação da integridade das mensagens recebidas com facilidade.
Entretanto, existe um sério problema que ainda não discutimos: Como iniciar a comunica-
ção segura entre duas entidades desconhecidas?. Em outras palavras: Como realizar a troca
das chaves públicas, de forma segura, antes de iniciar o processo de comunicação?. Uma so-
lução óbvia para este caso, seria simplesmente disponibilizar as chaves públicas das entidades
na Internet – o único local em comum e de acesso público para os indivíduos em questão. No
entanto, esta solução torna-se inviável pela existência do ataque man-in-the-middle – “homem
do meio” (Melhores detalhes no capítulo 6). Segundo Stallings (STALLINGS, 2006), um dos
principais papéis da criptografia de chave pública é resolver o problema da distribuição das cha-
ves, tanto da pública quanto da privada. Com isso é necessário que haja um método a troca das
chaves públicas com segurança (certificado digital), antes de iniciar uma comunicação.
5.2.1 Certificados Digitais
O certificado digital é uma credencial o qual possui a finalidade de identificar uma entidade
(pessoa jurídica, pessoa física, computadores, aplicação WEB), para comprovar a sua identidade
com o intuíto de assegurar as transações eletrônicas. Também conhecido como certificado de
identidade ou certificado de chave pública, o certificado digital é basicamente um documento
eletrônico que utiliza a assinatura digital para vincular uma chave pública a uma entidade. Re-
sumidamente, o certificado de identidade garante a autenticidade de autoria na relação existente
entre a chave pública e a entidade.
Inicialmente, uma das primeiras soluções para resolver o problema da permuta das chaves
públicas, segundo Tenenbaum (TANENBAUM, 2002), foi originar um centro de distribuição de
chaves disponível 24 horas por dia para providenciar as devidas chaves públicas sob demanda.
Entretanto, um dos principais problemas é a característica da escalabilidade2 , pois em algum
determinado tempo poderia ocorrer um “gargalo” no centro de distribuição, e assim, caso ocorra
alguma falha, se tornaria automaticamente indisponível, e portanto, o estabelecimento de uma
comunicação segura iria tornar-se inesperadamente inexequível.
Desse modo, a solução final para esse problema foi então, redirecionada para uma organi-
zação denominada autoridade certificadora – AC (do inglês Certification Authority – CA), a
qual é definida como um terceiro confiável e responsável pelo gerenciamento de certificados.
No mundo real, uma credencial de identificação (Cadastro de Pessoas Físicas – CPF, Carteira
de Motorista, Carteira de Identidade – RG, Passaporte) será genuína em qualquer órgão pú-
blico ou privado, se a mesma foi devidamente emitida por um órgão habilitado pelo governo.
Analogicamente, esta mesma situação acontece no mundo virtual, isto é deve-se confiar apenas
nos certificados digitais emitidos por Autoridades Certificadoras de confiança (por exemplo,
CertiSign (DIGITAL, 2009), VeriSign (VERISIGN, 2009)).
Os certificados digitais possuem um padrão, definido pela ITU-T, conhecido como X.509,
que atualmente se encontra na versão 3. Basicamente um certificado no padrão X.509 é com-
posto pelas seguintes informações do proprietário: chave pública, nome e endereço de e-mail, a
validade da chave pública, nome e endereço da Autoridade Certificadora que o emitiu, número
de série do Certificado Digital e assinatura digital da AC.
Enfim, um certificado digital é simplesmente um documento eletrônico assinado por uma

2 Escalabilidadeé uma característica desejável em todo o sistema, em uma rede ou em um processo, que indica
sua habilidade de manipular uma porção crescente de trabalho de forma uniforme, ou estar preparado para crescer.
autoridade certificadora e que contém todas as informações necessárias do proprietário (ver

figura 5.3). O titular pode, então, publicar o seu certificado na Internet, e qualquer indivíduo
que precise da chave pública do titular, basta adquirir o seu certificado e verificar da assinatura
da AC.
Fig. 5.3: Gerando um Certificado Digital
5.2.1.1 A Solução do Problema Inicial
Dessa maneira, retornando ao problema inicial, agora temos duas entidades hipotéticas, A e
B, sendo que A deseja realizar uma comunicação segura com B. Sendo assim, o primeiro passo
da solução seria que B gerasse um certificado digital através de uma Autoridade Certificadora
de confiança. Basicamente, a AC iria assinar digitalmente a chave pública de B, de modo que a
utilização ou a falsificação dessa chave seria evitada. Posteriormente, a entidade B enviaria seu
certificado para a entidade A, e após uma análise e a confirmação da assinatura digital da AC,
A concluiria que a AC é confiável. Portanto, A retiraria do certificado a chave pública de B, e
a partir desta, criptografaria todas as informações que serão remetidas ao dono da chave. Deste
ponto em diante, somente a chave privada do destinatário pode decriptografar os dados, ou seja,
apenas B poderá ler o conteúdo da mensagem. Portanto, a comunicação é realmente segura.
69
6 Os Ataques
Depois de apresentar um estudo sobre algumas importantes ferramentas de segurança, é

necessário conhecer alguns principais tipos de ataques hacking existentes e praticados atual-
mente. Em outras palavras, para garantir sistemas seguros é preciso também compreender como
induzi-los ao estado de falha e, consequentemente, descobrir as vulnerabilidades de segurança
da aplicação.
Há a necessidade de ressaltar que não existe na prática uma técnica passo a passo para
realizar uma invasão bem sucedida. O que existe são táticas e estratégias realizadas de forma
inteligente, isto é, de modo planejado. Por outro lado, os ataques de rede estão em constante
evolução, e assim, a cada dia são descobertas novas vulnerabilidades e consequentemente sur-
gem formas de praticar ataques. Esse ciclo induz à desatualização da segurança. Enfim, vamos
apresentar uma introdução às estratégias preferidas dos invasores da última geração. Outra im-
portante consideração é que alguns logs de redes são abandonados e provavelmenet não estão
recebendo as mínimas correções de segurança necessárias.
6.1 Passo 1: Reconhecimento do Alvo
O reconhecimento do alvo nem sempre é necessário, porém informar-se sobre a arquitetura

da vítima possibilita um ataque bem sucedido. Como por exemplo, para descobrir o nome do
domínio de uma empresa ou organização, geralmente basta incluir um .com ou .com.br ao final
do seu nome. Caso isto não funcione, o próximo passo é buscar no Google (GOOGLE, 2009a).
Assim, com o nome do domínio, é possível aprender sobre a vítima por meio de ferramentas
como, por exemplo, o whois. O whois é um protocolo UDP (User Datagram Protocol) espe-
cífico para consultar as informações de contato (administrativo, técnico; além de endereços e
números de telefones dos mesmos) e do DNS (quem registrou, validade, quando o domínio foi
criado e atualizado) de algum domínio ou de um endereço IP existente na Internet.
Os invasores procuram detalhes técnicos, como a localização dos servidores DNS e a com-
petência dos técnicos de segurança da empresa. Isto é, se uma organização for incapaz de con-
figurar seu DNS corretamente, é bem provável que a segurança não terá qualidade o suficiente.
6.2 Passo 2: Verificar a segurança da Rede 70
Para realizar tal proposto, existem outras ferramentas como: nslookup, dig (Domain Informa-
tion Groper) e host. Estes são simplesmente comandos úteis que permitem a interrogação do
DNS pela, e ainda, o teste da configuração do DNS da vítima.
O DNS, na realidade, é configurado, no mínimo, em dois computadores chamado de pri-

mário e secundário. Esses computadores contêm um pequeno banco de dados DNS com in-
formações oficiais sobre seu próprio domínio. O que muitos invasores estão interessados é em
verificar se o servidor DNS foi configurado de forma a permitir transferência de zona. Quando
se altera o conteúdo de um arquivo da zona DNS, há uma transferência dos dados do servidor
DNS primário para o servidor DNS secundário. Essa transferência é chamada de transferência
de zona. Assim, o problema das transferências de zona é que muitas empresas colocam nesta
região informações sobre as suas redes internas. Outro erro grave é permitir a transferências
de zona remotamente. Com isso, o invasor pode usar comandos como o nslookup para execu-
tar essas transferências de zona para sua própria máquina, ou seja, configurar seu computador
para agir como se fosse membro interno da empresa. Esta ação é conhecida como ataque DNS
Spoofing (ZHANG et al., 2009), o qual veremos mais adiante no tópico 6.5.
Enfim, o DNS é o primeiro serviço examinado pelo invasor, pois este é uma fonte de infor-
mações de algum domínio, além da possibilidade de tirar conclusões sobre a topologia da rede
alvo. Entretanto, a visualização da configuração do DNS é erroneamente utilizada nas práticas
ilícitas por terceiros mal intencionados. Então, o que acontece depois que o invasor descobre
onde a aplicação reside?
6.2 Passo 2: Verificar a segurança da Rede
As barreras que os atacantes enfrentam são as aplicações protegidas por mecanismos de

segurança, como: balanceadores de carga, firewall, sistema de prevenção de intrusão (IPS1 ) e
firewals de aplicação WEB (WAF2 ). Desse modo, ao tentar atacar uma aplicação WEB, atrás
de um balanceador de carga, a primeira porção do ataque pode ser direcionada ao servidor
A, enquanto a segunda para o servidor B, o que resultará na interrupção do ataque. Da mesma
forma, se o site estiver protegido por um firewall, IPS ou WAF, estes dispositivos podem detectar
e bloquear os ataques, segundo os autores Ierace (IERACE et al., 2005) e Moosa (MOOSA;
ALSAFFAR, 2008).
1 Um sistema de prevenção de intruso é um mecanismo de segurança de rede que monitora o tráfego e/ou
atividades dos sistema em busca de comportamentos anômalos, em tempo real, para bloquear ou prevenir essas
atividades.
2 Um firewall de aplicação WEB é um dispositivo, plug-in do servidor, ou um filtro que se aplica em um conjunto
de regras para uma comunicação HTTP.

6.3 Passo 3: O Ataque 71
Objetivo deste passo é fundamentado na seguinte questão: “Como detectar tais dispositivos
e contornar suas medidas de proteção?”. Ou seja, é neste momento que o invasor irá testar toda
a segurança do alvo, desde a proteção do domínio (DNS) até a aplicação propriamente dita.
Como por exemplo, se o site usar o DNS para o balanceamento de carga, ferramentas como o
dig os mostrarão com facilidade. Isto é, se no momento da verificação o invasor detectar que o
IP do DNS se altera com frequência, provavelmente há um balanceamento de carga por DNS.
Existem também a ferramenta Nmap (LYON, 2008) um scanner de vulnerabilidade que realiza a
verificação de portas abertas do alvo, muito utilizado para avaliar a segurança dos computadores
e descobrir serviços ou servidores ativos na rede.
Já na detecção de firewall e WAF basta verificar a existência destes mecanismos por meio
de algum ataque simples, isto é, através de um ataque realizado por meio de uma máquina
remota ou atrás de um proxy anônimo, como o Tor3 (APPELBAUM et al., 2009), e verificar
a continuidade da conexão. Assim, caso a conexão seja interrompida imediatamente ou se as
tentativas subsequentes de conexões forem bloqueadas é porque existem os dispositivos citados.
s Assim, no caso de um balanceador de cargas, baseado em DNS, basta utilizar o endereço IP
no lugar do nome DNS em algum ataque, que irá garantir que todos os ataques serão enviados
para o mesmo sistema. Como geralemente os firewalls, IPS e WAF autorizam os tráfegos de
pacotes de e-mail e WEB, o contorno da segurança ocorre porque as maiorias das vítimas não
bloqueiam ou baixam a sensibilidade da segurança deste tráfego legítimo, isto é, na porta 80
para HTTP e na porta 25 para SMTP.
6.3 Passo 3: O Ataque
A maioria dos ataques é realizada através da porta padrão de comunicação — a porta 80.
Dessa maneira, para realizar os métodos descritos acima, o atacante busca servidores vulne-
ráveis através de ferramentas específicas como Nmap4 (LYON, 2008) ou Nessus5 (NESSUS,
2008) . Em seguida, ataca-os utilizando ferramentas auxiliares como: código exploits6 ou tool-
kits (por exemplo, Metasploit Framework 7 (METASPLOIT, 2008)). Com a exploração dessas
vulnerabilidades os invasores conseguem acesso de administrador, ou seja, acesso sem restri-
3 TOR é uma rede de computadores distribuída com o objetivo de oferecer meios de comunicação anônima na
Internet.
4 O Nmap possui novo método de scripts para examinar vulnerabilidades de segurança automaticamente de um
domínio
5 o Nessus é também software de verificação de falhas e vulnerabilidades de segurança
6 Um exploit é um software composto por informações maliciosas ou/e sequência de comandos que aproveita
as vulnerabilidades de um serviço ou servidores

7 O Metasploit Project é um projeto de segurança de computadores que fornece informações sobre vulnerabili-
dades de segurança e auxílios em testes de invasão.

6.4 Passo 4: “Lá Dentro” 72
ções, com isso, podem executar na vítima códigos hostis, roubar informações e apagar dados.
6.4 Passo 4: “Lá Dentro”
Se o invasor conseguiu chegar até aqui, significa que conseguiu comprometer um servidor,
executar um ataque local e ganhar o acesso com privilégio no sistema. Geralmente, é neste
momento que a maioria dos invasores instalam um rootkit8 para manter o acesso ativo e realizar
outra invasão posterior. Um atacante pode usar um rootkit para substituir arquivos executáveis
do sistema operacional para esconder processos e arquivos instalados por terceiros. Com acesso
aos sistemas internos, o invasor consegue acessar qualquer informação ou executar qualquer tipo
software, ou seja, contorna as proteções de segurança configuradas interna ou externamente à
rede. O agressor pode utilizar botnet9 para atacar outras máquinas e redes, enviar spam e coletar
informações pessoais da empresa. Isto é, “lá dentro”, as possibilidades são infinitas.
6.5 Exemplos de Ataques Conhecidos
Inicialmente, as páginas WEB e os e-mails eram compostos basicamente por texto estáticos
com formatação mínima e raramente continham conteúdos executáveis, hoje este cenário é
oposto. Com a introdução da WEB 2.0 e com aperfeiçoamento dos e-mails estes mecanismos
passaram a suportar várias tecnologias executáveis, bem como o famoso JavaScript. Ou seja,
ao mesmo tempo em que houve melhorias no ambiente WEB surgiram novos meios de ataques.
6.5.1 Ataques de Força Bruta
O ataque de força bruta (brute force) é um dos mecanismos mais rústicos para tentar realizar
uma invasão. Muitos hackers consideram esse tipo de ataque um ato de grosseria e não uma
técnica. Os ataques de força bruta são ferramentas automatizadas que simplesmente “saturam”
a vítima com uma grande variedade de informações comuns, como por exemplo, adivinhar a
senha do administrador através das combinações das palavras de um dicionário (criado pelo
próprio invasor e baseado nas informações obtidas do alvo). Assim, o conceito dessa invasão é,
portanto, baseado no processo de tentativa e erro. Exemplos de softwares famosos são: Hydra
(HAUSER, 2006) e o John The Ripper10 (PESLYAK, 2006).
8 Um rootkit é um sistema de software que consiste em um ou mais programas concebidos para obscurecer o
fato de que um sistema foi comprometido
9 Botnet é uma coleção de softwares robôs, ou bots, que são executados automaticamente e de forma autônoma.
10 John the Ripper é um software para quebra de senhas e também consegue identificar automaticamente qual é
o algoritmo de criptografia que foi utilizado para cifrá-las, por exemplo, em DES, MD4 e MD5.
6.5 Exemplos de Ataques Conhecidos 73
6.5.2 Ataque do “Homem do Meio”
O ataque do homem do meio (man-in-the-middle attack, frequentemente abreviado como

MITM) consiste na ação de um usuário mal intencionado em infiltrar-se na comunicação entre
duas entidades, capturar seus dados, e transmiti-las novamente sem que as vítimas percebam.
Em outras palavras, de acordo com Zhang (ZHANG et al., 2009), o MITM é uma forma de
escuta ativa em que o atacante faz conexões independentes com as vítimas e retransmite men-
sagens entre elas, fazendo-as acreditarem que estão se comunicando diretamente umas com as
outras, quando na verdade toda a conversa é “manipulada” pelo atacante.
Esse ataque é possível pois alguns tipos de comunicações não realizam a autenticação de
seus membros, possibilitando que qualquer indivíduo possa participar da comunicação. Basica-
mente, o que ocorre é a facilidade de alguém interceptar a mensagem de A para B, em seguida,
modifica-a e depois a reenvia para B, porém com alguns dados modificados. Atualmente, a mai-
oria dos protocolos criptográficos inclui alguma forma de autenticação das extremidades espe-
cificamente para evitar ataques MITM. Por exemplo, SSL autentica o servidor usando uma au-
toridade de certificação mutuamente confiável. Exemplos de algumas ferramentas que usam os
conceitos MITM: Cain and Abel11 (MONTORO, 2009) e Ettercap12 (ORNAGHI; ORNAGHI,
2005).
6.5.3 Ataques a Servidores Webs
Atualmente, a maioria dos servidores WEB é também servidor de aplicação. Entretanto,

onde há aplicações, há falhas de segurança. Normalmente, uma aplicação básica é composta,
no mínimo, pelos seguintes componentes: (1) a aplicação propriamente dita; (2) o servidor
WEB; (3) um sistema operacional e (4) um banco de dados. Enfim, todos esses componentes
possuem a possibilidade de serem atacados através das falhas de segurança da própria aplicação
e, com isso a existência de várias falhas podem ser combinada de modo a permitir a execução
de exploits e, consequentemente, permite a invasão do servidor. Não é trivial encontrar vulne-
rabilidades da aplicação. Desse modo, uma solução rápida é utilizar ferramentas automazidas,
ou seja, scanner de servidor WEB que tem como objetivo de procurá-las. Como por exemplo:
11 Cain é uma ferramente que pode executar ataques MITM, juntamente com os ataques sniffing e ARP poiso-
ning.
12 Ettercap é um sistema Unix e Windows ferramenta de computador de análise de protocolo de rede e auditoria
de segurança.
Nikto13 (NIKTO, 2007),Paros proxy14 (PAROSPROXY, 2004) e WebScarab15 (OWASP, 2008)

WebScarab.
6.5.3.1 XSS
O ataque XSS, também conhecido como CSS (Cross Site Scripting), é uma vulnerabilidade
frequentemente encontrada nos aplicativos WEB. O XSS é um exemplo perfeito do motivo pelo
qual jamais se deve mesclar dados e códigos em um único objeto. Inicialmente, o HTML era
uma linguagem simples e estática que tornava a WEB monótona. Hoje, graças as linguagens
como o JavaScript da Sun e ActiveScript e ActiveX da Microsoft, a WEB tornou-se dinâmica.
Porém, o grande problema é que atualmente os browser não tem como distinguir qual código
JavaScript, presente na página WEB, deve ou ser executado, como também, se é malicioso
ou não. Segundo Noureddine e Damodaran (NOUREDDINE; DAMODARAN, 2008), é neste
momento que nasceu o ataque XSS, pois os invasores têm a possibilidade de injetar client-side
script16 dentro das páginas WEB legítimas para que seja executado no momento em que tais
páginas forem acessadas.
Segundo Jovanovic (JOVANOVIC et al., 2006), um dos propósitos principais dos ataques
XSS é roubar as credenciais (por exemplo, o cookie) de um usuário autenticado, para que o
invasor consiga representar a sessão ativa da vítima. A ideia básica é que, em uma página vul-
nerável, o invasor pode injetar seu próprio comando malicioso, para que posteriormente busque
o verdadeiro código para invasão em outro domínio — normalmente controlado pelo próprio
invasor. Por exemplo, considera uma pagina WEB escrita em PHP que contenha a linha de có-
digo da listagem 1 onde as informações são recebidas através de uma caixa de texto. Os dados
do parâmetro são enviados por meio do comando GET, porém o invasor tem a possibilidade de
modificá-los, ver listagem 3.
Tudo o que o atacante deve fazer é enganar o usuário para clicar no link modificado da
listagem 3 ao invés do link da listagem 2, por exemplo, enviando-o para a vítima através de e-
mail. Ao clicar, a página (roubarCookie.php) é injetada na máquina da vítima e poderá roubar
cookies (que geralmente têm credenciais de autenticação), teclas, dados de formulário e assim
por diante — enviando para o servidor do invasor.
13 Nikto Web Scanner é um scanner que realiza testes para arquivos perigosos, verifica se os softwares do servidor
está desatualizado.
14 Parosproxy é utilizado para avaliar a vulnerabilidade de aplicações web desenvolvido em Java. Suporta a edi-
ção e visualização das mensagens HTTP e HTTPS, como também, um scanner para testes de ataques de aplicação
web comum, como injeção de SQL e cross-site scripting (XSS)
15 WebScarab é uma ferramenta, que age como uma proxy, interceptando as requisições e respostas entre o
browser o servidor WEB.

16 Código executável na máquina do cliente
echo ‘‘Parâmetros recebidos pelo comando GET: ’’ . $_GET[’parametro’];
Listagem 1: Simples código PHP vulnerável ao XSS.
http://site.vulneravel.com/post.php?parametro=id_sessao
Listagem 2: Link original
6.5.3.2 Injeção SQL
A maioria das aplicações WEB necessita armazenar informações, e nada melhor do que
um banco de dados para tal proposto. Infelizmente, várias aplicações deixam de inspecionar
o conteúdo de uma consulta SQL (query17 ) e, com isso, não constrõem consultas de forma
segura. O SQL Injection é então, de acordo com Lam (LAM et al., 2008), um ato que o atacante
consegue inserir instruções SQL dentro de uma query por meio da manipulação da entrada de
dados de uma aplicação.
Para concretizar o conceito da injeção SQL, vamos demonstrar um caso comum, com o
seguinte exemplo: supondo que para autenticar o acesso em uma aplicação fictícia é utilizado
o código da listagem 4. As variáveis username e password recebem o conteúdo enviado do
formulário da página WEB. Entretanto, se o usuário inserir os dados (’ or 1=1; –) para a va-
riável username e deixar vazio o campo password, resultará em outra consulta completamente
diferente da inicial, com relação a semântica SQL (ver listagem 5). Isto é, o invasor consegue
contornar o sistema de autenticação, pois não importa qual o nome do usuário a consulta sem-
pre retornará um valor booleano verdade, pois a query se resume na verificação booleana OR,
no qual um dos membros da equação é 1 = 1. Isso permite que o agressor se autentique sem
possuir uma senha ou nome de usuário válido.
O ponto-e-vírgula (;) adicionado denota o término de uma consulta e o início de outra. Já

o hífen duplo (–) indica que o restante da linha atual é um comentário e deve ser ignorado.
Se o código modificado estiver sintaticamente correto, será executado pelo servidor. Se não for
realizada qualquer validação sobre os textos enviados nos formulários para verificar tal situação,
qualquer utilizador mal intencionado pode obter acesso ao sistema. Esse é um exemplo muito
simples de ataque. Uma ferramenta para testar as injeção SQL em aplicações WEB é o SQLMap
(DAMELE, 2009) cujo objetivo é detectar as vulnerabilidades de injeção SQL.
17 A unidade de execução do SQL é denominada query, que é um conjunto de instruções que manipulam o banco
de dados.
http://site.vulneravel.com/post.php?parametro=
<script>document.location= ’servidor.invasor.com/roubarCookie.php?’+document.cookie</script>
Listagem 3: Exemplo de ataques XSS – Link modificado
SELECT * FROM users WHERE username = ’" + username + "’ AND password = ’" + password + "’";
Listagem 4: Exemplo de Injeção de SQL – Injetando código SQL nas caixas de textos
6.5.3.3 CSRF
O CSRF (Cross-site reference forgery – “pedido falso entre sites”) é um ataque similar ao
XSS, mas basicamente a diferença é que o invasor rouba os cookie (ainda com sessões ativas)
usados em outra aba no próprio navegador. Por exemplo, a vítima carrega uma página WEB
que faz referência a uma imagem cujo endereço foi substituído por uma chamada para outro
site, provavelmente uma que a vítima tenha um acesso por autenticação. E caso no momento do
acesso à página modificada, a vítima esteja autenticada nesta aplicação WEB, o invasor poderá
executar ações indesejadas, como uma transferência bancária (ver listagem 6, mas somente
funcionará se vítima estiver autenticada no banco e sua sessão ativa).
Esse ataque é relativamente novo, segundo Barth (BARTH et al., 2008), porque a navega-
ção por abas só se tornou popular nos últimos anos. De acordo com Wadlow e Gorelik (WA-
DLOW; GORELIK, 2009), essa técnica de invasão é uma demonstração interessante de como
um recurso do navegador pode amplificar velhos problemas. Uma das razões pelas quais os
engenheiros da Google (GOOGLE, 2009a) distribuem cada aba em processos distintos, no Ch-
rome (GOOGLE, 2009b), é para evitar ataques CSRF, afirmam Wadlow e Gorelik (WADLOW;
GORELIK, 2009).
6.5.3.4 Phishing
O ataque phishing é composto por um golpe eletrônico cujo objetivo é roubar dados sigi-
losos da vítima, tais como senhas, número da conta bancária e números de cartão de crédito,
através da falsificação de uma organização confiável e a subsequente comunicação eletrônica
“oficial” por meio de e-mails e páginas WEB falsas. Para conseguir capturar as informações
confidenciais, os phishers devem que utilizar técnicas para estimular as vítimas a cederem tais
informações. Segundo Moosa e Alsaffar (MOOSA; ALSAFFAR, 2008), esta indução para ex-
trair os dados é denominada engenharia social. O termo phishing é variante da palavra inglesa
fishing (em português, “pescar”), ou seja, a essência desse ataque é baseado na tentativa de
“pescar” os dados dos usuários.
SELECT * FROM users WHERE username = ’’ or 1=1;--’ AND password = ’’;
Listagem 5: O atacante é autenticando como o primeiro usuário da tabela user.
<img src=’’http://banco.exemplo/transferencia?conta=joao&valor=1000000&for=invasor’’>
Listagem 6: Exemplo do ataque CSRF
De acordo com Herzberg e Jbara (HERZBERG; JBARA, 2008), geralmente os phishers

utilizam logomarcas reais das empresas e cópias de mensagens eletrônicas legítimas, substi-
tuindo apenas os links para redirecionar a vítima à página fraudulenta, porém semelhante a
original. Um exemplo simples seria: detectar a diferença entre “google.com” e “googIe.com”,
no qual a letra minúscula “l” foi substituído pelo “I” maiúsculo. Desse modo, o objetivo desse
ataque é estimular uma ação imediata da vítima, estimulado-a agir primeiro e pensar depois.
Para conseguir tal proposto, normalmente, as falsas mensagens ameaçam os usuários através
do cancelamento da conta, caso não responda imediatamente. Outras agradecem a vítima por
fazerem uma compra que nunca fizeram, provocando-a a entrarem no sistema “falso” e veri-
ficar a possível compra realizada, porém no momento da autenticação a vítima fornece dados
válidos para autenticar no sistema “real”. Para combater este tipo de ataque, existe um grupo
anti-phishing (Anti-Phishing Working Group – APWG) (APWG, 2009) que é uma associação
centrada na eliminação da fraude e roubo de identidade virtuais.
6.5.3.5 DNS Spoofing
O DNS Spoofing é a arte de falsificar uma resposta DNS (DNS Responds) para enganar a
vítima desviando-a ao um domínio diferente do esperado, ou seja, apontar para um IP diferente
do que seria suposto a apontar. Por exemplo, a vítima visita uma página WEB de um banco
qualquer (www.banco.com.br) e imediatamente o navegador WEB irá realizar um pedido DNS
(DNS Request) da URL em questão para o servidor DNS, e este retornará uma resposta DNS
(DNS Responds), o qual contém o endereço IP legítimo do servidor WEB onde o site do banco
está armazenado. No entanto, durante um ataque de DNS Spoofing a vítima recebe uma res-
posta DNS modificada contendo um endereço IP de um outro servidor (normalmente de posse
do invasor) forçando-a a se conectar a esse servidor WEB. Caso o ataque DNS Spoofing seja
combinado com o phishing, a vítima será redirecionada a um site semelhante do banco, ou seja,
todo processo é transparente para o usuário, pois este digita uma URL válida e é direcionado a
uma página falsificada.
6.5.3.6 Clickjacking
Segundo Wadlow e Gorelik (WADLOW; GORELIK, 2009), o clickjacking é um ataque re-

lativamente novo, o qual permite aos invasores esconderem códigos maliciosos camufladoa em
um botão legítimo de uma página WEB legítima. Basicamente o ataque funciona da seguinte
maneira: em uma página clickjacked, os atacantes mostram um conjunto de botões falsos (so-
mente a “fachada” do botão), em seguida, carrega outra página sobre a primeira só que em uma
camada transparente. Assim, quando os usuários clicam nos falsos botões visíveis, estes estão
na verdade clicando nos botões da página escondida. O clickjacking é similar ao ataque cross-
site request forgery e para que o ataque funcione corretamente é necessário a captura de cookies
e que a sessão do usuário esteja ativa.
79
7 Auditoria de Segurança a Aplicações

Web
Depois de determinar a estratégia de defesa, desenvolver a política de segurança e implantar

a proteção, o próximo passo é o gerenciamento da segurança. Entretanto, um dos grandes
obstáculos desta atividade é identificar todos os pontos fracos do ambiente da aplicação WEB
que precisam de tratamento para definir quais serão os níveis de segurança necessários para
cada um deles. Os principais problemas de segurança são à entrada de dados arbitrários dos
usuários à aplicação WEB. Dessa maneira, com aumento dos serviços on-line, os aplicativos
WEB frequentemente são desenvolvidos sem a inclusão de uma segurança apropriada na camada
da aplicação.
O principal problema da insegurança da WEB dinâmica são as linguagens de programação

sofisticadas (por exemplo, AJAX) para WEB, pois a maioria das requisições são realizada em
client-side (execução ocorre no computador do usuário e não no servidor) as quais são passível
de alterações. Com isso, surgem as vulnerabilidades os quais representam um caminho para os
invasores acessar ou roubar dados e informações corporativas e pessoais. Portanto, é necessário
uma varredura nas aplicações WEB para procurar as vulnerabilidades através de ferramentas
específicas que veremos a seguir. Esta atividade representa uma maneira para os auditores de
segurança se defendam contra os ataques.
7.1 Arquitetura básica de Segurança na WEB
Uma arquitetura básica de segurança para a proteção das aplicações na WEB é ilustrada na
figura 7.1. Normalmente, esta arquitetura é composta por quatro camadas, as quais são: (1)
camada do usuário (desktop); (2) camada de transporte entre o usuário e o servidor WEB; (3)
camada da rede interna do servidor e (4) camada da aplicação. Desse modo, prover a proteção
nestas quatro camadas, consequentemente, irá garantir a segurança de toda a comunicação entre
o usuário e a aplicação WEB.
Na camada do usuário, ferramentas como antivírus e firewall domésticos fornecerá a se-

gurança neste nível. Já na camada de transporte, o uso de protocolos criptográficos, como
7.1 Arquitetura básica de Segurança na WEB 80
SSL/TLS e WS-Security, as informações poderá ser trafegadas com segurança e permitindo

acesso aos dados apenas para os indivíduos permitidos. Na camada do servidor WEB meca-
nismo como, fireall coorporativo, IDS (Intrusion Detection Systems) e IPS (Intrusion Prevention
Systems); realizam bloqueios de acessos não permitidos e de comportamento estranho ou des-
conhecidos em toda a rede, segundo Guimaraes e Murray (GUIMARAES; MURRAY, 2008).
E por último, na camada da aplicação, existem os WAF (Web application firewalls) que são
ferramentas para proteger aplicativos da WEB contra os atuais ataques, de acordo com Moosa e
Alsaffar (MOOSA; ALSAFFAR, 2008).
Fig. 7.1: Arquitetura básica de Segurança na WEB
No entanto, diante todas as camadas de segurança os invasores conseguem enganá-los e

romper as proteções do ambiente WEB. Isto ocorre, pois algumas entradas de dados podem ser
inofensivas aos mecanismos de defesa, porém quando analisados pela aplicação propriamente
dita podem levá-la ao um estado não previsto pelo desenvolvedor. Nesta instabilidade surgem
as brechas e consequentemente as invasões. Os estados imprevistos acontecem porque as ferra-
mentas que operam nas camadas de segurança descrito acima não analisa lógica da aplicação,
ou seja, estas ferramentas visualizam as aplicações como uma “caixa preta”. Assim é necessá-
rio utilizar as ferramentas de auditoria de segurança para garantir que as camadas de segurança
estão realmente funcionando, como também, filtrar tanto a entrada quanto a saída dos dados da
aplicação WEB.
Outra forma de garantir a segurança das aplicações é no seu desenvolvimento. Em ou-

tras palavras, deve incluir a segurança como parte do ciclo de vida do software. A figura 7.2
apresenta o ciclo de vida da ferramenta IBM Rational AppScan (IBM, 2009). Portanto, para
garantir a segurança desdo o princípio, é importante analisar os pontos fracos da aplicação an-
7.2 Modelo de Gerenciamento de Segurança 81
tes de construí-las para que o programador possa desenvolvê-la com uma pré-orientação sobre
a segurança. Ou seja, o ideal é desenvolvê-la com baixa taxa de vulnerabilidades, ao invés de
consertá-la, posteriormente, pelo estilo codifica/remenda (método “tapa-buraco”).
Fig. 7.2: Segurança: Parte do Ciclo de Vida do IBM Rational AppScan
7.2 Modelo de Gerenciamento de Segurança
7.2.1 Modelo de Teias
O Modelo de Teias (NAKAMURA; GEUS, 2004) é composto por sete fases e uma figura,
sendo que cada uma das fases possui uma função fundamental da maneira de como a segu-
rança deve ser executada. Todas as fases auxiliam na organização da estratégia de segurança,
diminuindo a probabilidade de algum aspecto ser esquecido. A figura 7.3 representa a figura
genérica do Modelo de Teias. No centro da figura encontra-se o recurso (por exemplo, firewall,
roteador, servidor WEB, servidor de e-mail, banco de dados, dentre outros) que será analisado.
Ao redor são traçados alguns elementos de segurança (por exemplo, portas abertas, controle de
acesso, senha, versão sistema operacional, procedimento em caso de ataque, dentro outros), os
quais devem ser avaliados.
Assim, o traço preto representa a situação real, enquanto o traço cinza representa a situação
desejada para o recurso. Cada circunferência circunscrita no recurso representa um nível de
segurança, o qual depende da política inicialmente estabelecida pelo gerente de segurança. Os
espaços entre os traços pretos e cinzas significa os risco do recurso. Assim, quanto maior o
espaço indica que o nível de segurança real do elemento é deficiente, e consequentemente,
será necessário maior esforço para atingir o nível ideal deste elemento, e, portanto melhorar a
Fig. 7.3: Modelo de Teias. Fonte: (NAKAMURA; GEUS, 2004)
segurança do recurso como um todo. Após a conclusão dos setes fases, gera como resultado,
uma relação da dimensão da segurança que é necessário ser aplicada em cada recurso, com o
objetivo de alcançar o nível ideal.
7.2.2 A sete fases do modelo
7.2.2.1 Fase 1: Definição dos elementos de segurança
O principal objetivo da primeira fase do Modelo de Teias é construir um framework de ele-

mentos de segurança. Um elemento de segurança é definido como qualquer individuo que age
diretamente ou indiretamente no nível de segurança de um determinado recurso. Cada elemento
tem a possibilidade de ser analisado e avaliado. Exemplos de elementos de segurança: senha,
controle de acesso, segurança física, portas abertas do sistema, procedimentos de segurança,
respostas aos ataques, vulnerabilidades, versões dos serviços.
7.2.2.2 Fase 2: Definição dos recursos
Depois de definir um framework para os elementos de segurança é necessário também de-

finir os recursos que serão gerenciados. Um recurso é qualquer entidade ativa e funcional do
sistema. Exemplos incluem: firewall, roteadores, servidores em gerais, banco de dados.
7.2.2.3 Fase 3: Análise de segurança
A análise de segurança compreende na relação entre os elementos de segurança e os recur-

sos, ou seja, para cara recurso definido é distribuído na figura da teia os respectivos elementos de
segurança aplicáveis a este recurso, isto é, os elementos influência no ciclo de vida do recurso.
Nessa fase é necessário conhecimentos, pois uma análise contendo erros pode comprometer as
fases seguintes, ou seja, danificar o gerenciamento como um todo, por não ministrar uma visão
da situação real do recurso.
7.2.2.4 Fase 4: Classificação dos recursos
A classificação dos recursos consiste em somente definir o nível de segurança de cada ele-
mento de segurança do recurso, e interligando-os iremos traçar a teia real do recurso. Também
é preciso conhecimentos técnicos e experiência profissional nesta fase, pois qualquer erro pode
gerar uma falsa sensação de segurança, e neste caso, as implantações das medidas de segurança
podem ser insuficientes ou desnecessárias. Esta fase deve sempre ser realizada com frequência,
porque pode surgir uma nova vulnerabilidade ou um novo método de ataque e, com isso, o que
é considerado seguro hoje, pode ser inseguro amanhã.
7.2.2.5 Fase 5: Avaliação dos riscos
Nessa fase consistem em apenas em realizar uma análise do recurso em questão de acordo
com os riscos envolvidos. Ou seja, consiste em mensurar os riscos de cada elemento de segu-
rança com o objetivo de minimizá-los.
7.2.2.6 Fase 6: Definição do nível de segurança desejado
Depois de examinar a avaliação dos riscos de cada elemento de segurança e compará-los

com os respectivos níveis de segurança reais, deve-se propor então um novo nível de segurança,
denominado de nível ideal, para que os riscos sejam diminuídos. Assim, interligando os novos
níveis iremos traçar a teia ideal.
7.2.2.7 Fase 7: Definição das medidas de segurança
Nesta fase a figura do Modelo de Teia esta completa (figura 7.4), e assim, é possível qual
elemento de segurança precisa aplicar as medidas de segurança necessárias para um progresso
geral do recurso. Esta analisa pode ser feita através da distância entre a teia real e a teia ideal.
Assim, o objetivo desta fase é determinar as medidas de segurança a ser tomados para a dis-
tância seja eliminada. Caso todas sejam omitidas o recurso encontra-se no seu estado ideal. É
neste momento que conhecimentos das técnicas e tecnologias de segurança são necessários e
fundamentais.
7.3 Ferramentas de auditoria de segurança 84
Fig. 7.4: Os elementos de seguraça definem o nível do servidor. Fonte: (NAKAMURA; GEUS,
2004)
7.2.3 Resultados apresentados pelo Modelo de Teias
O Modelo de Teia proporciona uma visualização panorâmica do sistema para realizar um

gerenciamento apropriado da segurança da aplicação. Portanto, através dessa visão é possível
reconhecer e identificar o fator limitante da segurança, isto é, os pontos de falha que limitam a
segurança da aplicação e que devem ser eliminados. Entretanto, o gerenciamento da segurança
através do Modelo de Teias compõe uma atividade que deve ser realizada constantemente, pois
os níveis de segurança mudam com frequência e, consequentemente, implica em adotar novas
medidas de segurança. Enfim, segundo Nakamura e Geus (NAKAMURA; GEUS, 2004) através
do Modelo de Teias é notável do que era difícil de gerenciar, tornou-se, pelo menos, gerenciável.
7.3 Ferramentas de auditoria de segurança
Muitas organizações dependem dos software baseado na WEB para executar seus processos
de negócio, realizar operações e prestar serviços cada vez mais sofisticados para os clientes.
Infelizmente, na corrida para cumprir prazos e permanecer à frente da concorrência, muitas
organizações deixam de realizar testes adequados de segurança certificar-se se as normas de
proteção estão funcionando normalmente. O resultado é que muitas empresas podem expor
involuntariamente os dados corporativos ou pessoais para os criminosos, os quais exploram
essas vulnerabilidades por diversão ou com objetivo de colocar toda a organização em risco.
Portanto, para proteger as informações sigilosas é necessário testar os aplicativos WEB em todo
o seu ciclo de vida, desde o momento de desenvolvimento até o de funcionamento.
A maioria das ferramentas de auditoria de segurança funciona como um proxy, um processo

que obriga todo o fluxo de informações a ser redirecionado para a auditoria, ou seja, a ferramenta
torna-se um intermediário para realizar análises dos dados (pedidos e respostas HTTP) que
percorrem na aplicação WEB. Em outras palavras, todas as ferramentas agem como um “homem
do meio”.
7.3.1 Ratproxy
O ratproxy (ZALEWSKI, 2008) é uma ferramenta de auditoria de segurança, disponibi-

lizado pelo Google (GOOGLE, 2009a), e tem o objetivo de realizar uma detecção precisa e
sensível de potenciais problemas de segurança no tráfego complexo do ambiente WEB 2.0. O
ratproxy possui licença livre de uso e atua como um proxy entre o servidor e as respectivas
aplicações WEB. Como resultado produz um relatório fácil de consultar sobre as falhas em po-
tencial que estejam presentes no aplicativo. Detecta e prioriza grandes classes de problemas de
segurança, tais como ataques XSS e CSRF, injeções de scripts, redirecionamento HTTP, dentre
outros. Esta ferramenta não depende do sistema operacional oferecendo suporte para os ambi-
entes: Linux, FreeBSD, MacOS X e Windows (através do Cygwin1 )e é licenciado pelo Apache
(Apache License 2.0) (APACHE, 2004).
7.3.2 WebScarab
O WebScarab (OWASP, 2008) é um framework para análise de aplicativos que se comu-

nicam utilizando os protocolos HTTP e HTTPS. Desenvolvido em Java, e, portanto é portátil
em várias plataformas. O WebScarab tem vários modos de operação, implementados por uma
série de plugins. No seu uso mais comum, o WebScarab funciona como um proxy intercep-
tar, permitindo que o operador de rever e modificar visitas criado pelo browser antes de serem
enviados para o servidor, e para rever e modificar respostas retornadas do servidor antes de
serem recebidos pelo navegador. Também pode realizar testes de ataques XSS e CSRF. Por-
tanto, o WebScarab é uma ferramenta que age como um “WEB debugging” (depurador WEB)
interceptando as requisições entre navegador e servidor WEB.
7.3.3 Paros
A ferramenta Paros (PAROSPROXY, 2004) foi desenvolvida para avaliar a segurança de

suas aplicações WEB. O seu uso é gratuito e totalmente escrito em Java. O Paros é um proxy
que analisa todos os dados HTTP e HTTPS entre o servidor e o cliente, incluindo os arquivos
cookies e campos de formulário, os quais podem ser interceptados e modificados em tempo real.
1 Cygwin é uma coleção de software para permitir que várias versões do Microsoft Windows possam trabalhar
com as ferramentes dos sistema baseado em Unix.

Além de verifica todas as páginas WEB, o Paros analisa também os conteúdo “invisíveis”, tais
como comentários e outras informações que auxiliam, direta ou indiretamente, a existência de
dados que não podem ser divulgado.
7.3.4 Burp Proxy
O Burp proxy (PORTSWIGGER, 2009) é um servidor proxy HTTP e HTTPS utilizado

para atacar e testar aplicações WEB. Esta ferramenta funciona como “homem do meio” entre o
navegador e o servidor WEB, permitindo o auditor a inspecionar e modificar o tráfego de men-
sagens em ambos os sentidos. O Burp proxy permite encontrar e explorar vulnerabilidades de
aplicativos através do controle e manipulação de parâmetros críticos e outros dados transmiti-
dos pelo aplicativo. Ao modificar solicitações do navegador em várias maneiras maliciosas, o
Burp proxy pode ser usado para simular ataques como injeção de SQL, roubo de sessão (ses-
sion hijacking) e cookies. Desenvolvido em Java, o Burp proxy não é um software livre sendo
necessário comprá-lo para utilizá-lo.
7.3.5 w3af
O w3af (Web Application Attack and Audit Framework) é um framework para automati-
zação da auditoria e exploração de vulnerabilidades nas aplicações WEB. Esta ferramenta é
um software livre e licenciado pelo GNU General Public License Version 2. (GNU, 2007), e
também, testas os principais ataques, como: XSS, CSRF e Injeção SQL. Desenvolvido na lin-
guagem de programação Python, portanto é o w3af pode ser executado tanto no ambiente Linux
quanto no Windows.
7.3.6 IBM Rational AppScan
O programa IBM Rational AppScan (IBM, 2009) automatiza os testes de segurança de apli-
cações WEB através da análise e identificação de vulnerabilidades e a geração de relatórios com
recomendações de correção para facilitar o reparo. Esta ferramenta oferece suporte para as
últimas tecnologias da WEB 2.0, incluindo suporte avançado para a tecnologia Adobe Flash e
avançadas linguagens JavaScript, juntamente com um suporte abrangente para o AJAX. Além
disso, cada vez que a aplicação é iniciada, o AppScan, baixa as notificações sobre as últimas
ameaças de segurança do banco de dados da IBM. O Rational AppScan é composta por um con-
junto de seis edições, porem todas fornecem mecanismo de varredura, elaboração de relatórios
e recomendações para correções. A diferença é que cada versão focaliza em áreas específicas
ao longo do ciclo de vida da aplicação WEB, assim temos:
• IBM Rational AppScan Tester Edition: Ajuda as equipes da garantia da qualidade a

encontrar e corrigir vulnerabilidades de segurança no início do processo de desenvolvi-
mento, reduzindo custos e riscos corporativos.
• IBM Rational AppScan Build Edition: Aplica os testes de segurança das aplicações
WEB dentro da gestão do fluxo de desenvolvimento. Como resultado, esta edição oferece
uma abrangente análise da vulnerabilidade, e oferece um ambiente de recomendações
específicas para a correção das falhas;
• IBM Rational AppScan Developer Edition: Esta edição permite aos desenvolvedores
a capacidade de invocar testes de segurança para aplicação WEB no seu ambiente de
desenvolvimento;
• IBM Rational AppScan Express Edition: A edição express garante solução para auto-
matizar testes de segurança de aplicações WEB de médio porte;
• IBM Rational AppScan Enterprise Edition: A edição express garante solução para
automatizar testes de segurança de aplicações WEB de grande porte, é projetado para
ajudar as organizações a distribuir a responsabilidade para os testes de segurança entre os
múltiplos stakeholder;
• IBM Rational AppScan Reporting Console: Esta versão é apoiada por um banco de
dados empresarial que lhe permite consolidar os resultados da verificação das varredura
do AppScan através da construção de um repositório centralizado das vulnerabilidade do
aplicativo WEB com o propósito de gerar um histórico das vulnerabilidades encontradas;
• IBM Rational AppScan Standard Edition: Garente solução para automatizar testes de
segurança de aplicações WEB de pequeno porte, reduzindo os custos associados a testes
de verificações de vulnerabilidade realiza manualmente.
Além procurar as vulnerabilidades comuns das aplicações WEB, o AppScan também faz va-
lidação e testes das ameaças classificadas pela WASC (Web Application Security Consortium)
(WASC, 2009). Infelizmente, todas as edições do IBM Rational AppScan oferece suporte ape-
nas para o sistema operacional Windows e, também, é preciso pagar pelo seu uso. Enfim, o
AppScan tenta promover a garantir da segurança dos aplicativos WEB em todo o ciclo de vida
de desenvolvimento do software.
7.4 Comparativo entre as Ferramentas de Auditoria 88
7.4 Comparativo entre as Ferramentas de Auditoria
Todos os software de auditoria descritos anteriormente são ferramentas que auxiliam na

segurança da aplicação WEB, os quais realizam testes dos principais tipos de ataques (como
por exemplo: XSS, CSRF e Injeção SQL) através da manipulação dos pedidos e respostas
HTTP/HTTPS entre o usuário e aplicação WEB. Por meio destas ferramentas é possível analisar
situações que não foram previstas em seu desenvolvimento, ou seja, fazem simulações de dados
inofensivos para a camada de segurança. Porém quando são analisados pela lógica da aplicação
pode encaminha-la a um estado instável e, portanto, facilitando as invasões.
Tab. 5: Comparativo entre as Ferramentas de Auditoria

Ratproxy WebScarab Paros Burp Proxy w3af IBM AppScan
Licença Livre Sim Sim Sim Não Sim Não
Multiplataforma Sim Sim Sim Sim Sim Não
Manipula pedidos/resposta HTTP(S)2 Não Sim Sim Sim Sim Sim
Relatório detalhado Sim Não Sim Sim Sim Sim
Sugestão para Correção Não Não Não Não Não Sim
Suporte SSL/TLS Sim Sim Sim Sim Sim Sim
XSS, Injeção SQL, CSRF Sim Sim Sim Sim Sim Sim
Análise de Cookies Sim Sim Sim Sim Sim Sim
Análise de dados ocultos Não Não Sim Não Não Sim
Análise RESTful3 Não Sim Sim Não Sim Não
Ambiente Desenvolvimento4 Não Não Não Não Não Sim
A tabela 5 mostra um comparativo das ferramentas de auditoria de segurança descritas an-

teriormente. Todos os softwares opera como um proxy interceptando as informações entre o
navegador e aplicação WEB. Alguns permitem a manipulação dos dados (pedidos e respostas
HTTP/HTTPS) para simular algum tipo de ataque (como por exemplo, o XSS) e, assim, testar
a segurança em vários setores da aplicação. Outros, no final dos testes, apresentam relató-
rios detalhados sobre as vulnerabilidades encontradas. No entanto, apenas a ferramenta IBM
AppScan gera um relatório que é composto com sugestões para corrigir os erros encontrados e,
também, possui testes em todos os estágios do desenvolvimento do software. Enfim, a maioria
das vulnerabilidades das aplicações WEB ocorrem por permitir a entrada de qualquer tipo de
dados, e estes quando analisados pela camada lógica da aplicação poderá assumir estados ins-
táveis, como por exemplo, habilitando acesso à um terceiro não autorizado, o qual consegue ter
o controle dos dados internos, sigilosos ou não, da aplicação WEB.
2A Manipulação dos pedidos/respostas HTTP e HTTPS são feitas em tempo real.
3 Todas as ferramentas de auditoria realizam testes nos métodos HTTP básicos, GET e POST. Entretanto, o
RESTful é composto também por mais dois métodos: PUT e DELETE. Estes métodos são diretamente relaciona-
dos com ações SQL, como: (1) PUT:Insert, (2) GET:Select, (3) POST:Update, (4) DELETE:Delete.
4 Integra-se testes de segurança no ambiente de desenvolvimento para ajudar a encontrar vulnerabilidades no
início da aplicação WEB.

89
8 Conclusão
No presente trabalho descrevemos os principais problemas relacionados com a segurança

e com a confiabilidade das aplicações no ambiente WEB. Frente aos problemas e às amea-
ças a segurança encontrados neste contexto, diversas técnicas são propostas com objetivo de
solucioná-los, ou pelo menos minimizá-los, para dificultar e impedir as ações realizadas por
terceiros não autorizados. Desse modo, como a criptografia é base da segurança, apresentamos
primeiramente, uma série de algoritmos criptográficos, os quais são divididos em três seções:
simétrico, assimétrico e hash. Como a comunicação entre o usuário e a aplicação WEB é feita
através da Internet por meio de um browser, é necessário proteger o canal de comunicação.
Esta funcionalidade é então destinada aos protocolos criptográficos, os quais são baseados na
integração dos três tipos de criptografia. Assim, a segurança do tráfego entre o navegador e a
aplicação WEB é garantida pelo SSL/TLS, caso a comunicação seja ponto a ponto, ou garantida
pelo WS-Security, caso as comunicações seja fim a fim.
Outra técnica para garantir a segurança no ambiente WEB é a identificação digital, processo
composto pela assinatura e certificado digital. As duas técnicas em conjunto são responsáveis
por estabelecer as transações eletrônicas respeitando as principais características de segurança –
integridade, autenticidade e da confidencialidade – impedindo a possibilidade das adulterações e
das interceptações das informações. Dessa forma, através da certificação digital é possível usar
a Internet como meio de comunicação alternativo para a disponibilização de diversos serviços
com uma maior agilidade, facilidade de acesso e substancial redução de custos.
Todas os mecanismos de proteção para ambiente WEB apresentados até então não garantem
a proteção na lógica da aplicação. Dessa forma, os principais problemas de segurança nas
aplicações WEB são a entrada de dados arbitrários, os quais podem ser inofensivos para os
protocolos criptográficos e, assim, deixam estas informações trafegarem livremente. Entretanto,
quando analisadas pela aplicação WEB propriamente dita, podem resultar na sua instabilidade e,
portanto, facilitando as invasões. Isto ocorre pois a maioria das aplicações são desenvolvidas em
linguagem sofisticada de programação (AJAX) onde as requisições são realizadas em client-side
as quais são passível de alterações. Desse modo, as maiorias dos ataques atualmente ocorrem
por não validar e filtrar a entrada das informações na camada da aplicação. Como exemplo
8 Conclusão 90
destas atividades citamos os principais tipos de ataques: injeção SQL, XSS e CSRF. Assim, para
solucionar este problema, apresentamos as ferramentas de auditoria de segurança que fazem
uma varredura nas aplicações WEB na procura dessas vulnerabilidades.
O objetivo dessa pesquisa não foi a de esgotar o assunto abordado, mas sim fornecer ao
leitor um texto compacto, mas que reúne conceitos fundamentais ao entendimento do tema.
Este trabalho pretende servir como base e motivação ao leitor na busca de novos conhecimentos
no campo da segurança relacionadas ao ambiente WEB. Há uma necessidade urgente para uma
detecção automática de vulnerabilidade no desenvolvimento dessas aplicações, especialmente
porque estão cada vez mais sendo utilizados em grande escala e tornando-se mais complexos,
como por exemplo, a introdução da computação na nuvem (cloud computing). Esta idéia é em
um futuro próximo utilizar, em qualquer lugar e independente de plataforma, as mais variadas
aplicações WEB através da Internet com a mesma facilidade de tê-las instaladas em nossos
próprios computadores. Logo, a segurança deste novo conceito será imprescindível.
91
Referências Bibliográficas
ALLEN, C. et al. The TLS Protocol Version 1.0. 1999. Disponível em: <http://www.ietf.org-
/rfc/rfc2246.txt>. Acesso em: 07.15.2009.
ANDERSON, R. et al. A Candidate Block Cipher for the Advanced Encryption Standard. 1998.
Disponível em: <http://www.cl.cam.ac.uk/˜rja14/serpent.html>. Acesso em: 21.04.2009.
ANSI. American National Standards Institute. 2009. Disponível em: <http://www.ansi.org/>.

Acesso em: 05.19.2009.
APACHE. Apache License, Version 2.0. 2004. Disponível em: <http://www.apache.org-

/licenses/LICENSE-2.0>. Acesso em: 14.10.2009.
APPELBAUM, J. et al. The Tor Projects. 2009. Disponível em: <http://www.torproject.org/>.

Acesso em: 10.10.2009.
APWG. Anti-Phishing Working Group. 2009. Disponível em: <http://www.antiphishing.org/>.

Acesso em: 10.10.2009.
BALDWIN, R. W. et al. The RC5 RC5-CBC RC5-CBC-Pad and RC5-CTS Algorithms. 1996.
Disponível em: <http://www.rfc-editor.org/rfc/rfc2040.txt>. Acesso em: 23.04.2009.
BALLANI, H. et al. Mitigating dns dos attacks. In: CCS ’08: Proceedings of the 15th ACM
conference on Computer and communications security. New York, NY, USA: ACM, 2008. p.
189–198. ISBN 978-1-59593-810-7. Acesso em: 21.10.2009.
BARISON, D. Segurança e privacidade em redes. Monografia do curso de Ciência da

Computação da Universidade Estadual de Londrina, p. 10–50, 2006. Acesso em: 18.04.2009.
BARKER, W. C. Recommendation for the Triple Data Encryption Algorithm (TDEA) Block
Cipher. NIST Special Publication 800-67. 2004. Disponível em: <http://csrc.nist.gov-
/publications/nistpubs/800-67/SP800-67.pdf>. Acesso em: 18.04.2009.
BARTH, A. et al. Robust defenses for cross-site request forgery. In: CCS ’08: Proceedings of
the 15th ACM conference on Computer and communications security. New York, NY, USA:
ACM, 2008. p. 75–88. ISBN 978-1-59593-810-7. Acesso em: 20.10.2009.
BERNSTEIN., D. J. DNSCurve: Usable security for DNS. 2009. Disponível em:

<http://dnscurve.org/index.html>. Acesso em: 07.04.2009.
CISCO. SSL: Foundation for Web Security. 1998. Disponível em: <http://www.cisco.com-
/web/about/ac123/ac147/archived issues/ipj 1-1/ssl.html>. Acesso em: 06.29.2009.
DAEMEN, J. et al. Aes proposal: Rijndael. The Rijndael Block Cipher, p. 4–16, 1999.
Disponível em: <http://www.daimi.au.dk/˜ivan/rijndael.pdf>. Acesso em: 20.04.2009.
DAMELE, B. SQLmap: automatic SQL injection tool. 2009. Disponível em: <http://sqlmap-
.sourceforge.net/>. Acesso em: 14.10.2009.
Referências Bibliográficas 92
DIFFIE, W. et al. New directions in cryptography. IEEE Transactions on Information Theory

Transactions on Information Theory, Vol. It-22, No. 6, p. 644–654, 1976. Disponível em:
<http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=01055638>. Acesso em: 05.04.2009.
DIFFIE, W. et al. New directions in cryptography. IEEE Transactions on Information Theory,
vol. It-22, p. 644–654., 1976. Disponível em: <http://www.cs.rutgers.edu/˜tdnguyen/classes-
/cs671/presentations/Arvind-NEWDIRS.pdf>. Acesso em: 05.14.2009.
DIGITAL, C. C. Certisign - A sua identidade na rede. 2009. Disponível em: <http://www-
.certisign.com.br/>. Acesso em: 07.15.2009.
DISTRIBUTED.NET. Project RC5. 2009. Disponível em: <http://www.distributed.net/rc5-
/index.php.en>. Acesso em: 25.04.2009.
EFF. Electronic Frontier Foundation’s "DES Cracker"Machine. [S.l.], 1998. Disponível
em: <http://w2.eff.org/Privacy/Crypto/Crypto% underline misc/DESCracker/HTML-
/19980716 eff des faq.html>. Acesso em: 16.04.2009.
ERL, T. WS-* Specifications. 2008. Disponível em: <http://www.ws-standards.com/ws-
security.asp>. Acesso em: 07.15.2009.
FIPS. Secure Hash Standard - FIPS PUB 180-2. 2002. Disponível em: <http://csrc.nist.gov-
/publications/fips/fips180-2/fips180-2withchangenotice.pdf>. Acesso em: 05.26.2009.
FREIER PHILIP KARLTON, P. C. K. A. O. The SSL Protocol Version 3.0. 1996. Disponível
em: <http://www.mozilla.org/projects/security/pki/nss/ssl/draft302.txt>. Acesso em:
06.14.2009.
FRIEDLANDER, A. et al. Dnssec: a protocol toward securing the internet infrastructure.
Commun. ACM, ACM, New York, NY, USA, v. 50, n. 6, p. 44–50, 2007. ISSN 0001-0782.
Acesso em: 21.10.2009.
GARFINKEL, S. et al. Web security privacy and commerce. 2, ilustrada. ed. [S.l.]: O’Reilly,
2002. Acesso em: 06.10.2009.
GNU. GNU General Public License. 2007. Disponível em: <http://www.gnu.org/copyleft/gpl-
.html>. Acesso em: 14.10.2009.
GOOGLE. Google. 2009. Disponível em: <http://www.google.com.br/>. Acesso em:
10.10.2009.
GOOGLE. Google Chrome. 2009. Disponível em: <http://www.google.com.br/chrome>.
Acesso em: 10.10.2009.
GOURLEY, D. et al. HTTP: the definitive guide. [S.l.]: Marjorie Sayer and Sailu Reddy and
Anshu Aggarwal, 2002. 322-335 p. Acesso em: 17.07.2009.
GUDGIN, M. et al. SOAP Version 1.2 Part 1: Messaging Framework (Second Edition). 2007.
Disponível em: <http://www.w3.org/TR/soap12-part1/>. Acesso em: 07.15.2009.
GUIMARAES, M. et al. Overview of intrusion detection and intrusion prevention. In:
InfoSecCD ’08: Proceedings of the 5th annual conference on Information security curriculum
development. New York, NY, USA: ACM, 2008. p. 44–46. ISBN 978-1-60558-333-4. Acesso
em: 18.10.2009.
GUTIERREZ, C. M. et al. Digital Signature Standard (DSS). 2008. Disponível em: <http:-
//csrc.nist.gov/publications/drafts/fips 186-3/Draft FIPS-186-3%20 November2008.pdf>.
Acesso em: 05.18.2009.
HAUSER, V. The Hacker’s Choice-Hydra. 2006. Disponível em: <http://freeworld.thc.org-

/thc-hydra/>. Acesso em: 11.10.2009.
HERZBERG, A. et al. Security and identification indicators for browsers against spoofing and
phishing attacks. ACM Trans. Internet Technol., ACM, New York, NY, USA, v. 8, n. 4, p. 1–36,
2008. ISSN 1533-5399. Acesso em: 20.10.2009.
HOFFMAN, P. Cryptographic Suites for IPsec. 2005. Disponível em: <http://tools.ietf.org-

/html/rfc4308>. Acesso em: 24.07.2009.
IBM. Rational AppScan. 2009. Disponível em: <http://www.webappsec.org/>. Acesso em:

14.10.2009.
IERACE, N. et al. Intrusion prevention systems. Ubiquity, ACM, New York, NY, USA,
v. 2005, n. June, p. 2–2, 2005. Acesso em: 20.10.2009.
ISO. ISO - International Organization for Standardization. 2009. Disponível em:

<http://www.iso.org/>. Acesso em: 07.15.2009.
ITU-T. Security architecture for open systems interconnection for CCITT Application:
Recommendation X.800. 1991. Disponível em: <http://fag.grm.hia.no/IKT7000/litteratur-
/paper/x800.pdf>. Acesso em: 05.29.2009.
JAMSA, K. A. et al. Hacker proof: the ultimate guide to network security General Interest.
[S.l.]: Cengage Learning, 2002. Acesso em: 21.07.2009.
JOVANOVIC, N. et al. Precise alias analysis for static detection of web application
vulnerabilities. In: PLAS ’06: Proceedings of the 2006 workshop on Programming languages
and analysis for security. New York, NY, USA: ACM, 2006. p. 27–36. ISBN 1-59593-374-3.
Acesso em: 21.10.2009.
KALISKI, B. Standard Specifications For Public Key Cryptography. 1999. IEEE 1363-2000.
Disponível em: <http://grouper.ieee.org/groups/1363/P1363/index.html>. Acesso em:
05.18.2009.
KAUFMAN, C. Internet Key Exchange (IKEv2) Protocol. 2005. Disponível em: <http://tools-
.ietf.org/html/rfc4306>. Acesso em: 05.17.2009.
KAUKONEN, K. et al. A Stream Cipher Encryption Algorithm "Arcfour". 1999. IETF Draft.
Disponível em: <http://www.mozilla.org/projects/security/pki/nss/draft-kaukonen-cipher-
arcfour-03.txt>. Acesso em: 28.04.2009.
KENT, S. IP Authentication Header. 2005. Disponível em: <http://tools.ietf.org/html-

/rfc4302>. Acesso em: 23.07.2009.
KENT, S. et al. Security Architecture for the Internet Protocol. 2005. Disponível em:
<http://tools.ietf.org/html/rfc4301>. Acesso em: 23.07.2009.
KHALIFA, O. et al. Communications cryptography. RF and Microwave Conference,

2004. RFM 2004. Proceedings, v. 5-6 October, p. xii+280, 2004. Disponível em:
<http://ieeexplore.ieee.org/xpl/RecentCon.jsp?punumber=9663>. Acesso em: 06.04.2009.
KRAUSE, M. et al. Handbook of Information Security Management. [S.l.]: Auerbach, 1998.
Acesso em: 10.04.2009.
KRAWCZYK, H. et al. HMAC: Keyed-Hashing for Message Authentication. 1997. Disponível
em: <http://tools.ietf.org/html/rfc2104>. Acesso em: 07.17.2009.
LABORATORIES, R. PKCS 1 v2.1: RSA Cryptography Standard. 2002. Disponível em:
<ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1/pkcs-1v2-1.pdf>. Acesso em: 05.08.2009.
LAM, M. S. et al. Securing web applications with static and dynamic information flow
tracking. In: PEPM ’08: Proceedings of the 2008 ACM SIGPLAN symposium on Partial
evaluation and semantics-based program manipulation. New York, NY, USA: ACM, 2008. p.
3–12. ISBN 978-1-59593-977-7. Acesso em: 11.10.2009.
LAW, L. et al. An Efficient Protocol for Authenticated Key Agreement. 1998. University of
Waterloo, Canada. Disponível em: <http://www.cacr.math.uwaterloo.ca/techreports/1998-
/corr98-05.pdf>. Acesso em: 05.17.2009.
LAWRENCE, K. et al. Organization for the Advancement of Structured Information Standards.
2006. Disponível em: <http://www.oasis-open.org/>. Acesso em: 07.15.2009.
LAWRENCE, K. et al. Web Services Security. 2006. Disponível em: <http://www.oasis-open-
.org/committees/wss>. Acesso em: 07.15.2009.
LAWRENCE, K. et al. WS-Trust 1.3. 2007. Disponível em: <http://docs.oasis-open.org/ws-
sx/ws-trust% -/200512/ws-trust-1.3-os.html>. Acesso em: 07.15.2009.
LIMA, M. F. Segurança e privacidade na comunicação em redes. Monografia do curso de
Ciência da Computação da Universidade Estadual de Londrina, 2008. Acesso em: 11.04.2009.
LISKOV, M. et al. Tweakable block ciphers. In: CRYPTO ’02: Proceedings of the 22nd
Annual International Cryptology Conference on Advances in Cryptology. London, UK:
Springer-Verlag, 2002. Disponível em: <http://www.cs.berkeley.edu/˜daw/papers/tweak-
crypto02.pdf>.
LYON, G. Nmap. 2008. Disponível em: <http://nmap.org/>. Acesso em: 10.10.2009.
METASPLOIT. Metasploit Project. 2008. Disponível em: <http://www.metasploit.com/>.
Acesso em: 10.10.2009.
MONTORO, M. Cain and Abel. 2009. Disponível em: <http://www.oxid.it/cain.html>.
Acesso em: 11.10.2009.
MOOSA, A. et al. Proposing a hybrid-intelligent framework to secure e-government web
applications. In: ICEGOV ’08: Proceedings of the 2nd International Conference on Theory
and Practice of Electronic Governance. New York, NY, USA: ACM, 2008. p. 52–59. ISBN
978-1-60558-386-0. Acesso em: 20.10.2009.
NAKAMURA, E. T. et al. Segurança de Redes: Em Ambientes Cooperativos. 3 edição. ed.
[S.l.]: Futura, 2004. Acesso em: 05.27.2009.
NESSUS. Nessus. 2008. Disponível em: <http://nessus.org/nessus/>. Acesso em: 10.10.2009.

NEUMANN, P. G. Risks to the public. SIGSOFT Softw. Eng. Notes, ACM, New York, NY,
USA, v. 33, n. 4, p. 17–26, 2008. ISSN 0163-5948. Acesso em: 11.10.2009.
NEWBILL, W. T. Licensing Declaration for US patent 6829355. 2007. Disponível em:
<https://datatracker.ietf.org/ipr/858/>. Acesso em: 05.26.2009.
NIKTO. Nikto CIRT Inc. 2007. Disponível em: <http://www.cirt.net/nikto2>. Acesso em:
14.10.2009.
NIST. Data Encryption Standard (DES). 1999. Disponível em: <http://csrc.nist.gov-
/publications/fips/fips46-3/fips46-3.pdf>. Acesso em: 15.04.2009.
NIST. Advanced Encryption Standard (AES). 2001. Disponível em: <http://www.csrc.nist-
.gov/publications/fips/fips197/fips-197.pdf>. Acesso em: 20.04.2009.
NIST. Nist’S Policy On Hash Functions. 2005. Disponível em: <http://csrc.nist.gov/groups-
/ST/hash/policy.html>. Acesso em: 05.26.2009.
NIST. SHA-3 competition. 2008. Cryptographic Hash Project. Disponível em: <http://www-
.csrc.nist.gov/groups/ST/hash/index.html>. Acesso em: 05.25.2009.
NOUREDDINE, A. A. et al. Security in web 2.0 application development. In: iiWAS
’08: Proceedings of the 10th International Conference on Information Integration and
Web-based Applications & Services. New York, NY, USA: ACM, 2008. p. 681–685. ISBN
978-1-60558-349-5. Acesso em: 11.10.2009.
OPENSSL. OpenSSL: The Open Source toolkit for SSL/TLS. 2009. Disponível em:
<http://www.openssl.org/>. Acesso em: 07.15.2009.
ORNAGHI, A. et al. Ettercap. 2005. Disponível em: <http://ettercap.sourceforge.net/>.
Acesso em: 11.10.2009.
OWASP. WebScarab Project. 2008. Disponível em: <http://www.owasp.org/index.php-
/Category:OWASP WebScarab Project>. Acesso em: 20.10.2009.
PAROSPROXY. Parosproxy.org - Web Application Security. 2004. Disponível em:
<http://www.parosproxy.org/>. Acesso em: 14.10.2009.
PESLYAK, A. John the Ripper password cracker. 2006. Disponível em: <http://www-
.openwall.com/john/>. Acesso em: 11.10.2009.
PORTSWIGGER. PortSwigger.net - Burp Proxy. 2009. Disponível em: <http://portswigger-
.net/proxy/>. Acesso em: 14.10.2009.
RESCORLA, E. HTTP Over TLS. 2000. Disponível em: <http://tools.ietf.org/html/rfc2818>.
Acesso em: 17.07.2009.
RESCORLA, E. et al. The Transport Layer Security (TLS) Protocol Version 1.2. 2008.
Disponível em: <http://tools.ietf.org/rfc/rfc5246.txt>. Acesso em: 07.15.2009.
RIVEST, R. et al. The MD6 hash function A proposal to NIST for SHA-3. 2008. Disponível
em: <http://groups.csail.mit.edu/cis/md6/submitted-2008-10-27/Supporting Documentation-
/md6 report.pdf>. Acesso em: 06.18.2009.
RIVEST, R. et al. The rc6 block cipher. RSA Laboratories and M.I.T. Laboratory for Computer
Science, Version 1.1, p. 1–3, 1998. Disponível em: <http://people.csail.mit.edu/rivest/Rc6-
.pdf>. Acesso em: 25.04.2009.
RIVEST, R. et al. A method for obtaining digital signatures and public-key cryptosystems.
Communications of the ACM, v. 21, p. 120–126, 1978. Disponível em: <http://theory.lcs.mit-
.edu/˜rivest/rsapaper.pdf>. Acesso em: 05.08.2009.
RIVEST, R. L. The rc5 encryption algorithm. Proceedings of the Second International

Workshop on Fast Software Encryption (FSE), e, p. 86–96, 1994. Disponível em:
<http://theory.lcs.mit.edu/˜rivest/Rivest-rc5rev.pdf>. Acesso em: 23.04.2009.
RIVEST, R. L. The MD6 Hash Algorithm. 2009. Disponível em: <http://groups.csail.mit.edu-

/cis/md6/index.html>. Acesso em: 06.18.2009.
SAEKI, M. Elliptic Curve Cryptosystems. 1997. School of Computer Science, McGill

University, Montreal. Disponível em: <http://www.cs.mcgill.ca/˜crepeau/PDF% -/memoire-
mugino.pdf>. Acesso em: 05.18.2009.
SAKALLI, M. et al. Cryptography education for students. In: Information Technology Based
Higher Education and Training, 2004. ITHET 2004. Proceedings of the FIfth International
Conference on. [S.l.: s.n.], 2004. p. 621–626. Acesso em: 07.04.2009.
SALOMON, D. Data privacy and security. [S.l.]: Springer, 2003. Acesso em: 21.04.2009.
SCHNEIER, B. The Blowfish Encryption Algorithm. 1993. Disponível em: <http://www-

.schneier.com/blowfish.html>. Acesso em: 21.04.2009.
SCHNEIER, B. Description of a New Variable-Length Key, 64-Bit Block Cipher (Blowfish).

1994. Acesso em: 21.04.2009.
SCHNEIER, B. Twofish. 1998. Disponível em: <http://www.schneier.com/twofish.html>.

Acesso em: 21.04.2009.
SCHNEIER, B. Cryptanalysis of MD5 and SHA: Time for a New Standard. 2004. Disponível
em: <http://www.schneier.com/essay-074.html>. Acesso em: 07.15.2009.
SCHNEIER, B. et al. The Twofish encryption algorithm: a 128-bit block cipher. New York,
NY, USA: John Wiley e Sons, Inc., 1999. 3 - 10 p. ISBN 0-471-35381-7. Acesso em:
21.04.2009.
SHIREY, D. R. W. Internet Security Glossary, Version 2. 2007. Disponível em: <http://tools-

.ietf.org/rfc/rfc4949.txt>. Acesso em: 05.29.2009.
STALLINGS, W. Network Security Essentials: Applications and Standard. [S.l.]: Prentice

Hall, 1999. 366 p. Acesso em: 18.04.2009.
STALLINGS, W. Cryptography and network security: principles and practice. 4, illustrated.

ed. [S.l.]: Prentice Hall, 2006. 189-194 p. Acesso em: 11.04.2009.
STALLINGS, W. Network security essentials: applications and standards. 3, illustrated. ed.

[S.l.]: Prentice Hall, 2007. Acesso em: 26.11.2009.
STEVENS, M. et al. Vulnerability of software integrity and code signing applications to

chosen-prefix collisions for MD5. 2007. Disponível em: <http://www.win.tue.nl/hashclash-
/SoftIntCodeSign/>. Acesso em: 05.22.2009.
TANENBAUM, A. S. Computer networks. 4, illustrated. ed. [S.l.]: Prentice Hall PTR, 2002.
789-802 p. Acesso em: 21.04.2009.
TüNNISSEN, J. DNSSEC: DNS Security Extensions Securing the Domain Name System. 2007.
Disponível em: <http://www.dnssec.net/>. Acesso em: 08.25.2009.
VERISIGN. VeriSign Nasdaq: VRSN. 2009. Disponível em: <http://www.verisign.com/>.

Acesso em: 07.15.2009.
VIVO, M. de et al. Internet security attacks at the basic levels. SIGOPS Oper. Syst. Rev., ACM,
New York, NY, USA, v. 32, n. 2, p. 4–15, 1998. ISSN 0163-5980. Acesso em: 06.06.2009.
W3C. World Wide Web Consortium. 2009. Disponível em: <http://www.w3.org/>. Acesso
em: 10.08.2009.
WADLOW, T. et al. Security in the browser. Commun. ACM, ACM, New York, NY, USA,
v. 52, n. 5, p. 40–45, 2009. ISSN 0001-0782. Acesso em: 19.10.2009.
WANG, X. et al. How to Break MD5 and Other Hash Functions. 2008. Shandong University,
Jinan 250100, China. Disponível em: <http://web.archive.org/web/20070604205756%
-/http://www.infosec.sdu.edu.cn/paper/md5-attack.pdf>. Acesso em: 05.21.2009.
WASC. Web Application Security Consortium. 2009. Disponível em: <http://www.webappsec-

.org/>. Acesso em: 14.10.2009.
X9. The Accredited Standards Committee X9, Inc. [s.d.]. Disponível em: <http://www.x9.org-
/home>. Acesso em: 05.19.2009.
ZALEWSKI, M. Ratproxy passive web application security assessment tool. 2008. Disponível
em: <http://code.google.com/p/ratproxy/>. Acesso em: 20.10.2009.
ZHANG, R. et al. On the feasibility of launching the man-in-the-middle attacks on voip from
remote attackers. In: ASIACCS ’09: Proceedings of the 4th International Symposium on
Information, Computer, and Communications Security. New York, NY, USA: ACM, 2009. p.
61–69. ISBN 978-1-60558-394-5. Acesso em: 20.10.2009.

Segurança de Aplicações Na Web

Caricato da

Informazioni sul documento

Descrizione originale:

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

Segurança de Aplicações Na Web

Caricato da

Copyright:

Formati disponibili

Departamento de Computação

Trabalho de Conclusão de Curso

THIAGO AUGUSTO LOPES GENEZ

SEGURANÇA DE APLICAÇÕES NA WEB

SEGURANÇA DE APLICAÇÕES NA WEB

Trabalho de Conclusão de Curso apresentado ao

Orientador: Prof. Dr. Mario Lemes Proença Jr.

SEGURANÇA DE APLICAÇÕES NA WEB

Trabalho de Conclusão de Curso apresentado

Prof. Dr. Mario Lemes Proença Jr.

Prof. Ms. Fábio Sakuray

Prof. Dr. Alan Salvany Felinto

À Deus pelo desafio da vida.

Ao meu irmão, Lucas, por acreditar e apoiar.

À todos os professores e funcionários do departamento de computação que ajudaram a concluir

Palavras-Chaves: Aplicação, Criptografia, Protocolos, Segurança, Vulnerabilidade

Keywords: Application, Cryptography , Protocol, Security, Vulnerability

2.1 Tipos de ameaça à segurança. Adaptado de (STALLINGS, 1999) . . . . . . . p. 25

2.2 Ataque Ativo: Ataque de mensagens repetitivas. Adaptado de (STALLINGS,

2.3 Ataque Ativo: Modification of Messages. Adaptado de (STALLINGS, 2006) p. 28

2.4 Ataque Ativo: Ataque DoS. Adaptado de (STALLINGS, 2006) . . . . . . . . p. 29

3.1 Modelo de Criptografia. Adaptado de (KRAUSE; TIPSON, 1998) . . . . . . p. 32

3.2 Esquema de uma criptografia simétrica. . . . . . . . . . . . . . . . . . . . . p. 34

4.1 Representação da pilha do protocolo SSL/TLS. Adaptado de (CISCO, 1998) . p. 48

4.2 Operação do SSL Record protocol. Adaptado de (CISCO, 1998) . . . . . . . p. 49

4.3 Tipos de protocolos do Handshake. Adaptado de (STALLINGS, 1999) . . . . p. 50

4.4 Estabelecimento da conexão entre cliente e servidor no SSL/TLS. Adaptado

4.5 Protocolo HTTP sem segurança . . . . . . . . . . . . . . . . . . . . . . . . p. 56

4.6 Protocolo HTTP com segurança . . . . . . . . . . . . . . . . . . . . . . . . p. 57

4.8 Visão geral do Framework WS-Security . . . . . . . . . . . . . . . . . . . . p. 61

4.9 Camada da segurança usando SSL/TLS. . . . . . . . . . . . . . . . . . . . . p. 62

4.10 Camada da segurança usando WS-Security. . . . . . . . . . . . . . . . . . . p. 62

5.2 Verificando a assinatura digital. (4) Destinatário recebe a mensagem assi-

7.1 Arquitetura básica de Segurança na WEB . . . . . . . . . . . . . . . . . . . p. 80

7.2 Segurança: Parte do Ciclo de Vida do IBM Rational AppScan . . . . . . . . p. 81

7.3 Modelo de Teias. Fonte: (NAKAMURA; GEUS, 2004) . . . . . . . . . . . . p. 82

7.4 Os elementos de seguraça definem o nível do servidor. Fonte: (NAKA-

1 Categoria para os algoritmos criptográficos de chave pública . . . . . . . . . p. 40

2 Tipos de mensagens do protocolo Handshake . . . . . . . . . . . . . . . . . p. 51

3 Cipher Suites do SSL v3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 54

4 Cipher Suites do TLS v1.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 55

5 Comparativo entre as Ferramentas de Auditoria . . . . . . . . . . . . . . . . p. 88

3DES Triple Data Encryption Standard

2 Conceitos Básicos de Segurança para Aplicações WEB p. 21

2.1 A necessidade de segurança . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 22

2.2 Os serviços disponibilizados pela segurança . . . . . . . . . . . . . . . . . . p. 23

2.2.5 Controle de Acesso . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 24

2.3 Tipos de ataques contra a Segurança . . . . . . . . . . . . . . . . . . . . . . p. 24

2.3.1 Ataques Passivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 26

2.3.1.1 Liberação do Conteúdo da Mensagem . . . . . . . . . . . p. 26

2.3.1.2 Análise de Tráfego . . . . . . . . . . . . . . . . . . . . . . p. 26

2.3.2 Ataques Ativos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 27

2.3.2.1 Ataque Disfarçado . . . . . . . . . . . . . . . . . . . . . . p. 27

2.3.2.2 Ataque de mensagens repetitivas . . . . . . . . . . . . . . p. 27

2.3.2.3 Modificação de Mensagens . . . . . . . . . . . . . . . . . p. 27

2.3.2.4 Ataque de Negação de Serviço . . . . . . . . . . . . . . . p. 28

2.4 O Problema da segurança no Ambiente WEB . . . . . . . . . . . . . . . . . p. 29

2.4.1 Como solucionar o problema de segurança na WEB . . . . . . . . . . p. 30

3.1 Objetivos da Criptografia . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 33

3.2 Algoritmos Simétricos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 33

3.2.1 Codificação em Blocos . . . . . . . . . . . . . . . . . . . . . . . . . p. 34

3.2.2 Codificação em Fluxo . . . . . . . . . . . . . . . . . . . . . . . . . p. 38