Your SlideShare is downloading. ×
Segurança de Aplicações Web (cont'd)
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Segurança de Aplicações Web (cont'd)

892
views

Published on

Treinamento oferecido pela Oi para prestadores de serviços que atuam no desenvolvimento de aplicações Web.

Treinamento oferecido pela Oi para prestadores de serviços que atuam no desenvolvimento de aplicações Web.

Published in: Technology

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
892
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Segurança de Aplicaçõesversão 2012-03
  • 2. Segurança de aplicações Ementa Parte 1 – Introdução Parte 2 – Riscos em aplicações web Parte 3 – Owasp Top 10 Tes Parte 4 – Encerramento
  • 3. Segurança de aplicações Ementa Parte 1 – Introdução  Apresentação  Motivação  Objetivos Tes  Exemplos de ataques  Segurança no desenvolvimento de software  Segurança de aplicações na Oi
  • 4. Segurança de aplicações Ementa Parte 2 – Riscos em Aplicações Web  Conceitos  Avaliação de risco Tes  Owasp  Owasp top 10
  • 5. Segurança de aplicações Ementa Parte 3 – Owasp top 10  Demonstração  Exemplos  Prevenção Tes Parte 4 – Encerramento  Recomendações Gerais  Conclusão
  • 6. Segurança de aplicações Parte 3 Tes Owasp Top 10
  • 7. OWASP Top 10 – Sequência de apresentação Para cada risco  Exemplo simplificado  Definição  Demonstração  Exemplo “real”  Prevenção  Correção do exemplo
  • 8. Aplicação de exemplo Aplicação de cadastro e visualização de notícias Intencionalmente vulnerável para ilustrar top 10
  • 9. Aplicação de exemplo – arquitetura Classes de domínio, JDBC, DAO Banco de dados MySQL JSP, HTML JSTL, JavaScript Servlets Arquivos de configuração
  • 10. Aplicação de exemplo – arquitetura (cont.)1 – Cliente faz uma requisição2 – Controller requisita dados do Model3 – Model envia os dados ao Controller4 – Controller repassa os dados à View5 – View apresenta os dados ao Cliente
  • 11. Aplicação de exemplo Aplicação de exemplo Tes Demonstração
  • 12. A1 A1 Tes Exemplo
  • 13. A1 – Exemplo Tes
  • 14. A1 – Exemplo (cont.) Tes
  • 15. A1 – Exemplo (cont.) Tes
  • 16. A1 Injection - Características "Injeção" de comandos a serem enviados para um interpretador Interpretadores  SQL  Shell  LDAP  XPATH  Hibernate  etc. Ainda é bastante comum Em geral, impacto significativo (execução de SQL, comando shell, etc)
  • 17. A1 Injection A1 Injection Tes Demonstração
  • 18. A1 Injection – Exemplo real 1Oi Vende
  • 19. A1 Injection – Exemplo real 1Oi Vende (cont.)
  • 20. A1 Injection – Exemplo real 1Oi Vende (cont.)
  • 21. A1 Injection – Exemplo real 1Oi Vende (cont.)
  • 22. A1 Injection – Exemplo real 2Sistema web de votação de Washington
  • 23. A1 Injection – Prevenção Evitar o uso do interpretador, quando possível Utilizar uma interface parametrizada (distinção entre código e dados) Codificar adequadamente os dados de acordo com o interpretador Validar positivamente os dados de entrada Usar bibliotecas especializadas para realizar a codificação e a validação dos dados (e.g. ESAPI, AntiSamy) Executar comandos sob credenciais pouco privilegiadas
  • 24. A1 Injection A1 Injection Tes Correção
  • 25. Segurança de Aplicações Tes
  • 26. A2 A2 Tes Exemplo
  • 27. A2 – Exemplo Tes
  • 28. A2 – Exemplo (cont.) Tes
  • 29. A2 Cross-site scripting – Características Execução de scripts no navegador de outro usuário Tipos de ataque  Armazenado no BD  Refletido através de dados de entrada (campos de formulário, url, etc) Muitas aplicações são vulneráveis Normalmente voltado para roubo de credenciais de sessão ou para redirecionar o usuário para um site malicioso
  • 30. A2 Cross-site scripting A2 Cross-site scripting Tes Demonstração
  • 31. A2 Cross-site scripting – Exemplo real
  • 32. A2 Cross-site scripting - Prevenção Separar o conteúdo não confiável da saída de dados para o navegador Codificar todo conteúdo a ser apresentado no navegador Atentar para o contexto HTML  body, attribute, Javascript, CSS, URL Usar bibliotecas especializadas (e.g. ESAPI, MS Anti XSS) Realizar validação positiva dos dados de entrada Para conteúdo HTML proveniente do usuário: OWASP AntiSamy
  • 33. A2 Cross-site scripting - Prevenção (cont.) Contexto de codificação de dados
  • 34. A2 Cross-site scripting A2 Cross-site scripting Tes Correção
  • 35. Segurança de Aplicações Tes
  • 36. A3 A3 Tes Exemplo
  • 37. A3 – Exemplo Tes
  • 38. A3 Broken authentication and session managementAutenticação em aplicações web  A natureza stateless do protocolo HTTP obriga o envio do session id a cada requisição  O identificador de sessão do usuário equivale às suas credenciais  Se exposto, pode ser reutilizado  rede  logs  navegador
  • 39. A3 Broken authentication and session management CookiesCookies Em geral armazenam o ID de sessão do usuário Proteção do conteúdo  httpOnly  secure
  • 40. A3 Broken authentication and session managementCaracterísticas  Falha na proteção de credenciais (ausência de hashing ou encriptação)  Exposição na URL  Falha nos mecanismos de gerência de credenciais (“lembrar senha”, “trocar senha”)  Possibilidade de ataque tipo session fixation  Ausência de mecanismo de logoff  Timeout de sessão inexistente ou muito alto
  • 41. A3 Broken authentication and session management A3 Broken authentication and session management Tes Demonstração
  • 42. A3 Broken authentication and session management Prevenção Forçar o uso de HTTPS Usar um mecanismo robusto de autenticação Usar um identificador de sessão forte Garantir que a sessão é destruída após o logoff Proteger o cookie com httpOnly e secure Reforçar a proteção contra ataques XSS
  • 43. A3 Broken authentication and session management A3 Broken authentication and session management Tes Correção
  • 44. Segurança de Aplicações Tes
  • 45. A4 A4 Tes Exemplo
  • 46. A4 – ExemploJSP TesHTML
  • 47. A4 – Exemplo (cont.) Tes
  • 48. A4 Insecure direct object references - Características Falha no mecanismo de autorização de acesso Permite o acesso a objetos restritos da aplicação Manipulação de parâmetros para obter acesso a objetos não autorizados Erros comuns  Parâmetros escondidos que referenciam objetos  Ausência de verificação do acesso ao objeto especificado  Verificação realizada no lado cliente
  • 49. A4 Insecure direct object references A4 Insecure direct object references Tes Demonstração
  • 50. A4 Insecure direct object references – Prevenção Usar referências indiretas  Criar um mapeamento entre identificadores e objetos Não permitir acessos diretos a objetos Validar a permissão de acesso do usuário ao objeto
  • 51. A4 Insecure direct object references A4 Insecure direct object references Tes Correção
  • 52. Segurança de Aplicações Tes
  • 53. A5 A5 Tes Exemplo
  • 54. A5 – Exemplo Tes
  • 55. A5 – Exemplo (cont.) Tes
  • 56. A5 Cross-site request forgery – Características O navegador do usuário é direcionado a executar um comando na aplicação vulnerável As credenciais do usuário autenticado são enviadas automaticamente pelo navegador Grande parte das aplicações é vulnerável a este tipo de ataque Impacto: execução de operação/transação com as credenciais do usuário
  • 57. A5 Cross-site request forgery A5 Cross-site request forgery Tes Demonstração
  • 58. A5 Cross-site request forgery – Exemplo realCold Fusion
  • 59. A5 Cross-site request forgery – Prevenção Criar um token aleatório ou criptografado por sessão ou requisição Enviá-lo a cada requisição (e.g. campo hidden de formulário) Evitar o envio do token na URL Validá-lo no servidor a cada requisição Se possível, utilizar tokens diferentes em operações críticas
  • 60. A5 Cross-site request forgery A5 Cross-site request forgery Tes Correção
  • 61. Segurança de Aplicações Tes
  • 62. A6 A6 Tes Exemplo
  • 63. A6 – Exemplo (cont.) Tes
  • 64. A6 Security misconfiguration – Características Problemas de configuração de segurança em qualquer componente da aplicação  servidor web  servidor de aplicação  framework  etc Falta de atualização de software Configuração default Usuário e senha padrão Listagem de diretórios no servidor
  • 65. A6 Security misconfiguration A6 Security misconfiguration Tes Demonstração
  • 66. A6 Security misconfiguration – Prevenção Rever a segurança da arquitetura da aplicação Realizar um hardening do ambiente de produção Criar um ambiente de homologação idêntico ao de produção Implementar um processo de atualização de software Estabelecer um processo de gerência de mudanças Estabelecer um processo de gerência de configuração Realizar uma análise de vulnerabilidades periódica
  • 67. A6 Security misconfiguration A6 Security misconfiguration Tes Correção
  • 68. Segurança de Aplicações Tes
  • 69. A7 A7 Tes Exemplo
  • 70. A7 – Exemplo Tes
  • 71. A7 – Exemplo Tes
  • 72. A7 – Exemplo Tes
  • 73. A7 Insecure cryptographic storage – Características Ausência de criptografia de dados sensíveis Uso de algoritmos fracos Uso inseguro de algoritmos Uso de chaves hard-coded Armazenamento inseguro de chaves
  • 74. A7 Insecure cryptographic storage A7 Insecure cryptographic storage Tes Demonstração
  • 75. A7 Insecure cryptographic storage – Exemplo real Oi Digital – hibernate.xml.cfg
  • 76. A7 Insecure cryptographic storage – Prevenção Criptografar dados sensíveis Utilizar algoritmos comprovadamente seguros de criptografia Usar chaves fortes Fazer hashing de senhas com algoritmo forte e usando salt Proteger chaves contra acesso não autorizado
  • 77. A7 Insecure cryptographic storageExemplos de algoritmos fortes de criptografia Chave simétrica  AES, Triple-DES Chave assimétrica  RSA, DSA Hashing  SHA-2
  • 78. A7 Insecure cryptographic storage A7 Insecure cryptographic storage Tes Correção
  • 79. Segurança de Aplicações Tes
  • 80. A8 A8 Tes Exemplo
  • 81. A8 – Exemplo Tes
  • 82. A8 Failure to restrict URL access – Características Ausência de verificação de autenticação do usuário Ausência de verificação de autorização do usuário Falhas nos mecanismos de autenticação/autorização Erro na configuração desses mecanismos Erro comum: apresentar apenas os links que o usuário tem acesso Impacto: acesso a dados de outros usuários, elevação de privilégios
  • 83. A8 Failure to restrict URL access A8 Failure to restrict URL access Tes Demonstração
  • 84. A8 Failure to restrict URL access – Exemplo real 2 Wordpress – Leitura de posts da lixeira
  • 85. A8 Failure to restrict URL access – Exemplo real 2 (cont.) Wordpress – Leitura de posts da lixeira
  • 86. A8 Failure to restrict URL access – Prevenção Restringir o acesso de usuários não autenticados Implementar mecanismo de controle de acesso em diversas camadas Evitar políticas de controle de acesso hard-coded Negar acesso às páginas por default, liberando de acordo com perfil Usar filtros externos à aplicação (e.g. web.xml) Impedir o acesso a arquivos não autorizados (configuração, logs, fontes, backups, etc)
  • 87. A8 Failure to restrict URL access A8 Failure to restrict URL access Tes Correção
  • 88. Segurança de Aplicações Tes
  • 89. A9 A9 Tes Exemplo
  • 90. A9 – Exemplo Tes
  • 91. A9 – Exemplo Tes
  • 92. A9 – ExemploRequisição TesResposta
  • 93. A9 Insufficient transport layer protection Características Aplicação permite tráfego sem SSL Ausência de SSL após o login Falha na proteção de todo o tráfego (interno, parceiros, etc) Uso de algoritmos fracos Uso de certificados digitais inadequados Impacto: sequestro de sessão ou obtenção de informações sensíveis
  • 94. A9 Insufficient transport layer protection A9 Insufficient transport layer protection Tes Demonstração
  • 95. A9 Insufficient transport layer protection – Exemplo real Facebook – ausência de HTTPS
  • 96. A9 Insufficient transport layer protection Prevenção Usar SSL sempre que possível Usar o atributo Secure nos cookies sensíveis Proteger o tráfego em todas as conexões Usar certificados digitais de ACs reconhecidas Usar algoritmos fortes com SSL
  • 97. A9 Insufficient transport layer protection A9 Insufficient transport layer protection Tes Correção
  • 98. Segurança de Aplicações Tes
  • 99. A10 A10 Tes Exemplo
  • 100. A10 – Exemplo Tes
  • 101. A10 – Exemplo (cont.) Tes
  • 102. A10 – Exemplo (cont.) Tes
  • 103. A10 Unvalidated redirects and forwards Características Redirecionamento de URL baseado em parâmetro da requisição Aplicação não valida adequadamente o parâmetro Impacto: usuário direcionado para site malicioso Forward da requisição para outra página com base em parâmetro Falha na verificação de segurança pode direcionar a requisição para uma outra página Impacto: acesso não autorizado
  • 104. A10 Unvalidated redirects and forwards A10 Unvalidated redirects and forwards Tes Demonstração
  • 105. A10 Unvalidated redirects and forwards – Exemplo realTrac – página de busca
  • 106. A10 Unvalidated redirects and forwards – Prevenção Evitar redirects e forwards sempre que possível Evitar o uso de parâmetros par redirects e forwards Validar os parâmetros  URL relativa à aplicação  URL autorizada para o usuário Mapear o parâmetro para um path no servidor ESAPI: SecurityWrapperResponse.sendRedirect( URL )
  • 107. A10 Unvalidated redirects and forwards A10 Unvalidated redirects and forwards Tes Correção
  • 108. Segurança de aplicações Parte 4 Tes Encerramento
  • 109. Recomendações Gerais Nunca confiar nos dados de entrada Fazer validação positiva dos dados Negar permissões por default Falhar de forma segura Usar o menor privilégio possível Gerar trilha de auditoria
  • 110. Recomendações Gerais (cont.) Cuidado com uploads e downloads Fazer a revisão de código crítico Usar assertivas lógicas Evitar code smells  duplicação de código  excesso de parâmetros  métodos muito longos  complexidade excessiva  classes muito grandes  nomes inadequados  etc
  • 111. Recomendações Gerais (cont.) Exemplo de code smell Oi digital – interface para gerar PDF de faturas public ServicoRecuperaConta ( String tipoConta, String su, String periodoReferencia, String numeroFatura, String meioAcesso, String contrato, String contaFatura, String cj, String ciclo, String cpf, String localidade, String ddd) { ….
  • 112. Conclusão Desenvolver software seguro é uma tarefa complexa Não existe uma solução “mágica” para todos os problemas O reúso de soluções robustas pode ajudar bastante É preciso haver maior interação entre SI e TI Capacitação das equipes é fundamental !
  • 113. Referências Owasp - www.owasp.org Web Application Security Consortium – www.webappsec.org Microsoft SDL – www.microsoft.com/security/sdl/default.aspx SafeCode – www.safecode.org OpenSAMM – www.opensamm.org BSIMM – bsimm.com
  • 114. Segurança de aplicações Obrigado ! Tes