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/
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
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
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
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.
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.
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.
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.
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.
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
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
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
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
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)
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
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
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