Tutorial: Principais Vulnerabilidades em Aplicações Web – Rafael Soares Ferreira. Webinar sobre este assunto também disponível em http://www.blog.clavis.com.br/webinar-20-as-principais-vulnerabilidades-em-aplicacoes-web-owasp-top-10-2013/

1. Rafael Soares Ferreira
Sócio Diretor Técnico
rafael@clavis.com.br
Principais Vulnerabilidades
em Aplicações Web

2. Apresentação
• Grupo Clavis
• Sócio Diretor Técnico
• Testes de invasão em redes, sistemas e
aplicações

3. Contatos
rafaelsoaresferreira@gmail.com
rafaelsoaresferreira
@rafaelsferreira
www.facebook.com/rafaelsoaresferreira

4. • Compras
• Redes Sociais
• Internet Banking
• Webmail
• Outras...
Utilização

5. • Protocolo leve e simples
• E “stateless”!
• Anytime, Anywhere
• Independe de plataforma
• Atualizações centralizadas
Benefícios

6. • O protocolo HTTP
HTTP 1.0 - RFC-1945
HTTP 1.1 – RFC-2616
RFC 1945:
...is an application-level protocol with the lightness and speed
necessary for distributed, collaborative, hypermedia
information systems. It is a generic, stateless, object-
oriented protocol which can be used for many tasks, such
as name servers and distributed object management
systems, through extension of its request methods
(commands)...
Protocolos e Tecnologias

7. • “Lightness”
• Protocolo em texto puro
• Simples de implementar um cliente
• “Stateless”
• Servidor responde a requisição e
• Encerra a conexão
Protocolos e Tecnologias

8. • Não confiar em dados externos
• Tudo pode ser forjado/modificado
• Validar todos os dados
• Prever e Tratar erros
• Testar segurança, revisar
Segurança Básica

9. Mudança de Paradigma
• What is a secure site?
“a site that uses the HTTPS protocol...”
• Segurança da comunicação é apenas 1
dos problemas
Segurança Básica

10. Erros Comuns
• Falta de Canonicalização
• Verificações Client-Side
• Segurança por Obscuridade
Segurança Básica

11. Canonicalização
• Decisões baseadas em nomes
• Representação de forma única
• Muitas representações para caracteres
• ASCII, hexadecimal, UTF-8, unicode ...
Segurança Básica

12. Canonicalização – Exemplo
• SecureIIS do eEye
http://www.exemplo.com/ver.asp?arquivo=../../../winnt/repair/sam
• Evasão
http://www.exemplo.com/ver.asp?arquivo=%2e%2e/%2e%2e/%2e
%2e/winnt/repair/sam
Segurança Básica

13. Verificações Client-Side
• Facilmente contornadas
• Desabilitar javascript
• Usar um proxy
• Plugins de browser
Segurança Básica

14. Verificações Client-Side
• Tamper data
Segurança Básica

15. Segurança por Obscuridade
• Esconder o problema não resolve
• Pode ser usada como camada adicional
• Nunca como SOLUÇÃO de segurança
Segurança Básica

16. Segurança por Obscuridade
• Trocando a string do Apache
ServerSignature Off
SecServerSignature “Meu Servidor“
Segurança Básica

17. Principais Ameaças
Injeções

18. Descrição
• Envio de dados não tratados para algum
serviço interno.
• Pode ser feita via SQL, LDAP, Xpath, comandos
de sistema operacional, argumentos de
programas, etc.
• Descoberta por varreduras e/ou fuzzers

19. SQL Injection

20. Exemplo
SQLi:
• Aplicação: OcoMon
• Versão: 2.0-RC6
• Bypass de autenticação via SQLi
• Validação de entradas feita client-side

21. Exemplo
• Página inicial filtrando caracteres
especiais através de javascript.

22. Exemplo
• É possível editar a função de validação, ou
impedi-la de ser executada no navegador.

23. Exemplo
• Sem a função de validação é possível
submeter a string admin ‘ or ‘ -- que possibilita
acesso ao sistema.

24. Impactos
• Dependendo do tipo de injeção os danos
causados podem ser:
ü Perda ou corrupção de dados
ü Negação de Serviço
ü Falhas de autenticação
ü Execução arbitrária de código e até
comprometimento total do sistema.

25. Como se Prevenir
• Não utilizar dados não confiáveis em
comandos e/ou queries.
• Rotinas de validação ou “escape” de
caracteres.
• É aconselhável o uso de validação positiva
nas entradas.
• Utilizar canonicalização de dados.

26. Quebra de Autenticação /
Sessão
Principais Ameaças

27. • Restrição de conteúdos / recursos
• Autenticação HTTP:
Basic -> credenciais concatenadas
separadas por “:” e codificadas em base64
Digest -> hash MD5
Definição

