Título: OWASP Top 10
- Experiência e Cases com Auditorias Teste de Invasão em Aplicações Web
Proposta: Esta palestra visa apresentar exemplos de vulnerabilidades mais comumente encontradas e más práticas de segurança detectadas em auditorias teste de invasão em aplicações web já realizadas e medidas simples que podem aumentar consideravelmente o nível de segurança e evitar incidentes graves em ambientes deste tipo. Além disto, será apresentada também a experiência da Clavis Segurança da Informação enquanto empresa de consultoria especializada ao realizar auditorias desta espécie tanto in-company quanto remotamente.
Cursos e Soluções Relacionados:
Formação de 100 horas – Auditor em Teste de Invasão – Pentest – Academia Clavis Segurança da Informação
http://www.blog.clavis.com.br/formacao-de-78-horas-auditor-em-teste-de-invasao-academia-clavis-seguranca-da-informacao/
Auditoria de Segurança em Aplicações Web
http://www.clavis.com.br/servico/servico-auditoria-seguranca-da-informacao-aplicacoes-web.php
Palestrante: Rafael Soares Ferreira
Sobre o Instrutor: Rafael Soares Ferreira é Diretor Técnico do Grupo Clavis Segurança da Informação, e é profissional atuante nas áreas de análise forense computacional, detecção e resposta a incidentes de segurança, testes de invasão e auditorias de rede, sistemas e aplicações. Já prestou serviços e ministrou cursos e palestras sobre segurança da informação para grandes empresas nacionais, internacionais, órgãos públicos e militares, assim como em diversos eventos, entre eles: FISL – Fórum Internacional de Software Livre, EnCSIRTs – Encontro de CSIRTs Acadêmicos, SegInfo – Workshop de Segurança da Informação, Congresso Digital, Fórum de Software Livre do Rio de Janeiro, Web Security Forum, Ultra SL – Ultra Maratona How To de Software Livre, FLISOL, entre outros. Na Academia Clavis é instrutor dos seguintes cursos: Certified Ethical Hacker (CEH), Teste de Invasão em Redes e Sistemas, Auditoria de Segurança em Aplicações Web,Análise Forense Computacional, Teste de Invasão em Redes e Sistemas EAD, Auditoria de Segurança em Aplicações Web EAD e Análise Forense Computacional EAD. Possui as certificações CEH (Certified Ethical Hacker) e SANS SSP-CNSA.
Gerenciamento de Vulnerabilidades em Redes Corporativas - CNASI RJ
OWASP Top 10 - Experiência e Cases com Auditorias Teste de Invasão em Aplicações Web
1. OWASP Top 10
Principais Vulnerabilidades
em Aplicações Web
Rafael Soares Ferreira
Sócio Diretor Técnico
rafael@clavis.com.br
2. $ whoami
• Grupo Clavis
• Sócio Diretor Técnico
• Detecção e resposta a incidentes de
segurança
• Testes de invasão em redes, sistemas e
aplicações.
4. Descrição
• Ocorre quando a aplicação envia 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
• Mais facilmente por verificação de código.
5. 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.
6. 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.
8. Descrição
• Ocorre quando uma aplicação inclui
dados não tratados em um objeto
enviado ao navegador.
• A detecção pode ser feita via teste de
injeção ou análise de código.
• Existem 3 principais tipos:
Stored
Reflected
DOM based XSS
9. Impactos
• Atacante pode executar scripts no
navegador da vítima para:
Roubo de informações de sessão
Pichação de Sites
Inserção de conteúdo malicioso
Redirecionamento de usuários e etc.
• Além da exposição de informações dos
usuários, tal falha pode denegrir a imagem
da instituição responsável pela aplicação.
10. 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.
16. Definição
Referência Direta a Objetos
• Exposição de informações internas
• Evite Controle de Acesso em camada de
apresentação
Modificações de informações para
acesso a dados não autorizados
17. Impacto
Referência Direta a Objetos
• Evite expor referências a objetos internos
Validação de referências
Mapas de referência
Ex: http://www.example.com/application?file=1
19. Definição
Cross Site Request Forgery
(CSRF)
• Browsers enviam alguns tipos de credenciais
automaticamente em cada requisição
Cookies
Cabeçalhos
Endereço IP
Certificados SSL
20. Impacto
Cross Site Request Forgery
(CSRF)
• 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
21. Como se Prevenir
Cross Site Request Forgery
(CSRF)
• Autenticações forçadas em requisições sensíveis
Controle exposição de dados utilizados
como credenciais
OWASP:
CSRF_Prevention_Cheat_Sheet
23. Definição
Falhas de Configuração
• 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
24. Como se Prevenir
Falhas de Configuração
• “Hardening” de servidores
Patchs e atualizações
Homologação de mudanças
Vulnerability Management
26. 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.
27. Impacto
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.
28. Como se Previnir
Requisitos mínimos para armazenamento
de dados em aplicações web:
− Algoritmos de criptografia e chaves utilizados devem
ser apropriadamente fortes.
− Chaves e senhas devem estar protegidas de acesso
não autorizado.
− Senhas devem armazenadas em hash com um
algoritmo de criptografia em uma só via forte e com
um salto apropriado.
30. Descrição
Falha em proteger requisições da página
apropriadamente
Falhas básicas de fácil detecção, uma vez
listadas todas as páginas (URLs) que
existem para atacar.
31. Impacto
Frequentemente, contas privilegiadas são o
alvo deste tipo de ataque
Uma vez bem sucedido, o atacante pode fazer
qualquer coisa que a vítima poderia fazer
32. Como se Prevenir
• É fundamental ter muito bem definido
o que se trata de informação pública
(não requer credenciais) e privada
(requer credenciais) e então proteger
a informação privada.
• Políticas mais restritivas (block all,
allow some) são mais adequadas que
as mais permissivas (allow all, block
some), pois os casos não previstos
são bloqueados e o acesso é liberado
sob demanda.
34. 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
35. Impacto
Estas falhas expõe dados de usuários e
podem conduzir a roubo de contas.
Se uma conta de administração for
comprometida, o site inteiro pode ser
exposto.
Utilizar de métodos de criptografia mal
configurados também podem facilitar
ataques de phishing e Man-In-The-Middle
(MITM)
36. Como se Prevenir
• É importante que a aplicação não
aceite requisições contendo dados
privados por canais inseguros
• A flag 'secure' dos cookies estipula
que o cookie só pode ser transmitido
através de um canal seguro
38. 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
39. Impacto
Redirecionamentos podem induzir usuários
a instalar malware ou revelar informações
sensíveis.
Repasses inseguros podem permitir
contornar controles de acesso.
40. Como se Prevenir
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 evitar, validar o parâmetro e verificar
autorização do usuário
43. Muito Obrigado!
rafael@clavis.com.br
@rafaelsferreira
Rafael Soares Ferreira
Sócio Diretor Técnico
Notas del editor
Rafael Soares Ferreira é Diretor Técnico do Grupo Clavis Segurança da Informação, e é profissional atuante nas áreas de análise forense computacional, detecção e resposta a incidentes de segurança, testes de invasão e auditorias de rede, sistemas e aplicações. Já prestou serviços e ministrou cursos e palestras sobre segurança da informação para grandes empresas nacionais, internacionais, órgãos públicos e militares, assim como em diversos eventos, entre eles: FISL - Fórum Internacional de Software Livre, EnCSIRTs - Encontro de CSIRTs Acadêmicos, SegInfo - Workshop de Segurança da Informação, Congresso Digital, Fórum de Software Livre do Rio de Janeiro, Web Security Forum, Ultra SL - Ultra Maratona How To de Software Livre, FLISOL, entre outros. Na Academia Clavis é instrutor dos seguintes cursos: Certified Ethical Hacker (CEH), Teste de Invasão em Redes e Sistemas, Auditoria de Segurança em Aplicações Web, Análise Forense Computacional, Teste de Invasão em Redes e Sistemas EAD, Auditoria de Segurança em Aplicações Web EAD e Análise Forense Computacional EAD. Possui as certificações CEH (Certified Ethical Hacker) e SANS SSP-CNSA. Tem especial interesse nas seguintes áreas: Análise forense computacional; Detecção e resposta a incidentes de segurança; Testes de invasão e auditorias de rede, sistemas e aplicações.
As falhas de injeção, em especial SQL Injection , são comuns em aplicações Web. A injeção ocorre quando os dados fornecidos pelo usuário são enviados a um interpretador com parte do comando ou consulta. A informação maliciosa fornecida pelo atacante engana o interpretador que irá executar comandos mal intencionados ou manipular informações Referências: http://www.matped.com/2009/07/injecao-codigo-paginas-php/
Uma referência direta à objeto ocorre quando um desenvolvedor expõe a referência a um objeto implementado internamente, como é o caso de arquivos, diretórios, registros da base de dados ou chaves, na forma de uma URL ou parâmetro de formulário. Os atacantes podem manipular estas referências para acessar outros objetos sem autorização. Referências: http://serdarbuyuktemiz.blogspot.com/2008/09/insecure-direct-object-reference.html
Um ataque CSRF força o navegador da vítima, que esteja autenticado em uma aplicação, a enviar uma requisição pré-autenticada a um servidor Web vulnerável, que por sua vez força o navegador da vítima a executar uma ação maliciosa em prol do atacante Referências: http://www.veracode.com/security/csrf http://www.securitytube.net/video/196
Atacantes tipicamente não contornam os algoritmos de criptografia em si, mas exploram outras brechas que permitem obter chaves ou cópias de dados em texto claro ( backups ), ou acessar dados via canais que descriptografam automaticamente. Dados sensíveis trafegados sem criptografia são capturados pela simples interceptação de tráfego Senhas protegidas por métodos de criptografia em uma só via podem ser quebradas através de “ Rainbow Tables ” Projetos relacionados a Rainbow Tables : http://regenboog.yellosoft.us/ http://project-rainbowcrack.com/ http://lasecwww.epfl.ch/~oechslin/projects/ophcrack
O comprometimento pode ser parcial se forem utilizadas diversas chaves protegendo dados de diferentes tipos. Assim, quando uma chave é comprometida, os dados criptografas com outras chaves permanecem seguros. É importante ter em mente que cópias dos dados ( backups , servidores de teste internos) também devem ser protegidos.
Riscos associados a métodos de criptografia inseguros envolvem conceitos de criptoanálise para contornar matematicamente este métodos e por isto estão fora do escopo da apresentação A escolha do algoritmo de criptografia também depende dos requisitos da aplicação. Um algoritmo considerado não tão forte pode ser escolhido por seu desempenho. Neste caso, é importante trocar regularmente as chaves de criptografia. Métodos de criptografia em uma só via também devem ser escolhidos apropriadamente, pois, geralmente nas aplicações web, o método é aplicado no lado do cliente, de forma que o procedimento que o executa fica exposto.
A falha está relacionada a possibilidade de contornar o mecanismo de autorização da aplicação web só pela modificação da URL. Por exemplo, dado um usuário conectado legitimamente à URL: http://www.aplicacao_web.com/sistema Se este usuário editar a URL e acessar, por exemplo: http://www.aplicacao_web.com/admin Por ele já estar autenticado em “ /sistema ” , ele pode entrar em “ /admin ” ? Ou pior, um usuário não autenticado pode acessar diretamente “ /admin ” ?
O comprometimento não está relacionado a roubo de credenciais de acesso, mas a personificação do usuário ( im personation attack ), onde o atacante se faz passar por outro usuário, tendo acesso à informação que o usuário tem permissão para acessar Uma vez executado o ataque, o atacante terá, provavelmente, a oportunidade de modificar as credenciais de acesso do usuário, mas esta ação é característica deste ataque e sim um produto do mesmo.
É fundamental ter muito bem definido o que se trata de informação pública (não requer credenciais) e privada (requer credenciais) e então proteger a informação privada. Políticas mais restritivas ( block all, allow some ) são mais adequadas que as mais permissivas (allow all, block some ), pois os casos não previstos são bloqueados e o acesso é liberado sob demanda. No caso de acessos automatizados, é importante fazer as verificações corretamente, pois um atacante pode simular um acesso automatizado para contornar os mecanismos de proteção.
A falha diz respeito ao problemas na proteção dos dados trafegados pela Internet. No caso das aplicações web, refere-se ao uso criptografia sobre o protocolo HTTP (HTTPS) Se a criptografia for utilizada somente para a autenticação, o atacante não poderá interceptar as credenciais de acesso, mas poderá interceptar o ID de seção e personificar o usuário ( impersonation attack ), a fim de acessar informações que o usuário tem permissão para acessar
Se não houver nenhuma proteção no transporte de dados, o atacante pode interceptá-los quando trafegam na rede, incluindo credenciais de acesso, informações pessoais, dados da aplicação, etc O uso de certificados auto-assinados é prejudicial à confiabilidade da aplicação e facilita a execução de ataques MITM, que, em geral, utilizam certificados auto-assinados (se o browser sempre apresenta o aviso alertando sobre o certificado auto-assinado, o usuário pode não perceber a diferença entre o certificado usual e o do atacante). É importante proteger também conexões de back end , pois estas podem revelar informações confidenciais ou que podem ser usadas para executar um ataque vindo da rede interna
Para proteger somente os dados privados, é preciso diferenciar os dados públicos dos privados e verificar a transição entre a transmissão de dados públicos e protegidos e vice-versa É importante também que a aplicação não aceite requisições contendo dados privados por canais inseguros, pois um atacante pode modificar a URL da aplicação e enviá-la a um usuário autenticado para interceptar os dados transmitidos por este usuário ao acessar esta URL modificada A flag 'secure ' dos cookies estipula que o cookie só pode ser transmitido através de um canal seguro
A falha diz respeito a manipulação de repasses ( forwards ) e redirecionamentos legítimos presentes na aplicação para destinos arbitrários controlados pelo atacante. Um ataque deste tipo, em geral, é muito similar a um ataque de injeção comum, mas difere quanto ao objetivo A falha de validação pode permitir que o atacante manipule um redirecionamento interno para um destino externo arbitrário
Um atacante pode redirecionar o atacante para um site malicioso a fim de instalar malware , para uma cópia do site para induzir o usuário a inserir suas credenciais de acesso, para um site que repassa requisições para o servidor web original ( Man-In-The-Middle attack ), etc O atacante pode manipular redirecionamentos internos para acessar páginas privadas ou para contornar mecanismos de autorização (escalada de privilégios) Ataques deste tipo contém uma etapa de engenharia social, pois o redirecionamento em si não configura dano obrigatoriamente, mas o que o usuário é induzido a fazer, uma vez redirecionado, que em geral é danosa
Estas falhas são úteis para os phishers , pois o endereço é enviado no phishing scam é, de fato, legítimo, mas redireciona para um destino arbitrário Ao se utilizar valores mapeados (tabelas hash ) só será possível redirecionar para os destinos pré-definidos, assim ainda que o redirecionamento tenha sido manipulado, é mais simples fazer os controles de autorização, pois os possíveis destinos estão restritos aos destinos mapeados. A ESAPI é uma API para desenvolvimento de aplicações web desenvolvida pela OWASP e inclui módulos de validação de entradas, codificação de saídas, autenticação, etc