28. • Identificadores de Sessão (“SESSION ID")
expostos
• Lembretes de Senha ou “logout” vulneráveis
Definição

29. Exemplo

30. Cookie:
[...]
Authorization: Basic dGVzdGU6ZHVtbXlwYXNzd29yZA==
[...]
Decodificando:
$ echo "dGVzdGU6ZHVtbXlwYXNzd29yZA==" | base64 –d
teste:dummypassword
Exemplo

31. • Tunelamento por SSL
• Políticas de segurança
• CAPTCHA
• Proteger Cookie
Como se Prevenir

32. Principais Ameaças
XSS – Cross Site
Scripting

33. Descrição
• Ocorre quando uma aplicação inclui
dados não tratados em um objeto enviado ao
navegador.
• Existem 3 principais tipos:
ü Stored
ü Reflected
ü DOM based XSS

34. Impactos
• Roubo de informações de sessão
• Pichação de Sites
• Redirecionamento de usuários e etc.
• Exposição de informações dos usuários

35. Descrição
Stored:
• Código injetado é armazenado
permanentemente na aplicação vulnerável
(comentários, posts, logs, etc)
• A vítima recebe o código malicioso junto com
alguma requisição feita.

36. Stored XSS

37. Exemplo
Stored:
• Aplicação: dotProject
• Versão: 2.1.5
• Múltiplas Vulnerabilidades de XSS e SQLi

38. Exemplo
• Na submissão de arquivos é possível
inserir um código malicioso no campo
descrição.

39. Exemplo
<script>alert('xss')</script>

40. Exemplo
• O código então será submetido a todos que
visualizarem a descrição de tal arquivo.

41. Descrição
Reflected:
• O código é “refletido” para o usuário através de
respostas que contenham dados não tratados
recebidos pela aplicação (resultado de buscas,
mensagens de erro, etc).
• Geralmente disseminado através de links
maliciosos.

42. Reflected XSS

43. Exemplo
Reflected:
• Acunetix test site:
http://testasp.vulnweb.com/search.asp
• Aplicação com exemplos de vulnerabilidades

44. Exemplo
Reflected:
• O código submetido na busca é retornado ao
usuário na página de resultado sem nenhum
tratamento.

45. Exemplo
Reflected:
• No caso de submissão de um código html por
exemplo, o mesmo será exibido para o usuário
como se pertencesse a página em questão.

46. Exemplo
Reflected:
• A submissão pode ser feita pels busca:
<br><br>Entre aqui com suas credenciais:<form
action="destination.asp"><table><tr><td>Nome:</td><td><input type=text
length=20 name=nome></td></tr><tr><td>Senha:</td><td><input type=text
length=20 name=senha></td></tr></table><input type=submit
value=Acessar></form>!
• Ou pela URL:
http://testasp.vulnweb.com/search.asp?tfSearch=%3Cbr%3E%3Cbr%3EEntre
+aqui+com+suas+credenciais%3A%3Cform+action%3D%22destination.asp%22%3E
%3Ctable%3E%3Ctr%3E%3Ctd%3ENome%3A%3C%2Ftd%3E%3Ctd%3E%3Cinput+type
%3Dtext+length%3D20+name%3Dnome%3E%3C%2Ftd%3E%3C%2Ftr%3E%3Ctr%3E%3Ctd
%3ESenha%3A%3C%2Ftd%3E%3Ctd%3E%3Cinput+type%3Dtext+length%3D20+name
%3Dsenha%3E%3C%2Ftd%3E%3C%2Ftr%3E%3C%2Ftable%3E%3Cinput+type%3Dsubmit
+value%3DAcessar%3E%3C%2Fform%3E+!

47. Descrição
DOM based XSS:
• Ocasionado por uma modificação no ambiente
DOM do navegador da vítima.
• O código executado é legítimo, porém devido a
essa alteração no ambiente sua execução é
feita de maneira anômala.

48. Exemplo
DOM based XSS:
• O seguinte código é executado no navegador
(client-side)

49. Exemplo
DOM based XSS:
• A variável “name” pode ser manipulada
conforme o exemplo a seguir:

50. Como se Prevenir
• “Escapar” caracteres vindo de fontes não
confiáveis e que serão utilizados no contexto do
navegador (body, atributos, JavaScript, CSS,
URL).
• A validação positiva é sempre interessante mas
é preciso atentar para peculiaridades da
aplicação em questão pois caracteres especiais
e codificações diversas podem fazer parte da
rotina da aplicação.

51. Referência Direta a
Objetos
Principais Ameaças

52. • Apenas proteção na camada de apresentação
não funciona
• Atacante simplesmente altera parâmetros e
consegue acessar o conteúdo
Definição

53. Exemplo

54. Como prevenir
• Trocar referências diretas por um valor de
mapeamento aleatório temporário
• Verificar se o parâmetro está dentro do padrão
• Verificar se o usuário tem permissão de acesso
• Verificar se o usuário pode executar a ação que
deseja em um determinado objeto

55. Falhas de
Configuração
Principais Ameaças

56. • Aplicações rodam em cima de serviços que
rodam em cima de SOs
• Todos podem ser vetores de ataque
• Exploits (e patchs!) se aplicam à qualquer tipo
de software
Definição

57. • “Hardening” de servidores
• Patchs e atualizações
• Homologação de mudanças
• Vulnerability Management
Como se Prevenir

58. Exposição de dados
sensíveis
Principais Ameaças

59. Descrição
• Falha mais comum e grave: simplesmente
não criptografar dados sensíveis
• Falhas quando a criptografia é empregada:
- Geração e armazenamento inseguros de chaves
- Não implantar políticas de rotação de chaves
- Utilizar algoritmos de criptografia fracos
- Utilizar métodos de criptografia em uma só via (hash)
fracos ou sem salto para proteger senhas.

60. Descrição
• Falha em proteger o tráfego de rede onde
passam os dados da aplicação
• Utilização de criptografia somente na
autenticação (expondo dados e IDs de seção)
• Utilização de certificados expirados ou mal
configurados
• Falhas básicas de fácil detecção, bastando
observar o tráfego de rede do site.

61. • Frequentemente comprometem todos os
dados protegidos por criptografia
• Tipicamente, estes dados incluem, mas não
estão limitados à:
- Credenciais de acesso
- Dados pessoais
- Registros de saúde
- Cartões de crédito, etc.
Impacto

62. • Algoritmos de criptografia e chaves utilizados
devem ser apropriadamente fortes.
• Senhas devem armazenadas em hash com um
algoritmo de criptografia em uma só via, forte e
com um salto apropriado.
• Proteger o transporte de dados adequadamente
pode afetar o projeto do site. Em geral, é mais
simples forçar o uso de criptografia em todo o
site.
Como se Prevenir

63. Falha no controle de
acesso
Principais Ameaças

64. Falha no controle de acesso
• Usuário autorizado modifica um parâmetro
ou URL e acessa uma função privilegiada
• Usuário anônimo acessa funções desprotegidas
• Impacto
• Acesso a contas e dados de outros
usuários
• Realizar ações de privilégio maior do que
devido

65. Falha no controle de acesso a
nível de função

66. Como prevenir
• Restringir acesso a usuários autenticados
• Mostrar somente o que for designado ao usuário
ou ao grupo
• Negar qualquer requisição a páginas não
autorizadas
• Não utilizar abordagens de análise automatizada
• Deve-se negar todo o conteúdo (DENY ALL)

67. Cross Site Request
Forgery
Principais Ameaças

68. • Browsers enviam alguns tipos de credenciais
automaticamente
- Cookies
- Cabeçalhos
- Endereço IP
- Certificados SSL
Definição

69. • A vítima acessa um site malicioso enquanto está
logada no sistema vulnerável
• O atacante força a vítima a fazer tal requisição
Impacto

70. Cross Site Request Forgery(CSRF)

71. • Autenticações forçadas em requisições
sensíveis
• Controle exposição de dados utilizados como
credenciais
• Adicionar um token secreto, não automático,
para todas requisições importantes
Como se Prevenir

72. Utilização de componentes
vulneráveis
Principais Ameaças

73. Utilização de componentes
vulneráveis
• Componentes bibliotecas e frameworks
• Demora na divulgação da vulnerabilidade
• Muitos produtores não lançam uma correção
(hot fix)

74. • Monitorar versões de todos os componentes,
incluindo todas dependências
• Manter componentes sempre atualizados
• Organizar uma política de segurança
• Buscar uma alternativa enquanto uma correção
não aparece
Como se Prevenir

75. Redirecionamentos e
repasses não validados
Principais Ameaças

76. Descrição
• Falha em validar o destino de
redirecionamentos ou repasses utilizados
• Problemas mais comuns:
- Ausência de validação do destino de um
redirecionamento ou repasse
- Similaridade entre redirecionamento para destinos
internos (da própria aplicação) e externos

77. l Redirecionamentos podem induzir usuários
a instalar malware ou revelar informações
sensíveis.
l Repasses inseguros podem permitir contornar
controles de acesso.
Impacto

78. l Evitar estas falhas é extremamente
importante, pois elas são os alvos favoritos de
phishers tentando ganhar a confiança de um
usuário.
l Recomendações básicas para utilizar
redirecionamentos e repasses:
- Não envolver parâmetros de usuário para calcular o
destino
- Se não puder ser evitar, validar o parâmetro e verificar
autorização do usuário
Como se Prevenir

79. Dúvidas?
Perguntas?
Críticas?
Sugestões?

80. Siga a Clavis

81. Rafael Soares Ferreira
Sócio Diretor Técnico
Muito Obrigado!
rafael@clavis.com.br
@rafaelsferreira